FreeRTOS学习（十）- 最核心的内容：优先级抢占式调度 + 上下文切换

经过前面多个模块的拆解，可以回答这个问题了。FreeRTOS 的"心脏"------也是它与裸机程序的根本区别------就一句话：

基于优先级的抢占式调度，配合 PendSV 中断实现的上下文切换。

整个 FreeRTOS 的所有其他机制（队列、信号量、定时器、事件组、内存管理...）都是建立在这个核心之上的"应用层"。理解了这个核心，就理解了 RTOS 的本质。

---

一、为什么这是"最核心"的？

把 FreeRTOS 比作一棵树：

                    应用代码
                       │
        ┌──────────────┼──────────────┐
        │              │              │
     队列/IPC       定时器        事件组/流缓冲
        │              │              │
        └──────────────┼──────────────┘
                       │
                  ┌────┴────┐
                  │ 任务调度 │  ← ★ 树干
                  │ + 切换  │
                  └────┬────┘
                       │
                  ┌────┴────┐
                  │  链表   │  ← 树根
                  │ + 内存  │
                  └─────────┘

砍掉队列、定时器、事件组 ，FreeRTOS 依然是个能用的 RTOS（你可以用全局变量+自旋等待做同步）。 砍掉任务调度+上下文切换，FreeRTOS 就退化成裸机程序------不再是 RTOS。

所以"任务调度+上下文切换"是 FreeRTOS 之所以是 RTOS 的充要条件。

---

二、核心机制的三个支柱

这个核心由三个紧密咬合的支柱支撑：

支柱 1：优先级就绪表（数据结构层）

核心数据结构 ：pxReadyTasksLists[configMAX_PRIORITIES] ------ 一个数组，每个元素是一条链表。

pxReadyTasksLists[0]  → [Idle任务]                    ← 优先级 0（最低）
pxReadyTasksLists[1]  → 空
pxReadyTasksLists[2]  → [任务A] → [任务B]             ← 优先级 2
...
pxReadyTasksLists[7]  → [任务H]                        ← 优先级 7（最高）

为什么用"每优先级一条链表"而不是一条全局排序链表？

• 选最高优先级任务时O(1) （查 uxTopReadyPriority 的最高位）
• 同优先级时间片轮转用 listGET_OWNER_OF_NEXT_ENTRY 的游标 O(1) 实现
• 插入/删除用 vListInsertEnd 也是 O(1)

这个设计把调度的热路径压到极致------每个 tick 只做常量操作。

支柱 2：Tick 中断驱动状态机（时基层）

核心函数 ：xTaskIncrementTick() ------ 每个 SysTick 中断调用一次。

它做三件事：

1. xTickCount++ ------ 推进系统时间
2. 检查延迟表 ：把到期任务从 pxDelayedTaskList 摘出，移入对应优先级的就绪表
3. 判断是否需要切换 ：若新就绪任务优先级 > 当前运行任务 → xSwitchRequired = pdTRUE

tick 溢出处理 ：用双延迟表互换（taskSWITCH_DELAYED_LISTS）O(1) 解决 32/64 位 tick 回绕问题。

这一步是"时间流逝→状态变化"的转换器：时间到了，阻塞的任务该醒了，醒了的任务可能比当前任务更急------于是请求切换。

支柱 3：PendSV 上下文切换（执行层）

核心函数 ：xPortPendSVHandler() ------ 优先级最低的中断，所有切换都集中到这里执行。

它做三件事：

1. 保存旧任务 ：stmdb r0!, {r4-r11} 把软件寄存器压入 PSP 栈，更新 TCB.pxTopOfStack
2. 选新任务 ：调用 vTaskSwitchContext() → taskSELECT_HIGHEST_PRIORITY_TASK() 更新 pxCurrentTCB
3. 恢复新任务 ：ldmia r0!, {r4-r11} 从新 TCB 弹出软件寄存器，bx r14 让硬件弹出剩余 8 个寄存器

