📚 课程目录第4章裸机编程与前后台系统

4、裸机编程与前后台系统：轮询、中断驱动、状态机，以及它们的优缺点

在单片机开发中，当我们尚未引入RTOS（实时操作系统）时，所有的任务调度都依赖于裸机编程模型。裸机编程并非一种单一模式，而是涵盖了从最简单的轮询到复杂的前后台状态机等多种架构。理解这些架构的本质区别、适用场景与潜在缺陷，是构建稳定、高效嵌入式系统的基础。本章将深入剖析轮询、中断驱动和状态机三种核心模型，并通过对比与案例，帮助你在实际项目中做出合理的架构决策。

上图展示了三种裸机架构的核心特征与选型逻辑。在实际工程中，它们并非互斥，而是经常以组合形式出现。例如，一个典型的产品可能使用中断驱动来捕获按键和通信数据，而在主循环中采用状态机来处理业务逻辑。理解每种模式的底层机制，是进行组合设计的前提。

4.1 轮询系统：最简单的顺序执行模型

核心原理

轮询系统是最基础的裸机编程模型。其核心思想是：主程序在一个无限循环（while(1)）中，按照固定的顺序，依次检查（查询）每个外设或事件标志的状态，并执行相应的处理代码。CPU 始终处于“忙碌”状态，即使没有任何事件发生，它也在不断地执行查询指令。

// 轮询系统典型结构
while (1) {
    // 任务1：查询按键
    if (KEY_Scan() == PRESSED) {
        Handle_Key();
    }
    // 任务2：查询串口接收标志
    if (UART_GetFlag() == RX_DONE) {
        Handle_UART_Data();
    }
    // 任务3：查询ADC转换完成
    if (ADC_GetFlag() == CONV_DONE) {
        Handle_ADC_Value();
    }
    // ... 其他任务
}

判断方法与操作流程

判断一个系统是否适合采用纯轮询架构，可以参考以下流程：

任务数量评估：如果系统需要处理的任务数量较少（通常少于5个），且每个任务的执行时间极短（微秒级），轮询是可行的。
实时性需求分析：如果对事件响应的最坏延迟时间要求不高（例如，允许毫秒级延迟），轮询可以满足。
事件发生频率：如果事件是周期性且可预测的，轮询可以很好地匹配。

案例拆解：LED闪烁与按键检测

假设我们需要实现一个简单的功能：LED以500ms间隔闪烁，同时检测按键，按下时翻转另一个LED状态。这是一个典型的双任务轮询场景。

背景与约束：使用STM32F103芯片，主频72MHz，无外部中断需求。
实现方式：在主循环中，使用HAL_GetTick()获取系统时基，判断是否达到500ms，达到则翻转LED。同时，每次循环读取按键GPIO电平。
结果分析：该方案代码简单，逻辑清晰。但存在一个隐患：如果按键检测函数中存在延时消抖（如delay(10ms)），则LED闪烁的周期会受到影响，产生时间漂移。

风险提示：轮询系统最大的问题在于“阻塞”。如果某个任务（如延时、等待标志位）长时间占用CPU，后续所有任务的实时性都会受到牵连。在轮询循环中，严禁使用长延时或死等待。

常见误区与总结

误区1：认为轮询就是“低效”的代名词。实际上，对于任务简单、逻辑固定的系统，轮询是最稳定、最易维护的方案。
误区2：在轮询中处理耗时操作。例如，在轮询中调用printf重定向到串口，如果串口速度慢，会严重拖慢整个循环。

总结：轮询系统是架构设计的“地基”。它适合处理那些对时间不敏感、逻辑简单的任务。它的优点是代码直观、无资源竞争问题；缺点是CPU利用率低、实时性差。

4.2 中断驱动系统：事件响应的革命

核心原理

中断驱动系统解决了轮询系统的实时性痛点。其核心思想是：CPU 在正常情况下执行主循环（通常为空循环或低优先级任务），当外部事件（如按键按下、串口收到数据）发生时，硬件会触发中断信号，CPU 暂停当前工作，跳转到对应的中断服务函数（ISR）中执行处理，处理完毕后返回主循环继续执行。

