What's changed: Initial version
5.3State-transition design & event-driven programming
Covers state-transition diagrams/tables for organizing embedded-device behavior, the trade-off between the event-driven approach, which reacts to external input, and the polling approach, which checks state at a fixed interval, and designing for exhaustiveness and exception transitions so no undefined transition is left behind.
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.
5.3.2Choosing between event-driven and polling
- Event-driven processing calls the corresponding handler at the moment external input (an interrupt, a received message, etc.) occurs. While no input is occurring, the CPU can be freed for other work or a low-power state, giving good power consumption and CPU efficiency. On the other hand, if handling is missing for an unanticipated combination or ordering of events (e.g., a communication-request event arriving while initialization is still incomplete), misbehavior is likely.
- Polling actively checks state or flags at a fixed interval. It is simple to implement and reliably captures state changes within the check interval, but tends to be disadvantageous in power consumption and responsiveness, since no other processing can occur during the interval (it occupies the CPU), and events that occur and clear faster than the interval can be missed. Event-driven is often favorable for battery-powered devices, but polling is sometimes used alongside it where certain periodic monitoring is required (e.g., safety monitoring of a sensor).
Most-tested: "a state-transition table mechanically fills every state times event combination, systematically detecting undefined transitions", "event-driven is power-efficient but vulnerable to unanticipated combinations", and "polling is reliable but occupies the CPU, hurting power consumption." Remember the contrast that a table, not a diagram, is what guarantees exhaustiveness.
Suppose a battery-powered industrial sensor device normally transitions among three states—standby, measuring, and transmitting—using an event-driven design. After deployment, a rare bug was reported where the device would occasionally stop responding while stuck in "transmitting." When the designer reviewed the state-transition diagram, it depicted only the main transition ("on transmit-complete event while transmitting, return to standby"), and it was easy to overlook that the diagram did not depict what should happen if a new measurement-start event arrived while transmitting. So they built a state-transition table, mechanically enumerating all three states times every anticipated event (measurement start, measurement complete, transmit complete, communication error, timeout, etc.), and found the gap: the transition for a measurement-start event arriving while transmitting was undefined. On real hardware, when this undefined combination occurred, internal variables proceeded into the next processing step in an inconsistent state, resulting in the device becoming unresponsive. To fix this, they explicitly defined an exception transition: "if a measurement-start event arrives while transmitting, hold the measurement-start request in a queue and process it again after transmission completes." They also added another exception route, anticipating that the transmit-complete event itself might never arrive due to a communication fault: a timeout event can also force a transition from transmitting to standby (or an error state). In this way, the core of robust embedded-software state-transition design is not just the main normal-path transitions, but mechanically enumerating every combination of state times event in a table and defining the next state for every one of them, without omission.
| Aspect | State-transition diagram | State-transition table |
|---|---|---|
| Readability | Easy to visually survey overall behavior | Grows large with many states/events, but is mechanically readable |
| Guaranteeing exhaustiveness | Omissions (undefined combinations) are easy to miss | Mechanically fills every state x event; systematically detects gaps |
| Best suited for | Sharing the overall picture early in design | Exhaustive review of complex devices; backing the implementation |
Trap: "Drawing a state-transition diagram alone prevents undefined transitions (omissions)" is wrong—while a diagram is strong at visualizing main transitions, as the number of states and events grows, omissions become easy to miss, and building a state-transition table that mechanically fills every combination is necessary to guarantee exhaustiveness. Also wrong: "event-driven is always superior to polling"—event-driven excels at power efficiency, but is vulnerable to undefined combinations or orderings of events, and combining it with polling is effective where reliable periodic monitoring is needed.
5.3.3Section summary
- A state-transition table mechanically fills every state x event combination, systematically detecting the undefined transitions (omissions) a diagram tends to miss
- Event-driven excels at power/CPU efficiency but is vulnerable to undefined combinations; polling is reliable but hurts power consumption by occupying the CPU
- Once a gap is found, explicitly define an exception transition, such as holding in a queue or a forced transition via timeout, so the device does not become unresponsive
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. For an industrial sensor device with complex state transitions, you want to mechanically and exhaustively uncover gaps such as "the transition for a specific event in a specific state is undefined" during an implementation review. Which approach is most appropriate?
Q2. For a battery-powered embedded device, you want to free the CPU into a low-power state whenever no external event is occurring. Which processing approach best fits this goal?
Q3. A review of the state-transition table found a gap: the transition for a measurement-start event arriving while transmitting is undefined. On real hardware, this gap led internal variables to proceed in an inconsistent state, causing the device to become unresponsive. Which corrective action is most appropriate?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.