嵌入式中断为何抖动？临界区怎么收口？

很多实时故障并不是主频不够，而是最短响应路径被自己切碎了。嵌入式系统一旦把中断抖动和临界区膨胀带进控制链，现场看到的就不是偶发慢一拍，而是每次边沿都带着不确定时差。

中断抖动首先来自屏蔽窗口不再只覆盖那条真正危险的共享访问。驱动初始化、日志打印、寄存器轮询甚至一次看似无害的内存复制，只要放在关中断区间里，都会把外设事件挡在门外。更麻烦的是，这个延迟不是固定常数。Flash 等待、总线仲裁、分支命中情况不同，都会让同一段代码每次占用的时钟数略有变化，于是外部脉冲明明等长，进入处理函数的时间却在晃。若后面接的是电机换相、采样锁存或脉宽测量，这点晃动很快就会被放大成控制误差。若中断还承担时间戳锁存，前后两个事件的先后关系也会被这段随机等待悄悄改写。

很多团队只看平均中断延迟，结果把真正伤人的尾部时延漏掉了。对实时路径更有效的做法，是把中断入口到关键动作之间的最长屏蔽窗单独标出来，再按调用链逐层拆短：能改成原子位操作的，不要整段关中断；能先缓存状态再后台处理的，不要把格式化和决策都塞进前台。只有把不可打断的部分压到最窄，延迟统计里的尖峰才会真正消失，而不是被均值掩盖。

临界区收口则是另一件经常被写坏的事。很多代码把“防止竞争”理解成“先锁住再说”，于是一个互斥段同时包住寄存器访问、状态机推进和回调通知，逻辑上看似安全，实际上把不同层次的共享资源混到了一把锁里。嵌入式软件只要让快路径和慢路径争同一个保护区，优先级再高的任务也会在低优先级代码尾部排队，最后把局部互斥写成全局堵塞。一把锁只要跨过驱动层和业务层，等待时间就会跟着最慢分支一起放大。

更稳妥的收口方法是先分清共享对象，再分清危险操作。位标志更新、环形队列入队、硬件影子寄存器刷新，它们需要的保护粒度并不相同；有些只要关本地中断几个指令周期，有些更适合用双缓冲或只写入一次的状态翻转。把临界区按对象拆开以后，还要继续检查是否把等待外设、等待标志或可重入回调错误地放在锁内。真正可维护的方案不是“锁得住”，而是别人一眼就能看出这把锁到底在保护哪一个不变量。

验证时也不能只靠逻辑推演，最好直接量测最坏路径。把 GPIO 戳点打在中断入口、锁获取前后和关键输出动作上，再叠加高负载通信、Flash 访问或日志风暴，就能看见抖动到底来自屏蔽窗还是来自锁竞争。很多系统空载时表现很好，一上整机就乱，通常不是算法突然退化，而是那些原本被忽视的共享路径一起挤进了实时窗口。这类量测比单看一次示波器截图更有用，因为最长尾巴会被钉在具体调用链上。

所以，实时性真正先坏在边界管理上。把中断屏蔽缩到最小，再把临界区按资源收口，响应时间才会从“平均很快”变成“每次都可预期”。