嵌入式状态机SimpleFSM实战：告别标志位地狱

很多嵌入式项目一开始都很简单：一个按键、一个 LED、一个超时判断、一个错误处理。写着写着，loop() 里就堆满了 if、else if、标志位、计时变量和各种“临时补丁”。代码虽能运行，但几周后再改需求时，你还敢保证改一个分支不会牵连其他逻辑吗？

SimpleFSM 要解决的正是这个问题。它是一个面向 Arduino、ESP8266、ESP32 等平台的有限状态机库。对于嵌入式软件来说，它特别适合用来管理 UI 菜单、设备启动流程、通信连接流程、电机控制流程、故障保护、低功耗策略等场景。如果想深入了解 C++ 在嵌入式开发中的更多实践，可以查阅相关 C/C++ 技术资源。

SimpleFSM 是什么

github 链接：https://github.com/LennartHennigs/SimpleFSM

有限状态机，简单说就是：系统在任意时刻只处于一个明确状态；外部事件、定时条件或内部判断会触发状态转换；转换时可以执行动作。

SimpleFSM 把这套模型封装成几个核心对象：State 表示状态，Transition 表示事件触发的转换，TimedTransition 表示定时转换，SimpleFSM 负责保存状态表、转换表并在 loop() 中调度。

它能处理哪些问题

第一类是流程型问题。比如设备上电后要自检，自检成功进入待机，用户按键后开始运行，运行完成后回到待机，出错后进入故障态。这类逻辑如果靠多个布尔变量维护，很快就会出现“变量组合爆炸”。状态机则要求你把每个状态和转换条件列出来。

第二类是时间型问题。嵌入式系统里常见“进入某状态后 3 秒自动下一步”“无人操作 30 秒进入休眠”“通信连接超过 5 秒未成功就超时”。

第三类是安全型问题。急停、故障、复位、超时保护往往要求“无论系统在哪里，都能立即进入安全状态”。SimpleFSM 提供全局转换，可以从任意状态跳转到指定状态，适合急停、错误处理、系统复位、低功耗入口。

使用 SimpleFSM 的基本步骤

使用时通常分五步：定义状态、定义事件编号、定义转换、设置初始状态、在 loop() 中周期调用 fsm.run()。如果有按键、串口命令、传感器报警，就在检测到事件时调用 fsm.trigger(EVENT_ID)；如果有自动超时，就用 TimedTransition；如果转换需要先判断条件，就加 Guard 函数。

需要注意一个工程细节：State 对象要放在全局或静态生命周期中，不要在普通函数里临时创建后把指针交给 FSM。在当前 2.x 用法中，建议使用 State*[] 形式添加状态，并且 fsm.add() 会返回 FSMError，工程代码中建议检查返回值。

Demo：智能风扇控制器

下面这个 demo 模拟一个小型智能风扇控制器。

它有 5 个状态：BOOT 上电自检、IDLE 待机、RUNNING 运行、SLEEP 休眠、FAULT 故障。

按键可启动/停止风扇；运行 10 秒后自动回到待机；待机 30 秒后自动休眠；任意状态检测到故障都会进入 FAULT；故障解除后按键复位回到 IDLE。

为了展示 Guard，IDLE -> RUNNING 只有在供电正常且没有故障时才允许发生。

这里假设故障输入为低电平有效，高电平表示故障解除；阅读代码时，可以先看 State、Transition 和 TimedTransition 三张表，硬件 IO 部分不必逐行深究。

Demo 解析

这段代码最重要的不是“风扇”，而是结构。State 把每个模式的入口动作放在一起，例如进入 RUNNING 就打开风扇，进入 FAULT 就立即关风扇并锁存错误。这样做的好处是：状态动作跟状态本身绑定，不会散落在多个 if 分支里。

Transition 表示事件驱动转换。比如 IDLE -> RUNNING 由 EVT_START 触发，但还要经过 canStart() 检查。这个 Guard 非常适合表达“允许启动的前置条件”，例如电压正常、温度正常、互锁开关闭合。业务代码不用到处判断 powerOK，状态机只在转换边上判断。

TimedTransition 表示非阻塞定时转换。BOOT -> IDLE 是 1 秒自检完成，RUNNING -> IDLE 是自动停止，IDLE -> SLEEP 是空闲休眠。它们都依赖 fsm.run(20) 周期调度，所以主循环仍然可以继续响应故障输入和按键，不会被 delay() 卡住。

全局转换是安全控制的关键。fsm.addGlobalTransition(&fault, EVT_FAULT) 的含义是：只要触发 EVT_FAULT，无论当前在 BOOT、IDLE、RUNNING 还是 SLEEP，都跳到 FAULT。实际产品里，过流、过温、急停、门禁打开等事件都可以这样建模。它把“安全优先级最高”从代码习惯变成了明确的状态机规则。

和传统写法相比

传统 if-else 写法的优势是上手快，少量状态时很直接。状态机并不是要替代所有分支判断，而是适合状态数量、事件数量和异常路径同时增长的场景。

当状态超过 4 个，事件超过 5 个，再叠加超时、错误、复位、低功耗，维护成本会快速上升。状态机写法一开始多了建模步骤，却能把复杂度固定在状态图和转换表里。

另外，SimpleFSM 可以通过 getDotDefinition() 导出状态图定义，便于评审和调试。

它还提供一些工程上很实用的能力：可以设置 final state 和 finished handler，适合一次性流程；可以通过 getState()、getPreviousState()、isInState() 查询当前状态；可以通过 getLastError()、getErrorString() 处理配置错误；内部对状态数、普通转换数、定时转换数有安全上限，避免过度分配内存。

嵌入式项目中的使用建议

第一，先画状态图，再写代码。只要你无法清楚画出系统有哪些状态、哪些事件、哪些异常路径，就说明代码里也会模糊。

第二，事件编号建议用 enum 管理，并从 1 开始，避免 0 被误用。

第三，状态回调里只做“进入该状态必须做的事”，不要把所有业务都塞进回调，否则状态机也会变成另一种大泥球。

第四，fsm.run() 要持续调用，尤其是用了 TimedTransition 时。它不是阻塞等待，而是每次进来检查时间是否到了。

第五，Guard 函数要短小、确定，最好只读取当前条件，不要在 Guard 里做复杂副作用。

第六，安全相关转换优先考虑全局转换，把故障态设计成“默认安全输出”，例如关电机、关加热、锁存报警。

对嵌入式开发者来说，掌握 SimpleFSM 这类轻量状态机库，往往比多写几层 if-else 更接近可维护的软件设计。如果你正需要更系统的状态管理方案，欢迎常来云栈社区的技术文档板块看看，那里沉淀了大量硬件与底层开发的避坑指南。