📖 Scenario: You are building a simple control system for a home heating device. The device has two main modes: Off and On. When it is On, it can be in two sub-states: Heating or Idle. This is a real example of a hierarchical state machine where states contain sub-states.
🎯 Goal: Create a hierarchical state machine in Embedded C that models the heating device states and prints the current state and sub-state.
📋 What You'll Learn
Define an enum for main states: Off and On
Define an enum for sub-states: Heating and Idle
Create variables to hold the current main state and sub-state
Write a function to print the current main state and sub-state
💡 Why This Matters
🌍 Real World
Hierarchical state machines are used in embedded systems like home appliances, robots, and automotive controls to manage complex behaviors clearly and efficiently.
💼 Career
Understanding hierarchical state machines is essential for embedded software engineers working on real-time systems and device firmware.
Progress0 / 4 steps
1
Define main states enum and current state variable
Create an enum called MainState with values OFF and ON. Then create a variable called currentMainState of type MainState and set it to OFF.
Embedded C
Hint
Use typedef enum { OFF, ON } MainState; to define the main states.
2
Define sub-states enum and current sub-state variable
Create an enum called SubState with values HEATING and IDLE. Then create a variable called currentSubState of type SubState and set it to IDLE.
Embedded C
Hint
Define sub-states similarly to main states using typedef enum.
3
Write a function to print current states
Write a function called printCurrentState that prints the current main state and sub-state using printf. Use switch statements on currentMainState and currentSubState to print the state names as strings.
Embedded C
Hint
Use nested switch statements to print main and sub-states.
4
Print the current state in main
Write a main function that calls printCurrentState() to display the current states.
Embedded C
Hint
Call printCurrentState() inside main() and return 0.
Practice
(1/5)
1. What is the main benefit of using a hierarchical state machine in embedded C programming?
easy
A. It removes the need for any state transitions.
B. It eliminates the need for events to change states.
C. It allows states to run in parallel without interaction.
D. It organizes states into groups, making complex behavior easier to manage.
Solution
Step 1: Understand hierarchical state machine purpose
Hierarchical state machines group related states inside bigger states to simplify complex logic.
Step 2: Identify the benefit
This grouping helps share common actions and manage transitions more clearly.
Final Answer:
It organizes states into groups, making complex behavior easier to manage. -> Option D
Quick Check:
Grouping states = easier management [OK]
Hint: Think of states like folders inside folders for clarity [OK]
Common Mistakes:
Thinking events are not needed in hierarchical state machines
Believing states run independently without interaction
Assuming no transitions are required
2. Which of the following is the correct way to define a sub-state inside a parent state in embedded C code for a hierarchical state machine?
easy
A. typedef enum { STATE_PARENT, STATE_CHILD } State;
B. typedef enum { STATE_PARENT, STATE_CHILD } State; // with STATE_CHILD as a separate enum
C. typedef enum { STATE_PARENT, STATE_CHILD } State; // with STATE_CHILD nested inside STATE_PARENT logically
D. typedef enum { STATE_PARENT, STATE_CHILD } State; // with STATE_CHILD declared inside STATE_PARENT block
Solution
Step 1: Understand enum usage for states
In embedded C, states are often defined as enums. Logical nesting is done by naming and design, not by code nesting.
Step 2: Identify correct sub-state definition
typedef enum { STATE_PARENT, STATE_CHILD } State; // with STATE_CHILD nested inside STATE_PARENT logically correctly states that STATE_CHILD is logically nested inside STATE_PARENT, even though enums are flat.
Final Answer:
typedef enum { STATE_PARENT, STATE_CHILD } State; // with STATE_CHILD nested inside STATE_PARENT logically -> Option C
Quick Check:
Logical nesting, not code nesting [OK]
Hint: Enums are flat; nesting is logical, not syntax [OK]
Common Mistakes:
Trying to nest enums inside enums (not allowed in C)
Assuming code blocks define sub-states
Declaring sub-states as separate enums without relation
3. Given the following code snippet for a hierarchical state machine, what will be the output when event EVENT_START occurs in STATE_IDLE?
#define EVENT_START 1
typedef enum { STATE_IDLE, STATE_ACTIVE, STATE_ACTIVE_SUB } State;
State current_state = STATE_IDLE;
void handle_event(int event) {
switch (current_state) {
case STATE_IDLE:
if (event == EVENT_START) {
current_state = STATE_ACTIVE;
printf("Entered ACTIVE state\n");
}
break;
case STATE_ACTIVE:
if (event == EVENT_START) {
current_state = STATE_ACTIVE_SUB;
printf("Entered ACTIVE_SUB state\n");
}
break;
default:
printf("No action\n");
}
}
handle_event(EVENT_START);
medium
A. No action
B. Entered ACTIVE state
C. Entered ACTIVE_SUB state
D. Compilation error
Solution
Step 1: Check initial state and event
The current_state is STATE_IDLE. The event is EVENT_START.
Step 2: Follow switch-case logic for STATE_IDLE
On EVENT_START in STATE_IDLE, current_state changes to STATE_ACTIVE and prints "Entered ACTIVE state".
Final Answer:
Entered ACTIVE state -> Option B
Quick Check:
STATE_IDLE + EVENT_START = Entered ACTIVE state [OK]
Hint: Trace current state before event handling [OK]
Common Mistakes:
Assuming it jumps directly to sub-state
Ignoring initial state value
Confusing event handling in different states
4. Identify the error in this hierarchical state machine event handler code snippet:
#define EVENT_GO 1
typedef enum { STATE_TOP, STATE_SUB } State;
State current_state = STATE_TOP;
void handle_event(int event) {
switch (current_state) {
case STATE_TOP:
if (event = EVENT_GO) {
current_state = STATE_SUB;
printf("Moved to SUB state\n");
}
break;
case STATE_SUB:
printf("In SUB state\n");
break;
}
}
medium
A. Using assignment (=) instead of comparison (==) in if condition
B. Missing default case in switch statement
C. Incorrect enum values for states
D. No return statement in function
Solution
Step 1: Examine if condition in STATE_TOP case
The condition uses single '=' which assigns EVENT_GO to event instead of comparing.
Step 2: Understand impact of assignment in if
This causes the condition to always be true if EVENT_GO is non-zero, leading to unintended behavior.
Final Answer:
Using assignment (=) instead of comparison (==) in if condition -> Option A
Quick Check:
Use '==' for comparison, not '=' [OK]
Hint: Check if conditions for == vs = errors [OK]
Common Mistakes:
Confusing assignment and comparison operators
Ignoring missing default case (not critical here)
Expecting return in void function
5. You want to design a hierarchical state machine in embedded C where STATE_RUNNING has two sub-states: STATE_RUNNING_FAST and STATE_RUNNING_SLOW. Which approach correctly models this hierarchy and allows shared entry actions for STATE_RUNNING and specific actions for its sub-states?
hard
A. Define separate enums for all states and use nested switch-case to handle parent and sub-states with shared and specific actions.
B. Use a single enum with flat states and duplicate code for shared actions in each sub-state case.
C. Use multiple variables to track parent and sub-state separately without nesting logic.
D. Implement sub-states as independent states without any relation to the parent state.
Solution
Step 1: Understand hierarchical state machine design
Parent states group sub-states to share common behavior and allow specific sub-state actions.
Step 2: Identify correct coding approach
Defining separate enums for parent and sub-states and using nested switch-case allows shared entry actions for parent and specific actions for sub-states efficiently.
Final Answer:
Define separate enums for all states and use nested switch-case to handle parent and sub-states with shared and specific actions. -> Option A
Quick Check:
Nested switch-case models hierarchy best [OK]
Hint: Use nested switch-case for parent and sub-state actions [OK]
Common Mistakes:
Duplicating shared actions in sub-states
Tracking states separately without hierarchy
Ignoring parent-child relationship in code
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.