3、中断管理优化：中断优先级配置、中断嵌套与抢占、ISR设计原则、中断延迟测量

中断管理，说白了就是嵌入式系统的“应急响应机制”。系统平时在跑主循环，突然来个外部事件——按键按下、数据包到达、定时器溢出——CPU就得放下手头的事，先处理这个“紧急情况”。

我做了十几年嵌入式，见过太多因为中断没处理好导致的“灵异现象”：系统偶尔卡死、响应时快时慢、优先级反转导致任务饿死……其实根子都在中断管理上。今天咱们就把这块彻底聊透。

3.1 中断优先级配置——别让“谁先来”变成“谁捣乱”

中断优先级，决定了多个中断同时到达时，CPU先响应谁。配置不当，轻则实时性下降，重则系统崩溃。

3.1.1 优先级分组模型

以ARM Cortex-M系列为例，NVIC支持最多256级优先级（实际芯片会裁剪）。优先级分为抢占优先级和子优先级两部分：

分组	抢占优先级位数	子优先级位数	优先级总数
NVIC_PriorityGroup_0	0	4	16
NVIC_PriorityGroup_1	1	3	8×2
NVIC_PriorityGroup_2	2	2	4×4
NVIC_PriorityGroup_3	3	1	2×8
NVIC_PriorityGroup_4	4	0	16×1

我个人习惯用Group_4（全抢占，无子优先级）。为什么？因为子优先级只在同抢占优先级时才有意义，而实际项目中我倾向于给每个中断分配唯一的抢占优先级——逻辑清晰，不容易出幺蛾子。

3.1.2 配置示例（STM32 HAL库）

// 设置优先级分组：4位抢占优先级，0位子优先级
HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4);

// 配置USART1接收中断：抢占优先级0（最高）
HAL_NVIC_SetPriority(USART1_IRQn, 0, 0);
HAL_NVIC_EnableIRQ(USART1_IRQn);

// 配置定时器中断：抢占优先级1
HAL_NVIC_SetPriority(TIM2_IRQn, 1, 0);
HAL_NVIC_EnableIRQ(TIM2_IRQn);

// 配置GPIO外部中断：抢占优先级2
HAL_NVIC_SetPriority(EXTI0_IRQn, 2, 0);
HAL_NVIC_EnableIRQ(EXTI0_IRQn);

3.2 中断嵌套与抢占——谁可以打断谁？

中断嵌套，就是高优先级中断可以打断正在执行的低优先级中断。这听起来很合理，但实际用起来有不少门道。

3.2.1 嵌套规则

• 规则1：只有抢占优先级更高的中断才能打断当前中断。
• 规则2：同优先级中断不能互相打断（Cortex-M硬件保证）。
• 规则3：中断嵌套深度受限于堆栈空间——每嵌套一层，压栈约8个字（32位）。

3.2.2 嵌套深度估算

假设每个中断服务程序需要64字节栈空间，系统总栈大小1024字节：

最大嵌套深度 = (总栈大小 - 主循环栈开销) / 单次中断栈开销
             = (1024 - 256) / 64
             = 12层

嗯，这里要注意：实际嵌套深度建议控制在3~5层以内。太深了，栈溢出风险急剧上升。

3.3 中断服务程序(ISR)设计原则——短、平、快

ISR的设计哲学就三个字：短、平、快。你想想看，中断期间CPU不能响应其他中断（除非嵌套），主任务也停着——ISR多跑1微秒，系统实时性就降1微秒。

3.3.1 黄金法则

1. 只做最必要的事：清除中断标志、读取/写入硬件寄存器、设置事件标志。
2. 绝对不要：调用printf、malloc、延时函数、复杂数学运算。
3. 数据传递用标志位或队列：ISR只负责“通知”，真正的处理交给任务级代码。

3.3.2 典型ISR模板

// 好的ISR：短小精悍
void USART1_IRQHandler(void)
{
    uint8_t data;
    
    // 1. 检查中断源
    if (__HAL_UART_GET_FLAG(&huart1, UART_FLAG_RXNE))
    {
        // 2. 读取数据（硬件操作）
        data = huart1.Instance->DR;
        
        // 3. 放入环形缓冲区（轻量级操作）
        ringbuf_put(&rx_ringbuf, data);
        
        // 4. 清除标志
        __HAL_UART_CLEAR_FLAG(&huart1, UART_FLAG_RXNE);
    }
}

// 坏的ISR：什么都往里塞
void BAD_USART1_IRQHandler(void)
{
    uint8_t data;
    char buffer[256];
    
    data = huart1.Instance->DR;
    
    // ❌ 不要在ISR里做字符串处理
    sprintf(buffer, "Received: %c\n", data);
    
    // ❌ 不要在ISR里调用阻塞函数
    HAL_Delay(1);
    
    // ❌ 不要在ISR里做复杂逻辑
    if (data == 0xAA)
    {
        // 触发某个复杂状态机...
    }
}

3.4 中断延迟测量——没有数据就没有优化

中断延迟，就是从硬件触发中断到ISR第一条指令执行的时间。这个指标直接决定了系统的实时性上限。

3.4.1 延迟组成

阶段	典型耗时	说明
硬件响应	3~12个时钟周期	CPU完成当前指令，识别中断
压栈	8~12个时钟周期	自动压入xPSR、PC、LR、R0-R3、R12
向量表查找	2~4个时钟周期	从向量表读取ISR地址
高优先级中断阻塞	不确定	如果有更高优先级中断正在执行
关中断时段	不确定	如果CPU当前处于关中断状态

3.4.2 实测方法

我常用的方法是：在中断触发前拉高一个GPIO，在ISR第一条指令拉低。用示波器测量脉冲宽度。

// 测量中断延迟的测试代码
// 在中断触发前（如定时器更新事件）执行：
GPIOA->BSRR = GPIO_PIN_0;  // 拉高PA0

// ISR第一条指令：
void TIM_IRQHandler(void)
{
    GPIOA->BRR = GPIO_PIN_0;  // 拉低PA0
    // ... 实际处理
}

示波器上看到的脉冲宽度，就是中断延迟。对于72MHz的STM32，这个值通常在0.5~2微秒之间。如果超过5微秒，说明系统里有太长的关中断区间。

3.5 中断管理知识体系

下面这张图，把中断管理的核心逻辑串起来了：

3.6 避坑指南与实战建议

最后，分享几个我这些年总结出来的实战经验：

• 中断优先级不要“平均主义”：给每个中断分配唯一抢占优先级，避免同优先级竞争。
• 关中断时间要量化：每次关中断操作，都要清楚它持续了多少微秒。超过10微秒的关中断区间，必须优化。
• ISR里别用循环等待：哪怕只等几个微秒，也会阻塞其他中断。用状态机代替轮询。
• 中断延迟要定期测量：每次软件迭代后，跑一遍延迟测试。我见过太多“改了一行代码，延迟翻倍”的案例。