一、状态机基础：从概念到实战
大家好，我是你们的嵌入式架构课讲师。今天咱们聊聊状态机——这个嵌入式开发里绕不开的核心概念。
说实话，我刚开始做嵌入式那会儿，对状态机也是一知半解。直到有一次，我负责一个智能门锁项目，按键逻辑写得乱七八糟，各种if-else嵌套，最后调试到崩溃。后来重构成了状态机，代码瞬间清爽了。嗯，从那以后，我就成了状态机的忠实粉丝。
1.1 什么是状态机？
状态机，全称是有限状态机（Finite State Machine，FSM）。说白了，它就是一个有记忆的逻辑模型。
你想想看，现实中有很多系统，它的行为不仅取决于当前输入，还取决于它之前处于什么状态。比如电梯——你按了2楼按钮，电梯不会立刻开门，它得先判断自己当前在几楼、正在上行还是下行。这就是状态机的典型场景。
我个人习惯把状态机理解成：一个系统在任意时刻，只能处于有限个状态中的一个。当某个事件发生时，系统会从当前状态切换到另一个状态，同时执行一些动作。
核心定义：有限状态机是一个数学模型，它由有限个状态、状态之间的转移以及转移时执行的动作组成。
1.2 状态机的三要素
状态机有三个核心要素，我称之为「铁三角」：状态、事件、动作。缺一个，状态机就不完整。
（1）状态（State）
状态就是系统在某个时刻的稳定情形。比如一个LED灯，它可以处于「亮」或「灭」两种状态。一个通信协议栈，可能处于「空闲」、「连接中」、「已连接」、「断开中」等状态。
我在项目中遇到过一个问题：有人把状态定义得太细，导致状态数量爆炸。比如一个简单的按键消抖，他定义了「按下检测」、「按下确认」、「释放检测」、「释放确认」等8个状态。其实用4个就够了。记住：状态是稳定的、可区分的，不是每个瞬间都要定义一个状态。
（2）事件（Event）
事件是触发状态转移的外部或内部刺激。比如按键按下、定时器超时、数据接收完成、错误发生等等。
事件可以是有形的（比如GPIO电平变化），也可以是无形的（比如内部计数器的溢出）。我个人习惯把事件分为三类：
- 外部事件：来自系统外部，如按键、传感器信号
- 内部事件：系统自身产生，如定时器超时、任务完成
- 时间事件：经过特定时间后触发，如超时处理
小技巧：事件命名要清晰。我见过有人用 event_1、event_2 这种名字，三个月后自己都看不懂。建议用「对象_动作」的格式，比如 KEY_PRESSED、TIMER_EXPIRED、DATA_RECEIVED。
（3）动作（Action）
动作是状态转移时执行的具体操作。比如点亮LED、发送数据、记录日志、启动定时器等。
动作可以发生在三个时机：
- 进入状态时（entry action）
- 离开状态时（exit action）
- 转移过程中（transition action）
我曾经犯过一个错误：把动作写在了状态转移条件里，结果每次判断条件时都执行了一遍动作。嗯，调试了整整一个下午才发现。所以记住：动作只应该在状态转移时执行一次，不要在条件判断里重复执行。
1.3 状态机的应用场景
状态机在嵌入式系统里几乎无处不在。我随便列几个常见的：
| 应用领域 | 典型场景 | 状态示例 |
|---|---|---|
| 人机交互 | 按键扫描、触摸屏手势识别 | 空闲、按下、长按、双击 |
| 通信协议 | UART、I2C、SPI、TCP/IP | 空闲、寻址、数据、校验 |
| 电源管理 | 电池供电设备 | 运行、休眠、深度睡眠、唤醒 |
| 工业控制 | PLC、电机控制 | 停止、启动、加速、匀速、减速 |
| 安全系统 | 门禁、报警器 | 布防、撤防、报警、旁路 |
为什么状态机在这些场景里这么吃香？因为它的逻辑是确定性的。你想想看，用if-else写复杂的逻辑，很容易出现遗漏分支。而状态机把所有可能的状态和转移都画在了一张表里，一目了然。
避坑指南：我曾经接手过一个项目，原来的工程师用switch-case写了200多行的状态处理代码。每个case里又嵌套了if-else，完全看不出状态转移关系。后来我花了三天时间，重新画了状态转移图，重构成了表格驱动的状态机，代码量减少了一半，bug也少了很多。
所以我的建议是：先画图，再写代码。状态转移图就是你的设计文档。
1.4 状态机的知识体系
为了让大家更直观地理解状态机的核心逻辑，我画了一张图：
这张图把状态机的核心逻辑展示得很清楚：状态是基础，事件是驱动力，动作是结果。三者形成一个闭环，不断循环。
1.5 一个简单的代码示例
光说不练假把式。我写一个最简单的LED状态机，大家感受一下：
// LED状态机 - 简单示例
typedef enum {
LED_OFF,
LED_ON
} led_state_t;
typedef enum {
BUTTON_PRESSED,
TIMEOUT_5S
} led_event_t;
led_state_t current_state = LED_OFF;
void led_fsm(led_event_t event) {
switch (current_state) {
case LED_OFF:
if (event == BUTTON_PRESSED) {
LED_ON(); // 动作：点亮LED
current_state = LED_ON; // 状态转移
}
break;
case LED_ON:
if (event == BUTTON_PRESSED) {
LED_OFF(); // 动作：熄灭LED
current_state = LED_OFF;
} else if (event == TIMEOUT_5S) {
LED_OFF(); // 动作：自动熄灭
current_state = LED_OFF;
}
break;
default:
// 异常处理
current_state = LED_OFF;
break;
}
}这个例子虽然简单，但包含了状态机的全部要素。你想想看，如果不用状态机，用if-else怎么写？大概会写成这样：
if (led_is_on) {
if (button_pressed) {
turn_off_led();
} else if (timeout_5s) {
turn_off_led();
}
} else {
if (button_pressed) {
turn_on_led();
}
}看起来差不多？但一旦状态多了，比如加入「闪烁」、「呼吸灯」等模式，if-else就会迅速膨胀成意大利面条。而状态机只需要增加新的状态和转移，结构依然清晰。
核心总结：状态机不是银弹，但它能让复杂的状态逻辑变得可管理、可调试、可扩展。我做了十几年嵌入式，可以负责任地说：凡是涉及多步骤、多模式的逻辑，用状态机准没错。
好了，这一章就到这里。记住三要素：状态、事件、动作。下一章咱们聊聊状态机的两种实现方式——switch-case和表格驱动，看看哪种更适合你的项目。