中断优先级：当低优先级中断永远得不到响应，硬件开始“无声抗议”

引言：中断——处理器的“紧急通道”

在现代计算机系统和嵌入式设备中，处理器需要同时处理众多外部事件，例如按键输入、网络数据包到达、定时器溢出、传感器数据就绪等。如果处理器采用轮询方式不断检查这些事件的状态，不仅会浪费大量 CPU 时间，还会导致事件响应的实时性无法保证。中断机制的引入，正是为了解决这一问题——它允许外设在需要处理器关注时主动向 CPU 发出信号，从而“打断”当前正在执行的程序，转而去处理紧急事件。

中断的本质是处理器硬件层面上的一种异常处理机制。当中断发生时，处理器会保存当前上下文（通常是将程序计数器、状态寄存器等压栈），然后跳转到预先设定好的中断服务程序（ISR）执行。ISR 完成后，再恢复上下文，继续执行被打断的程序。整个过程由硬件和软件协同完成，使得 CPU 能够对外部事件作出快速响应。

然而，当系统中有多个中断源时，问题就出现了：如果多个中断同时到达，CPU 应该先响应哪一个？如果正在处理一个中断时，另一个中断又来了，是立即打断当前处理，还是等待当前处理完成？这些问题的答案，就是中断优先级。中断优先级决定了中断事件的“紧急程度”，硬件和操作系统根据优先级来仲裁中断的处理顺序。

中断优先级的设计看似简单，却隐藏着深刻的陷阱。如果优先级分配不合理，一些“低优先级”的中断可能永远得不到 CPU 的响应，就像被遗忘在角落里的士兵，永远等不到命令。而硬件并不会默默忍受这种忽视——它会以各种方式“抗议”：数据丢失、外设故障、系统响应迟钝，甚至整个系统崩溃。本文将从中断优先级的基本原理出发，深入剖析低优先级中断被饿死的原因、后果，并通过代码实例演示这一现象，最后给出避免此类问题的设计策略。

第一部分：中断优先级机制详解

1.1 为什么需要中断优先级？

想象一个简单的系统：只有一个按钮和一个定时器。按钮中断负责检测用户按键，定时器中断负责产生精确的时基。如果两个中断同时发生，CPU 必须选择一个先处理。如果先处理按钮中断，可能会延迟定时器的更新，导致时间计算误差；如果先处理定时器中断，则可能让用户感觉到按键反应迟钝。因此，系统必须为每个中断源分配一个优先级，以便在冲突时做出决定。

中断优先级不仅用于解决同时到达的中断的仲裁，还用于决定中断嵌套的行为。当 CPU 正在处理一个较低优先级的中断时，如果来了一个更高优先级的中断，CPU 可以暂停当前中断处理，转而去处理更高优先级的中断，处理完后再继续之前的低优先级中断。这种机制称为中断嵌套，它保证了紧急事件能够得到及时处理，而不必等待无关紧要的中断完成。

1.2 硬件优先级与软件优先级

中断优先级可以大致分为两类：

• 硬件优先级：由处理器或中断控制器硬件决定的固定优先级。例如，早期的 8 位微控制器（如 8051）中，外部中断 0 的优先级高于外部中断 1，定时器 0 中断的优先级高于定时器 1，这些优先级是固定的，用户无法改变。

• 软件（可编程）优先级：现代处理器通常允许用户通过寄存器设置每个中断源的优先级。例如，ARM Cortex-M 系列处理器中的嵌套向量中断控制器（NVIC）支持 8~256 级可编程优先级（取决于具体实现）。用户可以根据任务的重要程度为每个中断分配一个优先级数值。

1.3 不同架构的中断优先级实现

1.3.1 简单微控制器（以 AVR 为例）

AVR 单片机（如 ATmega328P）具有固定的中断优先级。中断向量表的顺序决定了优先级——向量地址越靠前，优先级越高。例如，复位（Reset）优先级最高，然后是外部中断 0（INT0）、外部中断 1（INT1）、定时器 2 比较匹配等。用户无法改变这个顺序，只能通过全局中断使能位和个别中断使能位来控制是否响应中断。这种固定优先级机制简单但缺乏灵活性，在某些应用场景下可能无法满足需求。

