A New component

For Flowcode users to discuss projects, flowcharts, and any other issues related to Flowcode 2 and 3.

Moderators: Benj, Mods

Post Reply
User avatar
goldwingers
Posts: 118
Joined: Wed Sep 06, 2006 1:22 pm
Location: London
Been thanked: 1 time
Contact:

A New component

Post by goldwingers »

Guys, just a thought, as a new component, could we not have a digital square wave input module where the frequency is adjustable, and similarly operated by an ADC - Now that would be useful.

ie if we used an integer giving 0 - 1013 giving 0 -1Khz

also have multipliers of 10 giving 0- 10Khz
100 giving 0 - 100Khz


Ian

canipus
Posts: 31
Joined: Sun Nov 12, 2006 7:33 am
Contact:

Re: A New component

Post by canipus »

goldwingers wrote:Guys, just a thought, as a new component, could we not have a digital square wave input module where the frequency is adjustable, and similarly operated by an ADC - Now that would be useful.

ie if we used an integer giving 0 - 1013 giving 0 -1Khz

also have multipliers of 10 giving 0- 10Khz
100 giving 0 - 100Khz


Ian
I would think also that both of Ben's examples to cater for frequency division would make two very nice input modules; one for frequency division counter on the input and the other the voltage to frequency converter. I think a third option as you're suggesting with a clock value input to a frequency train output with the multipliers would be a great function also.

What I think would be really useful for testing these out would be a square wave generator component for the simulation so we could attach the generator to the input to test the flowchart rather than having to mouse click or keyboard switch an input off and on. Just a simple low frequency square wave oscillator would do for the purposes of hooking up and testing the simulation.

User avatar
goldwingers
Posts: 118
Joined: Wed Sep 06, 2006 1:22 pm
Location: London
Been thanked: 1 time
Contact:

Yea

Post by goldwingers »

Exactly my thoughts, to be able to set a frequency as a square wave input would add so much more flexibity to V3....

If we had a simple sq wave module and a macro for freq division imagine where we could go

You must have one slick finger if you tap at 1Khz Canipus


Ian

canipus
Posts: 31
Joined: Sun Nov 12, 2006 7:33 am
Contact:

Re: Yea

Post by canipus »

goldwingers wrote: You must have one slick finger if you tap at 1Khz Canipus


Ian
I wish... 8)
No what I have to do at the moment is just change the model to working with a few pulses and a small divider. If the concept works with this model then it should be ok with bigger numbers working much faster. ...famous last words :lol:

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Post by Benj »

Hi guys

If you get any code working then send it to me at ben@matrixmultimedia.co.uk

I will add it to flowcode when the SDK component is finished.

Thanks for all your ideas. Your help makes Flowcode great and more powerful.

canipus
Posts: 31
Joined: Sun Nov 12, 2006 7:33 am
Contact:

Post by canipus »

Benj wrote:Hi guys

If you get any code working then send it to me at ben@matrixmultimedia.co.uk

I will add it to flowcode when the SDK component is finished.

Thanks for all your ideas. Your help makes Flowcode great and more powerful.
Ben

I have improved, heavily commented, tested and debugged the Clock input Frequency Divider.
I will send it to you for the benefit of everyone.
I am quite proud of the achievement.
The way it works, translating your short hand, is that the variable number for the divisor integer that is used to compare the clock count, needs to be HALF the required frequency integer divider. IOW if you want the O/P frequency to be a division of 10 of the I/P, then the number for the divider variable is 5 (not 10). That is because you have a count of 5 to toggle the O/P from high to low and then another count of 5 to toggle the O/P from low to high. That one complete clock cycle on the output is taking 10 input clocks. Also, the count compare function needs to be an equals not a gretaer than >.

Unfortunately, there is a drawback in the algorithm, because you can only set up frequency divisor integers that are even numbers. We need to halve the frequency divisor to get the divider integer variable. If we want a frequency divisor of 11 then our divider variable is 5.5 which we can't do, so we're limited to even integers.

