N. Coesel wrote:
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.
In here lies the catch: state machines that are used to implement flow
control are often not formally specified and are often not documented.
If they are designed ad hoc by the programmer (which they often are),
they may also have difficult-to-find bugs.
Even a small state machine (3 - 6 states, 4 - 8 transitions) can be
really difficult to understand. The problem isn't the size of the code,
but that the interplay between the states is not visible in the code.
/adam
--
Adam Dunkels <[email protected]>
http://www.sics.se/~adam/