1.3.2 ARM Cortex-M 与 NVIC

ARM Cortex-M 处理器（如 Cortex-M0、M3、M4、M7）采用嵌套向量中断控制器（NVIC）来管理中断。NVIC 支持多达 240 个中断源，每个中断源都可以独立设置优先级。优先级数值越小，优先级越高（这是常见约定，但某些处理器可能相反）。

更重要的是，Cortex-M 支持优先级分组，即将优先级寄存器中的位划分为抢占优先级和子优先级（也称为响应优先级）。抢占优先级决定能否打断当前正在执行的中断（即中断嵌套）；子优先级则用于决定当两个具有相同抢占优先级的中断同时到达时，哪个先被响应。通过设置优先级分组，系统设计者可以灵活地控制中断的嵌套行为。

例如，在 STM32 中，可以通过 NVIC_PriorityGroupConfig() 函数设置分组方式。假设采用 4 位优先级（实际 STM32 只使用高 4 位，但具体位数因型号而异），可以配置为：

• 组 0：所有 4 位用于子优先级（无抢占优先级）

• 组 1：1 位抢占优先级，3 位子优先级

• 组 2：2 位抢占优先级，2 位子优先级

• 组 3：3 位抢占优先级，1 位子优先级

• 组 4：所有 4 位用于抢占优先级（无子优先级）

这种分组机制使得系统设计者可以在嵌套深度和同优先级内部排序之间做出权衡。

1.3.3 x86 架构的中断优先级

x86 处理器使用可编程中断控制器（PIC）或高级可编程中断控制器（APIC）来管理硬件中断。传统的 8259A PIC 支持 8 级中断优先级（IRQ0~IRQ7，IRQ0 优先级最高），可以通过级联扩展到 15 级。每个 IRQ 线都有一个固定的优先级顺序，但可以通过编程改变中断向量与 IRQ 的映射关系，从而间接调整优先级。

在保护模式下，x86 使用中断描述符表（IDT）来存储中断门、陷阱门等。中断门中的 DPL（描述符特权级）和中断处理程序本身的特权级会影响中断的响应，但硬件优先级仍然由 PIC/APIC 决定。APIC 引入了更灵活的优先级机制，支持 256 级优先级，并允许每个中断独立设置优先级。

1.3.4 RISC-V 的中断优先级

RISC-V 架构通常使用平台级中断控制器（PLIC）来管理外部中断。PLIC 支持多个优先级（通常最多 7 位，即 0~127 级），每个中断源可以独立设置优先级。PLIC 还支持中断使能、阈值设置等。当多个中断同时到达时，PLIC 会选择优先级最高的中断通知 CPU。如果优先级相同，则根据中断源编号（通常编号小的优先级高）进行仲裁。

此外，RISC-V 还有核心本地中断控制器（CLINT），用于管理定时器和软件中断，其优先级通常是固定的。

1.4 中断嵌套与抢占

中断嵌套是高优先级中断抢占低优先级中断的过程。通常，当 CPU 正在执行某个中断服务程序时，如果来了一个更高优先级的中断，CPU 会保存当前中断的上下文，然后响应更高优先级的中断。这个过程可以重复，形成多级嵌套。嵌套深度受限于堆栈大小和中断控制器设计。

然而，并非所有处理器都支持自动中断嵌套。例如，在 8051 中，当进入一个中断服务程序时，CPU 会自动关闭全局中断（即不再响应其他中断），直到服务程序执行 RETI 指令后才重新开放。这意味着 8051 默认不支持中断嵌套，除非用户在 ISR 中手动开启中断。

在 ARM Cortex-M 中，硬件自动支持中断嵌套。NVIC 会基于当前中断的优先级与待处理中断的优先级进行比较，如果待处理中断优先级更高，则自动抢占。这个过程无需软件干预，大大简化了中断处理。

