038、中断服务程序与运动控制实时性
038 中断服务程序与运动控制实时性
一次深夜的电机抖动
凌晨两点，示波器上PWM波形像喝醉了一样抖动。步进电机在低速运行时发出“咔咔”的异响，位置反馈偶尔跳变几个脉冲。我盯着逻辑分析仪抓到的时序图，发现中断响应时间从预期的2μs变成了15μs——某个外设的中断服务程序里，工程师顺手写了个delay_ms(1)。
这个场景在运动控制开发中太典型了。中断服务程序（ISR）是实时性的最后防线，但很多人把它当普通函数写。今天聊聊ISR在运动控制中的那些坑，以及怎么把实时性从“勉强能用”做到“稳如磐石”。
中断延迟：运动控制的第一道坎
运动控制对中断延迟的要求有多苛刻？以伺服驱动器的电流环为例，典型控制周期是50-100μs。这意味着从硬件触发中断到ISR开始执行，延迟不能超过几个微秒。但实际中，中断延迟由三部分组成：
- 硬件延迟：中断信号从外设到CPU核的时间，通常固定
- 中断屏蔽时间：CPU正在执行关中断的指令，或者更高优先级中断正在处理
- 上下文切换：保存寄存器、切换堆栈的时间
我见过最离谱的情况是，某工程师在定时器中断里调用了printf——串口输出一个字符要几十微秒，直接导致下一个中断被错过。运动控制里，错过一个中断周期，电机可能就失步了。
中断嵌套：双刃剑
很多人喜欢