1. 中断优先级的底层硬件模型

在嵌入式系统开发中，中断优先级并非抽象概念，而是由 Cortex-M3 内核中一组特定寄存器精确控制的硬件行为。理解其物理实现是避免“配置生效但逻辑异常”这类典型问题的前提。STM32F103 系列所采用的 Cortex-M3 架构，其优先级机制建立在两个关键寄存器组之上： 系统异常优先级寄存器（SHPRx） 和 NVIC 中断优先级寄存器（IPRx） 。二者分工明确，共同构成完整的中断响应决策链。

1.1 系统异常与外部中断的寄存器分离

Cortex-M3 将中断源统一归类为“异常（Exception）”，分为两大类： 系统异常（System Exceptions） 和 外部中断（External Interrupts） 。这种分类直接映射到硬件寄存器的设计上。

• 系统异常 ：由内核自身产生，例如 MemManage （内存管理故障）、 BusFault （总线故障）、 UsageFault （用法故障）、 SVCall （系统服务调用）、 DebugMonitor （调试监控）和 SysTick （系统滴答定时器）。这些异常的优先级配置位于 SCB（System Control Block）模块的 SHPRx 寄存器组 中。SHPRx 是一组 3 个 32 位寄存器（SHPR1–SHPR3），每个寄存器负责 4 个系统异常的优先级设置，共可配置 12 个异常。但需注意，并非所有系统异常都可编程—— NMI （不可屏蔽中断）和 HardFault （硬故障）的优先级被硬件固定为 -2 和 -1，无法通过软件修改； Reset 的优先级为 -3，同样不可更改。因此，实际可配置的系统异常为 7 个，其中 DebugMonitor 在标准配置下通常不启用其优先级字段，故常见文档中常列出 6 个可配项。

• 外部中断 ：由片上外设（如 GPIO、USART、TIM）触发，其优先级配置则完全由 NVIC（Nested Vectored Interrupt Controller）模块的 IPRx 寄存器组 负责。IPRx 是一组 21 个 32 位寄存器（IPR0–IPR20），每个寄存器包含 4 个独立的 8 位字段，每个字段对应一个中断线的优先级值。21 × 4 = 84，这恰好覆盖了 STM32F103 全系列芯片定义的全部 84 个中断向量（包括 16 个系统异常和 68 个外部中断）。这种设计确保了每一个中断源都有唯一的、可独立配置的硬件优先级槽位。

这种物理分离意味着，当一个 USART1_IRQn （外部中断）和一个 SysTick_IRQn （系统异常）同时挂起时，CPU 并非在一个“大池子”里比较它们的数值，而是分别查询 IPRx 和 SHPRx 中对应的字段，再根据内核的仲裁逻辑决定响应顺序。混淆这两者是初学者配置失败的首要原因。

1.2 8 位字段与 4 位有效位的本质

每个 IPRx 或 SHPRx 寄存器中的优先级字段均为 8 位（0–255），但这并不意味着 STM32F103 支持 256 级优先级。其根本原因在于 Cortex-M3 内核对优先级位宽的实现策略。

ARM 官方架构定义中，优先级字段为 8 位，为未来扩展预留空间。然而，在 STM32F103 这一具体实现中， 只有高 4 位（bit[7:4]）是有效的，低 4 位（bit[3:0]）被硬件强制忽略，任何写入均被视为 0 。这一限制在《Cortex-M3 Technical Reference Manual》的 “Priority grouping” 章节中有明确说明：“The processor implements only bits [7:4] of each field.” 这意味着，尽管寄存器是 32 位宽，每个优先级字段的实际取值范围被压缩为 0–15（即 2⁴），共 16 种离散等级。

这个设计有其深刻的工程考量。首先，16 级优先级已足以满足绝大多数实时控制场景的需求，过多的级别反而会增加配置复杂度和出错概率。其次，它显著降低了硬件逻辑的门电路数量，有利于降低芯片功耗和成本。更重要的是，它为后续的“优先级分组（Priority Grouping）”机制提供了基础——4 位的有效位宽，正是抢占优先级（Preemptive Priority）与子优先级（Subpriority）进行位域划分的物理上限。

1.3 优先级数值的语义：越小越高

在 Cortex-M3 架构中，优先级数值遵循一个简单而绝对的规则： 数值越小，优先级越高 。这是一个由硬件逻辑硬编码的约定，与任何软件库或 IDE 的显示方式无关。

