N. Coesel wrote:
Hello all,
I would like to issue a bit of warning here and ruin the party a little :-)
I've looked at protothreads myself and decided not to use them. My main
reason is that it will make the code very hard to maintain because
protothreads hide the way various 'processes' are working together.
I am not sure, but it sounds that you are referring to Contiki (which
uses protothreads to implement its processes) and not the protothreads
mechanism as such. Protothreads do not define the notion of a process.
In fact, protothreads do not at all define how the protothreads are
invoked. It is up to the surrounding code to invoke the protothreads.
Contiki provides such surrounding code, but protothreads are often used
on their own, without Contiki.
Or maybe I am missing something?
Besides, since protothreads offer no time-slicing, there is no advantage
over making modules each which an 'init' and a 'run' function. The run
function is being called from main repeatedly for every module. This setup
will make the code much easier to follow and maintain.
The advantage with using protothreads has nothing to do with
time-slicing, but is that you can write sequential code (that uses if
and while constructs) rather than explicit state machines.
If the 'run' function implements some form of higher-level logic that
cannot be expressed as a single one-shot function invocation, the 'run'
function must be rewritten as an explicit state machine. Such state
machines are typically not formally specified, difficult to write, read,
and maintain.
By using protothreads in the 'run' function, the code can be made
sequential and not split across different state handlers.
/adam
Nico Coesel
At 19:59 14-11-07 +0100, you 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). 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.
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.
/adam
[1] Adam Dunkels, Oliver Schmidt, Thiemo Voigt, and Muneeb Ali.
Protothreads: Simplifying event-driven programming of memory-constrained
embedded systems. In Proceedings of the Fourth ACM Conference on
Embedded Networked Sensor Systems (SenSys 2006), Boulder, Colorado, USA,
November 2006.
http://www.sics.se/~adam/dunkels06protothreads.pdf
http://www.sics.se/~adam/dunkels06protothreads.ppt
[2] http://www.sics.se/contiki/
--
Adam Dunkels <[email protected]>
http://www.sics.se/~adam/
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
--
Adam Dunkels <[email protected]>
http://www.sics.se/~adam/
