Mealy vs Moore — which is more common in firmware?

In a Moore machine, the output depends only on the current state. In a Mealy machine, the output depends on both the state and the most recent event (so the same state can produce different outputs based on which event arrived).

In practice, embedded firmware FSMs are mostly Moore-style, often with Mealy-style accents.

The Moore aspect is dominant because most embedded behavior is mode-driven: in CONNECTED, the radio stays on; in IDLE, it stays off. The state implies long-running behavior — peripheral configuration, LED color, sensor sampling rate — and that's set by entry actions when you transition into the state. As long as you remain in the state, the behavior is constant.

The Mealy aspect comes in for one-shot actions tied to specific transitions. A UART parser in state WAITING_FOR_LENGTH_BYTE does different things on BYTE_RX(0x00) (zero-length frame: emit empty message and return to idle) vs BYTE_RX(other) (start collecting payload). The action depends on which byte arrived, not just on the state. That's a Mealy transition.

So in real code you'll see: state-level entry/exit actions for Moore-style invariants, plus per-transition actions for Mealy-style event-specific work. The classification is mostly an analysis tool — you don't typically declare "this is a Moore FSM" — but knowing the distinction helps you think about where actions belong.

The interview-relevant test is: when asked, give a concrete example. "In a charger controller, CHARGING_FAST is Moore — the PMIC is configured for high current as long as we're in this state. But the transition from CHARGING_FAST to CHARGING_TRICKLE on THRESHOLD_REACHED(voltage) is Mealy — the action depends on the voltage value carried in the event."