The improvement I made gets round this and not only allows choosing any frequency divider integer but also allows you to vary the mark space ratio of the O/P waveform. Your shorthand produces a 1:1 mark space ratio which is what most people will require, but in working around the even only integer limitation, we also got the free added bonus of variable mark space ratios.

The trick is to replicate a second loop counter portion of your shorthand into the other leg after the decision box so as the output register toggles high/low as it alternately goes through two different loop counters. If you make one leg loop counter divider e.g. equal 5 and the other leg equal to 6, then you get one complete clock cycle at the O/P for 11 clocks on the I/P. IOW we now have a frequency division of 11 - an ODD number.
Continuing this theme, by setting up one leg to 10 and the other to 20 we get a frequency division of 30 and 1:2 mark space ratio. If we set one leg up to 2 and the other to 28, we still get a divide by 30 but with 2:28 or a 1:14 or a 14:1 (depending on the edits) mark space ratio. It is totally configurable and there is no limitation on choosing any frequency divider integer. The one small drawback is if you want to divide by an 'odd' integer you cannot get a precise 1:1 mark space ratio but it will be close and for many purposes in electronics it probably won't matter. Many times any analog electronic circuitry following the O/P clock will distort the ratio from a true 1:1 in any case.

Finally, please note I think I have also hit a similar bug during compilation that someone else mentioned on another thread re. the Wait unti xxx macros when using the PIC 12F629 and 12F675. The flowcode compile to ASM function produces a whole string of errors with those two target chips and yet breezes through quite happily with other targets as it should.

Ironically, the 12F targets are the two chips that could probably use the frequency divider the most. If someone wants to make a dedicated single chip divider then they're going to select the cheapest, smallest PIC they can find. At around a buck a piece and only 8 pins these are the chips to use. So if you could fix whatever is wrong with the c translation/assembly for those two chips I think that would be a good move.

I may be totally off wack here but I'm wondering whether there is a problem with the properties for these target being called port A (trisA). The data sheets specifically refer to these port-pins being labelled GPIO.0 GPIO.1 etc. I haven't found a problem usung the devices before in Flowcode but this is the first time I've used the Wait until xxx macros so something must be wrong.

I'll zip and forward the fcf file in the next hour?

regards

canipus

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Post by Benj »

Thanks for the work canipus its greatly appreciated. I have posted the file created by canipus on the website at the following address.

http://www.matrixmultimedia.com/softwar ... ivider.zip

I will look into the problems with the 12F devices and the switch macros. Hopefully I will be able to fix the problem and allow the 12F's to function correctly.

Once again thanks to Canipus for all his work and effort.

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Post by Benj »

The 12F devices load and compile fine as long as you are using the ports available on the chip. The GP I/O pins are refered to in Flowcode as PortA. As long as you are reading and writing to pins on portA the program will work. When using a pre made program like the one sent to me by Canipus, before it will let you select the 12F series of chips you have to switch all I/O to portA. Then it will let you change the chip and it will compile correctly.

I do not have a 12F chip available here to test that it works when on the chip so if somebody could test this for me that would be appreciated.

canipus
Posts: 31
Joined: Sun Nov 12, 2006 7:33 am
Contact:

Post by canipus »

Benj wrote:The 12F devices load and compile fine as long as you are using the ports available on the chip. The GP I/O pins are refered to in Flowcode as PortA. As long as you are reading and writing to pins on portA the program will work. When using a pre made program like the one sent to me by Canipus, before it will let you select the 12F series of chips you have to switch all I/O to portA. Then it will let you change the chip and it will compile correctly.

I do not have a 12F chip available here to test that it works when on the chip so if somebody could test this for me that would be appreciated.
Ben

The 12F devices do NOT compile with the Wait until xxx macros. I just retried setting all the switches to the PortA.x for the frequency divider and it makes no difference. Those devices will not compile.

The proof is I have just changed the frequency divider fcf file by replacing those macros with discrete function block that do the same job, and now the fcf file does compile.

I have e-mailed you the updated file because I also made a couple of other important improvements.

text follows:
11th January 2007 Frequency Divider 2

The following changes have been made since Freq. Divider 1
that have made the flowchart more universal to a wider range of PICS.

