2. 中断管理优化：中断优先级配置、中断嵌套处理、中断延迟分析与降低方法

中断管理，说白了就是嵌入式系统的“应急响应机制”。你想想看，一个外部事件来了，CPU得放下手头的活儿去处理它。这个处理得快不快、优不优先，直接决定了系统的实时性。我在三星平台上折腾了这么多年，中断这块踩过的坑真不少，今天就跟大家好好聊聊。

2.1 中断优先级配置——别让“小事”耽误了“大事”

中断优先级，就是给中断排个队。谁更重要，谁先处理。三星的ARM Cortex-M系列内核，比如S3C2440、S5PV210这些，都支持可编程的中断优先级。

我个人习惯，把时间关键的中断（比如定时器、PWM控制）设为最高优先级。把那些不那么紧急的（比如按键扫描、串口接收）放低一些。为什么？因为高优先级中断可以打断低优先级中断的执行。如果反过来，一个按键扫描把电机控制给打断了，那电机控制就可能出现抖动，这在工业控制里是致命的。

核心原则：中断优先级配置，要遵循“紧急且重要”优先的原则。不要把所有中断都设成同一个优先级，那样就失去了优先级的意义。

在三星的Exynos系列上，中断控制器（GIC）支持最多256个优先级。配置时，我一般这样写：

// 以S5PV210为例，配置外部中断EINT0为最高优先级
// 假设我们使用中断控制器VIC
void irq_priority_config(void)
{
    // 设置EINT0中断优先级为0（最高）
    VIC0->VIC_PRIORITY[IRQ_EINT0] = 0;
    
    // 设置UART0中断优先级为10
    VIC0->VIC_PRIORITY[IRQ_UART0] = 10;
    
    // 设置定时器中断优先级为5
    VIC0->VIC_PRIORITY[IRQ_TIMER0] = 5;
    
    // 使能中断
    VIC0->VIC_INTENABLE |= (1 << IRQ_EINT0);
    VIC0->VIC_INTENABLE |= (1 << IRQ_UART0);
    VIC0->VIC_INTENABLE |= (1 << IRQ_TIMER0);
}

小技巧：优先级数值越小，优先级越高。这个跟RTOS里的任务优先级是反过来的，别搞混了。我在项目中就见过有人把数值设反了，结果高优先级中断反而被低优先级打断，排查了半天。

2.2 中断嵌套处理——打断的艺术

中断嵌套，就是高优先级中断可以打断低优先级中断的服务程序。这听起来很美好，但处理不好就是灾难。

我曾经在一个电机驱动项目里，把PWM中断和ADC中断都开了嵌套。结果ADC中断处理时间稍长，PWM中断被延迟了，电机直接发出了刺耳的啸叫声。从那以后，我对中断嵌套就格外小心。

中断嵌套的处理，有几个关键点：

  • 中断服务程序（ISR）要短小精悍——ISR里只做最必要的事，比如读取数据、设置标志位。复杂的处理放到任务里去。
  • 合理设置优先级分组——ARM Cortex-M支持优先级分组，可以设置抢占优先级和子优先级。抢占优先级决定能否嵌套，子优先级决定同组内的响应顺序。
  • 注意中断栈溢出——嵌套多了，栈空间消耗大。三星平台的中断栈一般单独配置，我习惯给中断栈留足空间，至少256字节起步。

举个例子，在FreeRTOS + 三星平台上的中断嵌套配置：

// 设置优先级分组，4位抢占优先级，4位子优先级
// 这样最多16级抢占优先级，16级子优先级
NVIC_PriorityGroupConfig(NVIC_PriorityGroup_4);

// 配置定时器中断，抢占优先级0，子优先级0
NVIC_InitStructure.NVIC_IRQChannel = TIMER0_IRQn;
NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;
NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;
NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
NVIC_Init(&NVIC_InitStructure);

// 配置UART中断，抢占优先级1，子优先级0
// 这样UART中断可以被定时器中断打断
NVIC_InitStructure.NVIC_IRQChannel = UART0_IRQn;
NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 1;
NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;
NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
NVIC_Init(&NVIC_InitStructure);

