3、选型第一步：明确项目需求——任务数量、内存预算、时间约束、外设接口
好，咱们正式开始选型。很多新手工程师一上来就问我：「哪个 RTOS 最好用？」
说实话，这个问题没法回答。就像你问我「哪个螺丝刀最好用」——得先看你要拧什么螺丝，对吧？
选 RTOS 也一样。第一步不是看系统，而是看你的项目到底需要什么。我个人的习惯是，先拿出一张纸，把下面四个维度列清楚。这四样东西搞明白了，选型就完成了一半。
3.1 任务数量：别被「多任务」忽悠了
任务数量，听起来简单。但我在项目中见过太多人栽跟头。
有一次，一个同事说他的项目需要 20 个任务。我一看代码，好家伙，其中 8 个任务就是轮询一个 GPIO 电平变化。这完全可以用一个中断+信号量搞定。
为什么要抠这个？因为任务数量直接影响内核开销：
- 每个任务都有自己的栈空间——内存就这么被吃掉了
- 任务切换需要时间——上下文保存恢复，一次切换几十到几百微秒
- 调度器复杂度上升——任务多了，优先级管理就乱
我的经验法则：
- 任务数 < 10：轻量级 RTOS 完全够用（如 FreeRTOS、uC/OS-II）
- 任务数 10~30：需要考虑优先级管理和调度策略
- 任务数 > 30：建议上实时 Linux 或商用 RTOS
你想想看，一个典型的 IoT 设备，其实就 3~5 个核心任务：采集、处理、通信、显示、看门狗。剩下的都可以用中断或定时器搞定。
避坑指南：我曾经接手过一个项目，任务数从 12 个膨胀到 35 个。原因很简单——每个工程师都习惯「加一个新功能就开一个新任务」。最后系统调度抖动严重，我花了整整两周重构，把任务合并到 15 个，问题才解决。
所以我的建议是：任务数量宁少勿多。能用状态机解决的，就别开任务。
3.2 内存预算：RAM 和 ROM 的博弈
内存预算，这是选型的硬约束。说白了，你的芯片有多少 RAM，决定了你能跑什么 RTOS。
我习惯把内存预算分成三块：
| 内存类型 | 用途 | 典型占用 |
|---|---|---|
| 内核自身 | RTOS 内核代码、数据结构 | 2~20 KB（ROM） |
| 任务栈 | 每个任务独立的栈空间 | 每任务 256B~4KB（RAM） |
| 系统堆 | 动态分配（消息队列、信号量等） | 视情况而定 |
举个例子。一个项目用 STM32F103，RAM 只有 20KB。你开了 8 个任务，每个任务栈 1KB，这就 8KB 没了。内核再占 2KB，堆再留 4KB，剩下 6KB 给应用。嗯，有点紧。
注意：千万别把栈空间算得太死。我见过一个案例，工程师把每个任务的栈算到刚刚好，结果一跑起来就栈溢出。为什么？因为中断嵌套、函数调用深度，这些都会临时吃栈空间。
我的习惯是：算出来的栈大小 × 1.5，留出余量。
另外，ROM 也要算。FreeRTOS 内核大概 6~12KB，uC/OS-III 大概 20~30KB。如果你的芯片 Flash 只有 64KB，那选 FreeRTOS 就比 uC/OS 更合适。
3.3 时间约束：硬实时还是软实时？
时间约束，这是 RTOS 选型的核心。我把它分成两类：
- 硬实时：错过截止时间 = 系统故障。比如安全气囊、刹车控制
- 软实时：偶尔错过可以接受。比如温度采集、数据显示
为什么会这样？因为不同的 RTOS 对实时性的保证能力不一样。
我举个例子。FreeRTOS 是抢占式调度，但它的 tick 精度是毫秒级。如果你需要微秒级的响应，那 FreeRTOS 就不太合适。这时候你可能需要看 RT-Thread 或者商用 RTOS。
我的经验：
- 响应时间要求 < 100μs：建议用裸机中断 + 状态机，或者商用 RTOS
- 响应时间要求 100μs~1ms：FreeRTOS、uC/OS 都可以
- 响应时间要求 > 1ms：大部分 RTOS 都能满足
还有一点，中断延迟。我记得有一次做电机控制，中断响应慢了 200μs，电机就开始抖。查了半天，发现是 RTOS 关中断的时间太长。后来换了一个支持中断嵌套的 RTOS，问题才解决。
避坑指南：我曾经在一个项目中，把所有的任务优先级都设成一样。结果系统跑起来后，任务之间互相抢 CPU，响应时间完全不可控。后来我按照「紧急程度」重新分配优先级，才稳定下来。
记住：优先级不是越多越好，而是越合理越好。
3.4 外设接口：驱动好不好写？
外设接口，这个容易被忽略。但说实话，它往往决定了你的开发周期。
你想想看，如果你的项目要用到 USB、Ethernet、CAN、SD 卡，那 RTOS 对这些外设的支持就很重要。
我习惯问自己三个问题：
- RTOS 有没有现成的驱动？——比如 FreeRTOS 有 TCP/IP 协议栈，但需要自己移植
- 驱动好不好移植？——有些 RTOS 的驱动层设计得很抽象，移植起来很痛苦
- 社区资源多不多？——遇到问题能不能搜到答案
举个例子。RT-Thread 对 STM32 系列的支持就很好，很多外设驱动都是现成的。而 FreeRTOS 虽然内核稳定，但外设驱动需要你自己写或者找第三方。
我的建议：
- 如果项目外设简单（GPIO、UART、SPI、I2C），大部分 RTOS 都行
- 如果外设复杂（USB Host、Ethernet、CAN FD），优先选生态好的 RTOS
- 如果外设很特殊（比如 FPGA 接口、自定义协议），那就要考虑 RTOS 的驱动框架是否灵活
我记得有一次做工业网关，需要同时驱动 4 路 CAN 和 2 路 Ethernet。当时选了 FreeRTOS，结果 CAN 驱动移植花了两周。后来换成 RT-Thread，因为它的 CAN 驱动框架已经适配好了，只花了一天。
注意：别只看 RTOS 本身，还要看你的 MCU 型号。有些 RTOS 对特定 MCU 有专门的 BSP 包，能省很多事。
3.5 小结：先列需求，再选系统
好了，四个维度讲完了。我总结一下：
- 任务数量：能少就少，别为了「多任务」而多任务
- 内存预算：RAM 和 ROM 都要算，留出余量
- 时间约束：分清硬实时和软实时，别拿 FreeRTOS 做安全气囊
- 外设接口：驱动好不好写，决定了你的开发周期
把这些列成一张表，贴在工位上。然后你再去翻 RTOS 的手册，心里就有底了。
下一章，我会讲怎么根据这些需求，去对比不同 RTOS 的特性。到时候你会发现，选型其实没那么难。
嗯，今天就到这里。有问题随时找我。