为什么用 PendSV 而不是直接在 SysTick 里切换？ PendSV 优先级最低 → 如果有更高优先级中断正在执行，切换会延迟到所有中断处理完才发生 → 不抢占 ISR、不破坏中断实时性。

---

三、三个支柱如何协同运转

把三个支柱串起来，就是 FreeRTOS 运行的完整心跳：

   ┌─────────────────────────────────────────────────────────┐
   │  SysTick 硬件中断 (每 1ms)                               │
   └────────────────┬────────────────────────────────────────┘
                    │
                    ▼
   ┌─────────────────────────────────────────────────────────┐
   │  xTaskIncrementTick()         ← 支柱 2：Tick 驱动        │
   │                                                          │
   │   1. xTickCount++                                        │
   │   2. 延迟表到期任务 → 移入就绪表  ← 支柱 1：就绪表更新 │
   │   3. 若新就绪优先级 > 当前 → xSwitchRequired=TRUE      │
   │   4. 同优先级时间片到期 → xSwitchRequired=TRUE          │
   └────────────────┬────────────────────────────────────────┘
                    │ xSwitchRequired=TRUE
                    ▼
   ┌─────────────────────────────────────────────────────────┐
   │  设置 PendSV 悬挂位                                      │
   │  (portNVIC_INT_CTRL_REG = PENDSVSET_BIT)                │
   └────────────────┬────────────────────────────────────────┘
                    │ PendSV 优先级最低，等所有中断退出后才执行
                    ▼
   ┌─────────────────────────────────────────────────────────┐
   │  xPortPendSVHandler()        ← 支柱 3：上下文切换        │
   │                                                          │
   │   [硬件已自动压 xPSR/PC/LR/R12/R3-R0 到 PSP]           │
   │   1. stmdb r0!, {r4-r11}   → 压软件寄存器到旧任务栈     │
   │   2. str r0, [pxCurrentTCB] → 更新旧任务 pxTopOfStack   │
   │   3. bl vTaskSwitchContext  → 选新任务，更新 pxCurrentTCB│
   │   4. ldr r0, [pxCurrentTCB] → 取新任务 pxTopOfStack     │
   │   5. ldmia r0!, {r4-r11}   → 弹新任务软件寄存器         │
   │   6. msr psp, r0            → PSP 指向新任务硬件帧       │
   │   7. bx r14                 → 硬件弹 xPSR/PC/.../R0     │
   └────────────────┬────────────────────────────────────────┘
                    │
                    ▼
   新任务从上次被切走的位置继续执行

一个 tick = 一次"心跳"：时间推进 → 状态更新 → 可能切换 → 新任务运行。周而复始。

---

四、这个核心的精妙之处（深入讲解）

4.1 "优先级"是唯一的调度判据

FreeRTOS 调度器只看优先级，不看其他：

• 不看任务"等了多久"（同优先级才轮转，不同优先级严格抢占）
• 不看任务"重要性"（优先级数字就是重要性）
• 不看任务"CPU 占用率"（没有公平份额调度，高优先级不阻塞就永远不让出）

这意味着：高优先级任务必须自己阻塞或延时，否则低优先级任务永远得不到执行。这是"抢占式 RTOS"的根本契约。

void vHighPriorityTask(void *pv) {
    for(;;) {
        // 做事
        vTaskDelay(1);  // ★ 必须让出！否则低优先级任务饿死
    }
}

4.2 "阻塞"是调度的润滑剂

如果所有任务都不阻塞，抢占式调度就退化成"最高优先级任务独占 CPU"。FreeRTOS 的精髓在于让任务在不需要 CPU 时主动交出：

阻塞源	API	唤醒条件
时间	vTaskDelay(n)	n 个 tick 后
队列	xQueueReceive(q, &data, timeout)	队列有数据 or 超时
信号量	xSemaphoreTake(sem, timeout)	信号量可用 or 超时
事件组	xEventGroupWaitBits(eg, bits, ...)	指定 bit 被置位 or 超时
任务通知	ulTaskNotifyTake/XTaskNotifyWait	收到通知 or 超时

