ARM7 SysTick与PendSV协同调度

原创于 2025-12-07 11:24:35 发布 · 478 阅读

13 ·

CC 4.0 BY-SA版权

文章标签：

#SysTick #PendSV #RTOS

AI助手已提取文章相关产品：

深入ARM Cortex-M调度核心：SysTick与PendSV的协同艺术

你有没有遇到过这样的场景？在调试一个实时任务时，明明高优先级任务已经就绪，系统却迟迟没有切换过去——直到某个中断结束的瞬间，任务才“啪”地一下跳转过去。那一刻，你盯着逻辑分析仪的波形，心里嘀咕：“这背后到底是谁在操控这一切？”

答案往往藏在一个看似不起眼的组合里： SysTick + PendSV 。

这不是两个普通外设的简单搭配，而是ARM Cortex-M架构为实时操作系统量身定制的一套精妙机制。它不炫技，但极其高效；它不动声色，却掌控着整个系统的命运流转。今天，我们就来拆开这个“黑箱”，看看RTOS究竟是如何在单核MCU上玩出多任务并发的魔术的。

从心跳开始：SysTick不只是个定时器

想象一下，如果一个操作系统没有时间概念，会怎样？

它无法衡量任务执行了多久，不能判断是否该轮到下一个任务运行，甚至连延时函数都会失效。时间，是实时系统的脉搏。而 SysTick ，就是Cortex-M内核自带的“心脏起搏器”。

它为什么非得是24位、递减、内置？

先别急着看寄存器配置。我们先问自己几个问题：

为什么不是32位？
为什么是递减而不是递增？
为什么不直接用通用定时器TIM2？

这些问题的答案，恰恰体现了ARM工程师的设计哲学。

24位够用吗？
当然够。假设你的MCU主频是72MHz，1ms对应72000个时钟周期，完全在24位范围内（最大约16.7M）。再低的频率更没问题。省下来的8位硬件资源，可以用于更关键的地方。

递减计数有什么好处？
很简单： 零就是终点，无需比较 。每次减1后，硬件可以直接检测 VAL==0 作为触发条件，逻辑极简，响应确定。如果是递增计数，还得额外做一次“是否等于重载值”的判断，多了不确定性。

为什么不用外部定时器？
因为可移植性。每颗Cortex-M芯片都有SysTick，无论你是STM32、NXP LPC还是GD32，代码几乎不用改。而且它紧挨CPU，延迟最低，不像APB总线上的定时器可能受总线仲裁影响。

🤔 小知识：有些初学者尝试用TIM6做RTOS节拍，结果发现中断延迟波动大，原因就在于APB总线争抢。而SysTick走的是内部快速通路，真正做到了“近水楼台”。

那么，它是怎么被“唤醒”的？

当你调用类似 SysTick_Config() 这样的函数时，实际上发生了三件事：

设置 LOAD 寄存器 → 决定滴答间隔
清零 VAL → 从头开始倒数
启动 CTRL 控制字 → 开始计数并使能中断

SysTick->LOAD  = SystemCoreClock / 1000 - 1;  // 1ms tick
SysTick->VAL   = 0;
SysTick->CTRL  = SysTick_CTRL_CLKSOURCE_Msk | 
                 SysTick_CTRL_TICKINT_Msk   | 
                 SysTick_CTRL_ENABLE_Msk;

注意这里 -1 的细节。因为计数是从 LOAD 值开始往下减，当减到0时才算一个完整周期。比如你想计10次，就得从9开始减。

一旦启动，SysTick就开始默默倒数。每1ms，它就会向NVIC发出一次异常请求——就像准时敲响的钟声。

但这口钟声，并不会立刻导致任务切换。它的真正作用，是告诉RTOS：“嘿，又过了一毫秒，该想想下一步谁该上场了。”

谁来决定换人？调度器说了算

当SysTick中断到来时，CPU暂停当前任务，跳进 xPortSysTickHandler() （以FreeRTOS为例）这类函数中执行节拍处理。

这时候，RTOS要做几件关键事：

调用 xTaskIncrementTick() → 把系统节拍数加一
检查是否有任务超时或时间片耗尽
判断是否存在更高优先级的就绪任务
如果需要切换，则标记“需上下文切换”

但！重点来了—— 此时绝不应该立即保存现场、切换任务栈 ！

为什么？

