On 2007-11-14, Adam Dunkels <[email protected]> wrote:
> Grant Edwards wrote:
>> On 2007-11-14, Grant Edwards <[email protected]> wrote:
>>
>>> Is anybody aware of a lightweight coroutine implementation for
>>> mspgcc? The yield operation would need to be implemented
>>> without disabling interrupts...
>>
>> Protothreads looks promising:
>>
>> http://www.sics.se/~adam/pt/
>
> Yes, protothreads do not require any interrupt-disabling code
> (or any other low-level code for that matter - no assembler,
> no stack manipulation, etc - protothreads are pure C).
I guess I shouldn't be surprised that Adam reads this group
considering the original protothreads paper talked about
low-power wireless sensor nodes. :)
I see that the gcc "pointers to labels" implementation is what
is used by default (which removes the restriction on using
switch() statements in a protothread).
> The memory overhead is very low: only two bytes per
> protothread. Beware, however, that because protothreads are
> stackless, local variables are not stored across a blocking
> wait. Either use static local variables or pass around a state
> struct like event-driven programming.
Yup. That'll take a little getting used to, but hopefully gcc
will warn me if I forget. In practice very, very few of the
tasks I write ever need to be re-entrant, so static locals for
persistent stuff are are fine.
> The overhead or protothreads compared to an explicit
> switch()-based state machine is a few cycles so protothreads
> can even be used in time-critical code such as interrupts [1].
> We're using them in Contiki [2] for a bunch of different
> purposes ranging from low-level radio framing protocol parsers
> (inside an interrupt handler) to the high-level process
> structure of Contiki.
I think it's going to fit my application very well. I've got
I've also got a fairly minimal amount of RAM to play with and
some low-level interrupt-driven stuff that runs in the
background which can't tolerate any extra interrupt latency at
all. IOW: no disabling interrupts and no multiple stacks. But,
I've got a couple different independent "threads" that need to
run in the foreground using some sort of cooperative
multitasking, and making them all into explicit state-machines
would be messy. They'll be much easier to write as implicit
state-machines using protthreads.
--
Grant Edwards grante Yow! My CODE of ETHICS
at is vacationing at famed
visi.com SCHROON LAKE in upstate
New York!!
