My project is currently a soup of mixed IF ELSE statements that can be hard to follow as all the different “rules” are applied and moving through the states. I essentially have (6) modes/states that have been wrapped into functions that are managed via a Case stement in the main loop (ala RGBPongClock) and the transitions are buried at the top of those functions to allow for nearly any state to transition to another state. A little research has led me to Finite State Machines (FSMs) but I also see a lot of people pointing to ID3 and similar decision trees. The inputs that determine state are well defined/known. Given my system isn’t trying to solve for “known unknows” would the effort of a decision tree vs a FSM be worth it?
Way outside anything Particle specific but I will be porting a lib for the method I ultimately choose which might help someone else out.
I’ve used simple finite state machines (FSM) for many embedded projects. I often have several FSMs and an executive infinite loop that calls each FSM and does whatever non-FSM work is needed.
Each FSM does what it needs to in whatever state it is in and returns as quickly as possible. If the FSM has no work or is waiting for a flag from an ISR or some such, it uses a check-flag and if false, return. Polling without a busy loop that owns the CPU. Each FSM can be a switch statement. I like that as it’s easier to read than a string of if then’s. Each FSM will need module-level or function-level statics for persistent variables.
You can use multiple FSMs cleverly and avoid needing an RTOS.
This list of FSMs scheme is similar to the popular single-stack, run-to-completion scheduler. Single-stack is so much better. And avoiding the mutual-exclusion complexity of a preemptive scheduler for most embedded systems work.
I know I’m not giving tons of detail but my project is analogous to a “smart” thermostat or the Rachio Iro sprinkler controller. Is a decision tree appropriate for such a thing? I think FSM is the way to go for my needs and will probably nest multiple as each state my have a “sub-state” depending on user input. So a top level FSM controls the highest level of state with each sub-state being switched by a mode specific FSM. Mode states don’t switch but a few times a day so an infinite control loop looks over the system, collects data, initiates new states based on condition changes or user input. Does that sound like an appropriate approach? And as a side note: I’m looking for a partner on said project and need experienced people to join the team. Msg me if you are interested…equity stake, cash if you are cheap (gotta work with what I have) and will be a “side thing” until it’s at a self sustaining level.
I recommend using FSMs with a switch statement.
After you master that simple code, you may or may not want the elegance but
abstraction of the ID3. I prefer FSMs because the code and logic is
simple to follow. Even a long time later.
I’ve done decades of embedded work and I’ve never had an FSM that had more than 2 or 3 possible next-states. And most of the alternative next-states are when errors occur. Most have just one next-state, since the current state is just waiting for a condition (flag or data arrival) or time delay or some such.