FINITE STATE MACHINE library just ported

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:

original library:

original example:

What inspired me to start using FSMs in my projects is this post:

let me know if you find something out of place please


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


My alarm clock project uses Alexander Brevig’s FSM library. I also used it on a previous Teensy project. I really like that library!

1 Like

Great work :tada: Thanks @gusgonnet :sparkles:

1 Like

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.

1 Like

I agree to that

hehe, you made me google for KISS. Now what did you mean with C versus C++ and with the FSMs being reentrant?

Not the band!

yeah, that one I got! :smile:

the part I did not get was this one:

what did you mean by C and no C++ and by reentrant FSMs?


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.

1 Like

good to know! thanks for the explanation