1. 中断延迟基础：概念、测量与影响
各位好，我是老周。做嵌入式实时系统这么多年，我敢说——中断延迟是实时系统的命门。你系统跑得再快，调度算法再花哨，中断响应一拖，整个系统就崩了。今天咱们就把这个基础打牢。
1.1 中断到底是什么？
中断，说白了就是CPU正在干一件事，突然被另一件更紧急的事打断，去处理完再回来继续。嗯，就像你写代码写到一半，领导突然喊你开会——你得先保存现场，去开会，开完会再回来接着写。
在嵌入式系统里，中断的来源很多：
- 外部中断：按键按下、传感器信号跳变、网络数据包到达
- 内部中断：定时器溢出、DMA传输完成、看门狗超时
- 软件中断：系统调用、异常处理、任务切换
我在一个工业控制项目里遇到过，电机编码器的脉冲信号因为中断响应慢了半拍，导致位置计算偏差，机械臂直接撞上了限位块。从那以后，我对中断延迟就特别敏感。
核心认知：中断不是越快越好，而是可预测才重要。实时系统要的是“最坏情况下的响应时间”有保证，不是平均响应快。
1.2 中断延迟的定义与测量
中断延迟，指的是从中断信号到达CPU引脚到CPU开始执行中断服务程序第一条指令之间的时间差。你想想看，这段时间里CPU在干嘛？
- 当前指令执行完毕（有些CPU支持指令级中断，但大部分要等当前指令跑完）
- 保存上下文（压栈PC、状态寄存器、通用寄存器）
- 查找中断向量表（确定中断源对应的ISR入口地址）
- 跳转到ISR（取指、流水线刷新）
我习惯把中断延迟拆成两部分：
| 延迟分量 | 说明 | 典型时间 |
|---|---|---|
| 硬件延迟 | 中断信号传递、CPU响应逻辑、向量表查找 | 几十ns ~ 几百ns |
| 软件延迟 | 关中断时间、高优先级ISR执行、上下文保存 | 几μs ~ 几十μs |
测量中断延迟，我推荐两种方法：
- 示波器法：GPIO引脚在中断触发时拉高，ISR入口拉低，量脉冲宽度。简单粗暴，但精度高。
- 定时器捕获法：用定时器捕获中断触发时刻和ISR入口时刻，差值就是延迟。适合自动化测试。
我的经验：测量时一定要测最坏情况。我曾经在测试中只测了1000次，平均延迟2μs，结果上线后偶尔出现50μs的延迟——因为有个高优先级中断偶尔会嵌套。所以，测10万次以上，看最大值。
1.3 中断延迟对实时系统的影响
实时系统分两种：硬实时和软实时。中断延迟对它们的影响完全不同。
| 系统类型 | 延迟超标后果 | 典型场景 |
|---|---|---|
| 硬实时 | 系统崩溃、设备损坏、人员伤亡 | 安全气囊、飞行控制、医疗设备 |
| 软实时 | 性能下降、用户体验差、数据丢包 | 音视频播放、网络通信、人机交互 |
具体来说，中断延迟会带来三个典型问题：
- 数据丢失：UART接收中断延迟太长，硬件FIFO溢出，数据就丢了。我在一个串口通信项目里就吃过这个亏，115200波特率下，每字节约87μs，如果中断延迟超过这个时间，FIFO就满了。
- 任务超时：实时任务依赖中断来触发，中断晚了，任务就错过了截止时间。比如电机控制PWM周期是100μs，中断延迟50μs，那留给控制计算的时间就只剩一半了。
- 系统抖动：中断延迟不稳定，导致任务执行时间忽长忽短。这在音频处理里特别明显——声音会断断续续，像卡带一样。
避坑指南：我曾经在一个项目里，把所有中断优先级都设成一样，结果多个中断同时触发时，CPU不知道先处理哪个，延迟直接飙到毫秒级。记住：中断优先级必须合理分配，关键中断（如定时器、紧急故障）要设最高优先级。
1.4 中断延迟知识体系
下面这张图，是我梳理的中断延迟知识体系。你把它记在脑子里，后面调试的时候就知道从哪下手了。
1.5 一个真实案例
最后分享一个我早年踩过的坑。一个数据采集系统，要求每100μs采集一次ADC数据。我用定时器触发中断，在ISR里读ADC。测试时一切正常，但部署到现场后，数据偶尔出现跳变。
排查了三天，最后发现：系统里有个网络中断，优先级设得比定时器高。网络数据量大时，网络ISR执行时间超过50μs，导致定时器中断被延迟，ADC采样间隔变成了150μs。数据当然不准了。
解决方案很简单：把定时器中断优先级提到最高，网络中断降一级。同时，在网络ISR里只做数据接收，不做协议解析，把耗时操作放到任务里做。
教训：中断优先级不是越高越好，但时间关键的中断必须最高。另外，ISR里只做最必要的事，能放任务的就放任务。
好了，中断延迟的基础就讲到这里。记住：概念要清、测量要准、影响要懂。后面几章，咱们会深入具体的调试工具和优化方法。