2. 中断延迟定义：测量方法与关键因素

中断延迟，说白了就是从硬件中断信号拉高，到CPU真正执行中断服务程序（ISR）第一条指令之间的时间差。

我刚开始做嵌入式时，总觉得这玩意儿就是个理论值。直到有一次，一个电机控制项目在高速运转时频繁丢步，查了三天才发现是中断延迟超标了。嗯，从那以后，我对这个指标再也不敢马虎。

2.1 中断延迟的组成

中断延迟不是单一数值，它由几个阶段叠加而成。我习惯把它拆成三部分：

阶段	描述	典型耗时
硬件识别延迟	中断信号从外设到达CPU中断控制器的时间	几十ns ~ 几μs
CPU响应延迟	CPU完成当前指令、保存上下文、跳转到中断向量表	几μs ~ 几十μs
软件调度延迟	RTOS中断嵌套、优先级仲裁、中断屏蔽检查	几μs ~ 几百μs

你想想看，如果硬件识别只花50ns，但软件调度花了200μs，那瓶颈在哪？一目了然。

2.2 中断延迟的测量方法

测量中断延迟，我推荐三种方法。每种都有适用场景，别指望一招吃遍天。

方法一：GPIO示波器法（最直观）

1. 在中断源触发时，同时拉高一个空闲GPIO。
2. 在ISR第一条指令处，立即拉低该GPIO。
3. 用示波器测量GPIO高电平的宽度。

我在项目中遇到过，这种方法测出来的延迟包含了GPIO翻转本身的耗时（大约几十ns），但作为工程评估完全够用。

方法二：定时器捕获法（更精确）

1. 配置一个高精度定时器，频率至少1MHz以上。
2. 中断触发时，硬件自动捕获定时器计数值T1。
3. ISR第一条指令读取当前计数值T2。
4. 延迟 = (T2 − T1) × 定时器周期。

这种方法可以做到纳秒级精度，但需要硬件支持定时器输入捕获功能。ARM Cortex-M系列的DWT（Data Watchpoint and Trace）循环计数器也能干这事。

// 伪代码示例：定时器捕获法测量中断延迟
uint32_t capture_value;
uint32_t isr_entry_value;

void TIM_Capture_IRQHandler(void) {
    capture_value = TIM->CCR1;  // 硬件自动捕获
    isr_entry_value = TIM->CNT; // ISR入口读取
    uint32_t latency = isr_entry_value - capture_value;
    // 记录到环形缓冲区
}

方法三：RTOS内置统计法（系统级）

像FreeRTOS、RT-Thread这类系统，都提供了中断延迟统计API。它们会在任务切换时记录时间戳，然后汇总出最大、最小、平均延迟。

说白了，这种方法适合长期监控，不适合单次精确测量。我一般用它做压力测试——让系统跑一晚上，看最大延迟有没有超过阈值。

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

影响中断延迟的因素很多，我挑最重要的几个说。这些是我在多个项目中踩过的坑。

2.3.1 中断屏蔽（Interrupt Masking）

这是最大的影响因素，没有之一。当CPU关中断时，任何中断都得排队等着。

• 全局关中断：比如ARM的CPSID指令，关中断时间越长，延迟越大。
• 局部中断屏蔽：RTOS的临界区保护，往往只关高优先级中断。

我曾经在一个项目中，发现某驱动库的临界区长达150μs。嗯，那段时间所有中断都得等，你说实时性怎么保证？

2.3.2 中断优先级与嵌套

高优先级中断可以抢占低优先级中断。但如果多个高优先级中断同时触发，仲裁时间就会增加。

场景	延迟影响
单中断，无嵌套	最低，仅受关中断影响
多中断，优先级固定	中等，高优先级抢占低优先级
多中断，动态优先级	最高，仲裁逻辑复杂

2.3.3 CPU当前执行状态

CPU正在执行什么指令，直接影响响应速度。

• 多周期指令：比如除法、浮点运算，CPU必须等当前指令完成才能响应中断。
• 内存访问：Cache Miss时，CPU要等内存数据，中断响应也会被拖慢。
• 低功耗模式：从Sleep/Wake模式唤醒，需要额外时间。

你想想看，如果CPU正在做一次200周期的浮点除法，中断来了也只能等着。这就是为什么我建议把浮点运算放到任务里，别放在中断里。

2.3.4 中断控制器架构

不同的中断控制器，延迟差异很大。

• NVIC（ARM Cortex-M）：硬件自动压栈，延迟低且确定。
• GIC（ARM Cortex-A）：支持多核分发，但软件配置复杂，延迟略高。
• 外部中断控制器：比如FPGA实现的中断控制器，延迟取决于逻辑深度。

2.4 中断延迟知识体系

下面这张图，是我自己梳理的中断延迟知识结构。每次做性能调优前，我都会对照它过一遍。

2.5 避坑指南

最后，分享几个我踩过的坑，希望能帮你少走弯路。