所有阻塞的本质都一样 ：任务从就绪表移到某个"等待表"，pxDelayedTaskList 记录超时唤醒时间。时间到或事件发生 → 移回就绪表 → 若优先级够高 → 触发 PendSV 切换。

这就是为什么前面讲链表模块时说"TCB 有两个 ListItem"------一个挂状态表（就绪/延迟/挂起），一个挂事件等待表。阻塞 = 同时挂在延迟表和事件等待表上。

4.3 上下文切换的"硬件/软件分工"

这是 FreeRTOS 设计中最精妙的一笔：

保存者	保存什么	何时
硬件（Cortex-M 自动）	xPSR, PC, LR, R12, R3, R2, R1, R0（8个）	进入异常时自动压 PSP
软件（PendSV 汇编）	R4-R11（8个）	PendSV Handler 里手动压 PSP

为什么这样分工？

• 硬件自动保存的 8 个寄存器是"调用者保存"（caller-saved），中断处理函数可能用到它们，所以硬件必须帮 ISR 保存
• 软件手动保存的 R4-R11 是"被调者保存"（callee-saved），ISR 不用，但任务切换必须保存（否则新任务会看到旧任务的 R4-R11）
• 这种分工让进入中断的开销最小（只压 8 个），切换时才补压另外 8 个

浮点单元（FPU）的惰性压栈 进一步把这个设计推向极致：Cortex-M4F 的 FPU 寄存器 S0-S31/FPSCR 只在真正用到浮点 时才压栈（由 LR.EXC_RETURN bit4 控制），不用浮点的任务切换时完全不碰 FPU 寄存器------零开销。

4.4 "pxTopOfStack 必须是 TCB 首字段"的设计契约

typedef struct tskTaskControlBlock {
    StackType_t *pxTopOfStack;  // ★ 必须是第一个字段！
    ListItem_t xStateListItem;
    ListItem_t xEventListItem;
    UBaseType_t uxPriority;
    // ...
} TCB_t;

PendSV 汇编里：

ldr r2, [r3]      ; r2 = pxCurrentTCB (TCB 指针)
str r0, [r2]      ; ★ 偏移 0 → 直接写 pxTopOfStack

