Why state machines are used in embedded in Embedded C - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why use state machines in embedded systems?

Which of the following best explains why state machines are commonly used in embedded programming?

A They replace the need for interrupts and timers in embedded systems.

B They automatically optimize the code for faster execution without programmer intervention.

C They allow embedded devices to run multiple operating systems simultaneously.

D They help organize complex behavior into clear states and transitions, making code easier to understand and maintain.

💡 Hint

Think about how breaking down tasks into steps helps manage complexity.

State machines break down complex device behavior into simple states and clear rules for moving between them. This makes the code easier to read, debug, and maintain.

❓ Predict Output

intermediate

Output of a simple embedded state machine code

What will be the output of this embedded C code simulating a state machine?

Embedded C

typedef enum {IDLE, RUNNING, ERROR} State;

State current_state = IDLE;

void run_state_machine() {
    switch(current_state) {
        case IDLE:
            printf("Idle state\n");
            current_state = RUNNING;
            break;
        case RUNNING:
            printf("Running state\n");
            current_state = ERROR;
            break;
        case ERROR:
            printf("Error state\n");
            current_state = IDLE;
            break;
    }
}

int main() {
    for(int i=0; i<3; i++) {
        run_state_machine();
    }
    return 0;
}

A

Idle state
Idle state
Idle state

B

Idle state
Running state
Error state

C

Running state
Error state
Idle state

D

Error state
Running state
Idle state

💡 Hint

Look at how the state changes after each print.

The code starts in IDLE, prints "Idle state", then moves to RUNNING. Next, it prints "Running state" and moves to ERROR. Finally, it prints "Error state" and returns to IDLE.

🔧 Debug

advanced

Identify the bug in this embedded state machine code

What error will this embedded C code cause when run?

Embedded C

typedef enum {START, PROCESS, STOP} State;

State current_state = START;

void run_state_machine() {
    switch(current_state) {
        case START:
            printf("Start\n");
            current_state = PROCESS;
            break;
        case PROCESS:
            printf("Process\n");
            // Missing break here
        case STOP:
            printf("Stop\n");
            current_state = START;
            break;
    }
}

int main() {
    for(int i=0; i<4; i++) {
        run_state_machine();
    }
    return 0;
}

A

The output will be:
Start
Process
Stop
Start
Process
Stop

B

The output will be:
Start
Process
Process
Start
Process
Process

C The program will crash with a segmentation fault.

D

The output will be:
Start
Stop
Start
Stop

💡 Hint

Check what happens when a break is missing in a switch-case.

Because the break is missing after PROCESS, the code falls through to STOP case, printing both "Process" and "Stop" each time PROCESS is reached.

📝 Syntax

advanced

Which option has correct syntax for a state machine transition?

Which of the following code snippets correctly updates the state variable in an embedded C state machine?

A current_state == RUNNING;

B current_state => RUNNING;

C current_state = RUNNING;

D current_state := RUNNING;

💡 Hint

Remember the assignment operator in C.

In C, '=' is used to assign a value. '==' is a comparison, ':=' and '=>' are invalid syntax.

🚀 Application

expert

How many states are in this embedded state machine?

Given this embedded C code, how many unique states does the state machine have?

Embedded C

typedef enum {
    INIT = 0,
    WAIT = 1,
    RUN = 2,
    PAUSE = 3,
    STOP = 4
} State;

State current_state = INIT;

void run_state_machine() {
    switch(current_state) {
        case INIT:
            current_state = WAIT;
            break;
        case WAIT:
            current_state = RUN;
            break;
        case RUN:
            current_state = PAUSE;
            break;
        case PAUSE:
            current_state = STOP;
            break;
        case STOP:
            current_state = INIT;
            break;
    }
}

A 5

B 4

C 6

D 3

💡 Hint

Count all the enum values representing states.

The enum defines 5 states: INIT, WAIT, RUN, PAUSE, and STOP.

Practice

1. Why are state machines commonly used in embedded systems?

easy

A. To reduce the physical size of the embedded device

B. To increase the clock speed of the processor

C. To organize device behavior into clear, manageable steps

D. To store large amounts of data efficiently

Solution

