1. 中断延迟基础：概念、测量与关键因素

中断，是嵌入式系统里最核心的机制之一。说白了，就是CPU正在干着活，突然被一个外部或内部事件打断，转去处理更紧急的任务。我刚开始做嵌入式那会儿，总觉得中断就是个“跳转+返回”，后来踩了不少坑才明白——中断延迟才是决定系统实时性的命门。

1.1 中断的概念

中断的本质，是一种硬件触发的异步事件。CPU在执行主程序时，外设（比如定时器、UART、GPIO）或者软件自身（软中断）会向CPU发送一个信号。CPU收到信号后，暂停当前任务，保存现场，跳转到中断服务程序（ISR）去执行。处理完ISR，再恢复现场，继续原来的工作。

我习惯把中断分成三类：

• 外部中断：来自芯片引脚，比如按键按下、传感器触发。
• 内部中断：来自片上外设，比如定时器溢出、DMA传输完成。
• 软件中断：由指令主动触发，比如ARM的SWI、RISC-V的ECALL。

你想想看，如果没有中断，CPU就得轮询所有外设——那效率低得可怕。中断让CPU能“按需响应”，这才是实时系统的基石。

1.2 中断延迟的定义与测量方法

中断延迟，指的是从中断事件发生到ISR第一条指令开始执行之间的时间差。这个时间窗口，直接决定了系统对紧急事件的响应速度。

测量中断延迟，我常用的方法有两种：

方法	原理	精度	适用场景
GPIO翻转法	中断触发时拉高GPIO，ISR入口拉低，用示波器测量脉冲宽度	ns级	硬件调试、快速验证
定时器捕获法	用定时器捕获中断触发时刻和ISR入口时刻，计算差值	时钟周期级	精确测量、性能分析
Trace调试法	通过硬件Trace工具记录指令流，精确到每条指令的执行时间	指令级	深度优化、复杂场景

我个人最推荐Trace调试法。记得有一次，我用GPIO翻转法测出来延迟是1.2μs，但系统就是偶尔丢包。后来上了Trace工具才发现，有个高优先级中断偶尔会嵌套进来，把延迟拉到了3.8μs。GPIO法根本看不到这个细节。

1.3 影响中断延迟的关键因素

中断延迟不是固定的。同一个芯片，不同场景下可能差好几倍。我总结下来，主要有三个因素在作祟。

1.3.1 CPU架构

不同CPU处理中断的方式天差地别。

• ARM Cortex-M系列：硬件自动压栈，中断延迟极低（通常12个时钟周期左右）。我特别喜欢M4/M7的尾链技术，连续中断时能省掉一次出栈入栈。
• RISC-V：标准架构下中断处理比较“裸”，需要软件保存更多寄存器。但可定制性强，有些厂商加了硬件压栈。
• x86：中断描述符表（IDT）查找、权限检查，延迟相对较高。做工业控制时，我一般不会选x86。

举个例子，同样是响应一个外部中断，Cortex-M7可能只要几十纳秒，而某些低端RISC-V核可能要几百纳秒。选型时一定要看中断延迟的典型值。

1.3.2 总线仲裁

中断响应需要CPU访问中断控制器（如NVIC、PLIC）来获取中断向量。如果总线上有其他主设备（比如DMA、另一个CPU核）正在占用总线，CPU就得等。

总线仲裁策略也很关键：

• 固定优先级：CPU优先级最高，但DMA长时间占用时依然会阻塞。
• 轮询仲裁：公平但延迟不可预测。
• 时分复用：每个主设备有固定时间片，适合硬实时场景。

1.3.3 缓存命中率

这个因素经常被忽略，但影响巨大。ISR代码和中断向量表如果不在缓存里，CPU就得去慢速Flash或RAM里取指令，延迟直接翻倍。

我习惯的做法：

• 把中断向量表和最常用的ISR放在ITCM（指令紧耦合内存）或SRAM里。
• 用MPU（内存保护单元）锁定关键代码段，防止被其他任务踢出缓存。
• 避免ISR里调用复杂函数，防止缓存污染。

1.4 知识结构图：中断延迟全景

下面这张图，把中断延迟的核心要素串起来了。我建议你把它存下来，做优化时对照着看。

1.5 避坑指南：我踩过的三个坑

1. 别信数据手册的“典型值”：那是在最理想条件下测的。实际项目中，总线负载、缓存状态、中断嵌套都会让延迟翻倍。我习惯自己用Trace工具实测。
2. 小心中断嵌套：高优先级中断会打断低优先级ISR。如果嵌套层数太多，低优先级中断的延迟会变得不可控。我一般限制嵌套不超过2层。
3. 关中断的代价：有些开发者喜欢在ISR里关中断来保护临界区。但关中断的时间越长，其他中断的延迟就越大。我建议用临界区锁代替全局关中断，或者把关中断时间控制在1μs以内。