OpenClaw系列：从嵌入式裸机到芯片级系统深度实战
023、中断嵌套与优先级抢占：实时系统的关键设计
一、一个让我熬夜到凌晨三点的bug
去年做一款工业伺服驱动器，Cortex-M4内核，主频168MHz。现场反馈：电机偶尔出现“抽搐”，频率不高，但一抽就是致命的位置偏移。抓了三天波形，最后定位到——中断嵌套把关键时序打碎了。
现象是这样的：主循环里跑着FOC电流环，定时器中断每50us触发一次，优先级设成0（最高）。同时，一个UART接收中断优先级设成2，用来接收上位机指令。按理说UART优先级低，不会打断电流环。但诡异的是，电流环执行时间偶尔从正常的8us飙到22us，刚好超过50us周期，导致下一次中断被延迟，电流环失控。
查到最后，发现是UART中断里调了一个printf函数，这个函数内部用了互斥锁——在中断里用互斥锁，等于给自己挖坟。更致命的是，这个互斥锁的实现里关了一次全局中断，导致高优先级的定时器中断被硬生生堵住。这就是典型的优先级反转，只不过反转的不是任务，而是中断。
二、中断嵌套的硬件基础：NVIC到底怎么干活
先别急着写代码，把Cortex-M的嵌套向量中断控制器（NVIC）摸清楚。NVIC支持最多256个中断优先级（实际芯片会裁剪，比如STM32只用了4位，16级）。关键点：抢占优先级和子优先级。
抢占优先级决定一个中断能否打断另一个正在执行的中断。只有抢占优先级更高的中断才能打断低优先级的。子优先级只在同抢占优先级时决定谁先执行，但不能嵌套。
举个例子：中断A抢占优先级0，中断B抢占优先级1。A正在跑，B来了，B只能等着。但如果B的抢占优先级是0，子优先级比A高，那B会等A跑完再执行——因为同优先级不能嵌套，这是Cortex-M的硬性规定。
这里踩过坑：很多人以为子优先级高就能嵌套，错了。子优先级只决定“排队顺序”，不决定“打断能力”。想实现嵌套，必须用不同的抢占优先级。
NVIC还有一个容易被忽略的机制：尾链（Tail-Chaining）。当中断A退出时，如果中断B已经挂起，NVIC不会先恢复现场再压栈，而是直接跳转到B的中断向量。这能省掉两次栈操作，大概12个时钟周期。但前提是中断A和B的优先级相同——如果不同，尾链失效，必须走完整的压栈出栈流程。所以，频繁切换不同优先级的中断，性能会打折扣。
三、优先级抢占的“潜规则”：别信数据手册的表面数字
数据手册告诉你：优先级数值越小，优先级越高。但实际工程里，优先级分配不是简单的“高优先级放实时任务”就完事。
我习惯把中断分成三类：
但有一个陷阱：中断服务函数里绝对不能调用会触发上下文切换的OS API，除非你明确知道自己在做什么。FreeRTOS的xQueueSendFromISR是安全的，但vTaskDelay就是自杀。更隐蔽的是，有些库函数内部会调用__disable_irq()，比如某些老版本的printf实现。一旦全局中断被关，所有优先级的中断都被堵住，包括你的硬实时中断。
别这样写：在中断里用malloc。堆分配器通常不是可重入的，而且可能触发内存碎片整理，执行时间完全不可控。我见过一个案例，中断里malloc导致系统卡死，因为堆锁被主循环占着，中断死等。
四、中断嵌套的“蝴蝶效应”：一个低优先级中断如何毁掉高优先级
回到开头的伺服驱动器bug。UART中断优先级低，但它调用了printf，printf内部用了互斥锁。互斥锁的实现通常是这样的：
void lock(void) {
__disable_irq(); // 关全局中断
// 检查锁状态
__enable_irq(); // 开全局中断
}
问题出在：UART中断执行到__disable_irq()时，全局中断被关闭。此时定时器中断（优先级0）来了，但被硬件屏蔽。UART中断继续执行，直到__enable_irq()才放开。如果UART中断里执行了较长的操作（比如字符串格式化），定时器中断就被延迟了。
更隐蔽的是，如果UART中断里调用了另一个函数，那个函数又调用了锁，而锁的实现里又嵌套了__disable_irq()——虽然Cortex-M支持嵌套关中断，但每次__enable_irq()都会恢复之前的中断状态，而不是简单地开中断。这会导致中断使能状态混乱。
解决方案：中断里绝对不用互斥锁。改用无锁环形缓冲区或者信号量（通过xSemaphoreGiveFromISR）。如果必须用锁，用中断安全的原子操作，比如Cortex-M的LDREX/STREX指令，或者直接操作NVIC的优先级屏蔽寄存器（BASEPRI）。
BASEPRI是个好东西。它可以屏蔽所有优先级低于某个值的中断，而不影响更高优先级的中断。比如设置BASEPRI为4，那么优先级4及以上的中断都会被屏蔽，但优先级0~3的中断照常响应。这样，在临界区里，高优先级中断依然可以抢占，不会出现优先级反转。
五、实战：设计一个不会崩的中断嵌套方案
以STM32H7为例，我通常这样分配：
- 抢占优先级0：系统滴答定时器（OS心跳）、故障保护输入（比如过流检测，必须立即响应）。
- 抢占优先级1：PWM定时器更新中断（电流环、速度环）、编码器索引脉冲捕获。
- 抢占优先级2：DMA传输完成中断（ADC、DAC）、以太网MAC中断。
- 抢占优先级3：UART、SPI、I2C等外设中断。
- 抢占优先级4：外部GPIO中断（按键、传感器触发）。
每个抢占优先级下，子优先级用来区分同一优先级的中断顺序，但记住：同优先级不能嵌套，所以子优先级只影响“谁先执行”，不影响“谁打断谁”。
关键设计原则：
六、调试中断嵌套的“土办法”
逻辑分析仪是神器，但有时候手边没有。我常用一个土办法：在中断服务函数入口和出口各翻转一个GPIO，用示波器看波形。如果发现高优先级中断的波形被拉宽，说明有低优先级中断在搞鬼。
更精细的方法：在中断里记录时间戳。比如在定时器中断入口读取一个32位定时器值，存入环形缓冲区，然后通过UART导出。分析时间戳序列，如果发现某个中断的执行时间突然变长，就能定位到是哪个中断嵌套导致的。
别这样写：在中断里用HAL_Delay()。HAL库的Delay通常依赖SysTick中断，如果SysTick优先级比当前中断低，Delay会死等，导致系统卡死。如果SysTick优先级高，Delay会占用大量时间，影响其他中断。
七、个人经验：中断嵌套设计的“三要三不要”
三要：
- 要明确每个中断的“最大执行时间”，并在代码注释里写清楚。比如“此中断执行时间不超过5us，若修改请重新测量”。
- 要在中断入口和出口添加断言检查，比如检查栈剩余空间是否足够，防止嵌套过深导致栈溢出。
- 要定期审查中断服务函数，看是否有新加入的库函数调用。很多第三方库会在更新后引入不可重入的代码。
三不要：
- 不要在中断里调用任何可能阻塞的函数，包括但不限于：printf、malloc、互斥锁、信号量等待（FromISR版本的Give可以，但Take不行）。
- 不要依赖中断优先级来保证时序，除非你完全控制了所有中断源。外部中断（比如GPIO）可能来自不可预测的源，优先级设置不当会导致系统抖动。
- 不要忽视中断延迟的累积效应。单个中断延迟1us可能没问题，但如果每秒触发1000次，累积延迟就是1ms，对高速控制来说是灾难。
最后说一句：中断嵌套不是炫技，是不得已而为之。能用轮询解决的问题，别用中断；能用DMA解决的问题，别用CPU。真正的实时系统，中断越少越好，嵌套越浅越好。