1. Step 1: Understand the purpose of state machines

   State machines break down complex device behavior into smaller, clear steps called states.

2. Step 2: Identify the benefit in embedded systems

   This organization helps manage complexity and makes the system easier to design and debug.

3. Final Answer:

   To organize device behavior into clear, manageable steps -> Option C

4. Quick Check:

   State machines = clear steps [OK]

Hint: State machines simplify complex behavior into steps [OK]

Common Mistakes:

• Confusing state machines with hardware speed improvements
• Thinking state machines reduce device size
• Assuming state machines store data

2. Which of the following is the correct way to represent a state machine in embedded C?

easy

A. Using a switch-case statement to handle different states

B. Using a for loop to iterate through states

C. Using a recursive function to call states

D. Using a global variable to store sensor data

Solution

1. Step 1: Identify common state machine structure

   State machines in embedded C are often implemented with switch-case to handle each state clearly.

2. Step 2: Compare other options

   For loops and recursion are not typical for state transitions; global variables store data but don't represent states.

3. Final Answer:

   Using a switch-case statement to handle different states -> Option A

4. Quick Check:

   Switch-case = state machine structure [OK]

Hint: Switch-case is classic for state handling [OK]

Common Mistakes:

• Using loops instead of switch-case for states
• Confusing recursion with state transitions
• Mixing data storage with state control

3. Consider this embedded C code snippet implementing a simple state machine:

enum State {IDLE, RUNNING, STOPPED};
State currentState = IDLE;
switch(currentState) {
  case IDLE:
    currentState = RUNNING;
    break;
  case RUNNING:
    currentState = STOPPED;
    break;
  case STOPPED:
    currentState = IDLE;
    break;
}
printf("%d", currentState);

What will be the output?

medium

A. 0

B. 1

C. 2

D. Compilation error

Solution

1. Step 1: Trace the initial state and switch

   currentState starts at IDLE (0). The switch changes it to RUNNING (1).

2. Step 2: Determine the printed value

   After the switch, currentState is RUNNING, so printf prints 1.

3. Final Answer:

   1 -> Option B

4. Quick Check:

   State IDLE (0) -> RUNNING (1) printed [OK]

Hint: Follow state changes step-by-step [OK]

Common Mistakes:

• Assuming output is initial state value
• Thinking code causes error due to enum
• Confusing state values with strings

4. This embedded C code tries to implement a state machine but has a bug:

enum State {START, PROCESS, END};
State current = START;
switch(current) {
  case START:
    current = PROCESS;
  case PROCESS:
    current = END;
    break;
  case END:
    current = START;
    break;
}

What is the main problem?

medium

A. Missing break after case START causes fall-through

B. Enum values are not initialized

C. Variable current is not declared

D. Switch statement syntax is incorrect

Solution

1. Step 1: Check switch-case structure

   Case START lacks a break, so execution falls through to PROCESS case.

2. Step 2: Understand effect of missing break

   This causes current to skip PROCESS state and jump directly to END, breaking intended flow.

3. Final Answer:

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

4. Quick Check:

   Missing break = fall-through bug [OK]

Hint: Always add break after each case [OK]

Common Mistakes:

• Ignoring missing break causes fall-through
• Thinking enum needs explicit values
• Assuming variable declaration error

5. You want to design an embedded system that controls a traffic light with states: RED, GREEN, YELLOW. Which reason best explains why using a state machine is the best approach?

hard

A. It increases the brightness of the traffic light LEDs

B. It reduces the power consumption of the traffic light hardware

C. It allows the traffic light to store vehicle counts efficiently

D. It clearly defines each light state and transitions, making timing and control simple

Solution

1. Step 1: Identify traffic light control needs

   The system must cycle through RED, GREEN, YELLOW states in order with timing control.

2. Step 2: Understand state machine benefits

   State machines organize these states and transitions clearly, simplifying timing and logic.

3. Final Answer:

   It clearly defines each light state and transitions, making timing and control simple -> Option D

4. Quick Check:

   State machine = clear control flow [OK]

Hint: State machines map clear steps and transitions [OK]

Common Mistakes:

• Confusing state machines with hardware power savings
• Thinking state machines store data counts
• Assuming state machines affect LED brightness