Harold Hallikainen wrote:

> I often end up writing menu systems using state machines where, depending
> on a user action, a state is set. We then return to mainline code. The
> next time the menu system is called, it checks for a key. If one was
> pressed, it evaluates it based on the current state. This gets rather
> messy because I have to define all these different states. I like being
> able to have a wait loop in my code where it's just waiting for the next
> user input, but, while waiting, it goes off and does other stuff. I've
> written stuff where there's a NextTask() function that saves away the
> current stack, reloads the stack with the contents for the next task, then
> runs it until a NextTask() is hit. All functions run until they hit the
> NextTask(), which is generally until we get to a point where we are
> waiting for user input.

To accomplish the same thing with threads replace the NextTask()
with a boolean flag or status word and create a thread out of the following
code conditioned on flags and wait for key. For processors that
don't have stack access this may be one of the few solution.

Harold, I am not arguing against what you did or its implementation
just presenting a very small processor low overhead alternative.

It is possible that a NextTask() macro could be written to create threads
directly out of co_routines.

BTW Nice piece of code


w..


-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist