Event-driven state machine in Embedded C - Deep Dive

Overview - Event-driven state machine

What is it?

An event-driven state machine is a way to organize a program so it reacts to events by changing its state. It has a set of states and listens for events like button presses or sensor signals. When an event happens, the machine moves to a new state or performs an action based on rules. This helps manage complex behaviors in embedded systems clearly and predictably.

Why it matters

Without event-driven state machines, embedded programs can become tangled and hard to follow, especially when many things happen at once. This can cause bugs, missed signals, or unexpected behavior. Using this method makes programs easier to understand, test, and maintain, which is critical in devices like home appliances, cars, or medical tools where reliability matters.

Where it fits

Before learning event-driven state machines, you should understand basic programming concepts like variables, functions, and control flow in C. After mastering this, you can explore real-time operating systems, interrupt handling, and advanced embedded design patterns to build more responsive and efficient systems.

Mental Model

Core Idea

An event-driven state machine waits for events and changes its state or behavior based on those events following defined rules.

Think of it like...

It's like a traffic light controller that changes colors (states) when timers or sensors (events) tell it to, ensuring smooth traffic flow.

┌───────────────┐       event A       ┌───────────────┐
│    State 1    │ ────────────────▶ │    State 2    │
└───────────────┘                   └───────────────┘
       ▲                                  │
       │           event B                │
       └──────────────────────────────────┘

Build-Up - 6 Steps

1

Foundation

Understanding States and Events

Concept: Learn what states and events are in a program context.

A state is a condition or mode the system is in, like 'Idle' or 'Running'. An event is something that happens, like a button press or a timer tick. In embedded C, states can be represented by numbers or enums, and events can be inputs to the system.

Result

You can identify and name different states and events your system will handle.

Understanding states and events is the base for organizing how your program reacts to changes over time.

2

Foundation

Representing States in C Code

Concept: Use enums and variables to track the current state.

Define an enum listing all states, then use a variable to hold the current state. For example: enum State {IDLE, RUNNING, ERROR}; enum State current_state = IDLE; This lets the program know where it is at any moment.

Result

You have a clear way to store and check the system's state in code.

Representing states explicitly helps avoid confusion and makes the program easier to read and debug.

3

Intermediate

Handling Events with Switch Statements

Concept: Use switch-case to decide actions based on current state and event.

Write a function that takes an event and uses a switch on current_state to decide what to do. For example: switch(current_state) { case IDLE: if(event == START) current_state = RUNNING; break; case RUNNING: if(event == STOP) current_state = IDLE; break; } This controls how the state changes.

Result

Your program can now react to events by changing states.

Using switch-case structures makes the logic clear and easy to extend with new states or events.

4

Intermediate

Designing Event Queues for Asynchronous Inputs

🤔Before reading on: do you think handling events immediately or queuing them is better for embedded systems? Commit to your answer.

Concept: Learn to queue events so the system processes them one by one safely.

In embedded systems, events can happen anytime, even during processing. Using an event queue stores incoming events in order. The main loop then processes each event from the queue, preventing missed or overlapping events. This can be implemented as a circular buffer.

Result

Your system can handle multiple events reliably without losing any.

Knowing how to queue events prevents bugs caused by events arriving faster than they can be handled.

5

Advanced

Implementing State Actions and Transitions

🤔Before reading on: do you think states should only change or also perform actions? Commit to your answer.

Concept: States can have entry, exit, and during actions to perform tasks on transitions or while active.

Each state can have code that runs when entering, exiting, or while in that state. For example, turning on an LED when entering RUNNING, or stopping a motor when exiting. This separates behavior from state changes and improves clarity.

Result

Your state machine not only changes states but also performs meaningful actions at the right times.

Separating actions by entry, exit, and during states helps organize code and avoid side effects.

6

Expert

Optimizing for Low Memory and Real-Time Constraints

🤔Before reading on: do you think a state machine always needs dynamic memory? Commit to your answer.

Concept: Learn how to implement event-driven state machines efficiently without dynamic memory and with predictable timing.

Embedded systems often have limited RAM and strict timing. Use static arrays for event queues, avoid dynamic memory, and keep state handlers fast and simple. Use function pointers or tables to reduce switch-case overhead. This ensures the system meets real-time deadlines.

Result

Your state machine runs efficiently and reliably on resource-constrained devices.

Understanding resource limits and timing needs is crucial for robust embedded state machines.

Under the Hood

At runtime, the event-driven state machine waits for events, often from interrupts or input polling. When an event occurs, it is placed in a queue or handled immediately. The main loop processes events by checking the current state and applying transition rules. State changes update the current state variable, and associated actions run. This cycle repeats, allowing the system to respond dynamically to inputs.

Why designed this way?

