Very nice! Anything that allows something more sophisticated than switch:case in embedded systems are welcome! Also, state machines are way too often overlooked as a proper model for embedded systems architecture. My guess is that proper implementation may become hard (specially if you want to nest them), and there are lots of hardware engineers doing firmware.
In my case, when I want to use a state machine for a project, I usually go with Quantum Leaps [1] tools.
Nowadays their website seems cluttered and management-focused, but the tech is solid and the tools are very robust.
They also distribute a book [2] on how to use the model using their framework as an example, and I even implemented my version of it as an exercise years ago.
It does not have (or did not, I haven't checked in the last few years) a tool to translate from XMI to their framework, but they have a freeware to draw the chart. Frankly, I have not even used it: I draw the state machine using some editor and it is easy enough to translate to code and maintain. Maybe not the best, but up until now, very nice to deal with the limited complexity of most embedded systems.
I second the use of statemachine for embedded systems.
They’re particularly ideal for embedded systems. The limited ram in many embedded systems makes a full dynamic language difficult to fit but a state chart interpreter can be very minimal while production runs can be compiled directly to code. Memory management in state charts can often be much easier to handle.
There’s also a lot of benefit to describing valid states for your system both in terms of correctness and the ability of algorithmically finding an optimal reduced state machine.
Personally I am fond of SCXML as it’s fairly concise, can include code snippets, and has a relatively well documented standard easy to display by converting to Vue/React/WebComponents. XMI with its connection to UML didn’t seem appealing to me, but this project seems pretty robust!
> They’re particularly ideal for embedded systems.
While I agree, I think this promotes the idea that they're only good for embedded systems, especially small ones. State machines are not always the right tool for the job... only most of the time :)
State machines(or DFAs for you CS guys) are used all over. For instance, AFAIK, grep is generally implemented with a state-machine, albeit one which is dynamically constructed at run-time(which is a pretty cool concept if you ask me).
True! Statecharts are handy in lots of domains. Embedded happens to be a prime target due to the memory constraints combined with often limited behavioral requirements.
IMHO, most websites / UI's implement half of a poorly understood state machine (to roughly paraphrase the Common Lisp quip). Qt apparently also has an interesting statechart engine as well: http://blog.qt.io/blog/2017/01/23/qt-scxml-state-chart-suppo...
Depending on the application, I'll use a Finite State Machine pattern, but if I need something more complex I'll use QM QP/C (which is uses a hierarchical state machine pattern).
So it's good to see others using Quantum Leaps RTOS. It take a little bit to set up the environment and understand some of the bounds, but I really enjoying using their QM Modeling tool[1], I would recommend it. I would mainly use it for the logic and abstract out the code in separate files, so that you are not maintaining code in the GUI tool.
I went to the Quantum Leaps site to check out their run-to-completion scheduler(s), one of the rare RTOS alternatives out there. They seem to have an incredible vision, yet, unfortunately, the site and the books make you want to stop reading and go alone.
The site was not that bad a few years ago, but I guess this new structure sells better for some companies.
At the time, I actually bought the book and I liked it. It was a bit dense in the beginning, and I skipped the example, but I had some good takeaways, specially on the implementation of the system, which is described in the book.
A must read for anyone interested https://statecharts.github.io/ Also I highly recommend to check out `xstate` TypeScript library. It's a breeze to work with it.
Can't stress how great that resource truly is in understanding statecharts, which are state-machines but with lots of extra details that actually make them usable at scale in large projects.
On the topic of state-machines, there are some really cool typed libraries out there. The ones that stand out are motor[0] for Haskell and ST[1] for Idris.
There are so many FSM implementations. The problem is when you want to implement something like this in different platforms, one has to "change the engine" along with all the connectors. Why not to use something standard like BPMN as the base?
Thanks for sharing this. I really like the idea of being able to extract the state machine from a higher-level spec you've included here. The DHCP client example especially is really nice.
It's true that embedded software doesn't need to be written in C but if you're distributing a _library_ that's aimed at embedded systems then C is still a terrific choice for a ton of reasons. The goal of a library should be to embrace the path of least resistance for adoption. And when you're working in the embedded space that means targeting the least common denominator. Are all embedded systems extremely resource constrained? No, but many are. Do all applications running on embedded platforms need to be real-time? No, but many do.
Writing in C means you can get small binaries, with minimal runtimes, easy control over things like memory allocation, and if you want to use the library you don't have to write C because almost any language with any form of FFI is going to target C before it targets C++.
In my case, when I want to use a state machine for a project, I usually go with Quantum Leaps [1] tools. Nowadays their website seems cluttered and management-focused, but the tech is solid and the tools are very robust.
They also distribute a book [2] on how to use the model using their framework as an example, and I even implemented my version of it as an exercise years ago.
It does not have (or did not, I haven't checked in the last few years) a tool to translate from XMI to their framework, but they have a freeware to draw the chart. Frankly, I have not even used it: I draw the state machine using some editor and it is easy enough to translate to code and maintain. Maybe not the best, but up until now, very nice to deal with the limited complexity of most embedded systems.
[1] https://www.state-machine.com/doc/concepts#HSM [2] https://www.state-machine.com/psicc2/