Hi,
I just finished porting the wonderful FSM library from Arduino.
you can find it by the name of FINITESTATEMACHINE in /build, and the source code is here:
@gusgonnet, I tend to use switch/case statements for my FSMs, especially when I have more than one on an app. I’ll need to see how I could use this library. Thanks for porting it!
I never used FSMs before, I have always used status variables and flags of other sorts all over my code.
One strong point about this library in my opinion is that you can define three functions per state: enterFunction , updateFunction , exitFunction
They automatically get executed when, well, the said state enters, it’s looped on and exits. This simplified my life immensely, once I got to understand the way it works.
If you change your mind and need to add a state down the road in your project’s life it becomes so much easy, I now believe.
I’ll try to publish soon my version of an example to illustrate this behavior better.
Gustavo.
I’ve used FSMs professionally for many years.
C switch with case. I keep the code for each case to about 6 lines each; more, I use a function call. Keep code easier to read.
FSMs are also more self-documenting than a mess of globals and flags.
I often have several FSMs and a top level that just calls them all from a loop, usually.
I don’t usually have all the extra functions as in the library as in the lib. I like terse code, lots of comments.
And for most embedded work, I use C, not C++. KISS.
The FSMs are reentrant in my code.
Opinion alert:
In my professional work, I avoid C++ on small embedded where I can. This is because using the heap and dynamic memory allocation and de-allocation (malloc(), free(), new, delete) and garbage collection are too risky for most embedded projects.
With static class instances (not run time), the risk goes down. And one must not do I/O in a class constructor or destructor for fear of hangs, etc.
The list goes on, for why C++ is risky for embedded.
=====
Reentrant code for FSMs… if you think an FSM might be have several instances of the same code, instead of C++, I use C and pass to the FSM at initialization a pointer to a block of RAM of agreed size, or a compile time defined struct. The FSM keeps all of its variables in that. Thus it’s reentrant and the same code can run many FSMs that do about the same thing.