I like that idea!  And since some PICs have an "unadvertised"  4-bit D/A,
this suggests a zero-added-parts option that I may try out someday, just to
do it.

I'm encouraged to see that some people stick to the dirt-simple method of
timer flags and explicitly coded switch statements as state machines.  This
technique has worked very well for me.  Any application that needs far less
time that the processor provides is well adapted to this.  And the
processors just keep getting faster (with more memory) anyway.  There are
even cases where there's one time critical task, and that can be handled
and still leave left over time for all the slow running stuff to get done
as well.   I imagine DSP work wouldn't fit well here.

I have inherited other people's "task" designs, and they did work and were
somewhat fun to use.  But they didn't really accomplish anything that I
couldn't figure out how to do otherwise.  And then we have the embedded
OSes  with the threads.  And the programmers end up with their threads
locking out the other threads so nothing bad happens.  So then it performs
the same as any of the preceding schemes.  But they're trickier to manage.

Your outlook will, of course, differ.



On Fri, Apr 19, 2013 at 9:30 AM, Joe Wronski <jwronski@stillwatereng.net>wr=
ote:

> For tweaking the amount of code executed in each state machine, it can
> be useful to use a D/A converter, or a few (3) bits driving an R2R
> ladder.  Say you have 5 tasks in your main loop:
>
>
> int main() {
>      // initialize stuff...
>      while(1) {
>          one_machine();
>          two_machine();
>          ...
>          five_machine();
> }
>
> You can assign each machine an int value, and start each machine's
> routine with an assignment of it's value to the D/A or R2R port. You can
> watch the D/A or R2R with a scope, and learn how the work is being
> distributed among the machines, and adjust code based on that.
>
> #define ONE_VALUE 1
> one_machine() {
>          r2r_port =3D ONE_VALUE;
>          // work...
> }
>
> I don't recall where I first heard of it, but I've used it and it was
> useful.  If focusing on a single machine, you can use the same technique
> for each state in the machine.
>
> Joe W
>
>
> On 4/19/2013 3:23 AM, Veronica Merryfield wrote:
> > I have used a state machine based co-operative multitasking approach in
> many systems. The main code is a loop calling each task state machine,
> which is a large switch statement, usually. Finding the right size of blo=
ck
> and unrolling loops can get tedious and it can look messy but it does wor=
k
> well. I have had such systems deal with timers and comms, the interrupt
> handles just raise flags and the code in the state machines handles thing=
s.
>
>
>
--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.