4、状态机设计方法：状态图绘制、状态表定义、事件驱动与轮询的对比

在STM32机器人控制系统中，状态机是组织复杂行为逻辑的核心骨架。无论是简单的待机-巡航切换，还是涉及视觉识别与机械臂动作执行的完整任务链，状态机设计质量直接决定了代码的可读性、可维护性和实时响应能力。本章聚焦于状态机设计的三大核心方法：状态图的绘制规范、状态表的定义方法，以及事件驱动与轮询两种调度机制的对比选型。我们将从工程实践角度出发，结合STM32的资源约束（如中断优先级、定时器资源、外设响应时间），给出可落地的设计路径。

上图展示了状态机设计的三个核心工作产物之间的关系：状态图用于可视化状态转移逻辑，状态表将图的信息结构化以便编码实现，而事件驱动与轮询的选择则决定了状态转移如何被触发和执行。三者并非孤立，而是同一设计流程的不同视角。下面我们逐一深入。

4.1 状态图绘制：从行为需求到可视化模型

核心原理：状态图（Statechart）是一种描述系统在生命周期内所经历的状态序列的可视化建模工具。在STM32机器人中，每个状态代表一个稳定的行为模式，例如待机时电机停转、传感器低功耗运行；巡航时电机按设定速度前进、超声波传感器周期性测距。状态图的核心要素包括：状态节点（用圆角矩形表示）、转移箭头（带事件标签）、初始状态（实心圆点）和终止状态（同心圆）。绘制状态图的过程，本质上是将自然语言描述的需求（如“机器人遇到障碍物应停止”）转化为形式化的状态转移规则。

操作流程：绘制状态图建议遵循以下步骤：

1. 列出所有稳定状态：从系统需求中提取机器人可能处于的行为模式。例如待机、巡航、识别、动作执行、低电量保护、手动急停等。每个状态应具有明确的进入条件和退出条件。
2. 定义状态转移事件：识别触发状态变化的事件源。在STM32中，事件可能来自外部中断（如GPIO检测到碰撞开关）、定时器超时（如每100ms检查一次超声波距离）、串口接收（如遥控指令）或内部软件标志（如识别算法完成）。
3. 绘制转移箭头并标注事件：用箭头连接两个状态，在箭头上标注触发事件和可选的动作条件。例如从“巡航”到“识别”的转移，可标注“超声波距离 < 30cm”。
4. 检查完备性和冲突：确保每个状态在任意可能事件下都有明确的去向（包括停留在原状态），避免出现“未定义转移”导致系统卡死。

在绘制时，需要特别注意状态图的层次性。对于复杂系统，可以使用嵌套状态（如“巡航”内部包含“直行”、“左转”、“右转”子状态）来减少箭头交叉，提高可读性。但嵌套状态会增加实现复杂度，在STM32资源有限的情况下，建议先采用扁平状态图，待逻辑稳定后再考虑优化。

4.2 状态表定义：将图形转化为可编码的数据结构

核心原理：状态表（State Table）是状态图的表格化表达，它将状态转移关系组织为二维矩阵或列表形式，便于程序员直接编写代码。在STM32中，常用的实现方式有两种：二维状态转移表和事件-动作表。二维状态转移表的行表示当前状态，列表示事件，交叉单元格填写转移后的状态和需要执行的动作函数指针。这种方式的优点是查找效率高（O(1)时间复杂度），适合状态数较少（通常少于20个）的场景。

状态表定义步骤：

• 枚举所有状态和事件：使用C语言枚举类型定义，例如 typedef enum {STATE_IDLE, STATE_CRUISE, STATE_RECOGNIZE, STATE_ACT} State_t; 和 typedef enum {EVT_START, EVT_OBSTACLE, EVT_TARGET_CONFIRMED, EVT_ACTION_DONE} Event_t;。
• 定义动作函数原型：每个状态进入时需要执行的动作，例如 void Action_Idle_Enter(void);、void Action_Cruise_Update(void);。
• 填充转移表：对于每个状态和事件的组合，确定下一个状态和要执行的动作。如果某个事件在当前状态下无意义，可指向自身状态并执行空操作。

当前状态	事件：启动	事件：发现障碍	事件：目标确认	事件：动作完成
待机	巡航 / 启动电机	待机 / 无操作	待机 / 无操作	待机 / 无操作
巡航	巡航 / 无操作	识别 / 停止电机	巡航 / 无操作	巡航 / 无操作
识别	识别 / 无操作	识别 / 继续检测	动作执行 / 启动机械臂	识别 / 无操作
动作执行	动作执行 / 无操作	动作执行 / 无操作	动作执行 / 无操作	待机 / 复位所有外设

上表是一个典型的二维状态转移表。在实际编码中，可以使用结构体数组来存储这张表，每个元素包含 next_state 和 action_func 两个字段。主循环中只需根据当前状态和触发事件索引到对应元素，调用动作函数并切换状态即可。