1. The Wait Until High/Low xxxx macros have been replaced with alternative code blocks. The Flowcode file will now compile with the 12Fxxx processors as well as the 16Fxxx. There is a bug in these macros as of the current date that creates errors compiling with the 12Fxxx chips. When the macros were replaced with discrete function blocks the compile errors disappeared.
Part of the solution necessitated the creation of an extra variable for the processor I/P pin making 5 variables in total.

2. Some of the existing variables were accidentally left as 'BYTE' variables limiting the frequency divider to 2 x 255 (510 divisor). These have now been corrected to 'INTEGER' variables allowing the frequency divisor to be set from 1 to (2 x 32767) 65534.

With a crystal controlled clock of 1 MHz to the i/p pin, you can get an o/p frequency as low as 15.259Hz.
With a 32.768KHz i/p clock you can get a crystal controlled o/p signal as low as 0.5Hz in a single 8 pin PIC without using interrupts.
A dedicated 1 second timer can be easily produced for the cost of a 12F629 and 2 crystals; (one for the processor, and the other for the 32.768KHz i/p timebase).

--------------------------------------------------------------------------------------

User avatar
goldwingers
Posts: 118
Joined: Wed Sep 06, 2006 1:22 pm
Location: London
Been thanked: 1 time
Contact:

sdk

Post by goldwingers »

Ben,
I seem to remember that the SDK module production tool was available once upon a time, Is it still available or will the new version be free, to allow us into flowcode build modules which can be freely available as add ons?

Ian

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Post by Benj »

We will look into the 12F devices and try to find out why they wont compile on some machines. They seem to work fine here. I believe there will be a SDK available in the near future however Steve will need to confirm this.

Canipus's second version of the frequency devidor program can be downloaded from the following link.

http://www.matrixmultimedia.com/softwar ... ider_2.zip

Mark
Posts: 209
Joined: Thu Oct 19, 2006 11:46 am
Location: Bakewell, UK
Has thanked: 20 times
Been thanked: 16 times
Contact:

Post by Mark »

Benj,

I had some contacts with Steve a while ago on 12F problems and in my instance it all boiled down to the need to define not only the ADC usage on start up but also the capture compare. Once CMCON was also defined the input outputs worked fine.
Go with the Flow.

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Post by Benj »

Thanks Mark

Any chance you could post the code used in the definitions so other users can get these chips working.

canipus
Posts: 31
Joined: Sun Nov 12, 2006 7:33 am
Contact:

Post by canipus »

Mark wrote:Benj,

I had some contacts with Steve a while ago on 12F problems and in my instance it all boiled down to the need to define not only the ADC usage on start up but also the capture compare. Once CMCON was also defined the input outputs worked fine.
Mark

Unfortunately that is not the entire story. It doesn't all boil down to disabling the A/D comparators and disabling the A/D convertors (i.e changing the analog inputs to all digital). There is also a problem with the switch input macros Wait until xxxx. I have sent Ben code of a simple frequency divider circuit that will not compile with the inclusion of those macros but when those macros are replaced with discrete flow block that replicate those macros the flowcode will compile EVEN THOUGH THE A/D AND CMCON FUNCTIONS HAVE NOT BEEN TAKEN CARE OF. The difference is purely eith the inclusion or the exclusion of thos specific macros. The code is posted on the web site both with and without those macros. You can try it for yourself and see.

Mark
Posts: 209
Joined: Thu Oct 19, 2006 11:46 am
Location: Bakewell, UK
Has thanked: 20 times
Been thanked: 16 times
Contact:

Post by Mark »

Benj,

The change that correctly configured _cmcon for all digital inputs was to use D'3' rather than D'7' (which was what Flowcode used at the time). I recall that this did not match well with the data sheet but it did the job. The reason I tried it was that I recall it was mentioned in a Microchip seminar. (ps. sorry, the e-mails were with Ian not to Steve).

Canipus

I have no reason to disbelieve you, this was an 'in my instance' comment to add to the pot. Thanks for the comments you've been posting.
Go with the Flow.

Post Reply