This design separates event detection from event handling, improving responsiveness and predictability. It avoids complex nested if-else logic and scattered code by centralizing state and event management. Early embedded systems used polling loops, but event-driven state machines provide clearer structure and better scalability for complex behaviors.

┌───────────────┐   Event occurs   ┌───────────────┐
│   Event ISR   │ ───────────────▶│ Event Queue   │
└───────────────┘                  └───────────────┘
         │                                │
         ▼                                ▼
┌─────────────────┐             ┌─────────────────┐
│ Main Loop       │◀────────────│ Process Event   │
│ - Check queue   │             │ - Switch state  │
│ - Run actions   │             │ - Update state  │
└─────────────────┘             └─────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think a state machine must handle only one event at a time? Commit to yes or no.

Common Belief: A state machine can only process one event at a time and must ignore others until done.

Reality: Event-driven state machines often queue multiple events and process them sequentially to avoid losing any inputs.

Why it matters: Ignoring events can cause missed inputs, leading to incorrect or unsafe system behavior.

Quick: Do you think states must be represented only by numbers? Commit to yes or no.

Common Belief: States have to be simple numbers or integers in code.

Reality: States are better represented by enums or named constants for clarity and maintainability.

Why it matters: Using meaningful names prevents confusion and bugs when reading or modifying code.

Quick: Do you think event-driven state machines are too slow for embedded systems? Commit to yes or no.

Common Belief: Event-driven state machines add too much overhead and slow down embedded programs.

Reality: When designed well, they are efficient and help meet real-time requirements by organizing code and reducing complexity.

Why it matters: Avoiding state machines due to this misconception can lead to messy code that is harder to optimize and maintain.

Quick: Do you think state machines always need dynamic memory allocation? Commit to yes or no.

Common Belief: Event queues and state machines require dynamic memory allocation to work.

Reality: Most embedded state machines use static memory for queues and states to ensure predictability and avoid fragmentation.

Why it matters: Using dynamic memory in embedded systems can cause crashes or unpredictable behavior.

Expert Zone

1

Using function pointers for state handlers can reduce switch-case overhead and improve code modularity.

2

Designing state machines with hierarchical states allows reuse of common behaviors and reduces code duplication.

3

Careful event prioritization and filtering prevent starvation and ensure critical events are handled timely.

When NOT to use

Event-driven state machines are not ideal for very simple, linear tasks where a simple loop suffices. For highly concurrent or complex timing requirements, a real-time operating system (RTOS) with task scheduling might be better.

Production Patterns

In production, state machines are often combined with interrupt-driven event generation and use static event queues. They are modularized into separate files per state or subsystem. Logging and debugging hooks are added to trace state transitions for maintenance.

Connections

Finite Automata (Theory)

Event-driven state machines are practical implementations of finite automata concepts from computer science theory.

Understanding finite automata helps grasp the mathematical foundation of state machines and their correctness.

Reactive Programming

Both focus on reacting to events or data changes, but reactive programming is higher-level and often asynchronous.

Knowing event-driven state machines clarifies how reactive systems manage state and events at a low level.

Human Decision Making

Like a person changing behavior based on situations (events), state machines model decision processes in machines.

Recognizing this connection helps appreciate state machines as models of predictable, rule-based behavior.

Common Pitfalls

#1 Ignoring event queue overflow leading to lost events.

Wrong approach:

void enqueue_event(Event e) {
event_queue[queue_tail] = e;
queue_tail = (queue_tail + 1) % QUEUE_SIZE;
// No check for full queue
}

Correct approach:

void enqueue_event(Event e) {
int next_tail = (queue_tail + 1) % QUEUE_SIZE;
if(next_tail != queue_head) { // Check not full
event_queue[queue_tail] = e;
queue_tail = next_tail;
} else {
// Handle overflow, e.g., discard or flag error
}
}

Root cause:

Not checking if the queue is full before adding events causes overwriting and lost inputs.

#2 Using global variables for state without encapsulation.

Wrong approach:

enum State current_state;
// Accessed and modified anywhere in code

Correct approach:

static enum State current_state;
// Accessed only via state machine functions

Root cause:

Global state variables can be changed unexpectedly, causing bugs and making debugging hard.

#3 Performing long blocking operations inside state handlers.

Wrong approach:

case RUNNING:
do_heavy_computation(); // Blocks for seconds
break;

Correct approach:

case RUNNING:
start_heavy_computation_async();
break;

Root cause:

Blocking operations delay event processing, causing missed or delayed responses.

Key Takeaways

Event-driven state machines organize programs by defining clear states and reacting to events to change behavior.

Representing states with enums and handling events with switch-case or function pointers makes code clear and maintainable.

Using event queues ensures no events are lost and the system processes inputs in order.

Separating state entry, exit, and during actions helps keep behavior organized and predictable.

Efficient design respecting embedded constraints is key to building reliable, real-time systems.