Time- and Stack critical processes

[Jan Lichtenbelt]

Hi All,

Programming a microcontroller can be done on machine level or with a higher programming language. Flowcode is an example of this last one. But to get Flowcode really work in a microcontroller it has to be translated in machine codes. Matrix Multimedia made this possible for you in a very good way. They improve it all the time (like new free of charge versions) with the aim of others like you all in this forum.

You can follow the translation process of Flowcode into the microcontroller, because next to the Flowcode, also the C-version and the assembler version of the original Flowcode are available. Both the C-program and the assembler code can be changed by yourself.

Time critical processes
If time is critical, it is the question if the Flowcode delay is as accurate as it shows? The delay are realised by waiting an amount of programming steps. There are 3 points of care:
1) the crystal frequency
If the crystal frequency will be 20 MHz with a time period of 50 nsec, the programming step duration will be 50*4= 200 nsec (0.2 usec). In that case a 1 usec delay is simple 5 programming steps. However, if the crystal frequency is not a nice number, like eg. 19.6608 MHz, an integer delay time can never been realised. A programming step will be about 203 nsec and an “1” usec delay will be 1.017 usec in reality.
2) The delay subroutine
The delay subroutine of eg. usec is indeed 5 programming steps long, including subroutine return time (2 steps) but excluding the program call time (2 steps). These 5 programming steps will take 1 usec (see also point 1).
I tried to find the number of steps for 1 msec and found (7+245*20+18)=4925 programming steps, including the call and return of the subroutine, which will give a delay of 1.001 msec with a 19.6608 MHz crystal. Not bad, but not exact.
3) Pre subroutine steps
However, the delay subroutine call takes 2 programming step and to save the number of usec wanted, will take an other 3 additional steps. That means a 1 usec call in Flowcode will take 5+5=10 steps, is about 2 usec. And a N usec delay takes 5N+5 steps or N+1 usec for N= 1,2…until 255. Pay attention 0 usec delay takes 9 programming steps or about 1.8 usec!
Remark added Aug 11, 2011: For time delays > 255 usec an additional 5 programming steps are used (or 1 usec), for > 511 usec 10 steps (2 usec) and > 767 usec 15 steps (3 usec).
For the msec delay I found an additional 7 to 8 programming steps plus the 2 steps for the delay call, which is about 2 usec additional delay, which is small compared to the msec delay. Here also 0 msec delay takes 8 programming steps or 1.6 usec.

Stack critical processes
If stack is critical, look at the assembler file and you can figure out yourself which variables are not necessary. Just delete them. Flowcode and C place a lot of unused variables in the assembler file. Also additional (safety) programming steps can be deleted.
Deleting variables, you have to do that with some care. But that holds in general when using assembler programming which much less debugging possibilities compared to C or Flowcode.
Changing the assembler file can be done by learning assembler or just by trial and error. But I do not recommend that if you use the microcontroller in critical processes. For hobby that is ok.

This all learns the possibilities and restrictions of the use of Flowcode and C by looking more in detail to the derived assembler file.


Jan Lichtenbelt