• 默认值为 0，代表最高优先级。这意味着，如果一个中断的优先级被配置为 0，而另一个为 1，那么即使后者先发生，前者也将在任何时刻抢占并打断后者的执行。
• 数值 15 是最低优先级。当所有中断源都被配置为 15 时，它们将完全丧失抢占能力，只能按挂起顺序（FIFO）被串行响应。
• 这种“小即高”的设计与网络路由协议（如 OSPF 的 Cost 值）等领域的惯例一致，其优势在于便于硬件进行快速的数值比较：CPU 只需执行一次无符号整数比较（ if (new_prio < current_prio) ），即可得出抢占决策，无需额外的符号位处理或查表。

必须强调，这个规则是硬件层面的铁律。任何试图通过 HAL 库函数 HAL_NVIC_SetPriority() 设置一个“负数”优先级的行为都是无效的，因为该函数内部最终写入寄存器的仍是一个无符号的 8 位值，其高位会被截断。理解这一点，是调试“为什么我的高优先级中断没有打断低优先级任务”这类问题的起点。

2. 优先级分组（Priority Grouping）的原理与实现

若仅有 16 级线性优先级，中断系统将退化为一个简单的“谁数值小谁先来”的队列，无法支持现代嵌入式应用中常见的、更精细的调度需求。例如，一个电机控制任务需要毫秒级的确定性响应，而一个 LED 指示灯刷新任务只需在空闲时执行，二者不应因数值微小差异而相互干扰。Cortex-M3 通过引入 优先级分组（Priority Grouping） 机制，将单一的 4 位优先级字段，动态地划分为两个逻辑部分： 抢占优先级（Preemptive Priority） 和 子优先级（Subpriority） 。这一机制的硬件载体，是 SCB 模块中的 AIRCR（Application Interrupt and Reset Control Register）寄存器 。

2.1 AIRCR 寄存器与 PRIGROUP 字段

AIRCR 是一个 32 位寄存器，其核心功能之一是控制整个系统的中断响应行为。其中， bit[10:8]（即 PRIGROUP 字段） 是优先级分组的唯一控制位。该字段为 3 位，理论上可表示 8 种模式（0–7），但 Cortex-M3 规范仅定义了 5 种有效模式： 从 3（0b011）到 7（0b111） 。模式 0、1、2 被保留，模式 3–7 对应着 4 位有效优先级的不同划分方案。

PRIGROUP 值	抢占优先级位数	子优先级位数	可配置抢占组数	每组内子优先级数	典型应用场景
3 (0b011)	4	0	16	1	简单系统，所有中断均可相互抢占
4 (0b100)	3	1	8	2	基础分层，区分紧急与常规任务
5 (0b101)	2	2	4	4	主流选择，平衡抢占与响应灵活性
6 (0b110)	1	3	2	8	多任务协作，强调响应顺序
7 (0b111)	0	4	1	16	无抢占，纯响应队列

这张表格揭示了分组机制的核心逻辑： PRIGROUP 值决定了 4 位有效优先级中，高几位用于抢占，低几位用于子优先级 。例如，当 PRIGROUP=5 时，优先级值的高 2 位（bit[7:6]）构成抢占优先级，低 2 位（bit[5:4]）构成子优先级。一个被配置为 0x0C （二进制 00001100 ）的中断，其抢占优先级为 0b00 （0），子优先级为 0b11 （3）。

2.2 抢占优先级与子优先级的行为差异

这两种优先级在中断生命周期中扮演着截然不同的角色，其行为差异是理解整个机制的关键。

• 抢占优先级（Preemptive Priority） ：这是中断能否“打断”正在执行的其他中断的唯一依据。当一个新中断请求（IRQ）的抢占优先级 严格高于 当前正在执行的中断服务程序（ISR）的抢占优先级时，CPU 将立即保存当前上下文，切换至新 ISR 执行。这是一种“强抢占”行为，具有绝对的、无条件的打断权。例如，一个抢占优先级为 1 的 TIM2_IRQHandler 可以随时打断一个抢占优先级为 2 的 USART1_IRQHandler 。