1.5 中断屏蔽与临界区

为了确保关键代码段的原子性，程序员有时需要暂时关闭中断，以防止中断打断这些代码的执行。这部分代码称为临界区。在关闭中断期间，所有可屏蔽的中断都将被忽略。如果关闭时间过长，可能会导致中断丢失或延迟响应。因此，临界区应尽量短小。

中断屏蔽可以通过全局中断使能位（如 ARM 的 PRIMASK 或 x86 的 cli/sti 指令）实现，也可以通过中断控制器单独屏蔽某个中断源。

第二部分：低优先级中断被饿死的场景分析

2.1 饿死现象的本质

所谓“低优先级中断被饿死”，是指由于高优先级中断频繁发生且占用大量 CPU 时间，导致低优先级中断永远无法得到 CPU 的响应。从 CPU 的角度看，它总是在执行高优先级中断服务程序或主程序，而低优先级中断虽然已经触发（挂起位已置位），但由于其优先级较低，只要还有更高优先级的中断等待处理，CPU 就不会响应它。

这种现象类似于操作系统中进程的“饥饿”问题。在中断系统中，饿死的直接原因是高优先级中断的到达速率过高，以至于在两次高优先级中断之间，CPU 没有足够的时间窗口来响应低优先级中断，或者即使有窗口，也可能被其他中断抢占。

2.2 典型场景

2.2.1 高速数据采集与低速外设共存

考虑一个数据采集系统：一个高速 ADC 以 100 kHz 的速率产生中断，用于读取转换结果；同时，系统还有一个 UART 接口，用于接收用户命令。如果设计者将 ADC 中断设置为最高优先级，而 UART 中断设置为较低优先级，那么当 ADC 连续工作时，UART 中断将几乎没有机会被响应。

假设 ADC 中断服务程序需要执行 200 个 CPU 周期（包括保存上下文、读取数据、清除中断标志、恢复上下文）。如果 CPU 主频为 100 MHz，则每个 ADC 中断耗时 2 μs。ADC 中断间隔为 10 μs（100 kHz），因此 CPU 有 8 μs 的空闲时间可用于执行主程序或处理其他中断。这 8 μs 看似足够，但如果 ADC 中断服务程序的执行时间恰好占用了大部分时间片，或者有多个高优先级中断级联，留给 UART 的时间窗口可能不足以完成 UART 中断的处理。更严重的是，如果 UART 中断在到达时恰好被一个 ADC 中断抢占，而下一个 ADC 中断又很快到来，那么 UART 中断可能永远无法完成。

2.2.2 定时器中断的滥用

许多系统使用一个高频率的定时器中断作为系统的心跳（如 1 kHz 或 10 kHz），用于任务调度、时间计数等。如果这个定时器中断的优先级被设置得过高，并且它的服务程序包含了大量工作（如软件定时器处理、任务切换等），那么其他低优先级中断（如按键输入、传感器数据就绪）将被严重延迟。

例如，在实时操作系统中，通常会将系统 tick 定时器中断设置为较高的优先级，以保证时间精度。但如果 tick 中断处理函数过于冗长，或者系统中还有多个高优先级中断，那么用户交互中断就可能被饿死，导致系统看起来“卡死”，但实际上 CPU 一直在处理 tick 中断。

2.2.3 错误处理与正常工作的矛盾

某些系统为错误检测功能设置了较低的中断优先级，认为错误很少发生，因此不需要及时响应。然而，当系统出现故障时，错误事件可能会频繁发生（例如，通信线路噪声导致的帧错误中断）。此时，如果这些错误中断的优先级低于正常数据流中断，它们可能被忽略，而错误状况会持续恶化，最终导致系统崩溃。这种“饿死”反而掩盖了问题，使得调试困难。

2.3 饿死的数学分析

