📚 课程目录第3章驱动层状态机设计原则

驱动层状态机设计原则：四个核心法则

做嵌入式驱动开发这些年，我踩过最多的坑，就是状态机写得乱七八糟。一个简单的按键驱动，愣是能写出三四种不同的状态流转方式。后来我总结出四条原则，说白了就是让状态机变得可读、可改、可维护。今天咱们一条一条聊。

单一职责原则：一个状态只做一件事

先问个问题：你的状态机里，一个状态是不是既在等数据，又在做超时判断，还在处理错误？如果是，那多半要出问题。

单一职责原则要求：每个状态只负责一个明确的行为。比如 SPI 驱动里的状态，就应该是：

SPI_IDLE —— 等待命令
SPI_TX —— 发送数据
SPI_RX —— 接收数据
SPI_ERROR —— 错误处理

别把「发送并等待应答」塞到一个状态里。我见过有人把发送、接收、超时重试全写在一个状态里，结果调试时根本分不清当前到底卡在哪一步。

判断标准：如果你给状态起名字时需要加「和」「与」「并」这些字，说明职责过重了。

开闭原则：对扩展开放，对修改关闭

这个原则在驱动层尤其重要。硬件换了个型号，你的状态机就得大改？那肯定不行。

开闭原则的核心是：新增功能时，尽量不修改已有状态和转移逻辑。怎么做？我习惯用状态表 + 回调函数的方式：

// 状态表结构
typedef struct {
    State_t      state;
    State_t      next_state;
    Event_t      trigger_event;
    Status_t   (*action)(void *param);
} StateTransition_t;

// 状态表实例
static StateTransition_t g_spi_trans_table[] = {
    {SPI_IDLE,  SPI_TX,   EVT_START_TX,  spi_start_tx},
    {SPI_TX,    SPI_RX,   EVT_TX_DONE,   spi_start_rx},
    {SPI_RX,    SPI_IDLE, EVT_RX_DONE,   spi_process_data},
    {SPI_IDLE,  SPI_ERROR, EVT_TIMEOUT,  spi_handle_error},
    // 新增状态只需在表末尾追加
    {SPI_IDLE,  SPI_CFG,  EVT_CONFIG,    spi_enter_config},
};

你看，新增一个 SPI_CFG 配置状态，只需要在表里加一行，原有的状态和转移逻辑完全不动。这就是开闭原则的落地方式。

我的经验：状态表用 const 数组放在 Flash 里，既省 RAM，又方便做单元测试。我曾经在一个项目里用这种方式，三天内适配了三款不同的传感器，改的只是状态表里的回调函数指针。

状态显式化原则：别藏着掖着

这个原则最容易被忽略。很多人喜欢用位掩码、枚举值、甚至 int 变量来「隐式」表示状态。结果呢？代码里到处都是 if (flags & 0x02) 这种鬼东西。

状态显式化原则要求：每个状态必须有明确的符号名称，并且状态机当前状态必须能通过一个变量直接读出。

我推荐的做法：

用 typedef enum 定义所有状态，不要用宏定义
状态变量用 volatile 修饰，防止编译器优化掉
调试时直接打印状态名，而不是打印数字再查表

typedef enum {
    UART_IDLE    = 0,
    UART_TX_BUSY = 1,
    UART_RX_BUSY = 2,
    UART_ERROR   = 3,
    UART_TIMEOUT = 4
} UartState_t;

volatile UartState_t g_uart_state = UART_IDLE;

// 调试时直接输出状态名
const char* uart_state_name(UartState_t state) {
    switch(state) {
        case UART_IDLE:    return "UART_IDLE";
        case UART_TX_BUSY: return "UART_TX_BUSY";
        case UART_RX_BUSY: return "UART_RX_BUSY";
        case UART_ERROR:   return "UART_ERROR";
        case UART_TIMEOUT: return "UART_TIMEOUT";
        default:           return "UNKNOWN";
    }
}

避坑指南：我曾经在一个项目里用位域来表示多个状态，结果调试器里根本看不清当前状态。后来花了整整两天才把状态机理清楚。从那以后，我再也不用隐式状态了。

状态转移的确定性：同一个输入，同一个结果

这是状态机最核心的性质。说白了就是：给定当前状态和输入事件，下一个状态必须是唯一确定的。

怎么保证？我总结了三条硬性规则：

每个状态-事件对只能对应一个转移，不能有歧义
不允许出现「默认转移」，所有转移必须显式定义
状态转移表必须覆盖所有状态-事件组合，不能有遗漏

来看一个反例：

// 错误示范：同一个事件导致不同状态
if (event == EVT_TIMEOUT) {
    if (some_condition) {
        next_state = STATE_RETRY;   // 条件A
    } else {
        next_state = STATE_ERROR;   // 条件B
    }
}

这种写法，状态转移依赖于外部条件，本质上是不确定的。正确的做法是把条件判断放到事件处理函数里，而不是放到状态转移逻辑里：

// 正确做法：事件本身已经包含了条件信息
switch (current_state) {
    case STATE_WAIT_ACK:
        if (event == EVT_ACK_OK) {
            next_state = STATE_IDLE;
        } else if (event == EVT_ACK_TIMEOUT) {
            next_state = STATE_RETRY;
        } else if (event == EVT_ACK_ERROR) {
            next_state = STATE_ERROR;
        }
        break;
}

四条原则的关系图谱

下面这张图，是我做状态机设计时脑子里始终挂着的框架：

四条原则的对比总结

原则	核心要求	常见反例	我的建议
单一职责	每个状态只做一件事	一个状态里同时处理发送、接收、超时	状态名里出现「和」字就拆分
开闭原则	新增功能不改已有代码	每次加状态都要改 switch-case 结构	用状态表 + 回调函数
状态显式化	状态有明确符号名	用位掩码或 magic number 表示状态	用 enum + 状态名打印函数
确定性	同一输入同一输出	状态转移依赖外部条件	状态-事件对必须唯一

小技巧：写状态机之前，先画一张状态转移图。把每个状态、每个事件、每个转移都画清楚。画图的过程，就是检查这四个原则的过程。我每次画完图，至少能发现两三个设计问题。

嗯，这四条原则说起来简单，真正落地的时候还是需要反复练习。你想想看，一个 SPI 驱动，如果能把这四个原则都做到位，那基本上就是教科书级别的代码了。下次咱们聊具体怎么用状态表来实现这些原则，到时候我会拿一个真实的 I2C 驱动来拆解。