FreeRTOS 任务上下文切换核心汇编 PendSV_Handler 寄存器入栈与出栈深度剖析

FreeRTOS 任务上下文切换核心汇编 PendSV_Handler 寄存器入栈与出栈深度剖析

在基于 ARM Cortex-M（如 M3/M4/M7/M33）构建的 FreeRTOS 实时多任务系统中，系统如何在微秒级时间内将当前正在运行的 任务 A（Task A） 暂停挂起，并无缝切入另一个就绪的 任务 B（Task B） 继续执行？

这一串联起整个 RTOS 多任务调度生命的终极核心枢纽，就是著名的 可挂起的系统调用异常（PendSV, Pendable Service Call / PendSV_Handler）。

许多初学者常常产生两大核心困惑：

深入掌握 Cortex-M PendSV 异常悬起与延迟执行机制、硬件自动压栈帧（Hardware Stack Frame）与软件手动压栈帧（Software Stack Frame）的双层拼图拓扑 以及 port.c 中 xPortPendSVHandler 汇编源码逐行微观时序，是每一个 RTOS 架构师与内核开发者必须吃透的终极压轴底层内功。

为什么必须选用 PendSV？（消灭中断嵌套踩踏惨案）

直接在 SysTick 中切换上下文 vs 挂起 PendSV 延迟切换微观对决：

【场景 A: 错误地在 SysTick ISR 中直接切换堆栈 (灾难惨案！)】
1. 外部高频电机中断 IRQ 正在执行…
2. SysTick 滴答中断突发到来，强行抢占嵌套了电机中断；
3. SysTick 发现需要切换任务，【直接粗暴修改 PSP 堆栈指针切到 Task B 并执行异常返回！】
4. 致命后果: 电机中断在被抢占时压在原堆栈中的现场被彻底破坏，电机 ISR 退出时系统【瞬间 HardFault 崩溃！】

【场景 B: 正确选用 PendSV 延迟执行 (FreeRTOS 黄金标准！)】
1. SysTick 或 外部 ISR 发现需要切换任务，【仅向 SCB->ICSR 写入一位，挂起 PendSV 异常 (Set PendSV Pending)】！
2. 系统继续执行未完的所有高优先级硬件中断；
3. 【只有当全系统所有的高优先级硬件中断全部执行完毕、系统准备返回线程模式的最后 1 个纳秒】:
4. 【最低优先级的 PendSV 异常才真正被 CPU 触发执行！】
5. 此时没有任何嵌套中断存在，堆栈环境极其纯净，上下文切换 100% 绝对安全！

任务上下文堆栈帧的“双层拼图”微观拓扑

当发生 PendSV 异常时，一个完整的任务上下文（16 个核心整型寄存器）是由 硬件自动压栈 与 软件汇编手动压栈 协同拼装完成的：

任务堆栈中的完整 16 寄存器双层上下文拓扑：

【低地址 (栈顶 / 当前 PSP 指向此处)】
├── R4 ┐
├── R5 │
├── R6 │
├── R7 ├─► 【第 1 部分: 软件手动压栈帧 (Software Stacking / 8 个寄存器)】
├── R8 │ – 由 PendSV_Handler 汇编代码显式执行 "stmdb r0!, {r4-r11}" 保存！
├── R9 │ – 存放任务长期持有的局部变量与非易失性通用寄存器。
├── R10 │
└── R11 ┘
├── R0 ┐
├── R1 │
├── R2 │
├── R3 ├─► 【第 2 部分: 硬件自动压栈帧 (Hardware Stacking / 8 个寄存器)】
├── R12 │ – 发生 PendSV 异常瞬间，由 CPU 硬件在 12 周期内【自动物理压栈！】
├── LR │ – 包含函数调用返回地址 (LR) 与程序计数器 (PC)！
├── PC │
└── xPSR ┘
【高地址 (栈底)】

xPortPendSVHandler 汇编源码逐行微观解剖实战

在 FreeRTOS 的 portable/GCC/ARM_CM4F/port.c（或 portasm.s）中，官方汇编实现如下：

.syntax unified
.text
.align 4
.global xPortPendSVHandler
.type xPortPendSVHandler, %function

xPortPendSVHandler:
// =========================================================================
// 阶段 1: 保存当前正在运行任务 (Old Task) 的上下文到其 PSP 栈中
// =========================================================================
mrs r0, psp // 读取当前任务的进程堆栈指针 PSP 到 R0
isb

// 提取当前任务控制块指针: r3 = &pxCurrentTCB, r2 = pxCurrentTCB
ldr r3, =pxCurrentTCB
ldr r2, [r3]

// 核心保存指令: 将 R4-R11 共 8 个寄存器原子压入 PSP 栈，并自动递减 R0 (更新栈顶指针)
stmdb r0!, {r4-r11}

// 将压栈后最新的栈顶地址 R0，保存到当前任务 TCB 的第一项 (TCB->pxTopOfStack)
str r0, [r2]

// =========================================================================
// 阶段 2: 调用 C 语言调度器选择最高优先级的就绪任务 (New Task)
// =========================================================================
stmdb sp!, {r3, r14} // 将 r3(&pxCurrentTCB) 和 r14(EXC_RETURN) 压入 MSP 保护
mov r0, #configMAX_SYSCALL_INTERRUPT_PRIORITY
msr basepri, r0 // 屏蔽受控中断，进入内核临界区
dsb
isb

// 调用 C 语言任务调度选择函数: 更新 pxCurrentTCB 指向最高优先级就绪任务！
bl vTaskSwitchContext

mov r0, #0
msr basepri, r0 // 恢复中断屏蔽 (退出临界区)
ldmia sp!, {r3, r14} // 从 MSP 恢复 r3 和 r14

// =========================================================================
// 阶段 3: 恢复新任务 (New Task) 的上下文并切入执行
// =========================================================================
// 提取新任务的 TCB 指针
ldr r1, [r3] // r1 = 新任务 pxCurrentTCB
ldr r0, [r1] // r0 = 新任务的最新栈顶指针 (pxTopOfStack)

// 核心恢复指令: 从新任务栈中弹出恢复 R4-R11 这 8 个寄存器，并递增 R0
ldmia r0!, {r4-r11}

// 将新任务更新后的堆栈指针恢复写入 CPU 的 PSP 寄存器
msr psp, r0
isb

// =========================================================================
// 阶段 4: 终极一跃！触发硬件异常返回 (BX R14 / EXC_RETURN = 0xFFFFFFFD)
// =========================================================================
// CPU 硬件捕获 EXC_RETURN 瞬间自动完成:
// 1. 自动从新任务 PSP 栈中弹出恢复 (R0-R3, R12, LR, PC, xPSR)！
// 2. 处理器模式平稳降级为 Thread 线程模式！
// 3. PC 寄存器被自动恢复为新任务上次被暂停时的下一条指令地址！
// 新任务毫无感知、天衣无缝地满血继续奔跑！
bx r14

工业实测性能对战

在 Cortex-M4（STM32F407 @ 168MHz）上，针对 FreeRTOS 任务上下文切换的物理时钟周期数进行高精度 GPIO 探针测量：

透视 PendSV 延迟执行在消除中断嵌套踩踏上的精妙机理，吃透硬件自动压栈与汇编手动压栈的双层拼接时序，嵌入式架构师才能深刻领会 RTOS 在裸机硬件之上构建轻量、极速多任务并行世界的终极算法美学。