我们可以用排队论的思想来理解中断饿死。假设高优先级中断的到达间隔服从指数分布，平均到达率为 λ，服务时间（即 ISR 执行时间）为 μ（常数或分布）。如果 λ * μ > 1，即高优先级中断的利用率超过 100%，那么 CPU 将永远无法处理低优先级中断。即使 λ * μ < 1，由于随机波动，也可能出现一段时间内连续高优先级中断导致低优先级中断被延迟的情况。这种延迟如果超过低优先级中断的容忍时间（比如外设的缓冲区溢出时间），就会导致实际上的饿死（因为数据已经丢失）。

从确定性角度看，如果高优先级中断以最小间隔 T_high 周期性发生，并且其 ISR 执行时间为 C_high，那么低优先级中断可用的最大连续时间窗口为 T_high - C_high。如果低优先级中断的 ISR 执行时间 C_low 大于这个窗口，那么低优先级中断永远无法完成。即使 C_low 小于该窗口，如果低优先级中断恰好发生在高优先级中断刚刚开始的时候，它也会被推迟到下一个高优先级中断完成后才能开始，但如果多个高优先级中断连续抢占，仍然可能导致饿死。

第三部分：硬件“无声抗议”——饿死的后果

当低优先级中断被饿死时，硬件并不会沉默。外设期待 CPU 及时响应其中断请求，以完成数据传输或状态更新。如果 CPU 一直无视，外设会采取一系列“抗议”措施，这些措施可能表现为系统故障或性能下降。

3.1 数据丢失与缓冲区溢出

最常见的情况是数据丢失。以 UART 为例，接收端通常有一个硬件 FIFO，当接收到一定数量的字节或达到超时条件时，会触发接收中断。如果 CPU 不能及时响应中断来读取 FIFO 中的数据，FIFO 可能会溢出，后续的字节被丢弃。这将导致通信错误，应用程序可能收到不完整的数据包。

类似地，ADC 转换结果如果没有及时读取，可能会被新的转换结果覆盖；DMA 传输完成中断如果被延迟，可能导致 DMA 描述符未能及时更新，造成数据错乱。

3.2 外设状态异常与错误中断

有些外设具有超时或错误检测机制。例如，一个带有硬件流控制的 UART 如果发现数据溢出，可能会设置溢出错误标志，甚至触发错误中断。如果错误中断本身优先级较低，也可能被饿死，导致错误状态无法清除，外设进入故障模式。

在电机控制系统中，如果霍尔传感器中断（用于检测转子位置）被饿死，控制器可能无法及时换相，导致电机失步、电流过大，甚至烧毁驱动器。硬件可能会检测到过流并触发保护，但这种保护往往是在损害已经发生之后的补救。

3.3 系统响应迟钝与假死

用户可见的后果是系统响应迟钝。例如，按下按钮后，LED 没有立即点亮，而是过了几秒才反应；触摸屏滑动卡顿；网络 ping 延迟剧增。这些现象虽然不至于让系统崩溃，但严重影响用户体验。在某些实时控制系统中，响应迟钝可能导致控制失效，造成安全事故。

3.4 看门狗复位

为了防止系统死锁，许多嵌入式系统会启用看门狗定时器。如果 CPU 由于持续处理高优先级中断而无法喂狗（即主程序得不到执行），看门狗将超时并复位系统。这种复位可能是间歇性的，让人难以捉摸。调试时，如果仅仅关注高优先级中断，可能会忽略低优先级中断饿死导致主程序被饿死的根本原因。

3.5 硬件状态机紊乱

某些外设具有状态机，需要 CPU 在中断服务程序中更新状态。例如，一个 SD 卡控制器在完成命令后会产生中断，CPU 需要根据响应更新内部状态。如果这个中断被饿死，状态机可能停留在中间状态，导致后续命令失败。更糟糕的是，如果外设在等待 CPU 响应期间继续接收新的命令，可能会引发协议错误。

3.6 实际案例：医疗设备中的饿死事件

