State machine for protocol handling in Embedded C - Step-by-Step Execution

Concept Flow - State machine for protocol handling

Start

↓

Wait for Event

↓

Check Event Type

↓

Event A

↓

Handle A

↓

Update State

↓

Wait for Event

The state machine waits for events, checks their type, handles them accordingly, updates state, and loops back to wait for the next event.

Execution Sample

Embedded C

typedef enum {IDLE, RECEIVING, PROCESSING, DONE} State;
State current_state = IDLE;

void handle_event(char event) {
  switch(current_state) {
    case IDLE: if(event == 'S') current_state = RECEIVING; break;
    case RECEIVING: if(event == 'E') current_state = PROCESSING; break;
    case PROCESSING: current_state = DONE; break;
    case DONE: current_state = IDLE; break;
  }
}

This code shows a simple state machine that changes states based on events 'S' and 'E'.

Execution Table

Step	Current State	Event	Condition Checked	State Change	Next State
1	IDLE	'S'	event == 'S' is True	current_state = RECEIVING	RECEIVING
2	RECEIVING	'E'	event == 'E' is True	current_state = PROCESSING	PROCESSING
3	PROCESSING	any	no condition, move to DONE	current_state = DONE	DONE
4	DONE	any	no condition, move to IDLE	current_state = IDLE	IDLE
5	IDLE	'X'	event == 'S' is False	no change	IDLE

💡 Execution stops after step 5 because event 'X' does not trigger a state change.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5
current_state	IDLE	RECEIVING	PROCESSING	DONE	IDLE	IDLE

Key Moments - 3 Insights

Why does the state not change when event 'X' is received in IDLE state?

Because the condition event == 'S' is False at step 5 in the execution_table, so no state change happens.

Why does the PROCESSING state move to DONE without checking an event?

At step 3, the code moves from PROCESSING to DONE unconditionally, as shown in the execution_table under Condition Checked.

What happens after the DONE state is reached?

At step 4, the state machine resets to IDLE unconditionally, preparing for new events.

Visual Quiz - 3 Questions

Look at the execution_table, what is the current_state after step 2?

A PROCESSING

B DONE

C RECEIVING

D IDLE

💡 Hint

Check the 'Next State' column at step 2 in the execution_table.

At which step does the state machine return to IDLE?

A Step 3

B Step 4

C Step 5

D Step 2

💡 Hint

Look at the 'Next State' column for when current_state becomes IDLE.

If event 'S' was received at step 5 instead of 'X', what would be the next state?

A PROCESSING

B IDLE

C RECEIVING

D DONE

💡 Hint

Refer to step 1 where event 'S' causes transition from IDLE to RECEIVING.

Concept Snapshot

State machine uses states and events to control flow.
Use enum for states and switch-case for transitions.
Check events in each state to decide next state.
Unconditional transitions are possible.
Loop back to wait for new events after handling.

Full Transcript

This example shows a simple state machine in embedded C for protocol handling. It starts in the IDLE state and waits for events. When event 'S' is received in IDLE, it moves to RECEIVING. Then, on event 'E' in RECEIVING, it moves to PROCESSING. From PROCESSING, it moves unconditionally to DONE, and from DONE back to IDLE. If an unknown event like 'X' is received in IDLE, no state change occurs. The execution table traces each step, showing conditions checked and state changes. The variable tracker shows how current_state changes after each step. Key moments clarify why some transitions happen unconditionally and why some events do not cause changes. The visual quiz tests understanding of state changes at specific steps. This pattern helps manage protocol states clearly and predictably in embedded systems.