State machine for protocol handling in Embedded C

Introduction

A state machine helps manage different steps or stages in a communication protocol clearly and safely.

When you need to handle different messages or commands in a fixed order.

When your device talks to another device and must follow rules step-by-step.

When you want to keep your code organized and easy to understand.

When you want to avoid mistakes by controlling what happens next based on current state.

Syntax

Embedded C

typedef enum {
    STATE_IDLE,
    STATE_WAIT_ACK,
    STATE_PROCESS_DATA,
    STATE_ERROR
} State;

typedef enum {
    EVENT_START,
    EVENT_ACK_RECEIVED,
    EVENT_TIMEOUT
} Event;

State current_state = STATE_IDLE;

void handle_event(Event event) {
    switch (current_state) {
        case STATE_IDLE:
            if (event == EVENT_START) {
                current_state = STATE_WAIT_ACK;
            }
            break;
        case STATE_WAIT_ACK:
            if (event == EVENT_ACK_RECEIVED) {
                current_state = STATE_PROCESS_DATA;
            } else if (event == EVENT_TIMEOUT) {
                current_state = STATE_ERROR;
            }
            break;
        case STATE_PROCESS_DATA:
            // process data here
            current_state = STATE_IDLE;
            break;
        case STATE_ERROR:
            // handle error
            current_state = STATE_IDLE;
            break;
    }
}

Use enum to define all possible states clearly.

Use a switch statement to decide what to do based on the current state.

Examples

This example shows a simple 3-step state machine reacting to events 1 and 2.

Embedded C

typedef enum {
    STATE_INIT,
    STATE_WAIT,
    STATE_DONE
} State;

State state = STATE_INIT;

void update_state(int event) {
    switch(state) {
        case STATE_INIT:
            if (event == 1) state = STATE_WAIT;
            break;
        case STATE_WAIT:
            if (event == 2) state = STATE_DONE;
            break;
        case STATE_DONE:
            // finished
            break;
    }
}

This example uses characters as events to move between states.

Embedded C

enum State {IDLE, RECEIVING, SENDING};
enum State current = IDLE;

void process_event(char event) {
    switch(current) {
        case IDLE:
            if (event == 'r') current = RECEIVING;
            break;
        case RECEIVING:
            if (event == 's') current = SENDING;
            break;
        case SENDING:
            if (event == 'i') current = IDLE;
            break;
    }
}

Sample Program

This program simulates a simple protocol using a state machine. It prints messages as it moves through states based on events.

Embedded C

#include <stdio.h>

typedef enum {
    STATE_IDLE,
    STATE_WAIT_ACK,
    STATE_PROCESS_DATA,
    STATE_ERROR
} State;

typedef enum {
    EVENT_START,
    EVENT_ACK_RECEIVED,
    EVENT_TIMEOUT
} Event;

State current_state = STATE_IDLE;

void handle_event(Event event) {
    switch (current_state) {
        case STATE_IDLE:
            if (event == EVENT_START) {
                printf("Starting protocol, waiting for ACK...\n");
                current_state = STATE_WAIT_ACK;
            }
            break;
        case STATE_WAIT_ACK:
            if (event == EVENT_ACK_RECEIVED) {
                printf("ACK received, processing data...\n");
                current_state = STATE_PROCESS_DATA;
            } else if (event == EVENT_TIMEOUT) {
                printf("Timeout! Error occurred.\n");
                current_state = STATE_ERROR;
            }
            break;
        case STATE_PROCESS_DATA:
            printf("Data processed successfully. Returning to idle.\n");
            current_state = STATE_IDLE;
            break;
        case STATE_ERROR:
            printf("Handling error, resetting to idle.\n");
            current_state = STATE_IDLE;
            break;
    }
}

int main() {
    handle_event(EVENT_START);
    handle_event(EVENT_ACK_RECEIVED);
    handle_event(EVENT_START);
    handle_event(EVENT_TIMEOUT);
    handle_event(EVENT_START);
    handle_event(EVENT_ACK_RECEIVED);
    handle_event(EVENT_START);
    handle_event(EVENT_ACK_RECEIVED);
    handle_event(EVENT_START);
    handle_event(EVENT_TIMEOUT);
    return 0;
}

Important Notes

Always define all possible states to avoid unexpected behavior.

Keep state transitions clear and simple to follow.

Use print statements or logging to debug state changes during development.

Summary

A state machine helps control protocol steps clearly and safely.

Use enums and switch-case to manage states and events.

Testing with different events helps ensure your protocol works as expected.

Practice

1. What is the main purpose of using a state machine in protocol handling in embedded C?

easy

A. To reduce the size of the compiled program

B. To speed up the processor clock

C. To avoid using any conditional statements

D. To clearly control the sequence of protocol steps and handle events safely

Solution

1. Step 1: Understand the role of a state machine

   A state machine organizes different states and transitions to manage complex sequences clearly.

2. Step 2: Relate to protocol handling

   Protocols require strict step-by-step control and safe event handling, which state machines provide.

3. Final Answer:

   To clearly control the sequence of protocol steps and handle events safely -> Option D

4. Quick Check:

   State machine controls protocol steps safely = C [OK]

Hint: State machines organize steps and events clearly [OK]

Common Mistakes:

• Thinking state machines speed up hardware
• Believing they reduce program size automatically
• Assuming they remove all conditionals

2. Which of the following is the correct way to define states for a protocol using enums in embedded C?

