State transition table approach in Embedded C - Step-by-Step Execution

Concept Flow - State transition table approach

Start

↓

Current State

↓

Input Event

↓

Look up next state & action in table

↓

Perform action

↓

Update current state

↓

Wait for next input or exit

The program starts with a current state and input event, looks up the next state and action in a table, performs the action, updates the state, and repeats.

Execution Sample

Embedded C

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

State current_state = STATE_IDLE;

void process_event(Event e) {
  switch (current_state) {
    case STATE_IDLE:
      if (e == EVENT_START) {
        // action
        current_state = STATE_BUSY;
      }
      break;
    case STATE_BUSY:
      if (e == EVENT_STOP) {
        // action
        current_state = STATE_IDLE;
      }
      break;
  }
}

This code changes state from IDLE to BUSY on START event, and back on STOP event.

Execution Table

Step	Current State	Input Event	Lookup Result (Next State, Action)	Action Performed	New State
1	STATE_IDLE	EVENT_START	(STATE_BUSY, Start action)	Start action executed	STATE_BUSY
2	STATE_BUSY	EVENT_START	(No transition)	No action	STATE_BUSY
3	STATE_BUSY	EVENT_STOP	(STATE_IDLE, Stop action)	Stop action executed	STATE_IDLE
4	STATE_IDLE	EVENT_STOP	(No transition)	No action	STATE_IDLE
5	-	-	-	No more events, stop	-

💡 No more input events to process, execution stops.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
current_state	STATE_IDLE	STATE_BUSY	STATE_BUSY	STATE_IDLE	STATE_IDLE	STATE_IDLE

Key Moments - 3 Insights

Why does the state not change on step 2 when EVENT_START is received in STATE_BUSY?

Because the state transition table has no entry for EVENT_START in STATE_BUSY (see execution_table row 2), so no action or state change occurs.

How does the program decide which action to perform?

It looks up the current state and input event in the transition table to find the matching next state and action (see execution_table column 'Lookup Result').

What happens if an input event is not in the table for the current state?

No transition occurs, no action is performed, and the state remains unchanged (see execution_table rows 2 and 4).

Visual Quiz - 3 Questions

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

A STATE_BUSY

B STATE_START

C STATE_IDLE

D No state

💡 Hint

Check the 'New State' column in execution_table row 3.

At which step does the program perform the 'Stop action executed'?

A Step 3

B Step 2

C Step 1

D Step 4

💡 Hint

Look for 'Stop action executed' in the 'Action Performed' column.

If EVENT_START is received in STATE_BUSY, what happens according to the execution_table?

A State changes to STATE_IDLE

B No action and state remains STATE_BUSY

C Start action executed and state changes

D Program crashes

💡 Hint

See execution_table row 2 for EVENT_START in STATE_BUSY.

Concept Snapshot

State transition table approach:
- Define states and events.
- Use a table to map (state, event) to (next state, action).
- On event, lookup table, perform action, update state.
- If no entry, stay in current state.
- Makes state management clear and scalable.

Full Transcript

This example shows how a program manages states using a state transition table approach. It starts in STATE_IDLE. When EVENT_START occurs, it looks up the table, finds to move to STATE_BUSY and performs the start action. If EVENT_START happens again in STATE_BUSY, no change occurs because no transition is defined. When EVENT_STOP occurs in STATE_BUSY, it transitions back to STATE_IDLE and performs the stop action. If EVENT_STOP occurs in STATE_IDLE, no change happens. This approach helps organize state changes clearly by using a lookup table for transitions and actions.