4.3 事件驱动与轮询的对比：实时性与资源消耗的权衡

核心原理：状态机的运行需要事件来驱动转移。在STM32中，获取事件有两种基本方式：轮询（Polling）和事件驱动（Event-Driven）。轮询是指主循环不断扫描各个事件源（如读取GPIO电平、检查定时器标志、解析串口缓冲区），一旦发现条件满足就执行相应转移。事件驱动则依靠中断或外设的硬件信号来主动通知CPU，例如外部中断EXTI检测到碰撞开关变化、定时器更新中断触发周期性事件、DMA传输完成中断通知数据就绪。

对比分析：两种方式各有优劣，选择时需要综合考虑响应时间要求、CPU负载、代码复杂度和调试难度。

对比维度	轮询方式	事件驱动方式
响应延迟	取决于主循环扫描周期，通常为毫秒级	中断响应，微秒级，实时性高
CPU占用	持续占用CPU进行无效扫描，功耗较高	空闲时CPU可进入低功耗模式，仅在事件发生时唤醒
代码结构	简单直观，主循环顺序执行，易于调试	需要编写中断服务函数（ISR），注意共享数据保护
扩展性	事件源增多时，轮询周期变长，响应变慢	每个中断独立，扩展性好，但中断优先级管理复杂
典型应用	按键扫描、传感器周期读取（100ms以上）	急停信号、编码器计数、通信接收

操作流程：在实际工程中，通常采用混合策略：将紧急且低频的事件（如碰撞急停、遥控急停）配置为外部中断，实现立即响应；将周期性事件（如超声波测距、状态超时检查）放在定时器中断中设置标志位，主循环轮询标志位；将非实时性任务（如LCD显示刷新、日志输出）放在主循环中轮询执行。这种设计既保证了关键事件的实时性，又避免了中断服务函数过于复杂。

4.4 案例拆解：基于状态表的STM32巡逻机器人实现

下面通过一个完整的案例，展示如何将状态图、状态表和事件驱动/轮询策略结合起来，实现一个可运行的STM32机器人控制程序。

背景与约束：我们使用STM32F103C8T6最小系统板，搭载两个直流减速电机（通过PWM控制）、一个HC-SR04超声波传感器、一个碰撞开关（接PA0外部中断）和一个LED指示灯。系统要求：待机时LED慢闪（1Hz），巡航时LED常亮，识别时LED快闪（10Hz），动作执行时LED熄灭。碰撞开关触发时，无论处于何种状态，立即进入待机并停止电机。

初始现象与目标：初始代码采用纯轮询方式，主循环中依次读取超声波距离、检查碰撞开关电平、更新LED状态。实测发现，当超声波测距函数（需要发送触发信号并等待回波，最长阻塞约20ms）执行时，碰撞开关的响应延迟达到20ms以上，无法满足急停要求。目标是将急停响应时间缩短到1ms以内，同时保持代码结构清晰。

分析判断过程：问题根源在于轮询方式下，主循环被超声波测距的阻塞延时拖累。解决方案是将碰撞开关改为外部中断触发，超声波测距保留轮询但降低频率（每100ms一次），状态转移逻辑使用状态表驱动。

实际操作步骤：

1. 配置外部中断：将PA0配置为上升沿触发的外部中断，在中断服务函数中仅设置 emergency_stop_flag = 1;，不执行其他操作。
2. 定义状态表和事件枚举：按照4.2节的方法定义状态、事件和转移表。
3. 修改主循环：主循环首先检查 emergency_stop_flag，若置位则强制转移到待机状态并清除标志；然后检查定时器标志（每100ms），若超时则执行超声波测距并更新距离值；最后根据当前状态和最新事件执行状态转移。
4. 调整定时器：使用TIM2产生1ms时基中断，用于LED闪烁计时和超声波测距周期计时。

结果对比：改造后，碰撞开关的响应时间从原来的20ms降低到约50μs（中断响应时间），满足急停要求。CPU负载在待机时明显下降，因为主循环在没有事件时大部分时间处于WFI（等待中断）低功耗模式。代码行数从原来的150行增加到220行，但逻辑清晰度显著提升，后续添加新状态（如“低电量保护”）只需修改状态表和增加动作函数，无需改动主循环结构。

风险与代价：中断方式的代价是需要额外管理中断优先级和共享变量保护。在本案例中，emergency_stop_flag 被声明为 volatile uint8_t，并在主循环中读取后清零，避免了竞争条件。另外，中断服务函数必须保持极短，不能调用任何可能阻塞的函数（如printf）。

复盘经验：状态机设计的核心不是代码技巧，而是对系统行为的清晰建模。状态图帮助我们在编码前发现逻辑漏洞（例如遗漏了“低电量”状态），状态表让代码与设计文档一一对应，而事件驱动与轮询的合理分工则保证了实时性与资源消耗的平衡。建议在项目初期就绘制完整的状态图，并组织团队评审，避免后期返工。