There is a lot of confusion about state machines in embedded software. Some example of this is the recent discussion in this forum: "FSM - Mealy vs Mo ore".
It seems to me that the real question to ask is not Mealy vs Moore, but "in put-driven" vs "event-driven" state machines.
"Input-driven" state machines seem to be far more popular, and most example s published in various magazines, books, and online pertain to "input-drive n" (a.k.a. "polled") state machines.
For example, here is an article "Embedded State Machine Implementation", wh ich was quite popular:
From this article you can see that the state machines described there are N OT driven by events. Instead, the state machine code is called "as fast as possible", or periodically" from while(1) "superloop" to poll for the event s. In the code, you can easily recognize such input-driven state machines b y the if() statements that check the inputs in each state and only after di scovering the right combination of inputs, they execute actions.
In the diagrams, you can easily recognize input-driven state machines by th e fact that state transitions are NOT labeled by events, but rather by guar d conditions. The brackets around those guard conditions, which are require d by the UML state machine notation, are often missing, but you typically c an recognize that the labels are conditions, especially when you see logic operators, like and/or.
The main problems with "input-driven" (polled) state machines are that they might miss changes in the inputs (if sampling is too slow) or recognize th e changes in different order, depending on the timing (race conditions). Th ey are also wasteful, as they need to run "all the time". Finally, it is ha rd to apply hierarchical event processing, because there are no explicit ev ents.
This is all in contrast to truly "event-driven" state machines, which are d efined in the UML (State Machine package). These state machines are driven by events, which are generated externally to the state machine and then (ty pically) queued to be processed. This separates event generation from the s tate machine logic.