// 中断服务函数示例
void EXTI0_IRQHandler(void) {
    if (EXTI_GetITStatus(EXTI_Line0) != RESET) {
        // 清除中断标志位
        EXTI_ClearITPendingBit(EXTI_Line0);
        // 标记按键事件
        g_key_event = 1;
        // 注意：ISR中应尽量少做耗时操作
    }
}

// 主循环
while (1) {
    if (g_key_event) {
        g_key_event = 0; // 清事件
        Handle_Key();    // 处理按键
    }
    // 其他低优先级任务
}

判断方法与操作流程

中断驱动系统的设计关键在于“中断服务函数（ISR）的划分”：

明确中断源：确定哪些事件需要立即响应（如电源故障、紧急停止），哪些可以延迟处理。
ISR 职责划分：ISR 中只做“标记事件”或“拷贝数据”等最短操作，将复杂的逻辑处理放到主循环中。
数据共享保护：如果主循环和 ISR 共享变量（如 g_key_event），必须使用 volatile 关键字修饰，防止编译器优化导致数据不一致。

案例拆解：串口数据接收与解析

假设我们需要通过串口接收一帧数据（帧头+长度+数据+校验），并解析执行命令。

背景与约束：串口波特率115200，数据帧长度不固定（最长256字节）。
初始现象：如果采用轮询接收，CPU 必须时刻查询接收寄存器，导致无法处理其他任务。
分析判断：采用中断驱动。在 USART_IRQHandler 中，将接收到的字节存入环形缓冲区（Ring Buffer），并更新接收计数。
实际操作：主循环中，检查环形缓冲区是否有完整的一帧数据（通过查找帧头并校验长度），有则取出并解析。
结果对比：采用中断+缓冲区后，CPU 的负担大大减轻，即使在高数据速率下，也能保证不丢字节，且主循环可以同时处理LED闪烁等任务。

经验之谈：在 ISR 中操作环形缓冲区时，务必注意临界区保护。通常采用“关中断”或“暂停中断”的方式，防止在读写缓冲区时被新的中断打断，导致数据错乱。

常见误区与总结

误区1：ISR 中执行耗时操作。例如在 ISR 中调用 HAL_Delay() 或进行浮点运算，这会严重阻塞其他中断的响应。
误区2：忘记清除中断标志位。这会导致中断反复触发，系统卡死在 ISR 中。
误区3：共享变量未加 volatile。这会导致主循环读取到过期的缓存数据。

总结：中断驱动系统极大地提升了系统的实时响应能力，但引入了“异步并发”的复杂性。设计者必须时刻关注数据一致性和临界区保护。它是前后台系统的核心，但并非万能。

4.3 状态机：管理复杂逻辑的利器

核心原理

状态机（Finite State Machine, FSM）是一种数学模型，它由一组状态、一组输入事件、一组输出动作和状态转移规则组成。在单片机中，状态机通常通过 switch-case 或函数指针表实现。它将复杂的业务逻辑分解为多个离散的“稳定状态”，每个状态只处理特定的输入，并根据条件跳转到下一个状态。

// 状态机示例：按键长按与短按检测
typedef enum {
    KEY_STATE_IDLE,   // 空闲
    KEY_STATE_DOWN,   // 按下
    KEY_STATE_LONG,   // 长按触发
} KeyState_t;

KeyState_t key_state = KEY_STATE_IDLE;

void Key_Process(void) {
    uint8_t key_val = KEY_Read();
    switch (key_state) {
        case KEY_STATE_IDLE:
            if (key_val == PRESSED) {
                key_state = KEY_STATE_DOWN;
                // 启动定时器，用于区分长按/短按
                Timer_Start(100ms);
            }
            break;
        case KEY_STATE_DOWN:
            if (key_val == RELEASED) {
                // 短按逻辑
                Handle_ShortPress();
                key_state = KEY_STATE_IDLE;
            } else if (Timer_Expired()) {
                // 长按逻辑
                Handle_LongPress();
                key_state = KEY_STATE_LONG;
            }
            break;
        case KEY_STATE_LONG:
            if (key_val == RELEASED) {
                key_state = KEY_STATE_IDLE;
            }
            break;
        default:
            key_state = KEY_STATE_IDLE;
            break;
    }
}

