📚 课程目录第4章软件因素对中断延迟的影响

4. 软件因素对中断延迟的影响：关中断时间、临界区设计、中断服务程序长度

中断延迟，说白了就是硬件发出中断信号到CPU开始执行中断服务程序（ISR）第一条指令之间的时间差。硬件因素我们上一章聊过了，今天重点说说软件层面——很多时候，延迟的瓶颈不在芯片，而在你的代码里。

我个人习惯把软件因素归纳为三个核心点：关中断时间、临界区设计、ISR长度。这三者互相影响，但每个都有独立的优化空间。

关中断，就是CPU暂时不响应任何中断请求。这段时间里，所有中断都被挂起。你想想看，如果关中断时间太长，高优先级的中断就只能干等着。

我在项目中遇到过这样一个案例：一个电机控制项目，PWM中断要求50μs内响应。结果测试发现偶尔会延迟到200μs。查了半天，发现是某个驱动库在Flash写入时关了中断，一关就是150μs。嗯，这就是典型的关中断时间失控。

  核心原则：关中断时间必须小于系统允许的最小中断延迟。对于硬实时系统，这个时间通常需要控制在10μs以内。

常见的关中断场景包括：

怎么优化？我建议从这几个方向入手：

小技巧：我习惯在关中断入口和出口各翻转一个GPIO，然后用逻辑分析仪抓波形。一眼就能看出哪些代码段关中断时间超标。

临界区，就是那些不能被中断打乱的代码段。设计得好，保护到位且延迟可控；设计得不好，要么数据出错，要么延迟爆炸。

我曾经接手过一个通信协议栈，里面到处都是关中断操作，平均每个临界区长达80μs。后来重构时发现，很多临界区其实只需要保护一个全局变量的读写，完全可以用原子操作替代。

临界区实现方式	保护粒度	对中断延迟影响	适用场景
关全局中断	粗	大（所有中断被屏蔽）	极短操作（< 1μs）
关特定中断优先级	中	中（只屏蔽低优先级中断）	中等长度操作（1-10μs）
原子操作（LDREX/STREX）	细	极小（不关中断）	单变量读写
自旋锁（多核）	细	极小（只阻塞其他核）	多核共享资源

设计临界区时，我遵循三条原则：

避坑指南：我曾经在临界区内调用了回调函数，结果回调函数里又关了中断。两层嵌套下来，关中断时间直接翻倍。后来我规定：临界区内禁止调用外部函数，除非明确标注了中断安全性。

ISR的长度直接影响中断延迟——不只是当前中断的延迟，还影响其他中断。你想想看，如果ISR执行了100μs，这100μs里其他中断都得排队等着。

我记得有个项目，ADC中断里做了浮点运算和滤波算法，ISR执行时间长达300μs。结果UART中断响应延迟从设计的10μs变成了实测的350μs。嗯，这就是典型的ISR超时问题。

ISR应该只做三件事：

其他所有处理，都应该放到任务层去执行。这就是所谓的上半部/下半部设计模式。

  经验法则：ISR执行时间不应超过系统最小中断周期的10%。比如中断周期是100μs，ISR最好控制在10μs以内。

优化ISR长度的具体方法：

实测方法：我习惯在ISR入口和出口各翻转一个GPIO，然后用示波器测量脉冲宽度。这样能精确知道ISR的实际执行时间，比软件打点更可靠。

关中断时间、临界区设计、ISR长度，这三者不是孤立的。它们共同决定了系统的中断延迟表现。

举个例子：如果你把临界区设计得很短（比如只关中断1μs），但ISR里做了大量计算（比如50μs），那高优先级中断的延迟依然很大。反过来，ISR很短但临界区很长，同样会出问题。

我画了一张图，帮你理清这三者的关系：

从图中可以看出，三个因素最终汇聚到同一个目标：可预测的低中断延迟。任何一个环节出问题，都会破坏这个目标。

说了这么多，到底怎么落地？我总结了一套检查清单，每次做中断延迟优化时都会过一遍：

注意：优化中断延迟时，不要只盯着一个指标。我见过有人把ISR优化到1μs，但关中断时间却从5μs变成了20μs——因为他在临界区里加了复杂的原子操作。整体延迟反而变差了。要全局看，不要局部优化。

最后说一句：中断延迟优化没有银弹。每个系统的中断负载、硬件特性、实时要求都不一样。关键是要掌握分析方法，然后针对具体问题做具体优化。嗯，这就是我这么多年积累下来的核心经验。