3. 裸机任务调度雏形

做了这么多年嵌入式，我见过太多项目从“跑起来就行”变成“改一行崩一片”。裸机编程在简单场景下确实够用，但一旦系统复杂起来，那些隐藏的坑就会一个个冒出来。今天咱们就聊聊裸机开发中最让人头疼的四个问题——优先级反转、延时阻塞、代码耦合、扩展性差。

说实话，这些问题我早期做项目时全踩过。有一次调试一个多传感器采集系统，明明每个模块单独测试都正常，合在一起就随机死机。查了三天，最后发现是优先级反转导致的。嗯，从那以后我才真正重视起任务调度的问题。

痛点一：任务优先级反转——高优先级任务被低优先级任务“绑架”

先看一个典型场景。你的系统里有三个任务：

• Task_High（高优先级）：处理紧急报警
• Task_Mid（中优先级）：普通数据采集
• Task_Low（低优先级）：LCD刷新显示

假设 Task_Low 先拿到了共享资源（比如一个 SPI 总线），正在慢慢传输数据。这时 Task_High 突然被触发，它也想用 SPI。但资源被 Task_Low 占着，Task_High 只能等。

问题来了——Task_Mid 这时也准备好了，它不需要 SPI，所以直接抢占了 CPU。Task_Low 被 Task_Mid 打断，迟迟释放不了 SPI。Task_High 就这么被一个中优先级的任务“间接阻塞”了。

这就是经典的优先级反转。高优先级任务反而被低优先级任务拖死。

裸机下怎么处理？通常的做法是关中断保护临界区，或者用信号量。但关中断会影响实时性，信号量又容易死锁。说白了，裸机缺乏一个统一的任务调度机制来管理这种资源竞争。

痛点二：延时阻塞——CPU在“空转”

裸机编程里最常见的延时写法是什么？

void delay_ms(uint32_t ms) {
    for (uint32_t i = 0; i < ms * 1000; i++) {
        __NOP();  // 空操作，纯浪费CPU
    }
}

或者用定时器轮询：

void delay_ms(uint32_t ms) {
    uint32_t start = get_tick();
    while (get_tick() - start < ms) {
        // 死等，啥也不干
    }
}

这两种方式本质上都是忙等待。CPU 在这段时间里除了数数，什么正事都干不了。

你想想看，如果你的系统有 5 个任务，每个任务里都有 100ms 的延时，那 CPU 至少有 500ms 在空转。对于电池供电的设备来说，这简直是灾难。

裸机下有没有替代方案？有，用状态机。但状态机写起来代码量翻倍，而且逻辑一复杂就容易出 bug。我见过一个同事写的 2000 行状态机，最后他自己都看不懂了。

痛点三：代码耦合度高——牵一发而动全身

裸机程序的结构通常是这样的：

// main.c
int main(void) {
    init_all();  // 初始化所有外设
    
    while (1) {
        process_sensor();   // 处理传感器
        process_comm();     // 处理通信
        process_display();  // 处理显示
        process_control();  // 处理控制逻辑
    }
}

所有功能都挤在 main 函数的大循环里。每个函数之间通过全局变量传递数据：

// globals.h
extern uint8_t sensor_data[64];
extern uint8_t comm_buffer[128];
extern uint16_t display_frame;
extern uint8_t control_flag;

这种写法有什么问题？

• 修改一个模块，可能影响所有模块。比如你改了 sensor_data 的格式，comm 模块和 display 模块都得跟着改。
• 调试困难。全局变量被到处修改，出问题时根本不知道是谁改的。
• 团队协作难。两个人同时改同一个文件，合并冲突是家常便饭。

痛点四：可扩展性差——加个功能就像“拆房子”

裸机程序的可扩展性差，本质上是时间维度和空间维度都缺乏抽象。

时间维度：所有任务共享一个 CPU，执行顺序完全由代码顺序决定。你想加一个新任务？得先找到合适的时间片，然后祈祷它不会影响现有任务的时序。

空间维度：模块之间通过全局变量耦合，没有清晰的接口定义。加一个新模块，往往需要修改多个已有模块的代码。

我整理了一个对比表，可以看得更清楚：

维度	裸机编程	RTOS
任务管理	手动轮询，顺序执行	优先级调度，抢占式执行
资源竞争	关中断/全局变量	信号量/互斥锁/消息队列
延时处理	忙等待，浪费CPU	任务挂起，CPU可做其他事
模块耦合	高，全局变量满天飞	低，通过IPC通信
扩展性	差，加功能需重构	好，加任务不影响现有逻辑

说白了，裸机编程就像用记事本写一本长篇小说——前期写写日记还行，写到后面章节多了，想改前面一段就得翻遍整本书。而 RTOS 就像给你一个结构化的写作工具，每个章节独立，修改一个不影响其他。

核心问题总结：一张图看懂四大痛点

下面这张图展示了裸机编程四大痛点之间的关系和影响链路：

这四个痛点不是孤立的，它们互相影响。优先级反转和延时阻塞导致系统实时性变差，代码耦合高让问题更难定位，可扩展性差则让每一次需求变更都变成一场噩梦。

我个人觉得，当你发现项目里开始出现以下信号时，就该考虑引入 RTOS 了：

• 全局变量超过 50 个
• main 循环里的函数超过 10 个
• 开始出现“这个 bug 偶尔出现，重启就好”的情况
• 加一个新功能需要改 3 个以上已有文件