5.3State-transition design & event-driven programming

An embedded device behaves by moving among a limited number of states, such as power-off, booting, standby, running, and fault. If you implement this without clearly organizing "which state am I in now, and on what event do I move to which next state," the device can hang or misbehave under an unanticipated combination of inputs. This section covers methods for systematically designing states and how to choose the way the system reacts to external events.

5.3.1State-transition diagrams and tables

• A state-transition diagram depicts the states a device can be in as circles (nodes) and the moves between states as event-labeled arrows (edges). It makes the overall behavior easy to survey visually, but as the number of states and events grows, the diagram becomes cluttered and omissions (undefined transitions) are easy to miss.
• A state-transition table is a matrix with "current state" on the vertical axis and "possible events" on the horizontal axis, with each cell recording the "next state (and action to take)." Because it mechanically fills in every combination of state times event, it can systematically detect the kind of gap—"what happens if this event arrives in this state is undefined"—that a state-transition diagram tends to miss. In level-4 embedded design, the more complex the device, the more emphasis is placed on exhaustively enumerating transitions via a table.