State machine design for Arduino - Deep Dive

Overview - State machine design for Arduino

What is it?

A state machine is a way to organize a program by dividing its behavior into different states. Each state represents a specific mode or condition of the system, and the program moves between these states based on events or conditions. In Arduino projects, state machines help manage complex behaviors like controlling motors, reading sensors, or handling user inputs in an organized way. This approach makes the code easier to understand, maintain, and expand.

Why it matters

Without state machines, Arduino programs can become messy and hard to follow, especially when handling many tasks or conditions. This can lead to bugs and unpredictable behavior. Using state machines helps keep the program organized, making it reliable and easier to fix or improve. It also allows the Arduino to react quickly and correctly to changes, which is important in real-world projects like robots or home automation.

Where it fits

Before learning state machines, you should understand basic Arduino programming, including variables, functions, and control structures like if-else and loops. After mastering state machines, you can explore more advanced topics like event-driven programming, interrupts, and multitasking on Arduino.

Mental Model

Core Idea

A state machine is like a map of all possible modes a system can be in, with clear rules for moving from one mode to another based on events.

Think of it like...

Imagine a traffic light at an intersection. It has states like green, yellow, and red. The light changes from one state to another in a fixed order depending on time or sensors. This keeps traffic flowing smoothly and safely.

┌───────────┐     timer/event     ┌───────────┐
│   State   │ ───────────────▶ │   State   │
│    A      │                  │    B      │
└───────────┘                  └───────────┘
     ▲                              │
     │          another event       │
     └──────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Arduino Program Flow

Concept: Learn how Arduino runs code repeatedly in a loop and how decisions are made using if-else statements.

Arduino programs have two main parts: setup() runs once at the start, and loop() runs over and over. Inside loop(), you can check conditions using if-else to decide what to do next. For example, turning an LED on or off based on a button press.

Result

You can control simple behaviors by checking conditions repeatedly.

Knowing how Arduino runs code in a loop helps you see why organizing behavior into states can make complex decisions clearer.

2

Foundation

What is a State in Programming?

Concept: A state is a named condition or mode that a program can be in at any time.

Think of a state as a label for what the Arduino is doing now. For example, a robot might have states like 'Moving Forward', 'Turning Left', or 'Stopped'. The program behaves differently depending on the current state.

Result

You understand that states help describe what the system is doing at a moment.

Recognizing states as distinct modes helps break down complex behavior into manageable parts.

3

Intermediate

Implementing States with Variables

🤔Before reading on: do you think using numbers or words to represent states is better? Commit to your answer.

Concept: Use a variable to store the current state and change it to move between states.

Create an integer or enum variable to hold the current state. Use a switch-case or if-else structure inside loop() to run code based on the state. Change the state variable when certain conditions happen, like a button press or timer.

Result

The Arduino can switch behaviors by changing the state variable.

Using a variable to track state makes the program's flow clear and easy to control.

4

Intermediate

Handling State Transitions Clearly

🤔Before reading on: do you think transitions should happen anywhere in the code or only in one place? Commit to your answer.

Concept: Keep state changes organized and predictable by handling transitions in a controlled way.

Inside the state handling code, check for events that cause a state change. Update the state variable only when those events occur. Avoid changing states in multiple scattered places to prevent confusion.

Result

State transitions become easier to track and debug.

Organizing transitions prevents bugs caused by unexpected or conflicting state changes.

5

Intermediate

Using Enums for Readable States

Concept: Use enum types to name states instead of numbers for clearer code.

Define an enum with names like IDLE, RUNNING, ERROR. Use these names in your code instead of numbers. This makes the code easier to read and understand.

Result

Code is more self-explanatory and less error-prone.

Readable state names help maintain and share code with others.

6

Advanced

Adding Entry and Exit Actions

🤔Before reading on: do you think actions should happen only while in a state or also when entering and leaving it? Commit to your answer.

Concept: Perform specific actions when entering or leaving a state to manage setup and cleanup.

Track the previous state and detect when the state changes. Run code when entering a new state (like turning on an LED) or leaving a state (like stopping a motor). This keeps state behavior clean and predictable.

Result

States manage their own setup and teardown, improving reliability.

Entry and exit actions prevent side effects from leaking between states.

7

Expert

Using Function Pointers for State Actions

🤔Before reading on: do you think storing state behavior in functions improves flexibility? Commit to your answer.

Concept: Store each state's behavior in a separate function and call it via a pointer for cleaner and modular code.

Create functions for each state’s behavior. Use a function pointer variable to call the current state’s function inside loop(). Change the pointer to switch states. This approach separates code and makes adding states easier.

Result

Code becomes modular, easier to extend, and reduces bugs.

Function pointers enable flexible and scalable state machine design.

Under the Hood

At runtime, the Arduino repeatedly runs the loop() function. The state machine uses a variable to remember the current state. Based on this state, the program executes specific code blocks. When events occur, the state variable updates to a new value, changing the program’s behavior on the next loop. This simple memory and decision process creates the illusion of the Arduino 'remembering' what it is doing and reacting accordingly.