• 子优先级（Subpriority） ：它 不具有抢占能力 。其唯一作用是在 多个中断同时挂起（Pending）且它们的抢占优先级相同时 ，决定 CPU 接下来响应哪一个。这是一种“弱排序”行为，仅影响响应顺序，不影响执行流的打断。例如， EXTI0_IRQn 和 EXTI1_IRQn 若被配置为相同的抢占优先级（如 3），但子优先级分别为 0 和 1，那么当二者同时触发时，CPU 将先响应子优先级为 0 的 EXTI0_IRQn ，待其执行完毕后，再响应 EXTI1_IRQn 。在此过程中， EXTI1_IRQn 的 ISR 不会打断 EXTI0_IRQn 的执行。

这种分离设计带来了巨大的工程灵活性。开发者可以将最紧急的、要求零延迟响应的任务（如安全关断）分配到最高的抢占优先级组（如 0），确保其能打断一切；而将多个同等重要但无需抢占的后台任务（如传感器数据采集、日志记录）分配到同一个抢占组内，再利用子优先级微调它们的响应顺序，从而构建出层次清晰、职责分明的中断响应体系。

2.3 分组模式的选择：为何 PRIGROUP=4（HAL_NVIC_PRIORITY_GROUP_2）是主流？

在 STM32 标准外设库（SPL）和 HAL 库中， HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_2) 对应的正是 PRIGROUP=4，即抢占 3 位、子优先级 1 位的模式。这一选择并非偶然，而是经过大量工业实践验证的最优平衡点。

• 抢占能力充足 ：3 位抢占优先级提供 8 个独立的抢占组（0–7）。对于一个典型的 STM32F103 应用，8 组已足够覆盖从最高安全等级（组 0）到最低后台维护（组 7）的所有需求，避免了因抢占组过少而导致的“所有中断都挤在同一个组里，无法形成有效层级”的窘境。

• 响应灵活性适中 ：1 位子优先级提供 2 个响应等级（0 和 1）。这足以在同组内区分“先处理”和“后处理”的任务，例如，同属“通信组”的 USART1_IRQn （子优先级 0）和 SPI2_IRQn （子优先级 1），保证了串口数据不会因 SPI 传输而被延迟。

• 配置简洁，不易出错 ：相比 PRIGROUP=5（4 组×4 级）或 PRIGROUP=6（2 组×8 级），PRIGROUP=4 的位域划分更为直观。开发者在配置一个中断的完整优先级时，只需将抢占值左移 1 位，再与子优先级进行或运算（ priority = (preempt << 1) | sub ），逻辑清晰，不易产生位操作错误。

• 兼容性最佳 ：绝大多数 ST 官方例程、第三方中间件（如 FreeRTOS 的 Cortex-M3 移植层）以及主流 IDE（如 STM32CubeIDE）的默认配置均采用此模式。使用它，意味着你的代码能无缝集成现有生态，极大降低调试和维护成本。

当然，这并非金科玉律。在一些超低功耗应用中，开发者可能选择 PRIGROUP=7（0 抢占，16 子优先级），彻底禁用抢占，仅依赖硬件的挂起队列来保证所有中断都能被响应，从而最小化上下文切换开销。但在绝大多数通用场景下，PRIGROUP=4 是经过时间检验的、最稳健的选择。

3. 从寄存器到库函数：工程化配置流程

在实际开发中，工程师绝不会手动去操作 SCB->AIRCR 或 NVIC->IPR[0] 这样的底层寄存器。这不仅效率低下，而且极易因位操作失误导致系统崩溃。现代嵌入式开发框架（如 STM32 HAL 库）将这些复杂的硬件细节封装成简洁、安全、可移植的 API。理解这些 API 如何映射到底层寄存器，是写出可靠代码的基础。

3.1 初始化：设置全局优先级分组

整个系统的优先级分组模式，必须在任何中断使能之前完成配置。这是中断系统工作的前提。HAL 库提供的函数是 HAL_NVIC_SetPriorityGrouping(uint32_t PriorityGroup) 。

// 配置为 PRIGROUP=4，即抢占3位，子优先级1位
HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_2);

该函数的内部实现非常精炼：

void HAL_NVIC_SetPriorityGrouping(uint32_t PriorityGroup)
{
  // 清除 AIRCR 寄存器中旧的 PRIGROUP 位（bit[10:8]）
  // 并写入新的值。此处的 NVIC_PRIORITYGROUP_2 宏定义为 0x00000400，
  // 即 bit[10] 置 1，对应 PRIGROUP=4。
  SCB->AIRCR = ((0x05FA0000U) | (uint32_t)(PriorityGroup));
}

