第四章 嵌入式RTOS选型与移植：FreeRTOS、RT-Thread等系统选型，任务优先级设计与资源规划

各位同学，咱们今天聊聊RTOS选型。说实话，这问题我每年都会被问到几十次。很多刚入行的朋友总觉得，选个RTOS嘛，哪个流行用哪个呗。嗯，真这么干，后面量产的时候有你哭的。

我个人习惯，选RTOS之前先问自己三个问题：

• 我的芯片资源有多紧张？RAM、Flash够不够？
• 团队对哪个系统最熟悉？学习成本能不能接受？
• 产品生命周期多长？后续要不要OTA升级？

这三个问题想明白了，选型就完成了一半。

4.1 FreeRTOS vs RT-Thread：我的实战对比

先说说FreeRTOS。这玩意儿我用了快十年了。它的优点就一个字——稳。代码量极小，内核只有几千行，移植起来特别快。我在一个Cortex-M0的芯片上跑过，RAM只占1.5KB左右，Flash也就4KB。对于资源极度受限的场景，它几乎是唯一选择。

但FreeRTOS有个痛点——生态太弱。它就是个纯粹的内核，没有设备框架，没有组件。你想用个文件系统？自己写。想用个TCP/IP协议栈？自己移植LwIP。说白了，它给你的是毛坯房，装修全靠自己。

RT-Thread就不一样了。它更像一个完整的物联网操作系统。我记得第一次用RT-Thread时，最让我惊喜的是它的设备驱动框架。你写个传感器驱动，只需要实现几个标准接口，上层应用直接调用，根本不用管底层寄存器。这对产品开发效率提升太大了。

但RT-Thread也有代价。它的内核比FreeRTOS大不少，RAM至少需要8KB以上，Flash也得20KB起步。如果你的芯片是那种几毛钱的超低端MCU，还是老老实实用FreeRTOS吧。

4.2 移植实战：从裸机到RTOS

移植RTOS这事儿，说难不难，说简单也不简单。我见过太多人栽在同一个坑里——中断优先级配置。

以FreeRTOS为例，它的调度器依赖一个周期性中断（通常是SysTick）和一个PendSV中断。这两个中断的优先级必须设置正确。我曾经在一个项目里，因为把SysTick优先级设得比某个外设中断还低，结果系统跑着跑着就死机了。查了整整两天才找到原因。

正确的做法是：

// FreeRTOSConfig.h 中配置
#define configLIBRARY_LOWEST_INTERRUPT_PRIORITY   15
#define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 5

// 中断优先级分组设置为4位抢占优先级
NVIC_PriorityGroupConfig(NVIC_PriorityGroup_4);

// SysTick优先级设为最低
NVIC_SetPriority(SysTick_IRQn, 15);

// PendSV优先级设为最低
NVIC_SetPriority(PendSV_IRQn, 15);

这里有个关键点：所有调用FreeRTOS API的中断，优先级必须高于configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY。说白了，就是不能让高优先级中断里调用系统API，否则会破坏内核的临界区保护。

4.3 任务优先级设计：别让优先级成为你的噩梦

任务优先级设计，这是RTOS开发中最容易出问题的地方。我见过一个团队，把系统里所有任务都设成不同优先级，结果高优先级任务把低优先级任务饿死了。你想想看，一个按键扫描任务优先级比通信任务还高，这合理吗？

我个人习惯，优先级设计遵循三个原则：

1. 实时性决定优先级：响应时间要求越短的任务，优先级越高。比如电机控制任务，响应时间要求1ms以内，优先级最高。日志打印任务，响应时间100ms都行，优先级最低。
2. 任务数量越少越好：我见过有人把每个功能都拆成一个独立任务，结果系统里跑了30多个任务。这其实没必要。任务切换是有开销的，任务越多，系统越不稳定。我的经验是，一个MCU上跑5-8个任务就够了。
3. 同优先级任务用时间片轮转：如果两个任务实时性要求差不多，就设成相同优先级，让调度器自动轮转。这样既保证了公平性，又降低了优先级反转的风险。

#define TASK_PRIO_MOTOR     5
#define TASK_PRIO_COMM      4
#define TASK_PRIO_SENSOR    3
#define TASK_PRIO_DISPLAY   2
#define TASK_PRIO_LOG       1

4.4 资源规划：堆栈、队列、信号量

资源规划这事儿，说白了就是算账。你的芯片有多少RAM，每个任务分多少堆栈，消息队列开多大，信号量用几个，都得算清楚。

先说堆栈。每个任务都需要独立的堆栈空间。堆栈大小怎么定？我有个土办法：先给每个任务分配一个较大的堆栈（比如512字节），然后让系统跑起来，用调试器查看每个任务的实际堆栈使用峰值。根据这个数据，再调整到合适大小。

我曾经在一个项目里，因为堆栈设得太小，导致任务运行到一半栈溢出，程序直接跑飞。那会儿还没有调试器，我只能用串口打印定位问题。折腾了整整一个周末。从那以后，我每个任务都会预留30%的堆栈余量。

消息队列和信号量的数量，取决于你的任务间通信需求。我一般这样规划：

4.5 量产化考量：稳定性压倒一切

最后聊聊量产化。实验室里跑得好好的代码，一到量产就出问题，这种事我见得太多了。原因往往出在RTOS配置上。

比如，FreeRTOS的configTICK_RATE_HZ，实验室里设成1000Hz没问题，但量产时如果芯片温度升高，晶振频率漂移，系统时钟就可能不准。我建议量产时把这个值设成100Hz，够用就行，别追求极致。

再比如，RT-Thread的线程栈溢出检测，开发阶段一定要打开。但量产时建议关掉，因为检测本身会消耗CPU资源。不过关掉之前，一定要确保所有任务的堆栈都经过充分测试。

嗯，说到量产，还有个容易被忽略的点——看门狗。RTOS环境下，看门狗不能简单地在主循环里喂。我习惯创建一个最低优先级的空闲任务，专门负责喂狗。这样只要系统还在运行，看门狗就不会复位。如果某个高优先级任务卡死了，空闲任务得不到CPU时间，看门狗就会触发复位。