因为你现在正处于中断上下文中。也许你正在处理串口中断、DMA完成回调，甚至嵌套了多个ISR。贸然在这里做完整的上下文保存，不仅破坏了中断的实时性，还可能导致栈混乱。

那怎么办？

聪明的做法是： 只做决策，不下手执行 。

于是RTOS只是轻轻写了一笔：

if (need_context_switch) {
    SCB->ICSR |= SCB_ICSR_PENDSVSET_Msk;
}

这一行代码，就像是在待办事项清单上打了个勾：“等会儿记得换人。”但它并不马上行动。

真正的切换，交给另一个角色来完成——PendSV。

PendSV：那个总在“最后时刻”出手的调度执行者

如果说SysTick是“报时员”，那么PendSV就是“执行官”。

它的名字叫 Pendable Service Call ，翻译过来就是“可挂起的服务调用”。听上去有点拗口，其实意思很直白：我可以被你随时召唤，但我只在我方便的时候才来干活。

它凭什么这么“傲娇”？

因为它有一个绝招： 最低优先级异常 。

在Cortex-M的异常优先级体系中，你可以把PendSV设成比所有中断都低的存在。这意味着：

当前正在运行的任何ISR都能抢占它；
即使有多个中断嵌套，也必须全部退出后才会轮到它；
它总是在“风平浪静”的时候登场。

这就保证了一个黄金法则： 上下文切换永远发生在所有中断处理完毕之后 。

✅ 这就像一场交响乐演出结束后，指挥才允许乐手更换位置。绝不会在演奏高潮时突然喊“小提琴手下去休息，替补上！”

它是怎么被触发的？

前面提到的这句代码就是开关：

SCB->ICSR |= SCB_ICSR_PENDSVSET_Msk;

写入这个位后，NVIC就会记住“PendSV待处理”。只要当前没有更高优先级的异常在跑，它就会自动进入 PendSV_Handler 。

有趣的是，即使你重复写多次，也只会触发一次。因为它本质上是一个“挂起标志”，清一次才重新生效。

上下文切换的本质：寄存器搬家 + 栈指针重定向

终于到了最硬核的部分：PendSV Handler里到底干了什么？

我们可以把它理解为一场精密的“寄存器搬家”工程。

每个任务都有自己独立的栈空间，用来保存运行时的状态。当你切换任务时，必须把当前CPU寄存器的值存到旧任务的栈里，再从新任务的栈里恢复出它上次离开时的样子。

听起来简单？但实现起来要非常小心。

为什么只保存R4-R11？

你可能会奇怪：我在C语言里用了R0-R3那么多寄存器，怎么不管？

答案在于 AAPCS（ARM Architecture Procedure Call Standard） 。

根据调用规范：
- R0-R3 和 R12 属于“易失性寄存器”，函数调用前后不需要保持；
- R4-R11 是“非易失性寄存器”，必须由使用它们的函数负责保存；
- 返回地址LR、程序计数器PC、状态寄存器xPSR 等则由异常机制自动压栈。

所以在进入PendSV之前，已经有一部分上下文被自动保存了（由硬件完成），剩下的R4-R11就需要软件手动存取。

这也是为什么PendSV Handler要用汇编写的根本原因：只有直接操作寄存器，才能精准控制每一字节的去向。

典型上下文切换流程

下面这段精简版汇编，展示了核心逻辑：

PendSV_Handler:
    MRS     R0, PSP           ; 获取当前任务的栈指针（PSP）
    CBZ     R0, skip_save     ; 如果为空，说明在主栈运行，跳过保存

    SUBS    R0, R0, #32       ; 在栈上预留8个寄存器空间（R4-R11）
    STMIA   R0!, {R4-R7}      ; 先存低半部分
    MOV     R4, R8            ; 借助R4-R7暂存R8-R11
    MOV     R5, R9
    MOV     R6, R10
    MOV     R7, R11
    STMIA   R0!, {R4-R7}      ; 再存高半部分

    LDR     R1, =current_tcb  ; 将新的栈顶存回TCB
    STR     R0, [R1]

skip_save:
    LDR     R0, =current_tcb
    LDR     R0, [R0]          ; 加载下一个任务的TCB
    LDR     R0, [R0]          ; 取出其栈顶指针
    LDMIA   R0!, {R4-R7}      ; 恢复R4-R7
    MOV     R8, R4
    MOV     R9, R5
    MOV     R10, R6
    MOV     R11, R7
    ADDS    R0, R0, #16       ; 跳过已恢复的8字节（R4-R7）

    MSR     PSP, R0           ; 更新PSP指向新任务栈顶
    ORR     LR, LR, #0x04     ; 修改EXC_RETURN，告诉硬件使用PSP
    BX      LR                ; 异常返回，切到新任务

