中断延迟分析：定义、组成与计算方法

中断延迟，说白了就是从硬件触发中断信号，到CPU真正执行中断服务程序（ISR）第一条指令所花的时间。这个指标直接决定了系统的实时响应能力。我做过一个电机控制项目，就因为中断延迟超标，导致过流保护总是慢半拍，烧了好几个驱动板——从那以后，我对中断延迟的分析再也不敢马虎。

中断延迟的组成

中断延迟由两部分构成：硬件延迟和软件延迟。它们像接力赛一样，一棒接一棒地传递，每一棒都会消耗时间。

硬件延迟因素

硬件延迟是芯片设计时就定死的，你改不了，但必须心里有数。我列几个常见的因素：

• 中断信号传递时间：从外设引脚到中断控制器，再到CPU核心，路径上的门电路延迟。一般在几纳秒到几十纳秒。
• 中断控制器仲裁时间：多个中断同时到达时，控制器需要判断优先级。ARM Cortex-M的NVIC大概需要3-5个时钟周期。
• CPU当前指令完成时间：CPU必须等当前指令执行完才能响应中断。最坏情况是遇到多周期指令，比如除法、内存访问。
• 流水线冲刷时间：CPU需要清空流水线，保存上下文。Cortex-M3/M4大概需要12个时钟周期。

软件延迟因素

软件延迟才是中断延迟的大头，也是我们工程师能优化的地方。我遇到过不少项目，硬件延迟只有几十纳秒，软件延迟却跑到几十微秒，问题全出在这里。

软件延迟因素	说明	典型时间
关中断时间	临界区保护时关闭中断，导致中断无法响应	1-100 µs
高优先级ISR执行时间	当前正在执行的高优先级中断会阻塞低优先级中断	取决于ISR长度
RTOS调度延迟	RTOS在调度时可能暂时关闭中断	5-50 µs
嵌套中断处理	中断嵌套时，低优先级中断等待高优先级完成	取决于嵌套深度
上下文保存/恢复	CPU自动压栈和出栈的时间	10-30个时钟周期

这里我要特别强调关中断时间。我曾经在一个项目中，某个驱动库的临界区关了50微秒的中断，导致另一个高优先级的中断响应延迟超标。查了两天才找到原因——说白了就是代码里关中断的粒度太粗了。

最大中断延迟的计算方法

最大中断延迟，就是系统在最恶劣情况下，中断响应需要的最长时间。计算这个值，你需要考虑所有可能阻塞中断的因素。

计算公式如下：

最大中断延迟 = 硬件延迟 + 最大关中断时间 + 所有高优先级ISR执行时间之和 + RTOS调度延迟

我们来拆解一下：

1. 硬件延迟：查芯片手册，一般有明确数值。
2. 最大关中断时间：遍历所有临界区，找出关中断最长的那个。
3. 高优先级ISR执行时间：把所有比目标中断优先级高的ISR执行时间加起来。
4. RTOS调度延迟：RTOS在调度时关中断的时间，一般有典型值。

这个38.1微秒，就是中断A在最坏情况下的响应时间。如果你的系统要求中断A在30微秒内响应，那这个设计就不合格。

中断延迟分析流程图

下面这张图，帮你理清中断延迟的整个分析流程：

如何测量中断延迟

理论计算是一回事，实际测量是另一回事。我建议你在项目初期就搭好测量手段：

• GPIO翻转法：中断触发时拉高一个GPIO，ISR第一条指令拉低。用示波器看脉冲宽度。
• 定时器捕获法：用定时器的输入捕获功能，记录中断触发和ISR执行的时间戳。
• RTOS内置工具：像FreeRTOS的trace功能，可以记录中断响应时间。

总结一下

中断延迟分析，说白了就是搞清楚从信号到响应这段时间里，每一纳秒都花在了哪里。硬件延迟你改不了，但软件延迟——关中断时间、ISR执行时间、RTOS调度延迟——这些都是你可以优化的。

记住：最大中断延迟 = 硬件延迟 + 最大关中断时间 + 所有高优先级ISR执行时间之和 + RTOS调度延迟。这个公式，我建议你贴在工位上。