某款输液泵设备中，设计者将电机控制中断设置为最高优先级（以确保平稳运转），而将按键中断和警报中断设置为较低优先级。在正常工作时，一切正常。但当输液泵以高速运转时，电机控制中断频繁触发，按键中断几乎得不到响应，导致护士无法通过按键停止输液。更危险的是，当输液管堵塞导致压力传感器触发警报中断时，由于优先级较低，警报声迟迟不能响起，直到压力过大导致管路破裂。这个案例凸显了饿死的严重后果。

第四部分：代码示例与模拟

为了更直观地展示低优先级中断被饿死的现象，我们以 STM32F4 系列微控制器为例，编写一段演示代码。我们将使用两个中断源：

• 定时器 2 中断：设置为高优先级，以 1 kHz 的频率触发（即每 1 ms 一次）。在 ISR 中，我们模拟一个耗时较长的处理（例如通过循环延时占用一定时间）。

• 外部中断（如按键）：设置为低优先级，由用户按键触发。在 ISR 中，我们简单地翻转一个 LED，表示中断已响应。

通过观察 LED 是否随按键变化，即可判断外部中断是否得到了及时响应。如果按键后 LED 不亮，说明外部中断被饿死。

4.1 硬件环境假设

• 微控制器：STM32F407VG（Cortex-M4）

• 开发板：有板载 LED（例如 PD12）和按键（例如 PA0，连接到外部中断线 0）

• 定时器：TIM2，时钟 84 MHz（假设 APB1 为 42 MHz，TIM2 倍频后为 84 MHz）

4.2 代码结构

我们将编写以下函数：

• SystemClock_Config()：配置系统时钟。

• GPIO_Init()：初始化 LED 和按键 GPIO。

• TIM2_Init()：初始化定时器，设置 1 ms 中断。

• EXTI_Init()：初始化外部中断线 0。

• NVIC_Init()：设置中断优先级分组，并为 TIM2 和 EXTI0 分配优先级。

• 中断服务程序：TIM2_IRQHandler 和 EXTI0_IRQHandler。

4.3 关键代码

4.3.1 优先级设置

使用 STM32 的标准库或 HAL 库。这里以标准外设库为例：

c

// 设置优先级分组为组2：2位抢占优先级，2位子优先级
NVIC_PriorityGroupConfig(NVIC_PriorityGroup_2);

// 设置 TIM2 中断优先级：抢占优先级为 0（最高），子优先级为 0
NVIC_InitTypeDef NVIC_InitStructure;
NVIC_InitStructure.NVIC_IRQChannel = TIM2_IRQn;
NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;
NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;
NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
NVIC_Init(&NVIC_InitStructure);

// 设置 EXTI0 中断优先级：抢占优先级为 3（最低），子优先级为 0
NVIC_InitStructure.NVIC_IRQChannel = EXTI0_IRQn;
NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 3;
NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;
NVIC_Init(&NVIC_InitStructure);

注意：抢占优先级数值越小，优先级越高。这里 TIM2 抢占优先级为 0，EXTI0 为 3，因此 TIM2 可以抢占 EXTI0。

4.3.2 定时器初始化

c

void TIM2_Init(void) {
    RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM2, ENABLE);
    
    TIM_TimeBaseInitTypeDef TIM_TimeBaseStructure;
    TIM_TimeBaseStructure.TIM_Prescaler = 84 - 1;  // 84 MHz / 84 = 1 MHz
    TIM_TimeBaseStructure.TIM_CounterMode = TIM_CounterMode_Up;
    TIM_TimeBaseStructure.TIM_Period = 1000 - 1;   // 1 MHz / 1000 = 1 kHz
    TIM_TimeBaseStructure.TIM_ClockDivision = 0;
    TIM_TimeBaseStructure.TIM_RepetitionCounter = 0;
    TIM_TimeBaseInit(TIM2, &TIM_TimeBaseStructure);
    
    TIM_ITConfig(TIM2, TIM_IT_Update, ENABLE);
    TIM_Cmd(TIM2, ENABLE);
}

4.3.3 外部中断初始化

