In the early times of computer programming, 'spaghetti code' was a term often used (correctly) to describe typical source code and its unmanageability. Fortunately, formal structured methods were eventually developed to offer some organization to this arcane process. However, the challenge to organize logic into manageable patterns continues to persist today. You should now recognize that this is why Finite State Machine concepts are so useful. FSMs allow you to organize your logic into independent blocks of event-action-transition logic that are easy to design, debug, document and verify. In fact, one could consider all embedded systems, in particular the software, as Finite State Machines, whether explicitly designed as such or not. It is very conceivable that, upon reviewing non-FSM-based embedded source code, state behavior could be determined and proper partitioning would likely be indicated. So, why aren't FSM concepts used more frequently in embedded system software?...Is it due solely to lack of knowledge or training?... or is it the fact that most embedded systems still use a commercial or open-source RTOS? They work, but at what cost?

Multitasking, kernals, schedulers, code re-entrancy, mutexes, inverted priorities, arbitrary partitioning, context switching...ugh!...and now Finite State Machines? Yes, but you won't need that RTOS at all. Staccato™'s 'system of Finite State Machine-encoded tasks' allows for direct execution without an RTOS. Staccato™ is an RTOS alternative.

If you think you would benefit from using Finite State Machines in your embedded project software, discuss it with your team members and suggest it to your manager. The Staccato Crossroads SDK provides individual IEEE-CEU Certified Training and many examples of how to architect your embedded system software.