4. 中断延迟分析：中断响应时间、中断嵌套、中断屏蔽
好，咱们今天聊个硬核话题——中断延迟。做运动控制的人，最怕的就是中断响应不及时。我见过不少项目，明明算法写得挺好，一上机就跑飞了，最后查出来都是中断惹的祸。
说白了，中断延迟就是CPU从收到中断信号，到真正执行中断服务程序（ISR）之间的那段时间。这段时间里，系统在干嘛？在忙别的事。你想想看，如果电机正在高速旋转，位置环每100微秒就要更新一次，结果中断晚了50微秒，那位置精度直接就崩了。
4.1 中断响应时间
中断响应时间，我习惯把它拆成三部分：
- 硬件延迟：CPU内部的中断采样、流水线冲刷、向量表查找。这部分通常是固定的，几到几十个时钟周期。
- 软件开销：保存上下文（压栈）、切换堆栈指针、跳转到ISR入口。这部分取决于编译器生成的代码质量。
- 关中断时间：如果CPU当前正处在关中断状态，那必须等开中断后才能响应。这是最不可控的部分。
核心公式：
最坏中断延迟 = 硬件延迟 + 软件开销 + 最大关中断时间
我在项目中遇到过一件事：某次用STM32F4做伺服驱动器，PWM中断优先级设得最高，但偶尔还是会出现位置超差。查了两天才发现，是Flash读取时有个隐藏的关中断窗口，大概1.2微秒。嗯，就是这1.2微秒，让我的位置环从100微秒抖到了101.2微秒，累积误差肉眼可见。
我的建议：测量中断延迟不要只看平均值，一定要看最坏情况。用GPIO翻转法，在ISR入口和出口各拉一次电平，用示波器抓最长的那个脉冲宽度。
4.2 中断嵌套
中断嵌套，说白了就是高优先级中断打断低优先级中断。听起来很美好，但实际用起来坑不少。
为什么会这样？因为嵌套意味着更多的压栈、更多的上下文切换。如果嵌套层数太深，堆栈可能溢出。我曾经在一个项目中，三层嵌套就把堆栈干到了2KB，而默认配置只有1KB——结果就是系统随机死机，查了三天才定位到。
| 嵌套层数 | 额外压栈开销（ARM Cortex-M4） | 典型堆栈消耗 |
|---|---|---|
| 0 | 0 周期 | ~64 字节 |
| 1 | ~12 周期 | ~128 字节 |
| 2 | ~24 周期 | ~192 字节 |
| 3 | ~36 周期 | ~256 字节 |
我个人习惯，在运动控制系统中尽量控制嵌套层数不超过2层。为什么？因为运动控制对确定性要求极高，嵌套带来的不确定性太大了。你想想看，如果PWM中断被CAN中断打断，CAN中断又被定时器中断打断，那PWM中断的响应时间就完全不可控了。
避坑指南：我曾经在项目中允许了4层嵌套，结果在极端工况下（同时收到CAN、SPI、定时器、外部触发四个中断），堆栈直接爆了。从那以后，我定了个规矩：运动控制相关的中断（PWM、编码器、故障保护）优先级最高，且不允许被其他中断嵌套。
4.3 中断屏蔽
中断屏蔽，就是主动关掉某些中断。听起来简单，但用不好就是灾难。
我见过最典型的错误：在临界区里关中断时间过长。比如在Flash写操作时，有些库函数默认关中断几十毫秒。你想想看，如果电机在高速运转，几十毫秒不响应中断，位置环早就飞了。
中断屏蔽的三种常见场景：
- 临界区保护：访问共享数据时，关中断防止数据竞争。但关中断时间要控制在微秒级。
- 优先级反转避免：低优先级中断持有资源，高优先级中断等待——这时候可以临时屏蔽低优先级中断。
- 系统启动/休眠：在系统状态切换时，短暂屏蔽所有中断。
我的经验法则：关中断时间不要超过系统最小时钟节拍的1/10。比如你的PWM周期是100微秒，那关中断时间不要超过10微秒。超过这个数，抖动就会肉眼可见。
嗯，这里要注意：中断屏蔽不是万能的。有些CPU架构（比如Cortex-M3/M4）有“咬尾中断”机制，可以在不增加延迟的情况下处理连续中断。但如果你手动屏蔽了中断，这个优化就失效了。
4.4 知识体系总览
下面这张图，是我自己总结的中断延迟分析框架。每次做新项目，我都会对着这张图检查一遍。
这张图把中断延迟的三个核心维度串起来了。我个人习惯，每次做中断设计时，先对着这张图过一遍：响应时间能不能接受？嵌套层数有没有失控？关中断时间有没有超标？
一个小技巧：在代码里埋一个“中断延迟监控”任务，每隔一段时间记录一下实际的中断响应时间。如果发现异常，立刻报警。我在某次项目中靠这个功能抓到了一个间歇性的Flash操作问题——那个问题如果不抓，产线上一半的板子都会在运行2小时后死机。
好了，中断延迟这块就聊到这儿。记住一句话：运动控制系统的实时性，很大程度上取决于你对中断延迟的把控。别小看那几微秒的抖动，在高速高精度的场景下，它就是合格与不合格的分界线。
公众号:蓝海资料掘金营，微信deep3321