At 20:05 14-11-07 +0000, you wrote: >On 2007-11-14, N. Coesel <[email protected]> wrote: > >> 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 don't see how. Can you provide an example?
Look at the protothreads examples and the defines that make up protothreads. The whole idea is pretty nifty. But I think it is beyond the grasp of a lof of programmers and therefore prone to errors which are hard to debug. >> 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. > >The advantage is that you can structure a protothread as >"normal" thread with linear code that waits in multple places. >With a simple run() function, you've got to explicitly design >and implement a state machine. With protothreads, the state Yes, but the statemachine will have obvious states and will be recognised as such by nearly every programmer. >machine is implicit in the ordering and control flow of the >source code. I find normal C control flow mechanisms >(if-then-else, while, switch, etc.) far, far, easier to read >and maintain that an explicit state-machine with a giant >switch() statement and assignments to state variables that are >in effect just gotos that allow you to create completely >indecipherable paths through the state machine. That depends on how the statemachine is designed, implemented and documented. If pieces of code in a case get too large, move them to seperate functions. Or split the application in several modules. My embedded applications usually consist of several independant (small) modules each with their own initialisation function, run function, commands and 'API'. A statemachine consisting of more than 6 states is very rare in my software. Nico Coesel