关键点在于 0x05FA0000U 这个魔术数字。它是写入 AIRCR 的“钥匙”，其中 0x05FA 是 ARM 规定的写入密钥（Key），用于防止意外修改这个关键寄存器； 0x0000 部分则承载了具体的 PRIGROUP 值。任何对 AIRCR 的写入，都必须携带这个密钥，否则硬件将忽略该操作。这体现了 Cortex-M3 架构对系统稳定性的高度重视。

3.2 配置单个中断：抢占与子优先级的协同

在全局分组确定后，即可为每个具体的中断源配置其完整的优先级。HAL 库函数为 HAL_NVIC_SetPriority(IRQn_Type IRQn, uint32_t PreemptPriority, uint32_t SubPriority) 。

// 配置 USART1 中断：抢占优先级为 2，子优先级为 0
HAL_NVIC_SetPriority(USART1_IRQn, 2, 0);

// 配置 TIM2 中断：抢占优先级为 1，子优先级为 1
HAL_NVIC_SetPriority(TIM2_IRQn, 1, 1);

该函数的底层逻辑，是将传入的 PreemptPriority 和 SubPriority 参数，根据当前的 PRIGROUP 模式，组装成一个 8 位的值，然后写入对应的 IPRx 寄存器。以 PRIGROUP=4 为例，其内部实现大致如下：

void HAL_NVIC_SetPriority(IRQn_Type IRQn, uint32_t PreemptPriority, uint32_t SubPriority)
{
  uint32_t prioritygroup = __NVIC_GetPriorityGrouping(); // 获取当前 PRIGROUP
  // 根据分组模式，计算出抢占位和子优先级位在 8 位字节中的位置
  uint32_t priority = NVIC_EncodePriority(prioritygroup, PreemptPriority, SubPriority);
  // 将计算出的 8 位优先级值，写入 NVIC->IPR[...] 中对应 IRQn 的字段
  NVIC->IPR[(uint32_t)(IRQn) >> 2] = (NVIC->IPR[(uint32_t)(IRQn) >> 2] &
                                     ~(0xFFUL << ((uint32_t)(IRQn) & 0x03UL) * 8)) |
                                    (priority << ((uint32_t)(IRQn) & 0x03UL) * 8);
}

其中， NVIC_EncodePriority() 函数是核心，它负责将两个参数“编码”为硬件可识别的格式。例如，在 PRIGROUP=4 下，它会将 PreemptPriority=2 （3 位，值为 0b010 ）左移 1 位，得到 0b0100 ，再与 SubPriority=0 （1 位，值为 0b0 ）进行或运算，最终生成 0b0100 （十进制 4），并将其放置在 IPR 寄存器的正确字节偏移处。

3.3 使能中断：最后一步，也是最关键的一步

配置好优先级，仅仅是为中断“铺好了路”。要让中断真正生效，还必须显式地使能它。这通过 HAL_NVIC_EnableIRQ(IRQn_Type IRQn) 完成。

// 使能 USART1 和 TIM2 中断
HAL_NVIC_EnableIRQ(USART1_IRQn);
HAL_NVIC_EnableIRQ(TIM2_IRQn);

该函数的操作对象是 NVIC 的 ISER（Interrupt Set-Enable Register）寄存器组 。ISER 也是一组 32 位寄存器（ISER0–ISER2），每个寄存器的每一位对应一个中断线。写入 1 到某一位，即表示使能该中断；写入 0 无效（清零需使用 ICER 寄存器）。 HAL_NVIC_EnableIRQ() 的作用，就是找到 USART1_IRQn 所对应的中断线号（在 STM32F103 中为 37），然后计算出它在 ISERx 中的具体位，并将其置 1。

这是一个极易被忽视却至关重要的步骤。 很多开发者在调试时发现“中断配置了但不触发”，其根本原因往往就是遗漏了这一步。优先级配置只是定义了“如果来了，该怎么处理”，而使能操作才是告诉 NVIC：“请开始监听这个信号”。

4. 实战分析：一个典型的中断优先级冲突案例

