3. SafeRTOS概述
各位好，我是你们这节课程的讲师。今天我们来聊聊 SafeRTOS 的内核核心——任务状态机和调度策略。这部分内容，说白了就是操作系统的心脏。你写的所有应用代码，最终都要靠它来安排执行。
我个人习惯把任务状态机比作一个「人的一天」：有的人在干活（运行），有的人在等通知（阻塞），有的人被晾在一边（挂起），还有的人随时准备上场（就绪）。理解了这几个状态的流转，你就掌握了 RTOS 的脉搏。
3.1 任务状态机：四个状态与六种跳转
SafeRTOS 的任务状态，比某些 RTOS 要简洁。它只有四个状态：就绪（Ready）、运行（Running）、阻塞（Blocked）、挂起（Suspended）。没有「新建」或「终止」这种花哨的中间态，干净利落。
核心原则：任何时刻，一个 CPU 核心上只能有一个任务处于运行态。其他任务要么排队等 CPU，要么在等某个事件。
3.1.1 状态定义与转换条件
| 状态 | 含义 | 典型进入方式 | 典型退出方式 |
|---|---|---|---|
| 就绪（Ready） | 任务已就位，只等 CPU | 创建任务、从阻塞超时返回 | 被调度器选中 → 运行 |
| 运行（Running） | 正在占用 CPU 执行代码 | 调度器从就绪队列选中 | 时间片用完、被抢占、主动阻塞 |
| 阻塞（Blocked） | 等待某事件（信号量、队列、延时） | 调用 vTaskDelay()、获取信号量失败 | 事件到达或超时 → 就绪 |
| 挂起（Suspended） | 被强制暂停，不参与调度 | 调用 vTaskSuspend() | 调用 vTaskResume() → 就绪 |
嗯，这里要注意：挂起态和阻塞态有本质区别。阻塞态的任务还在「等」，一旦条件满足会自动回到就绪队列；挂起态的任务是被「冻住」了，必须由另一个任务或中断主动唤醒它。我在项目中遇到过有人把挂起当阻塞用，结果任务永远醒不过来——因为没人调用 vTaskResume()。
3.1.2 状态转换图
下面这张图，是我自己画的状态机流转图。你把它记在脑子里，调试任务卡死的问题时能省一半时间。
调试小技巧：用 vTaskList() 或 uxTaskGetSystemState() 打印所有任务的状态。如果发现某个任务长期卡在「阻塞」态但超时时间很短，八成是事件没发出来。我曾经排查过一个传感器驱动，就是靠这个 API 发现任务一直在等一个永远不会来的信号量。
3.2 调度策略：抢占式 + 时间片轮转
SafeRTOS 的调度策略，说白了就是两套机制的组合拳：基于优先级的抢占式调度 是主心骨，时间片轮转 是同优先级任务之间的公平机制。
3.2.1 基于优先级的抢占式调度
这是 SafeRTOS 的默认调度方式。每个任务有一个优先级（0 ~ configMAX_PRIORITIES-1，数值越大优先级越高）。调度器永远选择就绪态中优先级最高的那个任务来运行。
你想想看，这意味着什么？
- 如果高优先级任务就绪了，低优先级任务立即被踢出 CPU——这叫「抢占」。
- 高优先级任务如果不主动阻塞，低优先级任务永远没机会跑。
- 中断服务程序（ISR）的优先级高于任何任务，ISR 可以随时打断任务。
⚠️ 优先级反转陷阱：当低优先级任务持有高优先级任务需要的资源时，高优先级任务反而被阻塞。我曾经在一个电机控制项目里遇到过：一个高优先级的控制任务被一个低优先级的日志任务拖死，因为日志任务拿着互斥锁不放。解决方案是使用优先级继承协议，或者干脆把临界区做短。
3.2.2 时间片轮转
当多个任务具有相同优先级时，抢占式调度就「失灵」了——因为大家的优先级一样高，谁也不能抢谁。这时候就需要时间片轮转。
SafeRTOS 的每个 tick（系统时钟节拍），调度器会检查当前运行的任务是否用完了它的时间片。如果用完了，就切换到同优先级的下一个就绪任务。
| 特性 | 抢占式调度 | 时间片轮转 |
|---|---|---|
| 触发条件 | 更高优先级任务就绪 | 当前任务时间片耗尽 |
| 适用范围 | 不同优先级之间 | 同优先级任务之间 |
| 是否可配置 | 默认开启，可关闭 | 由 configUSE_TIME_SLICING 控制 |
| 典型场景 | 实时控制任务抢占后台任务 | 多个同等重要的数据采集任务 |
3.2.3 调度决策流程
我习惯用下面这个伪代码来理解调度器的决策逻辑。它虽然简单，但覆盖了 90% 的调度场景。
// 调度器核心决策逻辑（简化版）
void vTaskSwitchContext(void) {
// 1. 查找最高优先级的就绪任务
UBaseType_t uxHighestReadyPriority =
uxTopReadyPriority; // 位图加速查找
// 2. 从该优先级的就绪链表中取第一个任务
TCB_t *pxNewTCB =
listGET_OWNER_OF_HEAD_ENTRY(
pxReadyTasksLists[uxHighestReadyPriority]);
// 3. 如果当前任务时间片用完且优先级相同
if (pxCurrentTCB->uxTimeSliceExpired) {
// 将当前任务移到链表尾部
vListRemove(&(pxCurrentTCB->xStateListItem));
vListInsertEnd(
&(pxReadyTasksLists[uxCurrentPriority]),
&(pxCurrentTCB->xStateListItem));
}
// 4. 切换任务
pxCurrentTCB = pxNewTCB;
}性能关键点：SafeRTOS 使用就绪任务位图来加速优先级查找。它维护了一个 uxTopReadyPriority 变量，通过位运算可以在 O(1) 时间内找到最高优先级的就绪任务。这也是 SafeRTOS 能在中断上下文快速完成上下文切换的原因之一。
3.3 实际项目中的调度策略选择
讲了这么多理论，我们来点实际的。我在做工业控制器项目时，总结了一套调度策略选择指南：
- 硬实时任务（如电机控制、PWM 输出）：分配最高优先级，使用抢占式调度。这些任务必须「说一不二」，延时超过 1ms 就可能出事故。
- 软实时任务（如传感器数据采集）：分配中等优先级，可以配合时间片轮转。偶尔被阻塞一下问题不大。
- 后台任务（如日志记录、状态上报）：分配最低优先级，利用空闲时间执行。我习惯把这类任务做成「空闲钩子函数」，或者用极低优先级任务。
避坑指南：我曾经把三个同优先级的通信任务放在一起，结果它们互相抢时间片，导致每个任务的数据包都发不完整。后来我把其中一个任务的优先级调高一级，让它先发完再让出 CPU，问题就解决了。记住：时间片轮转不是万能的，关键路径上的任务还是得用优先级来保证。
3.4 本章小结
SafeRTOS 的任务状态机只有四个状态，但状态之间的转换逻辑必须烂熟于心。调度策略的核心是「高优先级优先 + 同优先级轮转」，理解了这个，你就能预测任意时刻哪个任务在跑。
嗯，最后留个思考题：如果一个任务调用了 vTaskSuspend() 挂起自己，它还能被其他任务唤醒吗？答案其实就在状态机图里——挂起态只能通过 vTaskResume() 回到就绪态，所以只要还有别的任务或中断能调用这个函数，它就能被唤醒。但如果所有任务都把自己挂起了……那系统就死锁了。别问我怎么知道的。