警告：在RTOS环境下，中断嵌套要特别小心。如果ISR里调用了RTOS的API（比如xSemaphoreGiveFromISR），一定要确保这些API是“中断安全”的。否则，一个嵌套中断就可能把RTOS的内核数据搞乱，系统直接崩溃。

2.3 中断延迟分析与降低方法——跟时间赛跑

中断延迟，就是从硬件触发中断到CPU开始执行ISR的第一条指令之间的时间。这个时间越短，系统的实时性越好。

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

延迟来源 说明 典型时间（ARM Cortex-A8 @ 1GHz）
硬件延迟 中断信号从外设传到CPU的时间 几十ns
CPU响应延迟 CPU完成当前指令、保存上下文的时间 几十到几百ns
中断屏蔽时间 CPU关中断的时间 取决于代码，可能几us到几ms
优先级仲裁时间 中断控制器判断哪个中断优先 几十ns

我建议，降低中断延迟可以从这几个方向入手：

  1. 减少关中断的时间——这是最有效的方法。检查代码里有没有大段的关中断区域，比如在临界区里做复杂计算。能用信号量或互斥锁代替关中断的，尽量用。
  2. 使用快速中断（FIQ）——三星平台支持FIQ，它比普通IRQ有更高的优先级，而且有独立的寄存器组，省去了保存上下文的开销。把最关键的中断（比如电机控制、PWM同步）设为FIQ。
  3. 优化中断向量表——把中断向量表放在SRAM里，访问速度比Flash快。三星的S5PV210支持把向量表重定向到SRAM。
  4. 避免在ISR里调用慢速函数——比如printf、延时函数。这些函数会大大增加中断处理时间。

举个例子，把中断向量表重定向到SRAM：

// 在启动代码中，把中断向量表复制到SRAM
// 然后设置VTOR寄存器指向SRAM地址
#define VECTOR_TABLE_SRAM   0x20000000  // SRAM起始地址
#define VECTOR_TABLE_FLASH  0x00000000  // Flash起始地址

void vector_table_relocate(void)
{
    uint32_t i;
    uint32_t *src = (uint32_t *)VECTOR_TABLE_FLASH;
    uint32_t *dst = (uint32_t *)VECTOR_TABLE_SRAM;
    
    // 复制256个中断向量
    for (i = 0; i < 256; i++) {
        dst[i] = src[i];
    }
    
    // 设置VTOR寄存器
    SCB->VTOR = VECTOR_TABLE_SRAM;
    
    // 确保内存屏障
    __DSB();
    __ISB();
}

避坑指南：我曾经在一个项目中，把中断向量表重定向到SRAM后，发现中断响应速度确实快了，但偶尔会出现“幽灵中断”——就是没有触发条件，CPU却进了中断。后来排查发现，是SRAM里的向量表被意外修改了。解决办法是把SRAM的向量表区域设置为只读，或者用MPU保护起来。

2.4 实战经验总结

说了这么多，总结几条我在三星平台上做中断优化的经验：

  • 中断优先级不是越高越好——优先级太高，会频繁打断低优先级任务，导致低优先级任务饿死。我一般把优先级分为3-4级就够了。
  • 中断嵌套要控制深度——我一般限制嵌套不超过3层。超过3层，栈空间和调试难度都会急剧上升。
  • 测量中断延迟——用GPIO翻转法，在ISR入口和出口各翻转一次GPIO，用示波器看脉宽。这是最直观的测量方法。
  • 考虑使用中断线程化——在RTOS里，可以把中断处理分成两部分：上半部（ISR）只做最紧急的事，下半部（任务）做剩余处理。这样既保证了实时性，又减少了关中断时间。

嗯，中断管理优化这块，说到底就是“快”和“稳”的平衡。快，要快到极致；稳，要稳如泰山。希望今天的分享对你有帮助。下一章，我们会聊聊任务调度优化，敬请期待。

← 上一章 📖 返回目录 下一章 →