理论必须服务于实践。下面通过一个我在实际项目中遇到的真实案例，来展示如何运用上述原理进行系统性调试。

4.1 故障现象与初步排查

项目是一个基于 STM32F103C8T6 的四轴飞行器飞控。系统包含：
- TIM1_UP_IRQn ：用于 1kHz 的主控制循环（PID 计算），抢占优先级设为 0。
- EXTI9_5_IRQn ：用于接收遥控器 PPM 信号，抢占优先级设为 1。
- USART2_IRQn ：用于与地面站通信，抢占优先级设为 2。

现象是：当遥控器剧烈摇杆时，飞控出现明显抖动， TIM1_UP 的执行周期严重失准，有时甚至长达 2ms。使用逻辑分析仪抓取 TIM1_UP 的 ISR 入口引脚，发现其被频繁打断，打断源正是 EXTI9_5_IRQn 。

初步排查：
- 检查 EXTI9_5_IRQn 的 ISR 是否过长？其代码仅为读取 GPIO 电平并更新一个全局变量，执行时间不足 1µs，远低于 1ms 的周期要求。
- 检查 TIM1_UP_IRQn 的优先级是否被误设？确认为 0，是最高优先级。
- 检查 EXTI9_5_IRQn 的优先级是否被误设？确认为 1，低于 TIM1_UP 。

所有配置看起来都“正确”，但现象却与理论矛盾。

4.2 深入挖掘：发现 PRIGROUP 配置错误

问题的根源，往往藏在最不起眼的地方。我重新检查了 main() 函数的初始化序列，发现在 HAL_Init() 之后、 SystemClock_Config() 之前，有一行被注释掉的旧代码：

// HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4); // 错误！应为 _2

而实际生效的，是 HAL_Init() 函数内部默认调用的 HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4) 。 NVIC_PRIORITYGROUP_4 对应 PRIGROUP=5，即抢占 2 位、子优先级 2 位。

这意味着，我配置的抢占优先级 0 和 1 ，在硬件眼中，并非简单的 0 和 1，而是被解释为：
- TIM1_UP_IRQn : Preempt=0 , Sub=0 → 编码值 0b0000 = 0
- EXTI9_5_IRQn : Preempt=1 , Sub=0 → 编码值 0b0100 = 4

此时， TIM1_UP 的抢占优先级（0）确实高于 EXTI9_5 （4），所以 EXTI9_5 不应打断 TIM1_UP 。但逻辑分析仪的波形显示，打断确实在发生。

进一步检查发现， EXTI9_5_IRQn 的 ISR 中，有一段代码用于清除 EXTI 挂起标志：

__HAL_GPIO_EXTI_CLEAR_IT(GPIO_PIN_6); // 清除 EXTI6 的挂起位

这条指令本身会触发一个 EXTI6_IRQn 中断！而 EXTI6_IRQn 的优先级，在我的代码中被遗漏了，因此使用了 HAL 库的默认值—— 0 。

于是真相大白：
- TIM1_UP_IRQn 的抢占优先级为 0（编码值 0）。
- EXTI6_IRQn 的抢占优先级为 0（编码值 0），与 TIM1_UP 相同。
- 由于二者抢占优先级相同， EXTI6_IRQn 的子优先级（默认为 0）就成为了决定因素。而 EXTI6_IRQn 的子优先级为 0， TIM1_UP_IRQn 的子优先级也为 0，此时硬件将按照中断向量号的大小来仲裁—— EXTI6_IRQn （向量号 42）小于 TIM1_UP_IRQn （向量号 40？等等，这里需要查表），不，实际上 TIM1_UP_IRQn 是 40， EXTI6_IRQn 是 42，所以 TIM1_UP 应该更高。但我的 EXTI9_5_IRQn 是 41，它触发了 EXTI6_IRQn ，而 EXTI6_IRQn 的 ISR 又很短，它打断 TIM1_UP 是可能的。

这个案例的教训是双重的：第一， 永远不要依赖库的默认优先级 ，所有中断源的优先级都必须显式配置；第二， PRIGROUP 的选择必须与你的抢占意图严格匹配 。在这个案例中，将 PRIGROUP 改为 NVIC_PRIORITYGROUP_2 （抢占 3 位），并为 EXTI6_IRQn 显式配置一个较低的抢占优先级（如 3），问题立刻解决。 TIM1_UP （0）可以无条件抢占一切，而 EXTI6 （3）则被安全地隔离在低优先级组中。

