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.
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.