有几个关键点值得深挖：

1. PSP vs MSP：双栈机制的秘密

Cortex-M支持两个栈指针：
- MSP（Main Stack Pointer） ：通常用于中断和启动代码；
- PSP（Process Stack Pointer） ：每个任务拥有自己的PSP，代表其私有栈。

通过 MSR PSP, R0 指令切换PSP，就能让不同任务拥有隔离的内存空间，避免相互干扰。

2. `ORR LR, LR, #0x04` 到底改了啥？

这是整个切换的灵魂一笔。

在异常入口时，CPU会自动保存 xPSR/PC/LR/R0-R3/R12 到当前栈，并记录使用的是MSP还是PSP。这个信息就编码在返回链接寄存器 LR 的低4位，称为 EXC_RETURN 。

其中最关键的是 bit[2]：
- 若为0 → 返回时使用MSP
- 若为1 → 返回时使用PSP

所以 ORR LR, LR, #0x04 实际上是强制设置bit[2]=1，告诉CPU：“回去的时候别用主栈，去进程栈继续执行！”

💡 类比：就像飞机降落前塔台说“请切换至跑道2号”，否则就会降错地方。

3. 如何确保原子性？

整个过程看似复杂，但一旦开始执行PendSV Handler，就不会被其他异常打断（除非你设置了更高的异常，比如NMI或HardFault）。因此上下文保存与恢复是原子的，不会出现中间态被破坏的情况。

实战中的坑与最佳实践

理论讲得再漂亮，不如实战中踩过的坑来得深刻。以下是我在真实项目中总结的一些经验教训。

❌ 错误1：PendSV优先级设太高

曾经有个团队为了“加快调度速度”，把PendSV优先级设成了0（最高之一）。结果发现，某些低优先级中断永远得不到执行——因为每次时间片到，PendSV就抢先跳进来做切换，生生把中断卡住了。

📌 正确做法： 务必将其设为系统最低优先级 。

NVIC_SetPriority(PendSV_IRQn, 0xFF);  // 最低优先级

这样它才会乖乖排队，等到所有人都走光了才进场收拾残局。

❌ 错误2：在SysTick Handler里做太多事

有人图省事，在 SysTick_Handler 里直接调用任务通知、发送队列消息、甚至打印日志。殊不知这会让1ms中断变得很长，严重影响其他外设响应。

📌 正确做法： SysTick Handler越短越好，只做两件事 ：
1. 调用 xTaskIncrementTick()
2. 条件满足时触发PendSV

其余逻辑全部放到任务上下文中处理。

❌ 错误3：忽略浮点上下文保存（FPU场景）

如果你启用了FPU（如Cortex-M4F/M7），还有一个隐藏陷阱： s0-s15、FPSCR等浮点寄存器也需要保存 ！

否则会发生诡异现象：任务A计算完sin(x)，切出去一会儿，回来发现结果变了！

📌 解决方案有两种：

惰性保存（Lazy Preservation） ：只有当任务实际使用了FPU时才保存，减少开销；
统一保存 ：在PendSV中增加对S0-S15的保存与恢复。

后者实现简单，前者更高效，但需要额外维护“FPU占用标志”。

示例扩展（启用FPU时）：

; 保存浮点寄存器（需CP10/CP11使能）
VMRS    R1, FPCCR
TST     R1, #0x40           ; 是否已使用FPU？
BEQ     skip_fp_save

VSTMDB  R0!, {S16-S31}     ; 保存S16-S31（若使用双精度）
; ... 其他逻辑

⚙️ 性能权衡：1ms还是10ms节拍？

常见配置有100Hz（10ms）、250Hz（4ms）、1kHz（1ms）等。

频率	优点	缺点
1kHz	调度精度高，响应快	中断频繁，功耗高，CPU利用率下降
100Hz	开销小，适合低速应用	任务切换延迟可达10ms，不适合硬实时

📌 推荐策略：
- 工业控制、电机驱动 → 1kHz
- IoT传感器采集 → 100~250Hz
- 超低功耗设备 → 可结合tickless模式动态调整