c

void EXTI_Init(void) {
    RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOA, ENABLE);
    RCC_APB2PeriphClockCmd(RCC_APB2Periph_SYSCFG, ENABLE);
    
    // 配置 PA0 为输入
    GPIO_InitTypeDef GPIO_InitStructure;
    GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN;
    GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_DOWN;
    GPIO_Init(GPIOA, &GPIO_InitStructure);
    
    // 连接 EXTI0 到 PA0
    SYSCFG_EXTILineConfig(EXTI_PortSourceGPIOA, EXTI_PinSource0);
    
    // 配置 EXTI 线0
    EXTI_InitTypeDef EXTI_InitStructure;
    EXTI_InitStructure.EXTI_Line = EXTI_Line0;
    EXTI_InitStructure.EXTI_Mode = EXTI_Mode_Interrupt;
    EXTI_InitStructure.EXTI_Trigger = EXTI_Trigger_Rising;
    EXTI_InitStructure.EXTI_LineCmd = ENABLE;
    EXTI_Init(&EXTI_InitStructure);
}

4.3.4 LED 初始化

c

void LED_Init(void) {
    RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOD, ENABLE);
    GPIO_InitTypeDef GPIO_InitStructure;
    GPIO_InitStructure.GPIO_Pin = GPIO_Pin_12;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;
    GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
    GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_100MHz;
    GPIO_Init(GPIOD, &GPIO_InitStructure);
}

4.3.5 中断服务程序

c

// TIM2 中断服务程序
void TIM2_IRQHandler(void) {
    if (TIM_GetITStatus(TIM2, TIM_IT_Update) != RESET) {
        TIM_ClearITPendingBit(TIM2, TIM_IT_Update);
        
        // 模拟耗时操作：延时 500 μs（假设 CPU 频率足够，这里用简单循环）
        volatile uint32_t delay;
        for (delay = 0; delay < 20000; delay++); // 粗略延时，具体值需根据实测调整
        
        // 可以在这里翻转另一个 LED 以观察频率，但为了简单，不添加额外操作
    }
}

// EXTI0 中断服务程序
void EXTI0_IRQHandler(void) {
    if (EXTI_GetITStatus(EXTI_Line0) != RESET) {
        // 翻转 LED，表示响应了按键中断
        GPIO_ToggleBits(GPIOD, GPIO_Pin_12);
        EXTI_ClearITPendingBit(EXTI_Line0);
    }
}

4.3.6 主函数

c

int main(void) {
    SystemClock_Config();   // 配置系统时钟 168 MHz（假设）
    LED_Init();
    TIM2_Init();
    EXTI_Init();
    
    // 设置优先级（已在各自初始化中设置，但需要分组）
    NVIC_PriorityGroupConfig(NVIC_PriorityGroup_2);
    
    // 设置 TIM2 优先级
    NVIC_SetPriority(TIM2_IRQn, 0);      // 抢占 0，子 0
    NVIC_EnableIRQ(TIM2_IRQn);
    
    // 设置 EXTI0 优先级
    NVIC_SetPriority(EXTI0_IRQn, 3 << 2); // 抢占 3，子 0（注意：在组2中，优先级寄存器的高2位是抢占，低2位是子。所以数值 = 抢占<<2 | 子）
    NVIC_EnableIRQ(EXTI0_IRQn);
    
    while (1) {
        // 主循环可以做一些低优先级工作，例如通过 LED 闪烁指示运行
        // 但为了观察中断饿死，主循环可以什么都不做
    }
}

4.4 实验观察

编译并下载程序到开发板。连接示波器或逻辑分析仪观察 PD12（LED）引脚。正常情况下，按下按键时，LED 应该翻转状态。然而，由于 TIM2 中断每 1 ms 触发一次，并且其 ISR 中有大约 500 μs 的延时（实际延时取决于循环计数值和 CPU 速度），CPU 大部分时间都在执行 TIM2 中断。因此，按键中断很难得到响应。如果按键中断发生在 TIM2 中断执行期间，它会被挂起；但由于 TIM2 中断频繁发生，且每次执行时间较长，导致下一个 TIM2 中断在 EXTI0 中断被响应之前就已经到来（因为 EXTI0 优先级低，即使被挂起，也要等待所有高优先级中断处理完毕才能执行）。这样，EXTI0 可能永远得不到执行。

