3. RTOS调度核心：任务状态机与调度策略
调度器是RTOS的心脏。我见过太多工程师把调度器当成黑盒子，出了问题就怀疑是内核bug。其实大部分调度问题，都是对任务状态机和调度策略理解不透彻造成的。
今天咱们就把这个黑盒子拆开，看看里面到底怎么转的。
3.1 任务状态机：就绪/运行/阻塞/挂起
一个任务在RTOS里，生命周期无非四种状态。你想想看，人一天也就几种状态：工作、休息、等车、被叫停。任务也一样。
| 状态 | 含义 | 典型触发条件 |
|---|---|---|
| 就绪（Ready） | 任务已准备好运行，等待CPU | 创建完成、阻塞条件解除、被抢占 |
| 运行（Running） | 任务正在占用CPU执行 | 调度器选中该任务 |
| 阻塞（Blocked） | 任务等待某事件或资源 | 等待信号量、消息队列、延时 |
| 挂起（Suspended） | 任务被强制暂停，不参与调度 | 调用挂起API、调试暂停 |
这里有个关键点：阻塞和挂起看起来都是"不跑"，但本质完全不同。阻塞是任务主动让出CPU，等条件满足后自动恢复；挂起是被外部强制停止，必须由外部显式恢复。
核心原则：只有就绪态的任务才能被调度器选中进入运行态。阻塞和挂起的任务，调度器根本不会看它们一眼。
我画了一张状态转换图，帮你理清这四者的关系：
调试小技巧：我习惯在系统空闲时打印所有任务的状态统计。如果发现某个任务长期处于就绪态却得不到CPU，说明优先级设置有问题；如果大量任务同时阻塞，可能是某个共享资源成了瓶颈。
3.2 调度策略：抢占式 vs 时间片 vs 协作式
调度策略决定了"下一个该谁跑"。三种主流策略，各有各的脾气。
3.2.1 抢占式调度（Preemptive）
这是RTOS的标配。高优先级任务就绪后，立即打断当前运行的低优先级任务。说白了就是"官大一级压死人"。
我曾经在一个电机控制项目里，把中断服务里触发的任务优先级设得太高，结果它一就绪就把通信任务给抢了，导致协议栈超时。后来加了个优先级天花板协议才解决。
关键指标：抢占延迟 = 关中断时间 + 调度器切换时间。这个值决定了系统的实时响应能力。
3.2.2 时间片轮转（Round-Robin）
同优先级任务轮流跑，每人分一个时间片。适合对实时性要求不高的批量处理场景。
时间片大小怎么设？设太短，上下文切换开销占比高；设太长，轮转一圈的响应时间就长了。我一般取系统时钟节拍的1~5倍，比如tick=1ms，时间片就设2~5ms。
3.2.3 协作式调度（Cooperative）
任务主动让出CPU才能切换。这玩意儿在RTOS里用得少，但在一些超低功耗场景下反而有优势——没有抢占，就没有不确定的上下文切换。
避坑指南：我曾经在一个协作式系统里，有个任务忘了调用yield()，结果整个系统卡死。如果你用协作式，务必在每个任务的循环末尾显式让出CPU，或者加个看门狗兜底。
三种策略的对比，我整理了一张表：
| 特性 | 抢占式 | 时间片 | 协作式 |
|---|---|---|---|
| 实时性 | 高（确定性强） | 中（取决于时间片大小） | 低（依赖任务主动让出） |
| 实现复杂度 | 高（需处理临界区） | 中 | 低 |
| 资源开销 | 高（频繁切换） | 中 | 低 |
| 适用场景 | 硬实时、多优先级 | 同优先级批量任务 | 超低功耗、简单系统 |
| 典型RTOS | FreeRTOS、uC/OS-III | 大部分RTOS都支持 | uC/OS-II（可配置） |
3.3 上下文切换的代价
上下文切换不是免费的。每次切换，CPU都要保存当前任务的寄存器、堆栈指针、状态字，再恢复下一个任务的。这个过程就是纯开销。
我实测过一个Cortex-M4平台，FreeRTOS一次上下文切换大约耗时1.2μs（CPU主频168MHz）。听起来不多，但如果每秒切换10000次，那就是12ms的CPU时间被白白吃掉。
3.3.1 切换开销的构成
- 寄存器保存/恢复：通用寄存器、浮点寄存器（如果有）、特殊功能寄存器
- 堆栈切换：更新PSP/MSP指针
- 调度器查找：从就绪队列中找到最高优先级任务
- MPU/MMU重配置：如果启用了内存保护
3.3.2 如何测量切换时间
我常用的方法：在切换前后各翻转一个GPIO，用示波器抓波形。代码大概这样：
// 在调度器入口和出口加GPIO翻转
void vPortYieldHandler(void) {
GPIO_SetBits(GPIOA, GPIO_Pin_0); // 开始切换
// ... 保存上下文 ...
// ... 选择下一个任务 ...
// ... 恢复上下文 ...
GPIO_ResetBits(GPIOA, GPIO_Pin_0); // 切换完成
}用示波器量一下高电平宽度，就是一次完整的上下文切换时间。
优化建议：如果发现切换开销占比超过5%，就该考虑优化了。常见手段包括：减少任务数量、合并短任务、使用信号量代替消息队列（信号量切换开销更小）。
3.3.3 切换频率的合理范围
| 系统类型 | 建议切换频率 | 说明 |
|---|---|---|
| 硬实时控制 | 1000~5000次/秒 | 如电机控制、飞控 |
| 数据采集 | 100~1000次/秒 | 如传感器轮询 |
| 人机交互 | 20~100次/秒 | 如按键、显示刷新 |
| 低功耗待机 | <10次/秒 | 如物联网终端 |
嗯，这里要注意：切换频率不是越高越好。我见过有人把时间片设成1个tick，结果系统50%的CPU时间都花在切换上，应用逻辑反而跑不动。
我曾经踩过的坑：在一个多传感器融合项目里，我创建了20多个任务，每个任务只做一点点事。结果上下文切换开销占了CPU的30%。后来我把功能相近的任务合并成几个状态机，切换开销直接降到3%。任务不是越多越好，够用就行。
最后说一句：调度策略没有银弹。抢占式响应快但开销大，协作式开销小但实时性差。选哪种，取决于你的系统到底要什么。我个人的习惯是：默认用抢占式，只有在对功耗极其敏感的场景下才考虑协作式。