如果 pxTopOfStack 不是首字段 ，汇编就得变成 str r0, [r2, #OFFSET]------多一条指令、多一个立即数。把它放首位，用零偏移寻址直接存取，节省了每次切换的指令周期。这种"数据结构为汇编优化"的契约在 FreeRTOS 移植层随处可见。

4.5 "延迟双表"优雅解决 tick 溢出

32 位 tick 在 1ms 节拍下 ~49.7 天溢出一次。如果不处理，溢出后所有"唤醒时间 < xTickCount"的判断都会错乱。

FreeRTOS 的解法：

pxDelayedTaskList        ← 当前 tick 域的延迟表
pxOverflowDelayedTaskList ← 跨过下一次溢出的延迟表

插入时：若 xTimeToWake < xTickCount（溢出了）→ 放 overflow 表。 tick 溢出时：taskSWITCH_DELAYED_LISTS() 互换两个指针 → O(1) 切换。

不需要遍历重排任何节点，一个指针交换解决所有问题。这个设计在 tasks.c 和 timers.c 中各实现了一次（任务延迟表 + 定时器到期表），思路完全一致。

---

五、把这个核心与其他模块串联

理解了核心，其他模块都变成了"核心机制的应用"：

队列 = 阻塞源 + 优先级唤醒

xQueueSend() 放数据
  → 若有等接收任务 → 从 xTasksWaitingToReceive 摘最高优先级
  → 移入就绪表
  → 若比当前任务高 → 触发 PendSV

队列本质上就是"让任务阻塞等待一个事件，事件发生时按优先级唤醒"。队列存储区只是附带功能。

互斥锁 = 队列 + 优先级继承

xSemaphoreTake() 拿不到
  → xTaskPriorityInherit(holder)  ← 抬升持有者优先级
  → 挂入等待表
  
xSemaphoreGive() 释放
  → xTaskPriorityDisinherit(holder)  ← 归还优先级
  → 唤醒最高优先级等待者

互斥锁就是"队列 + 优先级继承"的组合，解决优先级反转问题。

定时器 = 任务 + 队列 + tick

xTimerStart() 发命令到 xTimerQueue
  → 定时器守护任务被唤醒
  → 守护任务按到期时间排序处理
  → 到期 → 调用回调（在守护任务上下文）

定时器完全是"一个普通任务 + 一条队列 + 共享 tick 时基"的组合，没有任何特殊机制。

内存管理 = 独立于调度的基础设施

内存管理是唯一不直接依赖调度核心 的模块------它只提供 pvPortMalloc/vPortFree，被任务创建、队列创建等调用。但它的线程安全仍然依赖 vTaskSuspendAll/xTaskResumeAll（调度器挂起）。

---

六、一张图看懂 FreeRTOS 的"心跳"

时间轴 ─────────────────────────────────────────────────►

  优先级3   ──[TaskC运行]──┬──[TaskC继续]──┬──[TaskC运行]──
                           │               │
  优先级2   ──[TaskB阻塞]──┤               ├──[TaskB被唤醒]──[TaskB运行]
                           │               │
  优先级1   ──[TaskA阻塞]──┤───────────────┤
                           │               │
  tick #100  #101  #102  #103  #104  #105  #106  #107  #108
            │     │     │     │     │     │
            ▼     ▼     ▼     ▼     ▼     ▼
           [SysTick ISR]
            │
            ├─ xTickCount++
            ├─ 检查延迟表 → TaskB 在 #105 到期
            │   #105 时：TaskB 移入就绪表(优先级2)
            │           TaskC(优先级3)仍最高 → 不切换
            ├─ #106 时：TaskC 调 vTaskDelay → 进入延迟表
            │           TaskB(优先级2)现在最高 → xSwitchRequired=TRUE
            ▼
           [PendSV]
            │
            ├─ 保存 TaskC 上下文
            ├─ vTaskSwitchContext → pxCurrentTCB = TaskB
            ├─ 恢复 TaskB 上下文
            ▼
           TaskB 从上次阻塞点继续运行

---

七、FreeRTOS 核心设计的哲学总结

设计原则	体现
极简主义	内核核心仅 list.c + queue.c + tasks.c 三个文件；PendSV 切换仅 ~20 行汇编
确定性优先	O(1) 选最高优先级任务；O(1) tick 处理；O(1) 队列锁计数；最坏情况可分析
硬件/软件分工	硬件自动保存 caller-saved，软件手动保存 callee-saved；FPU 惰性压栈
数据结构为热路径优化	TCB 首字段是 pxTopOfStack；就绪表每优先级一条链表；哨兵消除边界判断
延迟处理减少中断关断时间	队列锁计数让 ISR 只做计数，链表操作延迟到任务上下文批量做
空间换时间	TCB 两个 ListItem（状态+事件）；哨兵节点；MiniListItem 省内存又保速度
可裁剪	从 heap_1 到 heap_5、从协程到 SMP、从静态到动态------同一套核心，多种配置

---

八、一句话总结

FreeRTOS 的核心是 "基于优先级的抢占式调度 + PendSV 上下文切换" ，由三个支柱协同实现：优先级就绪表 （O(1) 选任务）、Tick 中断 （时间推进→状态转换）、PendSV Handler （保存旧任务+选新任务+恢复新任务）。整个系统的其他所有模块------队列、信号量、定时器、事件组、内存管理------都是建立在这个核心之上的"应用层"。理解了这个核心，就理解了 RTOS 的本质：让多个任务"同时"运行，高优先级任务能抢占低优先级任务，阻塞的任务让出 CPU 给需要运行的任务。

这也就是为什么前面分析 PendSV 时说"PendSV 是 RTOS 运行过程中所有任务切换的唯一入口"------它就是 FreeRTOS 心脏的"瓣膜"，每一个 tick 都通过它完成一次可能的心跳。