4. 中断管理优化：中断延迟分析、中断嵌套与抢占、ISR设计最佳实践

中断管理，说白了就是TCU的“应急响应系统”。

我做了这么多年牵引控制，见过太多因为中断处理不当导致的“灵异现象”——电机突然抖一下，电流波形莫名其妙毛刺，甚至直接触发过流保护停机。这些问题，十有八九都出在中断管理上。

今天咱们就聊聊，怎么把中断这块“硬骨头”啃下来。

4.1 中断延迟分析：你到底慢在哪？

先问个问题：从硬件拉高中断引脚，到你的ISR第一条指令开始执行，这中间到底花了多少时间？

很多人觉得“不就是几个时钟周期嘛”。嗯，我年轻时也这么想，直到有一次在项目中，我发现中断延迟竟然达到了200多个CPU周期。当时查了三天，最后发现是中断优先级配置和总线仲裁的问题。

中断延迟主要由三部分组成：

• 硬件延迟：CPU响应中断前的“收尾工作”。比如当前指令必须执行完，流水线要排空，这些是固定的，一般2-5个时钟周期。
• 软件延迟：进入ISR前的现场保护。压栈、保存寄存器，这部分取决于你的CPU架构和编译器优化。
• 抢占延迟：如果当前正在执行更高优先级的中断，那你就得等着。这是最不可控的部分。

怎么测？我习惯用GPIO翻转法：

// 在ISR入口立即拉高GPIO
void TIM1_IRQHandler(void) {
    GPIO_SetBits(GPIOA, GPIO_Pin_0);  // 测量点：中断响应
    // ... 实际处理代码 ...
    GPIO_ResetBits(GPIOA, GPIO_Pin_0); // 测量点：中断退出
}

用示波器看这个GPIO的上升沿，对比中断触发信号，差值就是实际延迟。

4.2 中断嵌套与抢占：别让“好心”办了坏事

中断嵌套，听起来很高级对吧？但我在项目中吃过它的亏。

有一次调试一个TCU样机，只要电机转速超过3000rpm，系统就随机死机。查了整整一周，最后发现是PWM中断和ADC中断互相嵌套，导致栈空间溢出。

关于中断嵌套，我的建议是：

• 能不嵌套就别嵌套。很多实时系统其实不需要嵌套，优先级够用就行。
• 如果必须嵌套，控制嵌套深度。我个人习惯不超过2层。超过3层，栈空间就很难预估了。
• 注意临界区保护。嵌套中断里如果访问共享资源，一定要用关中断或信号量保护。

抢占策略怎么选？看这张表：

策略	适用场景	风险
完全抢占	高实时性要求，各中断优先级明确	栈空间大，嵌套深度不可控
非抢占	中断少，处理时间短	高优先级中断可能被低优先级阻塞
分组抢占	TCU常用，按功能分组	配置复杂，需要仔细规划

我个人在TCU里常用分组抢占。比如：故障保护中断一组（最高优先级），电流环一组，速度环一组，通信中断一组。同组内不嵌套，不同组之间可以抢占。

4.3 ISR设计最佳实践：短、平、快

ISR的设计原则，我总结成三个字：短、平、快。

短——ISR里只做最必要的事。你想想看，ISR里跑一个复杂的浮点运算，其他中断就得等着。我在项目中见过有人在ISR里做FFT，结果整个系统响应慢得像蜗牛。

平——避免在ISR里调用函数。尤其是那些你不知道执行时间的函数。我习惯的做法是：ISR里只设置标志位，主循环里处理具体逻辑。

// 不好的做法：ISR里直接处理
void ADC_IRQHandler(void) {
    ProcessADCData();  // 这个函数可能执行很久
}

// 好的做法：ISR只设标志
volatile uint8_t adc_ready_flag = 0;

void ADC_IRQHandler(void) {
    adc_ready_flag = 1;  // 就做这一件事
}

void main_loop(void) {
    if(adc_ready_flag) {
        adc_ready_flag = 0;
        ProcessADCData();  // 在主循环里处理
    }
}

快——ISR的执行时间要可预测。我一般要求ISR执行时间不超过50微秒。超过这个数，你就得考虑把部分处理挪到任务级去。

最后说一个容易被忽略的点：中断优先级要静态配置。不要在运行时动态修改优先级，这会导致不可预测的行为。我见过一个项目，为了“优化性能”在运行时改优先级，结果系统跑着跑着就乱了。

嗯，中断管理这块，说白了就是“该快的快，该稳的稳”。你把握好这个度，TCU的实时性就能上一个台阶。