判断方法与操作流程

判断是否使用状态机，可以参考以下标准：

逻辑是否具有“阶段”特征：例如，通信协议解析（等待帧头→等待长度→等待数据→校验）、按键操作（按下→长按→释放）。
是否存在多条件组合：如果某个动作需要根据多个历史条件决定，状态机可以清晰地表达。
可维护性要求：状态机将复杂的 if-else 嵌套打散，使得代码结构扁平化，易于阅读和修改。

案例拆解：简易温控器逻辑

设计一个温控器，具有三种模式：待机、加热、冷却。当温度低于下限时进入加热，高于上限时进入冷却，在中间范围时进入待机。

背景与约束：温度传感器采样周期1s，继电器控制加热/冷却。
状态定义：IDLE、HEATING、COOLING。
转移条件：IDLE → HEATING（温度 < 20℃）；IDLE → COOLING（温度 > 30℃）；HEATING → IDLE（温度 ≥ 22℃）；COOLING → IDLE（温度 ≤ 28℃）。
分析判断：如果使用多个布尔变量（is_heating, is_cooling）组合判断，逻辑会变得混乱。采用状态机后，每个状态下的行为（开启/关闭继电器）和转移条件一目了然。
结果对比：状态机版本代码量减少约30%，且通过查表法（转移表）可以轻松增加新的状态（如“除湿”模式），扩展性极强。

设计技巧：对于状态较多的系统，建议使用“状态转移表”来驱动 switch-case。将状态转移条件封装为函数指针，可以避免 switch-case 过长难以维护的问题。

常见误区与总结

误区1：状态划分过细。导致状态爆炸，增加系统开销和理解难度。
误区2：在状态机中执行阻塞操作。状态机应该快速执行并返回，任何耗时操作（如延时）都会破坏实时性。
误区3：状态转移条件不完整。导致系统进入非法状态（未定义的状态值），需要增加 default 分支兜底。

总结：状态机是裸机编程中管理复杂逻辑的“银弹”。它让代码变得可预测、可测试。它并非一种调度架构，而是一种逻辑组织工具，通常与轮询或中断配合使用。

4.4 三种架构对比与选型决策

为了更直观地指导选型，下表从多个维度对三种架构进行了对比：

对比维度	轮询系统	中断驱动系统	状态机（FSM）
实时性	差（依赖循环周期）	强（事件触发立即响应）	取决于承载环境（轮询或中断）
CPU利用率	低（空转查询）	高（无事可做时休眠）	高（逻辑紧凑）
代码复杂度	低	中（需处理临界区）	中高（需设计状态）
调试难度	易（顺序执行）	难（异步并发）	中（可预测状态）
资源消耗	无额外开销	需中断向量表、栈空间	需状态变量存储
典型应用	LED闪烁、按键扫描	串口接收、外部信号捕获	通信协议解析、按键消抖、菜单逻辑

在实际项目中，这三种架构往往是融合使用的。例如，一个典型的物联网传感器节点：

使用中断驱动来接收无线模块的SPI数据，保证数据不丢失。
在主循环中，使用状态机来管理网络连接状态（未连接→连接中→已连接→发送数据→等待ACK）。
对于LED指示等非关键任务，则采用简单的轮询方式。

关键提醒：无论采用哪种架构，都必须遵循“中断服务函数尽量短”的原则。如果 ISR 中的处理时间超过系统允许的中断延迟，就需要考虑将部分工作推迟到主循环中完成。此外，在裸机系统中，没有优先级抢占，因此主循环中的任务执行时间必须严格控制，否则会影响中断响应的及时性。