> 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
> block and unrolling loops can get tedious and it can look messy but it
> does work 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 things.

Multitasking is an INTERESTING subject! Years ago, I wrote about a simple
multitasking system for the PIC18 (see
http://www.piclist.org/techref/microchip/language/c/MultiTask.c.htm ).
Also, back when the 80286 was new, I wrote a system that kept a separate
stack for each task. Each task would call NextTask() while waiting for
I/O. That would save the current stack pointer and load it with the one
for the next task in the loop, then do a return.

Another area of interest is intertask communications. In the 286 system,
each task had an input FIFO. Any other task could put complete messages
(no partial messages allowed) in the FIFO of another task. When the
destination task was reached, it would "run to completion" on any message
that was in its input FIFO.

The handling of I/O is also interesting. The main thing about I/O, as far
as I'm concerned, is that it happens randomly and won't wait. However, if
the I/O device itself has "large enough" FIFOs, the device does not need
to be dealt with on an interrupt basis. Often an I/O interrupt is putting
data from a device into a FIFO for non-interrupt code to deal with or
outputting data that the non-interrupt code has put in an output FIFO.

A lot of my work is currently on PIC32s. I use a lot of state machines.
The original post that got this thread going dealt with pretty much
automatically generated state machines. But, I find switch/case state
machines pretty easy to deal with and make the code more readable. If each
state has a reasonable name, it makes it clear why we're changing state
and will do something else on the next call of this task. Static local
variables keep track of stuff we need between calls of the task while
automatic locals (of course) are used only during one call and are
discarded on exit.

So, interesting discussion. I'm learning stuff.

Thanks!

Harold


--=20
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!
Not sent from an iPhone.
--=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
.