第一章：状态机基础——从零开始理解状态机
大家好，欢迎来到《嵌入式状态机编程》的第一课。
说实话，我刚开始做嵌入式开发那会儿，对状态机也没什么概念。那时候写代码就是一堆 if-else 堆起来，程序跑着跑着就乱了。后来有个老工程师跟我说：「小伙子，你试试状态机。」嗯，从那以后，我的代码世界就变了。
今天我们就来聊聊状态机最基础的东西。别担心，没有复杂的公式，只有实实在在的经验。
什么是状态机？
状态机，全称是有限状态机（Finite State Machine，FSM）。说白了，它就是一个「有固定状态、能根据事件跳转」的模型。
你想想看，我们生活中的很多东西都是状态机。比如电梯：它要么在「静止」状态，要么在「运行」状态。按了楼层按钮（事件），它就从静止变成运行。到了目标楼层（另一个事件），它又回到静止。
在嵌入式系统里，状态机就是用来描述这种「状态-事件-动作」关系的工具。我个人的习惯是，只要遇到需要分步骤处理的任务，第一个想到的就是状态机。
核心定义：有限状态机是一个数学模型，它由有限个状态、有限个输入事件、以及状态转移规则组成。在任何时刻，系统只能处于其中一个状态。
状态机的三要素
状态机有三个核心要素，我管它叫「三剑客」：状态、事件、动作。缺一个都不行。
1. 状态（State）
状态就是系统在某个时刻的「样子」。比如一个按键：它可以是「按下」状态，也可以是「释放」状态。一个 LED 灯：可以是「亮」或「灭」。
我在项目中遇到过一个问题：有个同事把状态定义得太细了，搞了二十多个状态。结果代码比 if-else 还难维护。所以我的建议是：状态要够用，但别滥用。一般一个模块的状态控制在 5-10 个以内比较合理。
2. 事件（Event）
事件是触发状态变化的「导火索」。没有事件，状态机就是一潭死水。
事件可以来自外部，比如用户按了按钮、传感器检测到信号；也可以来自内部，比如定时器超时、数据接收完成。
我记得有一次调试一个通信协议栈，发现状态机卡住了。查了半天，原来是一个事件被重复触发了，导致状态来回跳。嗯，这里要注意：事件处理一定要做防抖和去重。
3. 动作（Action）
动作是状态转移时执行的「操作」。比如从「空闲」状态进入「忙碌」状态时，点亮一个指示灯；或者从「接收」状态进入「处理」状态时，启动一个定时器。
动作可以发生在三个地方：进入状态时、离开状态时、或者状态转移过程中。我个人习惯把「进入动作」和「离开动作」分开写，这样逻辑更清晰。
| 要素 | 含义 | 举例 |
|---|---|---|
| 状态 | 系统当前所处的模式 | 空闲、忙碌、错误 |
| 事件 | 触发状态变化的条件 | 按键按下、定时器超时 |
| 动作 | 状态变化时执行的操作 | 点亮LED、发送数据 |
状态机在嵌入式中的应用场景
状态机在嵌入式领域简直是无处不在。我做了十几年固件，几乎每个项目都用到了状态机。下面说几个典型的场景。
场景一：按键消抖与长按检测
按键处理是状态机的经典应用。一个按键有「按下」、「抖动」、「稳定按下」、「释放」等多个状态。用状态机来处理，代码清晰又可靠。
我曾经用纯 if-else 写过按键处理，结果抖动问题搞了三天没搞定。换成状态机后，两个小时就搞定了。你想想看，这就是工具选对的好处。
场景二：通信协议解析
像 UART、I2C、SPI 这些通信协议，数据是一帧一帧传过来的。用状态机来解析帧头、帧尾、数据长度、校验码，再合适不过了。
我记得有个项目是做 Modbus 协议栈，状态机写了不到 200 行代码，就把整个协议解析搞定了。要是用传统方法，至少得 500 行以上。
场景三：设备工作流程管理
很多嵌入式设备都有固定的工作流程：初始化 -> 待机 -> 运行 -> 暂停 -> 停止。每个阶段做的事情不一样，用状态机来管理流程，代码的可读性和可维护性都大大提升。
我建议你在设计这类系统时，先画一张状态转移图。把状态、事件、动作都标清楚，再开始写代码。这样能避免很多后期返工。
个人小技巧：刚开始学状态机时，可以用枚举类型来定义状态，用 switch-case 来实现状态转移。等熟练了，再考虑用函数指针表或者状态表驱动的方式。别一上来就搞复杂了。
一个简单的状态机示例
光说不练假把式。我们来看一个最简单的状态机代码——LED 灯控制。
// 状态定义
typedef enum {
LED_OFF,
LED_ON,
LED_BLINK
} led_state_t;
// 事件定义
typedef enum {
EVT_BUTTON_PRESS,
EVT_TIMER_TICK
} event_t;
// 状态机处理函数
void led_state_machine(event_t event) {
static led_state_t current_state = LED_OFF;
switch (current_state) {
case LED_OFF:
if (event == EVT_BUTTON_PRESS) {
current_state = LED_ON;
// 动作：点亮LED
gpio_set_level(LED_PIN, 1);
}
break;
case LED_ON:
if (event == EVT_BUTTON_PRESS) {
current_state = LED_BLINK;
// 动作：启动闪烁定时器
timer_start(BLINK_TIMER, 500);
}
break;
case LED_BLINK:
if (event == EVT_BUTTON_PRESS) {
current_state = LED_OFF;
// 动作：关闭LED和定时器
gpio_set_level(LED_PIN, 0);
timer_stop(BLINK_TIMER);
} else if (event == EVT_TIMER_TICK) {
// 动作：翻转LED
gpio_toggle(LED_PIN);
}
break;
}
}这段代码虽然简单，但包含了状态机的全部要素。你仔细看看：状态是 LED_OFF、LED_ON、LED_BLINK；事件是按键按下和定时器滴答；动作是点亮、关闭、翻转 LED。
避坑指南：我曾经犯过一个错误——在状态机里直接调用延时函数（比如 HAL_Delay）。结果整个系统卡死了，因为延时期间无法响应其他事件。记住：状态机里的动作一定要是非阻塞的。如果需要延时，用定时器事件来代替。
小结
好了，第一章的内容就到这里。我们讲了三个重点：
- 状态机是什么——一个有限状态的数学模型
- 三要素：状态、事件、动作
- 嵌入式中的应用场景：按键、通信、流程管理
下一章我们会深入讲状态机的两种实现方式：switch-case 和状态表驱动。到时候我会分享一些实际项目中的代码模板，保证你学了就能用。
记住我这句话：状态机不是万能的，但没有状态机是万万不能的。尤其是在嵌入式这种资源受限、实时性要求高的环境里，状态机是你最可靠的伙伴。
我们下章见。