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.

Practice

1. What is the main purpose of an event-driven state machine in embedded C?

easy

A. To change behavior based on events and current state

B. To execute code sequentially without conditions

C. To store large amounts of data in memory

D. To perform mathematical calculations only

Solution

1. Step 1: Understand the concept of event-driven state machine

   An event-driven state machine changes its behavior depending on the current state and the events it receives.

2. Step 2: Compare options with the concept

   To change behavior based on events and current state correctly describes this behavior. Other options describe unrelated concepts.

3. Final Answer:

   To change behavior based on events and current state -> Option A

4. Quick Check:

   Event-driven state machine = change behavior by events [OK]

Hint: Remember: state machines react to events and states [OK]

Common Mistakes:

• Thinking state machines just run code sequentially
• Confusing state machines with data storage
• Assuming state machines only do math

2. Which of the following is the correct way to define states in an event-driven state machine using embedded C?

easy

A. int STATE_IDLE = 0; int STATE_RUN = 1; int STATE_STOP = 2;

B. #define STATE_IDLE 0 #define STATE_RUN 1 #define STATE_STOP 2

C. typedef enum {STATE_IDLE, STATE_RUN, STATE_STOP} State;

D. char* states[] = {"IDLE", "RUN", "STOP"};

Solution

1. Step 1: Identify proper enum syntax in embedded C

   Using typedef enum with named states is the standard and clear way to define states.

2. Step 2: Check options for correctness and clarity

   The typedef enum syntax is the preferred choice for type safety and readability. Using separate ints, #defines, or string arrays lacks these benefits and is less idiomatic.

3. Final Answer:

   typedef enum {STATE_IDLE, STATE_RUN, STATE_STOP} State; -> Option C

4. Quick Check:

   Use enum typedef for states [OK]

Hint: Use typedef enum for clear state names [OK]

Common Mistakes:

• Using #define instead of enum for states
• Using strings instead of enums for states
• Not using typedef with enum

3. Given the following code snippet, what will be the value of current_state after handle_event(EVENT_START) is called?

typedef enum {STATE_IDLE, STATE_RUN, STATE_STOP} State;
typedef enum {EVENT_START, EVENT_STOP} Event;

State current_state = STATE_IDLE;

void handle_event(Event e) {
    switch(current_state) {
        case STATE_IDLE:
            if (e == EVENT_START) current_state = STATE_RUN;
            break;
        case STATE_RUN:
            if (e == EVENT_STOP) current_state = STATE_STOP;
            break;
        case STATE_STOP:
            break;
    }
}

handle_event(EVENT_START);

medium

A. Compilation error

B. STATE_RUN

C. STATE_STOP

D. STATE_IDLE

Solution

1. Step 1: Check initial state and event

   The initial state is STATE_IDLE. The event passed is EVENT_START.

2. Step 2: Follow the switch-case logic

   In STATE_IDLE, if event is EVENT_START, current_state changes to STATE_RUN.

3. Final Answer:

   STATE_RUN -> Option B

4. Quick Check:

   EVENT_START in STATE_IDLE moves to STATE_RUN [OK]

Hint: Trace event in current state switch-case [OK]

Common Mistakes:

• Ignoring event condition inside the case
• Assuming state changes without event match
• Thinking code has syntax errors

4. Identify the bug in this event-driven state machine code snippet:

typedef enum {STATE_IDLE, STATE_RUN} State;
typedef enum {EVENT_START, EVENT_STOP} Event;

State current_state = STATE_IDLE;

void handle_event(Event e) {
    switch(current_state) {
        case STATE_IDLE:
            if (e = EVENT_START) current_state = STATE_RUN;
            break;
        case STATE_RUN:
            if (e == EVENT_STOP) current_state = STATE_IDLE;
            break;
    }
}

medium

A. State enum missing STATE_STOP

B. Missing default case in switch statement

C. current_state not initialized

D. Using assignment '=' instead of comparison '==' in if condition

Solution

1. Step 1: Inspect the if condition in STATE_IDLE case

   The condition uses 'if (e = EVENT_START)', which assigns EVENT_START to e instead of comparing.

2. Step 2: Understand the effect of assignment in condition

   Assignment returns the assigned value, which is non-zero, so condition is always true, causing incorrect state changes.

3. Final Answer:

   Using assignment '=' instead of comparison '==' in if condition -> Option D

4. Quick Check:

   Use '==' for comparison, not '=' [OK]

Hint: Check if conditions use '==' not '=' [OK]

Common Mistakes:

• Confusing '=' and '==' in conditions
• Ignoring missing default case (not critical here)
• Assuming all states must be defined

5. You want to add a new state STATE_PAUSE and event EVENT_PAUSE to the existing state machine. Which code snippet correctly updates the handle_event function to handle pausing from STATE_RUN and resuming back to STATE_RUN from STATE_PAUSE?

hard

A. case STATE_RUN:
if (e == EVENT_PAUSE) current_state = STATE_PAUSE;
else if (e == EVENT_STOP) current_state = STATE_IDLE;
break;
case STATE_PAUSE:
if (e == EVENT_PAUSE) current_state = STATE_RUN;
break;

B. case STATE_RUN:
if (e == EVENT_PAUSE) current_state = STATE_IDLE;
break;
case STATE_PAUSE:
if (e == EVENT_PAUSE) current_state = STATE_STOP;
break;

C. case STATE_RUN:
if (e == EVENT_STOP) current_state = STATE_PAUSE;
break;
case STATE_PAUSE:
if (e == EVENT_PAUSE) current_state = STATE_IDLE;
break;

D. case STATE_RUN:
if (e == EVENT_PAUSE) current_state = STATE_STOP;
break;
case STATE_PAUSE:
if (e == EVENT_STOP) current_state = STATE_RUN;
break;

Solution

1. Step 1: Understand desired transitions

   From STATE_RUN, EVENT_PAUSE should move to STATE_PAUSE. From STATE_PAUSE, EVENT_PAUSE should resume to STATE_RUN.

2. Step 2: Check each option for correct transitions

   case STATE_RUN: if (e == EVENT_PAUSE) current_state = STATE_PAUSE; else if (e == EVENT_STOP) current_state = STATE_IDLE; break; case STATE_PAUSE: if (e == EVENT_PAUSE) current_state = STATE_RUN; break; matches these transitions exactly. Other options assign wrong states or events.

3. Final Answer:

   case STATE_RUN: if (e == EVENT_PAUSE) current_state = STATE_PAUSE; else if (e == EVENT_STOP) current_state = STATE_IDLE; break; case STATE_PAUSE: if (e == EVENT_PAUSE) current_state = STATE_RUN; break; -> Option A

4. Quick Check:

   Pause toggles between RUN and PAUSE states [OK]

Hint: Match events to correct state transitions carefully [OK]

Common Mistakes:

• Assigning wrong states on pause/resume events
• Confusing EVENT_PAUSE with EVENT_STOP
• Missing else if for multiple events