State transition table approach in Embedded C - Time & Space Complexity

Time Complexity: State transition table approach

O(n)

Understanding Time Complexity

We want to understand how the time to run a state machine using a state transition table changes as the number of states or inputs grows.

How does the program's work increase when the table or inputs get bigger?

Scenario Under Consideration

Analyze the time complexity of the following code snippet.

// State transition table example
#define STATES 4
#define INPUTS 3

int state = 0;
int transition_table[STATES][INPUTS] = {
  {1, 2, 3},
  {0, 2, 3},
  {1, 0, 3},
  {3, 3, 3}
};

int process_input(int input) {
  state = transition_table[state][input];
  return state;
}
    

This code updates the current state based on the input using a fixed table of next states.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: Accessing the transition table to find the next state.
• How many times: Once per input processed.

How Execution Grows With Input

Each input causes one table lookup and state update.

Input Size (n)	Approx. Operations
10	10 table lookups
100	100 table lookups
1000	1000 table lookups

Pattern observation: The work grows directly with the number of inputs processed.

Final Time Complexity

Time Complexity: O(n)

This means the time to process inputs grows in a straight line as you get more inputs.

Common Mistake

[X] Wrong: "The state transition table makes the program slower as the number of states grows because it searches through all states."

[OK] Correct: The program directly accesses the next state using indexes, so it does not search or loop through states. The time per input stays constant regardless of the number of states.

Interview Connect

Understanding how state machines work with tables helps you explain efficient designs in embedded systems and shows you can reason about how code scales with input size.

Self-Check

"What if the transition table was replaced by a loop searching for the next state? How would the time complexity change?"

Practice

1.

What is the main purpose of a state transition table in embedded C programming?

easy

A. To store global variables for the program

B. To map current states and events to the next states

C. To handle memory allocation dynamically

D. To perform arithmetic calculations efficiently

Solution

1. Step 1: Understand the role of state transition tables

   A state transition table is used to define how a system moves from one state to another based on events.

2. Step 2: Identify the correct purpose

   Mapping current states and events to next states is exactly what a state transition table does.

3. Final Answer:

   To map current states and events to the next states -> Option B

4. Quick Check:

   State transition table = map states and events [OK]

Hint: Think: state + event leads to next state [OK]

Common Mistakes:

• Confusing state tables with variable storage
• Thinking it manages memory
• Assuming it performs calculations

2.

Which of the following is the correct way to declare a state transition table in embedded C?

typedef enum {STATE_IDLE, STATE_RUN, STATE_STOP} State;
typedef enum {EVENT_START, EVENT_STOP} Event;

State state_table[][2] = { ... };

easy

A. State state_table[3][2];

B. int state_table[2][3];

C. State state_table[2][2];

D. Event state_table[3][2];

Solution

1. Step 1: Analyze the enums and dimensions

   There are 3 states and 2 events, so the table should have 3 rows (states) and 2 columns (events).

2. Step 2: Match the declaration with dimensions

   State state_table[3][2]; declares a State 2D array with 3 rows and 2 columns, matching the enums.

3. Final Answer:

   State state_table[3][2]; -> Option A

4. Quick Check:

   Rows = states, columns = events [OK]

Hint: Rows = states, columns = events in table declaration [OK]

Common Mistakes:

• Swapping rows and columns
• Using wrong data type for table
• Mismatching array size with enums

3.

Given the following code snippet, what will be the output?

typedef enum {IDLE, RUN, STOP} State;
typedef enum {START, STOP_EVENT} Event;

State state_table[3][2] = {
  {RUN, IDLE},
  {RUN, STOP},
  {IDLE, IDLE}
};

State current_state = IDLE;
Event event = START;

current_state = state_table[current_state][event];
printf("%d", current_state);

medium

A. 2

B. 0

C. 1

D. Compilation error

Solution

1. Step 1: Identify current state and event indices

   current_state = IDLE (0), event = START (0)

2. Step 2: Find next state from table

   state_table[0][0] = RUN (1)

3. Final Answer:

   1 -> Option C

4. Quick Check:

   state_table[0][0] = 1 (RUN) [OK]

Hint: Use enum values as indexes to find next state [OK]

Common Mistakes:

• Mixing event and state indices
• Assuming output is enum name, not int
• Forgetting zero-based indexing

4.

Identify the error in the following state transition table code snippet:

typedef enum {S0, S1} State;
typedef enum {E0, E1} Event;

State state_table[2][2] = {
  {S1, S0},
  {S0}
};

medium

A. Wrong enum type used for state_table

B. State enum values are not initialized

C. Array size should be [2][1] instead of [2][2]

D. Missing second element in second row of the table

Solution

1. Step 1: Check array initialization

   The first row has 2 elements, but the second row has only 1 element.

2. Step 2: Compare with declared size

   The array is declared as 2x2, so each row must have 2 elements.

3. Final Answer:

   Missing second element in second row of the table -> Option D

4. Quick Check:

   Array rows must match declared column size [OK]

Hint: Check all rows have correct number of elements [OK]

Common Mistakes:

• Ignoring incomplete row initialization
• Confusing enum initialization with array size
• Assuming default values fill missing elements

5.

You want to implement a state machine with states OFF, ON, and ERROR, and events POWER_ON, POWER_OFF, and FAULT. Using a state transition table approach, which of the following correctly defines the next state when the current state is ON and the event is FAULT?

typedef enum {OFF, ON, ERROR} State;
typedef enum {POWER_ON, POWER_OFF, FAULT} Event;

State state_table[3][3] = {
  {ON, OFF, ERROR},
  {ON, OFF, ???},
  {OFF, OFF, ERROR}
};

hard

A. ERROR

B. ON

C. OFF

D. POWER_OFF

Solution

1. Step 1: Identify current state and event indices

   Current state is ON (index 1), event is FAULT (index 2).

2. Step 2: Determine correct next state for fault event

   On fault, the system should move to ERROR state.

3. Step 3: Fill the missing table entry

   state_table[1][2] should be ERROR.

4. Final Answer:

   ERROR -> Option A

5. Quick Check:

   Fault event from ON leads to ERROR state [OK]

Hint: Fault event usually leads to ERROR state [OK]

Common Mistakes:

• Using event names as states
• Assigning ON or OFF instead of ERROR on fault
• Confusing event and state enums