4、状态机建模方法：状态转移图、状态转移表、伪代码

状态机建模，说白了就是把你的逻辑思路「画」出来、「写」清楚。很多新手工程师上来就写代码，写到一半发现状态漏了、跳转乱了，回头改得头皮发麻。我个人的习惯是——先建模，再编码。磨刀不误砍柴工。

这一章，我们聊三种最主流的建模方法：状态转移图、状态转移表、伪代码。它们各有各的脾气，也各有各的用武之地。

4.1 状态转移图（State Transition Diagram）

状态转移图，是嵌入式工程师的「通用语言」。你拿张纸，画几个圈，连几条线，整个系统的行为就一目了然了。我在项目中遇到过好几次，团队里硬件、软件、测试各说各话，最后大家对着图一聊，问题全清楚了。

4.1.1 核心要素

• 状态（State）：用圆角矩形或圆圈表示。每个状态代表系统的一个稳定阶段。
• 转移（Transition）：用带箭头的线表示。线上标注触发条件和动作。
• 初始状态（Initial State）：用一个小黑点加箭头指向起始状态。
• 终止状态（Final State）：用双层圆圈表示，不是所有状态机都有。

4.1.2 实战案例：按键消抖状态机

我们拿一个最常见的例子——按键消抖。你想想看，机械按键按下时会有抖动，如果不做处理，一次按下可能被误判成十几次。用状态机来处理，干净利落。

状态定义：
  IDLE      —— 空闲状态，等待按键按下
  DEBOUNCE  —— 消抖状态，等待抖动结束
  PRESSED   —— 确认按下状态
  RELEASE   —— 释放等待状态

4.2 状态转移表（State Transition Table）

图虽然直观，但一旦状态多了（比如超过 10 个），图就会变成一团乱麻。这时候，状态转移表就派上用场了。说白了，就是用表格把「当前状态 + 事件 → 下一状态 + 动作」的关系列清楚。

4.2.1 标准表格结构

当前状态	事件	条件	下一状态	输出动作
IDLE	按键按下	无	DEBOUNCE	启动定时器
DEBOUNCE	定时器超时	按键仍按下	PRESSED	触发按键事件
DEBOUNCE	定时器超时	按键已释放	IDLE	停止定时器
PRESSED	按键释放	无	RELEASE	启动释放定时器
RELEASE	定时器超时	无	IDLE	停止定时器

4.2.2 表格的扩展用法

在实际项目中，我习惯在表格里再加两列：优先级和超时处理。特别是当多个事件可能同时发生时，优先级能帮你决定先处理谁。

当前状态	事件	优先级	下一状态	超时动作
DEBOUNCE	按键按下	高	DEBOUNCE	重置定时器
DEBOUNCE	定时器超时	低	PRESSED	无

4.3 伪代码（Pseudo Code）

图和表都有了，但最终还是要落到代码上。伪代码就是图和表之间的桥梁。它不像真实代码那样拘泥于语法，但又能清晰地表达逻辑。

4.3.1 伪代码的写法规范

• 用 STATE_XXX 表示状态常量
• 用 EVENT_XXX 表示事件常量
• 用 switch-case 或 if-else 表达状态转移
• 注释要写清楚「为什么」而不是「是什么」

// 按键消抖状态机 - 伪代码
enum State {
  STATE_IDLE,
  STATE_DEBOUNCE,
  STATE_PRESSED,
  STATE_RELEASE
}

State currentState = STATE_IDLE

function handleKeyEvent(event) {
  switch (currentState) {
    case STATE_IDLE:
      if (event == EVENT_KEY_PRESSED) {
        startTimer(DEBOUNCE_MS)   // 启动消抖定时器
        currentState = STATE_DEBOUNCE
      }
      break

    case STATE_DEBOUNCE:
      if (event == EVENT_TIMER_EXPIRED) {
        if (isKeyStillPressed()) {
          triggerKeyEvent()       // 确认按键有效
          currentState = STATE_PRESSED
        } else {
          // 抖动导致的误触发，回到空闲
          currentState = STATE_IDLE
        }
      }
      break

    case STATE_PRESSED:
      if (event == EVENT_KEY_RELEASED) {
        startTimer(RELEASE_MS)    // 释放消抖
        currentState = STATE_RELEASE
      }
      break

    case STATE_RELEASE:
      if (event == EVENT_TIMER_EXPIRED) {
        currentState = STATE_IDLE
      }
      break
  }
}

4.3.2 伪代码的进阶技巧

我做了十几年嵌入式，总结出几个伪代码的实用技巧：

• 状态入口/出口动作：在进入或离开某个状态时，加上 entry() 和 exit() 标注。比如进入 DEBOUNCE 时启动定时器，退出时停止定时器。
• 状态内循环：如果某个状态需要持续做某件事（比如等待数据），用 do { ... } while (condition) 表达。
• 异常处理：每个状态都要考虑「如果事件不合法怎么办」。我习惯加一个 default: 分支，记录错误日志。

// 带入口/出口动作的伪代码
case STATE_DEBOUNCE:
  entry: startTimer(DEBOUNCE_MS)   // 进入时启动
  if (event == EVENT_TIMER_EXPIRED) {
    // 处理逻辑...
    exit: stopTimer()              // 退出时停止
    currentState = STATE_PRESSED
  }
  break

4.4 三种建模方法的对比

方法	优点	缺点	适用场景
状态转移图	直观、沟通效率高	状态多时杂乱	设计初期、团队评审
状态转移表	完整、无遗漏、易检查	不够直观	详细设计、代码生成
伪代码	接近代码、可执行性强	需要一定抽象能力	编码前最后一步

你想想看，这三种方法其实是一个递进关系：先用图画轮廓，再用表填细节，最后用伪代码搭桥到真实代码。我在实际项目中，通常三样都用——画图给团队看，做表给自己查，写伪代码给编码用。