easy

A. enum ProtocolState {IDLE, WAIT_ACK, SEND_DATA, ERROR};

B. enum ProtocolState = {IDLE, WAIT_ACK, SEND_DATA, ERROR};

C. enum ProtocolState {IDLE; WAIT_ACK; SEND_DATA; ERROR};

D. enum ProtocolState (IDLE, WAIT_ACK, SEND_DATA, ERROR);

Solution

1. Step 1: Recall enum syntax in C

   Enums use the syntax: enum Name {value1, value2, ...}; with commas separating values.

2. Step 2: Check each option

   enum ProtocolState {IDLE, WAIT_ACK, SEND_DATA, ERROR}; uses correct syntax with commas and no assignment. Others use invalid syntax like '=' or semicolons.

3. Final Answer:

   enum ProtocolState {IDLE, WAIT_ACK, SEND_DATA, ERROR}; -> Option A

4. Quick Check:

   Enum syntax with commas = B [OK]

Hint: Enums use commas, not equals or semicolons [OK]

Common Mistakes:

• Using '=' after enum name
• Separating values with semicolons
• Using parentheses instead of braces

3. Given the following code snippet, what will be the output printed?

typedef enum {IDLE, WAIT_ACK, SEND_DATA} State;

void handle_event(State *state, int event) {
    switch (*state) {
        case IDLE:
            if (event == 1) {
                *state = SEND_DATA;
                printf("Sending data\n");
            }
            break;
        case SEND_DATA:
            if (event == 2) {
                *state = WAIT_ACK;
                printf("Waiting for ACK\n");
            }
            break;
        case WAIT_ACK:
            if (event == 3) {
                *state = IDLE;
                printf("ACK received, back to IDLE\n");
            }
            break;
    }
}

int main() {
    State current_state = IDLE;
    handle_event(¤t_state, 1);
    handle_event(¤t_state, 2);
    handle_event(¤t_state, 3);
    return 0;
}

medium

A. Sending data
Waiting for ACK
ACK received, back to IDLE

B. Waiting for ACK
Sending data
ACK received, back to IDLE

C. Sending data
ACK received, back to IDLE
Waiting for ACK

D. No output

Solution

1. Step 1: Trace first event with state IDLE and event 1

   State is IDLE, event 1 triggers transition to SEND_DATA and prints "Sending data".

2. Step 2: Trace second event with state SEND_DATA and event 2

   State is SEND_DATA, event 2 triggers transition to WAIT_ACK and prints "Waiting for ACK".

3. Step 3: Trace third event with state WAIT_ACK and event 3

   State is WAIT_ACK, event 3 triggers transition to IDLE and prints "ACK received, back to IDLE".

4. Final Answer:

   Sending data Waiting for ACK ACK received, back to IDLE -> Option A

5. Quick Check:

   Events 1,2,3 cause correct state prints = A [OK]

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

Common Mistakes:

• Mixing order of printed lines
• Ignoring state changes after events
• Assuming all events print output

4. Identify the bug in this state machine code snippet and select the fix:

typedef enum {IDLE, SEND, WAIT} State;

void process_event(State *state, int event) {
    switch (*state) {
        case IDLE:
            if (event == 1) {
                *state = SEND;
                printf("Start sending\n");
            }
        case SEND:
            if (event == 2) {
                *state = WAIT;
                printf("Waiting for response\n");
            }
            break;
        case WAIT:
            if (event == 3) {
                *state = IDLE;
                printf("Back to idle\n");
            }
            break;
    }
}

medium

A. Change enum values to strings

B. Add a break after the IDLE case to prevent fall-through

C. Remove the break after SEND case

D. Replace switch with if-else statements

Solution

1. Step 1: Analyze switch-case structure

   The IDLE case lacks a break, so after executing IDLE code, it falls through to SEND case unintentionally.

2. Step 2: Identify fix to prevent fall-through

   Adding a break after IDLE case stops execution from continuing into SEND case.

3. Final Answer:

   Add a break after the IDLE case to prevent fall-through -> Option B

4. Quick Check:

   Missing break causes fall-through = A [OK]

Hint: Always add break after each case unless intentional fall-through [OK]

Common Mistakes:

• Ignoring missing break causing bugs
• Changing enum types unnecessarily
• Removing needed breaks

5. You want to extend a protocol state machine to handle a timeout event that resets the state to IDLE from any state. Which is the best way to implement this in embedded C?

hard

A. Use goto statements inside switch-case to jump to IDLE

B. Add a new state TIMEOUT and transition only from WAIT state

C. Add a check for timeout event before the switch-case and reset state to IDLE if triggered

D. Ignore timeout events in the state machine and handle separately

Solution

1. Step 1: Understand requirement for timeout handling

   Timeout should reset to IDLE from any state immediately when detected.

2. Step 2: Choose implementation approach

   Checking timeout before switch-case allows immediate reset regardless of current state.

3. Step 3: Evaluate other options

   Adding TIMEOUT state limits reset to one state only; ignoring timeout misses requirement; goto is poor style and error-prone.

4. Final Answer:

   Add a check for timeout event before the switch-case and reset state to IDLE if triggered -> Option C

5. Quick Check:

   Pre-check timeout for immediate reset = D [OK]

Hint: Check global events before state-specific logic [OK]

Common Mistakes:

• Adding unnecessary states for global events
• Ignoring timeout in state machine
• Using goto for flow control