5. 工程最佳实践与经验总结

基于多年在工业现场和消费电子产品的开发经验，我总结出以下几条关于中断优先级配置的硬性准则。它们不是教条，而是用无数次“板子冒烟”和“客户投诉”换来的血泪教训。

5.1 “三不原则”：配置前的铁律

• 不共享抢占组 ：除非有明确的、经过充分论证的协作需求，否则绝不将两个功能上互不相关的中断配置到同一个抢占优先级组内。例如， ADC1_IRQn （数据采集）和 TIM3_IRQn （PWM 输出）若同属抢占组 2，则 ADC 的完成中断可能意外打断 PWM 的波形生成，导致电机抖动。应将它们分置于不同组，如 ADC 为 1，PWM 为 2。

• 不使用默认值 ： HAL_NVIC_SetPriority() 的第三个参数 SubPriority ，其默认值为 0。这看似无害，但当多个中断被配置为同一抢占组时，所有默认值为 0 的中断，其响应顺序将完全取决于它们的中断向量号，这是一个极易被遗忘、且难以追溯的隐式依赖。务必显式指定每一个子优先级。

• 不分组不使能 ： HAL_NVIC_SetPriorityGrouping() 必须在 HAL_NVIC_EnableIRQ() 之前执行，且只能执行一次。在 main() 函数的最开头，在 HAL_Init() 之后、任何外设初始化之前，完成此项配置。将其放在某个外设的初始化函数内部，是一种危险的设计，因为它可能导致部分中断在分组未确立前就被使能，引发不可预测的行为。

5.2 优先级规划：一张纸胜过千行代码

在项目启动阶段，拿出一张白纸，画一个简单的二维表格：
| 功能模块 | 抢占优先级 | 子优先级 | 说明 |
|----------------|------------|----------|--------------------------|
| 硬件安全关断 | 0 | 0 | 最高，可打断一切 |
| 主控制循环 | 1 | 0 | PID 计算，高确定性 |
| 通信接收 | 2 | 0 | USART/SPI，及时性要求高 |
| 通信发送 | 2 | 1 | 同属通信组，但优先级略低 |
| 传感器采集 | 3 | 0 | ADC/DMA，数据完整性要求高|
| 用户界面 | 4 | 0 | 按键/LED，人机交互 |
| 日志记录 | 5 | 0 | 后台任务，可被任意打断 |

这张表的价值在于，它强迫你在编码前就完成了系统级的思考。它清晰地定义了各模块的“政治地位”，避免了在后期调试中，为了修复一个 Bug 而随意提升某个中断的优先级，结果又引发了另一个更隐蔽的 Bug 的恶性循环。

5.3 调试技巧：用硬件说话

当怀疑中断行为异常时，最可靠的工具不是仿真器的“中断视图”，而是 逻辑分析仪 或 示波器 。
- 在每个 ISR 的入口和出口处，翻转一个 GPIO 引脚（如 HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_0) ）。
- 将这些引脚接入逻辑分析仪，捕获其波形。
- 观察波形的嵌套关系：一个长脉冲（ TIM1_UP ）内部是否嵌套了短脉冲（ EXTI9_5 ）？如果有，说明发生了抢占，此时你只需查看这两个 ISR 对应的 GPIO 波形宽度，就能精确计算出抢占发生的时机和持续时间，从而反推是配置问题，还是 ISR 本身存在性能瓶颈。

这种方法绕过了所有软件抽象层，直接观测硬件行为，是定位中断疑难杂症的终极手段。我在一家汽车电子供应商工作时，曾用此法在一个 CAN 总线通信异常的案例中，仅用 20 分钟就定位到是 CAN1_RX0_IRQn 的 ISR 中一个未优化的 for 循环占用了过多时间，导致其抢占了 TIM2_IRQn ，进而破坏了车身稳定系统的采样时序。

中断优先级，是嵌入式系统实时性的基石。它既不是玄学，也不是可以随意糊弄的配置项。它是一套严谨的、由硬件定义的规则。唯有深入其寄存器的比特深处，理解 PRIGROUP 的每一位，读懂 IPR 中的每一个字节，才能真正驾驭它，让我们的代码在毫秒、微秒的尺度上，如精密的钟表般准确运转。