2. RTOS选型对比：FreeRTOS、uC/OS-III、RT-Thread在资源受限场景下的取舍
做嵌入式开发这么多年，我选过不下十种RTOS。牙刷这种场景，说白了就是资源极度受限——几KB的RAM，几十KB的Flash。你想想看，一个牙刷主控芯片，可能就是个Cortex-M0或者M0+，成本压到几毛钱。这时候RTOS选型就变得很关键了。
我个人习惯是，先看资源需求，再看生态，最后看授权。嗯，咱们一个一个来聊。
2.1 三大RTOS的核心参数对比
先上一张表，这是我做项目时常用的对比维度。数据都是基于Cortex-M0内核、无FPU的场景。
| 对比项 | FreeRTOS | uC/OS-III | RT-Thread |
|---|---|---|---|
| 最小ROM占用 | 4-6 KB | 6-10 KB | 3-5 KB（nano版） |
| 最小RAM占用 | ~200字节 | ~500字节 | ~300字节 |
| 任务栈开销 | 每任务约40字节 | 每任务约60字节 | 每任务约50字节 |
| 调度方式 | 抢占式+协作式 | 抢占式 | 抢占式+时间片 |
| 最大任务数 | 无限制（受RAM限制） | 无限制 | 无限制 |
| IPC机制 | 队列、信号量、互斥量 | 队列、信号量、互斥量、事件标志 | 邮箱、信号量、互斥量、事件集 |
| 许可证 | MIT（免费） | 商业授权（收费） | Apache 2.0（免费） |
| 社区活跃度 | 极高 | 中等 | 高（国内） |
关键结论：在牙刷这种资源极度受限的场景下，FreeRTOS和RT-Thread nano版是首选。uC/OS-III虽然功能强大，但它的商业授权费用和资源开销，说实话不太适合这种成本敏感的产品。
2.2 资源占用深度分析
咱们来拆开看看，这些资源到底用在哪了。
2.2.1 FreeRTOS：轻量级的王者
FreeRTOS我用了快十年了。它的设计哲学就是「够用就好」。内核只提供最核心的调度和IPC，其他功能全靠用户自己搭。
我记得有一次，给一个只有8KB Flash的芯片移植FreeRTOS。我把所有不需要的功能都裁剪掉——比如软件定时器、协程、任务通知的某些特性。最后内核只占了4.2KB Flash，RAM开销不到200字节。嗯，这个数据我记得很清楚，因为当时客户要求必须控制在5KB以内。
FreeRTOS的调度器实现非常精简。它的任务控制块（TCB）只保存必要的上下文信息。我在项目中遇到过一个问题：任务栈开得太小，导致栈溢出。FreeRTOS的栈溢出检测机制其实挺实用的，但默认是关闭的。我建议你在调试阶段一定要打开，等稳定了再关掉。
我的小技巧：FreeRTOS的configMINIMAL_STACK_SIZE不要直接用默认值。我一般会根据任务的实际调用深度，手动计算一下。比如一个任务里调用了sprintf，那栈至少得给256字节。
2.2.2 uC/OS-III：功能全面但有点重
uC/OS-III我接触得比较晚。说实话，它的代码质量很高，注释也很详细。但问题是，它太「重」了。
为什么这么说？uC/OS-III的内核包含了完整的时间管理、事件标志组、内存管理、任务内建信号量等等。这些功能在复杂系统里是优点，但在牙刷这种场景下，就成了负担。
我曾经尝试把uC/OS-III移植到一个16KB Flash的芯片上。折腾了两天，最后内核占了9KB，加上应用代码，Flash就快满了。而且它的RAM开销也比FreeRTOS大不少——每个任务多占20字节的TCB空间。你想想看，如果跑5个任务，就多出100字节。在只有2KB RAM的芯片上，这可不是小数目。
避坑指南：我曾经因为uC/OS-III的许可证问题吃过亏。当时项目快量产了，才发现uC/OS-III的商业授权费用不低。后来紧急换成FreeRTOS，重新移植和测试花了两周。所以，选型时一定要先确认许可证，尤其是商业项目。
2.2.3 RT-Thread：国产之光，但要看版本
RT-Thread这几年发展很快。它的nano版本就是为资源受限场景设计的。我测试过，nano版的内核可以裁剪到3KB左右，比FreeRTOS还小。
但要注意，RT-Thread的完整版和nano版差别很大。完整版包含了设备框架、文件系统、网络协议栈等，功能很强大，但资源开销也大。如果你用完整版，Flash至少得64KB起步。
我个人建议，在牙刷这种场景下，用RT-Thread nano就够了。它提供了和完整版一样的API接口，以后想升级也方便。我在一个项目中用过nano版，配合它的FinSH控制台，调试起来特别方便。
2.3 调度策略对比
牙刷的典型任务包括：电机控制（高优先级）、蓝牙通信（中优先级）、按键检测（低优先级）、LED指示（最低优先级）。
咱们看看三个RTOS怎么处理这种场景。
2.3.1 FreeRTOS的调度
FreeRTOS支持抢占式和时间片轮转。我一般会这样配置：
// 电机控制任务 - 最高优先级
xTaskCreate(MotorControlTask, "Motor", 128, NULL, 3, NULL);
// 蓝牙通信任务 - 中等优先级
xTaskCreate(BluetoothTask, "BLE", 256, NULL, 2, NULL);
// 按键检测任务 - 低优先级
xTaskCreate(KeyScanTask, "Key", 64, NULL, 1, NULL);FreeRTOS的调度器在任务切换时，会保存和恢复R4-R11这些寄存器。嗯，这里要注意，如果你的芯片有FPU，还得额外处理FPU寄存器。不过牙刷用的M0没有FPU，所以省心不少。
2.3.2 uC/OS-III的调度
uC/OS-III只支持抢占式调度。它的调度算法是基于优先级位图的，查找最高优先级任务的速度是O(1)。这一点比FreeRTOS的链表查找要快一些。
但说实话，在牙刷这种只有几个任务的场景下，调度性能的差异根本感觉不出来。我测试过，FreeRTOS的调度延迟大概在1-2微秒，uC/OS-III也在1微秒左右。这点差距，对牙刷来说完全不是问题。
2.3.3 RT-Thread的调度
RT-Thread支持抢占式和时间片轮转。它的调度器实现和FreeRTOS类似，但多了一个「软定时器」线程的概念。这个软定时器线程会占用一个优先级，如果你不用，记得关掉。
我的建议：在资源受限场景下，优先考虑FreeRTOS或RT-Thread nano。如果项目有商业授权顾虑，FreeRTOS的MIT许可证最省心。如果团队熟悉国产生态，RT-Thread nano也是好选择。uC/OS-III嘛，除非客户指定，否则我一般不会主动推荐。
2.4 实际移植中的注意事项
不管选哪个RTOS，移植到牙刷主控芯片时，有几个坑是共通的。
- 中断优先级配置：Cortex-M0只有4级中断优先级（2位）。RTOS通常需要至少2级——一级给SysTick，一级给PendSV。我建议你把SysTick设为最高优先级，PendSV设为最低优先级。
- 任务栈大小：牙刷的任务都很简单，但要注意函数调用深度。比如蓝牙协议栈的某些回调函数，可能会嵌套好几层。我一般会给蓝牙任务256字节栈，其他任务128字节就够了。
- 临界区保护：FreeRTOS和RT-Thread默认用关中断来保护临界区。关中断时间不能太长，否则会影响蓝牙的时序。我建议你把临界区的代码控制在10微秒以内。
- 低功耗处理：牙刷是电池供电的，低功耗很重要。FreeRTOS的Tickless模式我试过，效果不错。RT-Thread也有类似的低功耗管理组件。
避坑指南：我曾经在移植FreeRTOS时，忘了配置configCPU_CLOCK_HZ和configTICK_RATE_HZ。结果SysTick的定时完全不对，任务调度乱成一团。嗯，这种低级错误，犯过一次就不会再犯了。
2.5 最终选型建议
说了这么多，总结一下我的个人看法：
- 如果Flash < 16KB，RAM < 2KB：选FreeRTOS。它的裁剪性最好，资源占用最低。
- 如果Flash 16-32KB，RAM 2-4KB：FreeRTOS或RT-Thread nano都可以。看团队熟悉哪个。
- 如果Flash > 32KB，RAM > 4KB：可以考虑RT-Thread完整版，但牙刷一般用不到这么高配置。
- 如果客户指定或团队习惯：那就用uC/OS-III，但要做好资源紧张的准备。
最后说一句，选型没有绝对的对错。关键是你要清楚自己的资源边界，以及每个RTOS的取舍在哪里。我在项目中见过有人用FreeRTOS跑出了uC/OS-III的效果，也见过有人把RT-Thread裁剪得比FreeRTOS还小。工具是死的，人是活的。