Why designed this way?

State machines were designed to manage complex systems by breaking behavior into clear, manageable parts. Early embedded systems had limited memory and processing power, so simple state variables and switch-case logic were efficient. This design avoids complicated nested conditions and makes debugging easier. Alternatives like event-driven or object-oriented designs exist but can be heavier for small microcontrollers.

┌───────────────┐
│   loop()      │
│  ┌─────────┐  │
│  │Check    │  │
│  │State    │  │
│  └─────────┘  │
│       │       │
│       ▼       │
│  ┌─────────┐  │
│  │Run      │  │
│  │State    │  │
│  │Code     │  │
│  └─────────┘  │
│       │       │
│       ▼       │
│  ┌─────────┐  │
│  │Update   │  │
│  │State    │  │
│  └─────────┘  │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think a state machine always needs many states? Commit to yes or no.

Common Belief: State machines must have many states to be useful.

Reality: Even a simple system with two or three states benefits from a state machine design.

Why it matters: Thinking state machines are only for complex systems may prevent beginners from using them to organize simple but important behaviors.

Quick: Do you think state machines automatically handle timing and delays? Commit to yes or no.

Common Belief: State machines manage timing and delays internally without extra code.

Reality: State machines only manage states and transitions; timing must be handled explicitly by the programmer.

Why it matters: Assuming timing is automatic can cause bugs where states change too fast or too slow.

Quick: Do you think you can change states anywhere in the code without problems? Commit to yes or no.

Common Belief: You can change the current state variable anywhere in the program safely.

Reality: Changing states in many places can cause unpredictable behavior and bugs; transitions should be controlled and centralized.

Why it matters: Uncontrolled state changes make programs hard to debug and maintain.

Quick: Do you think function pointers for states are too complex for Arduino beginners? Commit to yes or no.

Common Belief: Using function pointers for state machines is too advanced and unnecessary.

Reality: Function pointers provide a clean and scalable way to manage states and are practical even on Arduino.

Why it matters: Avoiding function pointers limits code modularity and makes adding new states harder.

Expert Zone

1

State machines can be combined with timers and interrupts to handle asynchronous events efficiently.

2

Using hierarchical state machines allows grouping related states, reducing complexity in large projects.

3

Function pointers can be replaced with C++ classes and polymorphism for more advanced Arduino projects using C++ features.

When NOT to use

State machines are not ideal for highly parallel tasks or when real-time multitasking is required; in such cases, consider using RTOS (Real-Time Operating Systems) or event-driven frameworks.

Production Patterns

In real Arduino projects, state machines often control device modes like sleep, active, error recovery, and user interaction. They are combined with sensor readings and communication protocols to build robust embedded systems.

Connections

Finite Automata (Theory of Computation)

State machines in Arduino are practical implementations of finite automata concepts.

Understanding finite automata theory helps grasp the limits and power of state machines in programming.

Workflow Management in Business

Both use states and transitions to manage processes step-by-step.

Seeing state machines as workflows clarifies how complex tasks are broken into simple steps with clear rules.

Human Decision Making

Humans often operate like state machines, switching mental states based on events.

Recognizing this similarity helps design intuitive and predictable systems that match human expectations.

Common Pitfalls

#1 Changing states in many scattered places causing unpredictable behavior.

Wrong approach:

if (buttonPressed) { state = RUNNING; } // here
...
if (sensorTriggered) { state = ERROR; } // somewhere else

Correct approach:

switch(state) {
case IDLE:
if (buttonPressed) state = RUNNING;
break;
case RUNNING:
if (sensorTriggered) state = ERROR;
break;
}

Root cause:

Not centralizing state changes leads to conflicting updates and hard-to-find bugs.

#2 Using numbers directly for states making code hard to read and maintain.

Wrong approach:

int state = 1; // 1 means RUNNING
if (state == 1) { /* do something */ }

Correct approach:

enum State { IDLE, RUNNING, ERROR };
State state = IDLE;
if (state == RUNNING) { /* do something */ }

Root cause:

Using raw numbers hides meaning and increases errors.

#3 Assuming delay() can be used inside states without blocking other tasks.

Wrong approach:

case RUNNING:
delay(1000); // wait 1 second
state = IDLE;
break;

Correct approach:

case RUNNING:
if (millis() - startTime >= 1000) state = IDLE;
break;

Root cause:

delay() stops the whole program, blocking state machine responsiveness.

Key Takeaways

State machines organize program behavior into clear modes with defined transitions, making complex Arduino projects manageable.

Using variables or enums to represent states and controlling transitions centrally prevents bugs and improves code clarity.

Entry and exit actions for states help manage setup and cleanup, keeping behavior predictable.

Advanced techniques like function pointers or hierarchical states increase flexibility and scalability for larger projects.

Understanding state machines connects programming to broader concepts in computation, workflows, and human decision-making.