Simple state machine with switch-case in Embedded C - Deep Dive

Overview - Simple state machine with switch-case

What is it?

A simple state machine is a way to organize a program so it can be in one of several states at a time. Each state represents a specific mode or condition of the program. Using switch-case statements, the program decides what to do based on the current state and can change to another state when needed. This helps manage complex behaviors in a clear and organized way.

Why it matters

Without state machines, programs can become messy and hard to follow when they need to handle many different situations. State machines make it easier to control what the program does step-by-step, reducing bugs and making the code easier to change or fix. This is especially important in embedded systems where reliability and clarity are critical.

Where it fits

Before learning state machines, you should understand basic C programming, including variables, functions, and switch-case statements. After mastering simple state machines, you can learn more advanced topics like hierarchical state machines, event-driven programming, or real-time operating systems.

Mental Model

Core Idea

A state machine is like a program that remembers where it is and decides what to do next based on that memory.

Think of it like...

Imagine a traffic light that can be green, yellow, or red. It changes its color based on a timer and rules. The traffic light's color is its state, and the rules for changing colors are like the switch-case decisions.

┌─────────────┐
│   STATE 1   │
└──────┬──────┘
       │ event
       ▼
┌─────────────┐
│   STATE 2   │
└──────┬──────┘
       │ event
       ▼
┌─────────────┐
│   STATE 3   │
└─────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding program states

Concept: Introduce the idea that a program can be in different modes called states.

A state is a condition or mode that a program can be in. For example, a simple device might be OFF, ON, or in ERROR. We use variables to remember the current state.

Result

You can track what the program is doing at any moment by checking the state variable.

Understanding that a program can have different states helps organize behavior clearly instead of mixing all actions together.

2

Foundation

Using switch-case for decisions

Concept: Learn how switch-case statements let the program choose actions based on a variable's value.