我们可以通过调整 TIM2 ISR 中的延时长度来观察临界点。如果延时小于 1 ms - 中断响应开销，那么理论上在两次 TIM2 中断之间有一段空闲时间，EXTI0 有可能被执行。但为了确保饿死，我们可以让延时接近或超过 1 ms，使得 CPU 几乎 100% 忙于处理 TIM2 中断，此时按下按键，LED 可能根本不变化。

4.5 代码改进：增加计数显示

为了更清晰地展示饿死现象，可以在主循环中增加一个变量，记录按键被按下的次数（通过轮询按键状态），并在 TIM2 中断中定期输出（例如通过串口）。如果按键中断被饿死，但主循环仍然可以检测到按键（通过轮询），我们可以对比中断响应次数和实际按键次数。这显示了虽然硬件事件发生了，但其中断服务并未执行。

由于篇幅限制，此处不展开完整代码，但上述简单示例已足以说明问题。

第五部分：避免饿死的策略

5.1 合理分配优先级

优先级分配应基于中断事件的实时性要求和后果的严重性，而非单纯依据发生频率。例如，一个频率高但实时性要求不严格的中断（如用于统计的定时器）可以分配较低优先级；而一个频率低但一旦发生就必须立即处理的中断（如电源故障警告）应分配最高优先级。

常见原则包括：

• 关键性：对系统安全至关重要的中断（如看门狗、电源监测）应赋予最高优先级。

• 实时性：具有硬实时要求的中断（如电机控制 PWM 周期中断）应赋予较高优先级。

• 数据易失性：数据容易丢失的中断（如无 FIFO 的 UART 接收）应比有硬件缓冲的中断优先级高。

• 执行时间：中断服务程序较长的中断，如果优先级太高，会阻塞其他中断，因此可以考虑将其拆分为上半部和下半部，或将优先级适当降低，让短中断先执行。

5.2 使用优先级分组调整嵌套行为

通过设置不同的优先级分组，可以控制抢占的粒度。例如，如果系统中有多个频率高但允许一定延迟的中断，可以将它们放在同一个抢占优先级下，使用子优先级决定响应顺序，这样它们之间不会互相抢占，避免了频繁嵌套带来的开销和饿死风险。

在某些处理器中，可以设置中断阈值寄存器，屏蔽低于某优先级的中断，从而保护关键代码不被干扰。

5.3 缩短中断服务程序

中断服务程序应尽可能短小，只执行最必要的操作，如读取/写入硬件寄存器、清除中断标志、将数据交给后台处理（通过信号量、消息队列等）。耗时的处理应放在任务级（主循环或 RTOS 任务）中执行。这样，即使高优先级中断频繁发生，每个中断占用的时间很少，也能为低优先级中断留出执行窗口。

例如，将 ADC 中断中的数字滤波算法移到主循环中，中断只负责读取数据并设置标志。

5.4 采用中断与轮询结合

对于某些低频率、低实时性要求的事件，可以采用轮询方式代替中断。例如，按键检测可以通过主循环定期扫描，而不必使用中断。这样可以减少中断源的数量，简化优先级管理。但轮询会消耗 CPU 时间，且响应延迟可能较大。

5.5 使用 DMA 减轻中断负担

DMA 控制器可以在没有 CPU 干预的情况下完成数据传输，仅在传输完成时产生一次中断。这大大减少了中断频率，降低了高优先级中断对 CPU 的占用率。例如，使用 DMA 进行 ADC 连续采样，仅在缓冲区满时中断，而不是每次转换都中断。

5.6 动态优先级调整

