第4章裸机编程与状态机

裸机编程与状态机：轮询架构、前后台系统、有限状态机(FSM)设计与实现

大家好，我是你们的嵌入式系统架构师。今天咱们聊聊嵌入式开发最基础、也最容易被忽视的一块——裸机编程与状态机。说实话，很多新手一上来就追着RTOS跑，觉得裸机太low。但我做了十几年嵌入式，可以负责任地告诉你：裸机编程的功底，决定了你能走多远。

你想想看，一个简单的智能灯、一个遥控器、一个传感器节点，真的需要跑操作系统吗？杀鸡用牛刀，反而容易出问题。裸机编程，说白了就是让CPU在一个大循环里不停地干活。它简单、直接、可控，是实时控制系统的基石。

轮询架构：最朴素的干活方式

轮询架构，就是CPU不停地问每个设备：「你有事吗？你有事吗？」。就像你站在柜台后面，挨个问顾客要点什么。

// 典型的轮询架构
void main(void) {
    system_init();
    
    while(1) {
        check_button();    // 检查按键
        read_sensor();     // 读取传感器
        update_display();  // 更新显示
        control_motor();   // 控制电机
    }
}

这种架构的优点是简单到令人发指。我刚开始做项目时，一个温控器就用这种结构，跑得稳稳的。但缺点也很明显：如果某个任务卡住了，整个系统就瘫痪了。比如读取传感器时用了阻塞式I2C，那按键就永远没反应了。

⚠️ 避坑指南

我曾经在一个项目中，用轮询架构同时处理按键和LCD刷新。结果按键响应延迟高达200ms，用户按下去要等一会儿才有反应。后来发现是LCD刷新函数里有个10ms的延时，每次循环都卡在那里。解决办法是把延时拆成多个小段，或者改用状态机。

前后台系统：给轮询加点料

前后台系统，也叫中断驱动系统。前台是中断服务程序（ISR），处理紧急事件；后台是主循环，处理常规任务。这就像餐厅里，前台服务员（ISR）负责接单，后台厨师（主循环）负责做菜。

// 前后台系统示例
volatile uint8_t button_pressed = 0;

// 前台：中断服务程序
void EXTI0_IRQHandler(void) {
    button_pressed = 1;  // 只设置标志，不做复杂处理
    // 清除中断标志位
}

// 后台：主循环
void main(void) {
    system_init();
    
    while(1) {
        if(button_pressed) {
            button_pressed = 0;
            handle_button();  // 在主循环中处理
        }
        update_display();
        read_sensor();
    }
}

我个人习惯把中断服务程序写得尽可能短。为什么？因为中断是抢占式的，如果ISR执行时间太长，会阻塞其他中断，甚至导致系统抖动。记住一个原则：ISR里只做标记，不做处理。

💡 经验之谈

我建议在ISR中使用volatile关键字声明共享变量。否则编译器优化时，可能会把变量值缓存到寄存器里，导致主循环永远看不到变化。这个坑我踩过，调试了整整一天才发现是优化问题。

有限状态机(FSM)：让程序有「记忆」

有限状态机，说白了就是让程序知道自己「现在在干什么」。它由三部分组成：状态、事件、动作。状态是当前所处的阶段，事件是触发条件，动作是状态切换时执行的操作。

举个例子，一个简单的门禁系统：

// 门禁状态机
typedef enum {
    STATE_IDLE,      // 空闲
    STATE_WAIT_PIN,  // 等待输入PIN码
    STATE_OPEN,      // 门已打开
    STATE_ALARM      // 报警
} DoorState;

DoorState current_state = STATE_IDLE;

void door_fsm(uint8_t event) {
    switch(current_state) {
        case STATE_IDLE:
            if(event == EVENT_CARD_SWIPE) {
                current_state = STATE_WAIT_PIN;
                start_timer(5000);  // 5秒超时
                display_enter_pin();
            }
            break;
            
        case STATE_WAIT_PIN:
            if(event == EVENT_PIN_OK) {
                current_state = STATE_OPEN;
                unlock_door();
                start_timer(3000);  // 3秒后自动锁门
            } else if(event == EVENT_TIMEOUT) {
                current_state = STATE_ALARM;
                trigger_alarm();
            }
            break;
            
        case STATE_OPEN:
            if(event == EVENT_TIMEOUT) {
                current_state = STATE_IDLE;
                lock_door();
            }
            break;
            
        case STATE_ALARM:
            if(event == EVENT_RESET) {
                current_state = STATE_IDLE;
                stop_alarm();
            }
            break;
    }
}

你看，每个状态只关心自己能处理的事件，不相关的事件直接忽略。这样代码逻辑清晰，不容易出bug。我在项目中遇到过最复杂的FSM有32个状态，但维护起来依然很轻松，因为每个状态都是独立的。

🎯 核心要点

状态机是「事件驱动」的，不是「时间驱动」的
每个状态只处理自己关心的事件
状态切换要明确，避免「幽灵状态」
超时也是一种事件，需要单独处理

状态机的三种实现方式

实际项目中，状态机的实现方式主要有三种。我按推荐程度排序：

实现方式	优点	缺点	适用场景
switch-case	简单直观，代码量少	状态多时代码臃肿	状态少于10个
函数指针表	扩展性好，易于维护	调试稍复杂	状态10-30个
状态表驱动	结构清晰，可配置	占用RAM较多	状态超过30个

我个人最常用的是函数指针表。它把每个状态的处理函数放在一个数组里，通过状态索引直接调用。这样新增状态时，只需要添加一个函数和一条表项，不用修改switch-case结构。

// 函数指针表实现状态机
typedef void (*state_handler_t)(uint8_t event);

void state_idle(uint8_t event);
void state_wait_pin(uint8_t event);
void state_open(uint8_t event);
void state_alarm(uint8_t event);

state_handler_t state_table[] = {
    state_idle,
    state_wait_pin,
    state_open,
    state_alarm
};

void fsm_run(uint8_t event) {
    state_table[current_state](event);
}

💡 设计技巧

写状态机时，我建议画一张状态转移图。把每个状态、每个事件、每个动作都画清楚。画图的过程，就是理清逻辑的过程。很多bug在画图阶段就能发现，不用等到写代码。

知识体系总览

下面这张图，是我对本章知识体系的总结。你可以看到，裸机编程从最简单的轮询，到前后台系统，再到状态机，是一个逐步演进的过程。每一步都是为了解决前一步的问题。

嗯，这里要注意一点：状态机不是万能的。如果你的系统逻辑非常简单，比如就是读个传感器然后输出，那用轮询就够了，没必要硬上状态机。过度设计也是种病。

最后分享一个我自己的习惯：写状态机之前，先在纸上画出状态转移图。画清楚了再写代码。这样写出来的代码，bug少，可读性强。你想想看，一个画得清清楚楚的状态图，比看一堆switch-case要直观得多吧？

好了，这一章就到这里。记住：裸机编程不是过时的技术，它是实时控制系统的根基。把轮询、前后台、状态机这三个工具用好，你就能应对绝大多数嵌入式场景了。