The switch-case statement checks a variable and runs code for the matching case. For example: switch(state) { case OFF: // do something break; case ON: // do something else break; } This is cleaner than many if-else statements.

Result

You can write clear code that handles different states separately.

Switch-case makes it easy to separate code for each state, improving readability and reducing errors.

3

Intermediate

Building a simple state machine

Concept: Combine states and switch-case to create a program that changes states based on events.

Define an enum for states, a variable to hold the current state, and a switch-case to handle each state. Inside each case, decide if the state should change: enum State { OFF, ON }; State current_state = OFF; void update() { switch(current_state) { case OFF: // if button pressed, go ON break; case ON: // if button pressed, go OFF break; } } This loop runs repeatedly, updating the state.

Result

The program can switch between OFF and ON states based on input.

Combining states with switch-case creates a clear flow of control that is easy to follow and maintain.

4

Intermediate

Handling state transitions safely

🤔Before reading on: do you think changing states inside the switch-case can cause unexpected behavior if not careful? Commit to yes or no.

Concept: Learn how to change states without causing bugs like skipping states or infinite loops.

When changing states inside a switch-case, make sure to update the state variable carefully. Avoid changing the state multiple times in one update cycle. Use break statements to prevent fall-through. For example: switch(current_state) { case OFF: if(button_pressed) { current_state = ON; } break; case ON: if(button_pressed) { current_state = OFF; } break; } This prevents unexpected jumps.

Result

State changes happen predictably and the program behaves as expected.

Knowing how to control state changes prevents bugs that are hard to find and fix in embedded systems.

5

Intermediate

Adding actions inside states

🤔Before reading on: do you think actions inside states should happen before or after checking for state changes? Commit to your answer.

Concept: Learn to perform tasks specific to each state while managing transitions.

Inside each case, you can do work related to that state, like turning on an LED or reading a sensor. For example: switch(current_state) { case OFF: turn_off_led(); if(button_pressed) { current_state = ON; } break; case ON: turn_on_led(); if(button_pressed) { current_state = OFF; } break; } This way, the program acts differently depending on the state.

Result

The device behaves differently in each state and changes state when needed.

Separating actions by state keeps code organized and makes behavior predictable.

6

Advanced

Scaling state machines with enums and functions

🤔Before reading on: do you think using functions for each state makes the code easier or harder to manage? Commit to your answer.

Concept: Use enums for states and separate functions for state actions to improve code clarity and scalability.

Define an enum for all states. Write a function for each state’s behavior. In the main update, call the function based on the current state: enum State { OFF, ON, ERROR }; State current_state = OFF; void state_off() { turn_off_led(); if(button_pressed) current_state = ON; } void state_on() { turn_on_led(); if(button_pressed) current_state = OFF; } void update() { switch(current_state) { case OFF: state_off(); break; case ON: state_on(); break; case ERROR: /* handle error */ break; } } This keeps code clean and easy to add new states.

Result

The program is easier to read, maintain, and extend with more states.

Breaking state logic into functions helps manage complexity as projects grow.

7

Expert

Avoiding common pitfalls in embedded state machines

🤔Before reading on: do you think a state machine can fail silently if input events are missed? Commit to yes or no.

Concept: Understand subtle issues like missed events, timing problems, and state corruption in embedded systems.

In embedded systems, inputs can be noisy or missed if the state machine runs too slowly. Also, changing states without proper synchronization can cause race conditions. Use debouncing for buttons, check inputs regularly, and keep state changes atomic. For example, use volatile variables for states shared with interrupts. Also, avoid long blocking code inside states to keep responsiveness. Example: volatile State current_state; void ISR_button() { // safely update state or set flag } This prevents subtle bugs that are hard to debug.

Result

The state machine runs reliably without missing inputs or corrupting state.

Knowing embedded-specific challenges helps build robust state machines that work well in real hardware.

Under the Hood

A state machine stores its current state in a variable, usually an enum or integer. The switch-case statement reads this variable and executes code for that state. When conditions change, the code updates the state variable to a new value. On the next cycle, the switch-case runs the code for the new state. This cycle repeats, allowing the program to move through states over time.

Why designed this way?

Switch-case is a simple, efficient way to branch code based on discrete values, which fits perfectly with the concept of states. Using enums for states makes code readable and less error-prone. This design was chosen because it is easy to understand, fast to execute on embedded processors, and uses minimal memory.

┌───────────────┐
│ current_state │
└──────┬────────┘
       │
       ▼
┌─────────────────────┐
│    switch(current_state)   │
│ ┌───────────────┐  │
│ │ case STATE_1:  │  │
│ │   do_action(); │  │
│ │   current_state = STATE_2; │
│ │   break;      │  │
│ └───────────────┘  │
│ ┌───────────────┐  │
│ │ case STATE_2:  │  │
│ │   do_other();  │  │
│ │   break;      │  │
│ └───────────────┘  │
└─────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think a state machine always needs a default case in switch? Commit yes or no.

Common Belief: A state machine must always have a default case in the switch statement to handle unexpected states.

Reality: While a default case can catch unexpected states, it is better to explicitly handle all known states and treat unknown states as errors. Sometimes omitting default helps the compiler warn about missing states.

Why it matters: Relying on default can hide bugs where a state is not handled properly, leading to silent failures.

Quick: Do you think you can change multiple states in one update cycle safely? Commit yes or no.

Common Belief: You can safely change the state variable multiple times inside one switch-case execution.

Reality: Changing the state multiple times in one cycle can cause confusing behavior or skip states unintentionally. It's best to change state once per cycle.

Why it matters: Multiple changes can cause bugs that are hard to trace and make the program behave unpredictably.

Quick: Do you think state machines are only useful for big complex systems? Commit yes or no.

Common Belief: State machines are only needed for large or complex programs.

Reality: Even simple programs benefit from state machines because they organize code clearly and prevent bugs.

Why it matters: Ignoring state machines in small projects can lead to messy code and harder debugging later.

Quick: Do you think switch-case is the only way to implement state machines? Commit yes or no.

Common Belief: Switch-case is the only practical way to implement state machines in embedded C.

Reality: State machines can also be implemented with function pointers, tables, or object-oriented patterns, which can be more flexible or efficient in some cases.

Why it matters: Knowing alternatives helps choose the best approach for different project needs.

Expert Zone

1

State machines in embedded systems often need to be non-blocking to maintain system responsiveness.

2

Using volatile keyword for state variables shared with interrupts prevents compiler optimizations that break correctness.

3

Stacking or nesting state machines (hierarchical state machines) can manage complex behaviors but require careful design.

When NOT to use

Simple switch-case state machines are not ideal for highly complex systems with many states and transitions; in such cases, hierarchical state machines or event-driven frameworks are better. Also, if timing and concurrency are critical, real-time operating systems may be more appropriate.

Production Patterns

In real embedded projects, state machines are used for device modes, communication protocols, user interfaces, and error handling. Developers often combine state machines with timers and interrupts for responsive control.

Connections

Event-driven programming

Builds-on

Understanding state machines helps grasp event-driven programming where events trigger state changes and actions.

Finite automata (theory of computation)

Same pattern

State machines in programming are practical versions of finite automata studied in computer science theory.

Human decision making

Analogy

Humans often act like state machines, changing behavior based on current context and inputs, which helps understand program flow control.

Common Pitfalls

#1 Changing state multiple times in one update causes skipped states.

Wrong approach:

switch(current_state) {
case OFF:
current_state = ON;
current_state = ERROR;
break;
}

Correct approach:

switch(current_state) {
case OFF:
current_state = ON;
break;
case ON:
current_state = ERROR;
break;
}

Root cause:

Misunderstanding that multiple state changes in one cycle can confuse program flow.

#2 Not using break in switch-case causes fall-through bugs.

Wrong approach:

switch(current_state) {
case OFF:
do_off_action();
case ON:
do_on_action();
break;
}

Correct approach:

switch(current_state) {
case OFF:
do_off_action();
break;
case ON:
do_on_action();
break;
}

Root cause:

Forgetting break causes code for multiple states to run unintentionally.

#3 Using non-volatile state variable shared with interrupts causes stale reads.

Wrong approach:

State current_state;

void ISR() {
current_state = ERROR;
}

Correct approach:

volatile State current_state;

void ISR() {
current_state = ERROR;
}

Root cause:

Ignoring compiler optimizations that cache variables and miss updates from interrupts.

Key Takeaways

A simple state machine uses a variable to remember the current mode and switch-case to decide actions.

Organizing code by states makes programs easier to read, maintain, and less error-prone.

Changing states carefully and using break statements prevents common bugs.

In embedded systems, special care with timing, interrupts, and volatile variables ensures reliable state machines.

Advanced designs use functions per state and consider alternatives for complex or real-time needs.

Practice

1.

What is the main purpose of using a switch-case statement in a simple state machine?

easy

A. To create loops that repeat forever

B. To handle different states clearly and execute code based on the current state

C. To declare variables for each state

D. To stop the program immediately

Solution

1. Step 1: Understand the role of switch-case in state machines

   The switch-case statement lets the program choose what to do based on the current state value.

2. Step 2: Recognize how states are handled

   Each case corresponds to a state, so the program runs code specific to that state.

3. Final Answer:

   To handle different states clearly and execute code based on the current state -> Option B

4. Quick Check:

   switch-case manages states = To handle different states clearly and execute code based on the current state [OK]

Hint: Switch-case matches states to actions clearly [OK]

Common Mistakes:

• Thinking switch-case creates loops
• Confusing variable declaration with state handling
• Assuming switch-case stops the program

2.

Which of the following is the correct syntax for a switch statement in embedded C?

switch(state) {
  case 0:
    // code
    break;
  case 1:
    // code
    break;
  default:
    // code
}

easy

A. switch state { case 0: ... break; case 1: ... break; default: ... }

B. switch(state) { case 0: ... case 1: ... default: ... }

C. switch(state) case 0: ... break; case 1: ... break; default: ...

D. switch(state) { case 0: ... break; case 1: ... break; default: ... }

Solution

1. Step 1: Check the syntax structure of switch-case

   The switch statement requires parentheses around the variable and braces around the cases.

2. Step 2: Verify the use of colons and breaks

   Each case must have a colon and usually ends with a break to prevent fall-through.

3. Final Answer:

   switch(state) { case 0: ... break; case 1: ... break; default: ... } -> Option D

4. Quick Check:

   Correct switch-case syntax = switch(state) { case 0: ... break; case 1: ... break; default: ... } [OK]

Hint: Remember switch needs parentheses and braces [OK]

Common Mistakes:

• Omitting parentheses after switch
• Missing colons after case labels
• Forgetting break statements

3.

What will be the output of this code snippet?

int state = 1;
switch(state) {
  case 0:
    printf("State is zero\n");
    break;
  case 1:
    printf("State is one\n");
    break;
  default:
    printf("Unknown state\n");
}

medium

A. Unknown state

B. State is zero

C. State is one

D. No output

Solution

1. Step 1: Identify the value of state

   The variable state is set to 1 before the switch statement.

2. Step 2: Match the case with state value

   The switch matches case 1, so it prints "State is one" and then breaks.

3. Final Answer:

   State is one -> Option C

4. Quick Check:

   state=1 prints "State is one" [OK]

Hint: Match state value to case label to find output [OK]

Common Mistakes:

• Confusing case 0 with case 1
• Forgetting break causes fall-through
• Assuming default runs when case matches

4.

Find the error in this state machine code snippet:

int state = 0;
switch(state) {
  case 0:
    printf("Start\n");
  case 1:
    printf("Running\n");
    break;
  default:
    printf("Unknown\n");
}

medium

A. Missing break after case 0 causes fall-through

B. Switch statement missing parentheses

C. Default case should be first

D. Variable state is not initialized

Solution

1. Step 1: Check each case for break statements

   Case 0 does not have a break, so after printing "Start", it continues to case 1.

2. Step 2: Understand fall-through effect

   This causes both "Start" and "Running" to print when state is 0, which may be unintended.

3. Final Answer:

   Missing break after case 0 causes fall-through -> Option A

4. Quick Check:

   Missing break causes fall-through = Missing break after case 0 causes fall-through [OK]

Hint: Always add break after each case to avoid fall-through [OK]

Common Mistakes:

• Ignoring missing break leads to unexpected output
• Thinking default must be first case
• Assuming uninitialized variable error

5.

You want to design a simple state machine with three states: INIT (0), PROCESS (1), and DONE (2). The machine should start at INIT, then move to PROCESS, and finally to DONE. Which code snippet correctly updates the state inside the switch-case?

int state = 0;
switch(state) {
  case 0:
    // Move to PROCESS
    state = 1;
    break;
  case 1:
    // Move to DONE
    state = 2;
    break;
  case 2:
    // Finished
    break;
}

hard

A. Correctly updates state from INIT to PROCESS to DONE

B. Does not update state, stays in INIT forever

C. Skips PROCESS and goes directly to DONE

D. Causes infinite loop without state change

Solution

1. Step 1: Check state transitions in each case

   Case 0 sets state to 1 (PROCESS), case 1 sets state to 2 (DONE), case 2 does nothing (finished).

2. Step 2: Confirm the order of states

   The code moves from INIT to PROCESS to DONE in order, updating the state variable correctly.

3. Final Answer:

   Correctly updates state from INIT to PROCESS to DONE -> Option A

4. Quick Check:

   State updates follow sequence = Correctly updates state from INIT to PROCESS to DONE [OK]

Hint: Update state variable inside each case to move forward [OK]

Common Mistakes:

• Not updating state variable inside cases
• Skipping intermediate states
• Forgetting break causing unexpected behavior