某些系统支持动态改变中断优先级。例如，当检测到低优先级中断长期得不到响应时，可以临时提高其优先级，使其有机会执行。但这需要软件介入，且可能违反实时性假设，需谨慎使用。

5.7 使用 RTOS 的中断管理机制

实时操作系统通常提供统一的中断管理机制，如中断服务程序可以触发一个高优先级的任务，将中断处理推迟到任务上下文中。在任务中，可以设置优先级天花板协议，防止优先级反转。利用 RTOS 的同步机制（信号量、事件标志组）可以有效地将中断处理与任务调度结合，减少饿死的风险。

5.8 分析与测试

在设计阶段，应分析最坏情况下的中断响应时间，确保每个中断在最坏情况下都能在规定时间内得到响应。可以通过公式计算或使用仿真工具。测试时，应模拟最极端的中断负载，观察低优先级中断是否仍然能够正常工作。

第六部分：实际案例分析

6.1 工业机器人控制器

在一款多轴工业机器人控制器中，每个伺服电机都需要一个高频率的中断（如 10 kHz）来更新控制环。同时，系统还需要处理安全光幕中断（用于检测人员闯入）、通信中断（与上位机交换数据）、以及温度监测中断。设计初期，工程师将所有伺服电机中断设置为最高优先级，安全光幕中断次之，通信和温度中断最低。

在测试中，当机器人高速运行时，安全光幕中断偶尔被延迟几个毫秒，但仍在安全规范允许范围内（20 ms）。然而，在极端工况下，所有伺服电机同时达到最大加速度，伺服中断频率激增，导致安全光幕中断延迟超过 20 ms，触发了安全系统的故障保护，机器人紧急停止。分析发现，伺服中断处理时间过长，且由于优先级过高，安全光幕中断被饿死。解决方案是优化伺服中断处理，将部分计算移到任务级，并适当降低伺服中断的优先级（但仍高于安全光幕），同时提高安全光幕中断的优先级。经过调整，系统在最坏情况下的响应时间满足要求。

6.2 智能家居网关

某智能家居网关使用 ZigBee 模块接收传感器数据，ZigBee 模块通过 UART 与主控芯片连接。UART 接收中断优先级较低，而一个高频率的定时器中断用于网络协议栈的定时任务。当网络流量大时，定时器中断频繁触发，导致 UART 接收中断被延迟，UART 硬件 FIFO 溢出，丢包严重。用户发现传感器数据频繁丢失。

解决方案：将 UART 接收中断优先级提高，使其高于定时器中断。同时，将定时器中断的处理时间缩短，只进行必要的计时，协议栈处理放在主循环中。另外，增加 UART 的 FIFO 深度或使用 DMA 接收，减少中断频率。最终，数据丢失问题得到解决。

第七部分：结论

中断优先级是一把双刃剑。合理的优先级分配能够确保系统实时响应紧急事件，同时平衡各中断源的资源需求。然而，如果设计者忽视低优先级中断的响应需求，将高优先级中断的优先级设置得过高、频率过快或处理时间过长，就可能导致低优先级中断被饿死。硬件不会默默忍受这种忽视，而是通过数据丢失、状态异常、系统响应迟钝甚至复位等方式“抗议”，最终导致系统不可靠甚至失效。

本文通过理论分析、代码示例和实际案例，揭示了低优先级中断饿死的原理、后果及解决方案。要避免这一问题，工程师需要在设计阶段综合考虑中断的频率、实时性要求、处理时间以及系统整体架构，合理设置优先级，优化中断服务程序，利用 DMA 等硬件特性，并在必要时借助 RTOS 的机制。更重要的是，必须通过详尽的测试验证系统在最坏情况下的行为，确保所有中断都能在规定时间内得到响应。

中断系统的设计如同搭建一座桥梁，每一根梁柱（中断源）都需要恰到好处的支撑（优先级）。只有精心设计，才能让这座桥梁承受各种负载的考验，保障系统的稳定与安全。当硬件不再“抗议”，系统才能平稳运行。