第二十三章 多线程在嵌入式系统中的应用：RTOS线程模型、资源受限环境下的线程设计、中断与线程交互
嵌入式系统编程，说白了就是“戴着镣铐跳舞”。资源就那么点，实时性要求却高得吓人。我早年刚接触嵌入式多线程时，以为跟PC上写pthread差不多，结果板子直接跑飞了。嗯，今天我们就来聊聊嵌入式世界里，多线程到底该怎么玩。
一、RTOS线程模型：别把线程当“进程”用
在RTOS（实时操作系统）里，线程通常叫“任务”（Task）。每个任务有自己的栈空间、优先级和状态。跟Linux进程不同，RTOS里的所有线程共享同一个地址空间——说白了，没有MMU帮你隔离，一个线程写越界，整个系统就崩了。
核心区别：RTOS线程是轻量级的，创建和切换开销极小。我见过有人把任务栈设成1KB，照样跑得飞起。但在Linux里，默认线程栈就是8MB。
常见的RTOS线程状态机包括：
- 就绪（Ready）：线程具备运行条件，等待调度器分配CPU
- 运行（Running）：正在占用CPU执行
- 阻塞（Blocked）：等待某个事件或资源（信号量、队列、延时等）
- 挂起（Suspended）：被其他线程或中断强制暂停
举个例子，FreeRTOS里创建一个任务：
void vTaskFunction(void *pvParameters) {
while(1) {
// 任务主体
vTaskDelay(pdMS_TO_TICKS(100)); // 阻塞100ms
}
}
// 在主函数中创建
xTaskCreate(
vTaskFunction, // 任务函数
"Task1", // 任务名（调试用）
128, // 栈深度（单位：字，不是字节！）
NULL, // 参数
2, // 优先级（数值越大优先级越高）
NULL // 任务句柄
);
我的经验：栈大小别拍脑袋定。我习惯先设一个较大的值（比如512字），跑一段时间后用uxTaskGetStackHighWaterMark()查看实际使用峰值，再下调到1.5倍左右。这样既省内存，又不会栈溢出。
二、资源受限环境下的线程设计：能省则省
嵌入式MCU的RAM通常只有几十KB到几MB，Flash也就几MB。你想想看，每个线程的栈、TCB（任务控制块）、消息队列都得从这有限的资源里抠。所以设计时得精打细算。
2.1 线程数量：不是越多越好
我见过有人在一个Cortex-M0上开了20个线程，结果光切换开销就占了30%的CPU。其实很多场景下，3-5个线程就够用了。比如：
- 一个高优先级的数据采集线程
- 一个中优先级的处理线程
- 一个低优先级的通信或日志线程
2.2 栈空间复用：用“协作式”代替“抢占式”
在极端资源受限的情况下，可以考虑让多个任务共享同一个栈——也就是所谓的“协作式多任务”。任务主动让出CPU，而不是被调度器强制切换。这样每个任务不需要独立的栈，能省下大量RAM。
注意：协作式多任务要求每个任务不能长时间占用CPU。我曾经在一个项目中用这种模式，结果有个任务里的延时函数写成了死循环，整个系统直接卡死。嗯，从那以后我规定：协作式任务里绝对不允许使用阻塞型延时。
2.3 使用静态分配代替动态分配
在嵌入式里，malloc/free是禁忌。动态分配会导致内存碎片，而且分配时间不确定。RTOS通常提供静态创建接口：
StaticTask_t xTaskBuffer;
StackType_t xStack[128];
TaskHandle_t xHandle = xTaskCreateStatic(
vTaskFunction,
"Task1",
128,
NULL,
2,
xStack,
&xTaskBuffer
);
这样栈和TCB都在编译时分配好，运行期间不会出现内存不足的问题。
三、中断与线程交互：最危险的“握手”
中断是嵌入式系统的灵魂，但也是多线程编程中最容易出bug的地方。中断和线程共享数据时，稍不注意就是一场灾难。
3.1 中断服务程序（ISR）里该做什么？
ISR里应该“快进快出”。我个人的原则是：ISR里只做最必要的事——比如读取硬件寄存器、清除中断标志、然后通过RTOS的机制通知线程。绝对不要在ISR里做复杂计算或调用阻塞型API。
正确的做法是使用“延迟中断处理”模式：
// ISR
void UART_IRQHandler(void) {
uint32_t data = UART->DR; // 读取数据
BaseType_t xHigherPriorityTaskWoken = pdFALSE;
xQueueSendFromISR(xDataQueue, &data, &xHigherPriorityTaskWoken);
portYIELD_FROM_ISR(xHigherPriorityTaskWoken); // 如果需要，立即切换任务
}
// 线程
void vDataProcessingTask(void *pvParameters) {
uint32_t data;
while(1) {
xQueueReceive(xDataQueue, &data, portMAX_DELAY);
// 在这里做耗时处理
process_data(data);
}
}
关键点：ISR里调用RTOS的API时，必须使用“FromISR”后缀的版本（如xQueueSendFromISR）。普通版本会尝试获取调度器锁，这在中断上下文里是致命的。
3.2 中断与线程共享数据的保护
如果中断和线程共享一个全局变量，最简单的保护方式是“关中断”。但关中断的时间不能太长，否则会影响系统实时性。
volatile uint32_t g_shared_counter;
void thread_function(void) {
taskENTER_CRITICAL(); // 关中断
g_shared_counter++;
taskEXIT_CRITICAL(); // 开中断
}
void Some_IRQHandler(void) {
// ISR里不需要关中断，因为中断本身是嵌套的
g_shared_counter++;
}
我曾经踩过的坑：有一次我在ISR里修改了一个全局变量，线程里也修改同一个变量。我以为加了volatile就万事大吉，结果线程读到的值总是错的。后来才发现，线程里修改时没有关中断，导致ISR在线程修改过程中插了一脚，数据被撕成了两半。从那以后，凡是中断和线程共享的变量，我都用临界区保护。
3.3 中断优先级与线程优先级的配合
RTOS通常允许设置中断优先级，并且中断可以抢占线程。但要注意：中断优先级高于任何线程优先级。所以如果ISR里调用了会阻塞线程的API（比如发送队列），一定要确保接收线程的优先级足够高，否则可能造成优先级反转。
一个典型的配置：
| 组件 | 优先级 | 说明 |
|---|---|---|
| 定时器中断 | 最高（0） | 系统心跳，必须最快响应 |
| 外部中断（按键） | 高（1） | 用户交互，需要低延迟 |
| 数据采集线程 | 高（3） | 从队列取数据，优先级高于处理线程 |
| 数据处理线程 | 中（2） | 做算法运算，可以稍等 |
| 日志输出线程 | 低（1） | 串口打印，不着急 |
四、知识体系总览
下面这张图总结了本章的核心逻辑：从RTOS线程模型出发，到资源受限下的设计策略，再到中断与线程的交互机制。你可以把它当作嵌入式多线程编程的“作战地图”。
五、避坑指南与个人经验
最后，分享几个我这些年积累的“血泪教训”：
- 栈溢出检测一定要开：很多RTOS提供栈溢出钩子函数，别嫌麻烦，一定要注册上。我曾经在调试一个电机控制程序时，栈溢出导致控制参数被意外修改，电机直接飞车了。
- 中断里别打印：printf在ISR里调用，轻则阻塞系统，重则死锁。我习惯在ISR里只设一个标志位，由线程去处理打印。
- 优先级别设平级：如果两个任务优先级相同，时间片轮转会导致不可预测的切换点。我一般给每个任务分配不同的优先级，哪怕只差1。
- 测试要覆盖中断风暴：模拟高频中断场景，看看系统会不会出现任务饿死或队列溢出。我有个项目就是在高负载下，中断把CPU占满了，低优先级任务永远得不到执行。
嵌入式多线程编程，说白了就是“平衡的艺术”——在实时性、资源消耗和代码复杂度之间找最优解。希望今天的内容能帮你少走一些弯路。
公众号:蓝海资料掘金营，微信deep3321