3. 中断延迟测量：三种实战方法

中断延迟，说白了就是中断信号来了，到你的ISR（中断服务函数）真正开始跑，中间到底等了多久。这个指标在实时系统里太关键了。我见过不少项目，功能逻辑都对，就是中断响应慢了半拍，结果整个系统就崩了。

这一节，我带你用三种方法把中断延迟测出来。每种方法都有它的适用场景，也有它的坑。咱们一个一个来看。

3.1 方法一：逻辑分析仪测量法

这是最直观、也最让人信服的方法。你想想看，用眼睛直接看波形，还有什么比这更实在的？

操作步骤：

1. 在中断触发源（比如一个按键、一个定时器输出）上接一个探头。
2. 在ISR的第一条语句里，拉高一个空闲的GPIO引脚。
3. 用逻辑分析仪同时抓这两个信号。
4. 测量两个上升沿之间的时间差，就是中断延迟。

我曾经在一个电机控制项目里，用这种方法抓出来一个50微秒的延迟。当时怎么都找不到原因，后来发现是中断优先级配置错了，导致被另一个低频中断阻塞了。波形上一看，清清楚楚。

3.2 方法二：GPIO Toggle法

这个方法更轻量，不需要额外仪器。原理很简单：在中断触发前和触发后，各翻转一次GPIO，然后用示波器或者逻辑分析仪看脉宽。

实现代码：

// 中断触发前
GPIO_TogglePin(DEBUG_GPIO_PORT, DEBUG_PIN);
__disable_irq();
// 触发中断（比如软件中断）
__enable_irq();

// 在ISR中
void EXTI0_IRQHandler(void) {
    GPIO_TogglePin(DEBUG_GPIO_PORT, DEBUG_PIN);  // 第二次翻转
    // ... 实际中断处理 ...
    GPIO_TogglePin(DEBUG_GPIO_PORT, DEBUG_PIN);  // 第三次翻转
}

测量第一次和第二次翻转之间的时间，就是中断延迟。这个方法的好处是，你可以在目标板上直接测，不用改太多代码。但要注意，GPIO翻转本身也有开销，大概几十纳秒，测量结果里要扣掉这部分。

3.3 方法三：RTOS系统Tick测量法

如果你在用RTOS，这个方法最方便。利用系统Tick定时器，在中断前后记录Tick值，差值就是延迟时间。

实现思路：

volatile uint32_t latency_ticks;
volatile uint32_t tick_before, tick_after;

void trigger_interrupt(void) {
    tick_before = RTOS_GetTickCount();
    // 触发中断
    NVIC_SetPendingIRQ(EXTI0_IRQn);
}

void EXTI0_IRQHandler(void) {
    tick_after = RTOS_GetTickCount();
    latency_ticks = tick_after - tick_before;
    // ... 实际处理 ...
}

这个方法精度取决于Tick周期。一般RTOS的Tick是1ms或者10ms，所以只能测到毫秒级的延迟。对于微秒级的延迟，这个方法就不够用了。

测量方法	精度	所需工具	适用场景
逻辑分析仪法	纳秒级	逻辑分析仪	精确标定、调试
GPIO Toggle法	几十纳秒	示波器/逻辑分析仪	快速验证
RTOS Tick法	毫秒级	无额外工具	系统级监测

3.4 测量结果分析

拿到数据之后，怎么分析？我一般看三个维度：

• 最大值：决定了系统的最坏情况响应时间。实时系统里，这个值必须小于deadline。
• 平均值：反映了系统的典型性能。如果平均值偏高，说明中断处理本身可能有问题。
• 抖动（Jitter）：最大值和最小值的差。抖动大，说明系统里有不确定的阻塞因素。

我曾经在一个项目中，发现中断延迟的抖动特别大，从10微秒到200微秒都有。后来排查发现，是某个驱动里用了关中断的临界区，而且关的时间很长。把临界区优化成用信号量保护，抖动就降下来了。

3.5 知识结构图

下面这张图，把三种测量方法的流程和关系梳理清楚了。你可以对照着看，理解每种方法的定位。

嗯，三种方法各有千秋。逻辑分析仪法最准，但需要额外设备；GPIO Toggle法最灵活，适合现场调试；RTOS Tick法最方便，但精度有限。实际项目中，我建议你三种方法都掌握，根据场景灵活选用。