1. 中断系统本质：从硬件行为到软件抽象

中断不是编程技巧，而是嵌入式系统最基础的硬件协作机制。它定义了CPU如何在确定性执行与不确定性事件之间建立可靠桥梁。理解中断，必须回归其物理本质：一个由硬件信号触发、由内核电路响应、由软件逻辑处理的完整闭环。

在STM32F103这类基于Cortex-M3内核的处理器中，中断行为完全由硬件逻辑固化。当GPIO引脚电平变化、定时器计数溢出或串口接收缓冲区非空时，对应外设会向NVIC（Nested Vectored Interrupt Controller）发出一个有效电平信号。这个信号不经过任何软件判断，是纯粹的硬件事件。NVIC作为Cortex-M3内核内置的中断管理单元，接收到该信号后，立即启动一套预定义的硬件流程：暂停当前PC指针所指向的指令执行，将关键寄存器（R0-R3, R12, LR, PC, xPSR）压入当前堆栈，然后从向量表中读取对应中断号的入口地址，跳转至中断服务函数（ISR）执行。整个过程由硬件在数个时钟周期内完成，软件无法干预其原子性。

这种硬件强制介入的特性，决定了中断处理函数必须遵循严格的工程约束。它不能调用可能引发阻塞的函数（如 HAL_Delay ），不能进行复杂的浮点运算（除非明确配置浮点上下文保存），更不能执行耗时过长的操作。因为当中断发生时，主程序的执行状态被“冻结”在某个精确的指令边界上，而中断服务函数的执行时间直接决定了主程序被延迟的长度。一个设计不良的中断处理函数，轻则导致系统实时性恶化，重则引发堆栈溢出或看门狗复位。

因此，工程师视角下的中断，首先是一个 时间敏感的硬件事件响应通道 ，其次才是一个可编程的软件接口。所有关于优先级、分组、使能/失能的配置，其根本目的都是为了在多个硬件事件并发时，为CPU提供一套可预测、可配置的调度规则，确保关键任务得到及时响应，而非一种可有可无的“功能开关”。

2. Cortex-M3中断架构：256个向量的精密调度系统

Cortex-M3内核定义了一个标准化的异常与中断模型，其核心是256个固定编号的向量入口。这并非一个随意的数字，而是由内核硬件逻辑直接映射的地址空间。向量表起始地址由 VTOR （Vector Table Offset Register）寄存器指定，上电复位后默认指向Flash起始地址0x08000000。每个向量占用4字节，存储一个32位的函数指针，指向该异常或中断的服务例程。

这256个向量被严格划分为两大类：

• 系统异常（System Exceptions，编号1-15） ：由内核自身产生，具有固定名称和不可更改的优先级。其中前三个异常——Reset（编号1）、NMI（编号2）和HardFault（编号3）——拥有最高且固定的优先级，分别为-3、-2、-1。这种负数优先级是内核内部表示法，意味着它们永远高于所有可编程中断。Reset异常在芯片上电或复位时触发，是整个软件系统的起点；NMI（不可屏蔽中断）通常用于监控关键硬件故障（如电源掉压、温度超限），其“不可屏蔽”特性保证了即使在全局中断被禁用（ __disable_irq() ）状态下，该中断仍能被响应；HardFault则是内核检测到严重错误（如非法内存访问、未定义指令）时的最后防线。

• 外部中断（External Interrupts，编号16-255） ：由片内外设（如GPIO、USART、TIM）产生，其名称和功能由芯片厂商定义。STM32F103系列仅使用了其中一部分，共70个中断线，但其底层机制与M3规范完全一致。

中断的调度权完全掌握在NVIC手中。NVIC不仅负责接收中断请求（IRQ）、管理中断使能状态，其最核心的功能是实现 嵌套中断（Nesting） 和 优先级抢占（Preemption） 。这依赖于一个关键概念： 中断优先级分组（Priority Grouping） 。

Cortex-M3为每个可编程中断分配一个8位的优先级寄存器（ IP[255:0] ），但这个8位值并非直接代表一个单一优先级数值。它被NVIC根据 AIRCR （Application Interrupt and Reset Control Register）中的 PRIGROUP 字段动态拆分为两部分：高 n 位为 抢占优先级（Preemption Priority） ，低 (8-n) 位为 子优先级（Subpriority） 。 PRIGROUP 的值由 AIRCR[10:8] 三位决定，其取值范围为0-7，对应8种分组模式。

例如，当 PRIGROUP = 5 时，抢占优先级占5位（0-31），子优先级占3位（0-7）。这意味着系统最多可配置32个不同级别的“打断权”，以及在同级打断权下，再细分8个响应顺序。这种双层优先级设计是M3架构的精髓：抢占优先级决定“能否打断”，子优先级决定“谁先响应”。一个抢占优先级为0的中断，可以无条件打断任何抢占优先级大于0的中断服务函数；而两个抢占优先级相同的中断，若同时到来，则子优先级数值更小者（即数值更高）获得优先执行权。

3. STM32F103的中断裁剪与工程适配

ST公司在设计STM32F103时，并未全盘照搬Cortex-M3的256向量规范，而是进行了务实的裁剪与重构，使其更贴合通用MCU的应用场景。这种裁剪主要体现在中断编号体系和优先级分组能力上。

3.1 中断编号的重新映射

在标准Cortex-M3手册中，Reset异常编号为1。然而，在STM32F103的参考手册（RM0008）中，其向量表的布局发生了关键变化。Reset和NMI这两个最高优先级的系统异常，因其在启动阶段的特殊地位， 并未被赋予一个常规的、可用于 NVIC_SetPriority 函数配置的中断编号 。真正的、可供用户配置的中断编号，是从 HardFault 异常开始的。具体而言：
- HardFault 对应中断号 #3
- MemManage 对应 #4
- BusFault 对应 #5
- UsageFault 对应 #6
- SVCall 对应 #11
- PendSV 对应 #14
- SysTick 对应 #15

此后，所有外部中断才依次编号： EXTI0 为 #6 , EXTI1 为 #7 , …, EXTI15_10 为 #40 , ADC1_2 为 #41 , USB_HP_CAN_TX 为 #43 , 直至 TIM8_TRG_COM 为 #65 。这一编号体系是STM32固件库和HAL库一切中断操作的基础。任何试图对 Reset 或 NMI 调用 HAL_NVIC_SetPriority 的行为，都会因传入非法的中断号而导致未定义行为。

3.2 优先级分组的精简实现

STM32F103的NVIC硬件只实现了 PRIGROUP 的低3位（ AIRCR[10:8] ），这意味着其支持的分组模式仅有8种（0-7），但实际常用且被HAL库默认采用的是 GROUP_2 （即 PRIGROUP=2 ）和 GROUP_3 （即 PRIGROUP=3 ）。在 GROUP_3 模式下，抢占优先级占4位（0-15），子优先级占4位（0-15）。这是HAL库函数 HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_3) 所配置的状态。

这种精简并非能力削弱，而是工程权衡。对于一个运行FreeRTOS或裸机调度器的F103系统，16级抢占优先级已足以清晰划分任务等级：例如，将SysTick（系统滴答）设为最高抢占优先级0，确保调度器心跳绝对准时；将高速通信（如USB、CAN）设为1-3级，保障数据吞吐；将按键、LED等低速人机交互设为10-15级，避免其长时间占用CPU而影响系统响应。子优先级则用于微调同属一类的中断，例如，将 EXTI0 （常用于紧急停止按钮）设为子优先级0， EXTI1 （普通功能键）设为子优先级1，确保在二者同时触发时，安全相关的中断总能优先得到处理。

3.3 启动代码与向量表的绑定

中断的最终落地，依赖于启动代码（startup_stm32f103xb.s）中定义的向量表。该文件以汇编语言编写，其核心是一段名为 Vectors 的只读数据区：

    .section  .isr_vector,"a",%progbits
    .align  2
    .word   _estack
    .word   Reset_Handler
    .word   NMI_Handler
    .word   HardFault_Handler
    .word   MemManage_Handler
    ...
    .word   EXTI0_IRQHandler
    .word   EXTI1_IRQHandler
    .word   EXTI2_IRQHandler
    ...

这段代码将 Reset_Handler 、 NMI_Handler 等符号，按顺序填入向量表的对应位置。当 EXTI0 中断触发时，CPU硬件会自动从向量表的第7个位置（索引6）读取函数指针，并跳转执行。如果该位置存放的是 Default_Handler （一个弱定义的空函数），则系统将进入一个无限循环；如果存放的是用户定义的 EXTI0_IRQHandler ，则执行用户逻辑。

HAL库通过在 stm32f103xb_it.c 文件中提供一系列 __weak 声明的弱函数（如 void EXTI0_IRQHandler(void) ），实现了向量表与用户代码的解耦。开发者只需在自己的C文件中重新定义该函数，链接器便会自动将其地址覆盖向量表中的弱定义，从而完成中断服务函数的“注册”。这是一种简洁而高效的C语言机制，避免了繁琐的汇编跳转。

4. HAL库中断处理模型：三层抽象与职责分离

HAL库并非对底层中断机制的简单封装，而是一套经过深思熟虑的、职责分明的三层抽象模型。它将中断处理的复杂性分解为三个独立的层次，每一层各司其职，共同构成一个健壮、可维护的中断处理框架。

4.1 第一层：向量表入口（IRQ Handler）

这是中断流程的最前端，由启动代码和 stm32f103xb_it.c 共同定义。它的唯一且不可替代的职责是： 快速响应硬件中断，清除外设中断标志，并调用第二层的HAL处理函数 。此层代码必须极度精简，其执行时间应控制在微秒级别。

以 EXTI0_IRQHandler 为例，其标准实现如下：

void EXTI0_IRQHandler(void)
{
  /* 清除EXTI Line0上的中断挂起位 (Pending Bit) */
  HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_0);
}

这里的关键在于 HAL_GPIO_EXTI_IRQHandler 函数。它并非直接处理业务逻辑，而是作为一个“分发器”，其内部会：
1. 检查 EXTI->PR （Pending Register）寄存器，确认确实是 LINE0 产生了中断。
2. 自动写1到 EXTI->PR 的对应位，清除该中断挂起标志。这是防止中断被重复触发的必要步骤。
3. 调用第三层的回调函数 HAL_GPIO_EXTI_Callback 。

此层绝不应包含任何与业务相关的代码（如点亮LED、发送串口数据），因为这些操作可能耗时较长，会阻塞其他更高优先级的中断。

4.2 第二层：HAL中断服务函数（HAL_xxx_IRQHandler）

这是HAL库提供的标准化中间层，位于 stm32f103xb_hal_gpio.c 等外设驱动文件中。它的核心价值在于 统一化、标准化外设中断的底层操作 。对于GPIO外部中断， HAL_GPIO_EXTI_IRQHandler 的源码揭示了其工作原理：

void HAL_GPIO_EXTI_IRQHandler(uint16_t GPIO_Pin)
{
  /* 检查是否为指定引脚的中断挂起 */
  if(__HAL_GPIO_EXTI_GET_IT(GPIO_Pin) != RESET)
  {
    /* 清除该引脚的中断挂起位 */
    __HAL_GPIO_EXTI_CLEAR_IT(GPIO_Pin);
    /* 调用用户回调函数 */
    HAL_GPIO_EXTI_Callback(GPIO_Pin);
  }
}

__HAL_GPIO_EXTI_GET_IT 和 __HAL_GPIO_EXTI_CLEAR_IT 是底层宏，它们直接操作 EXTI->PR 寄存器。这种设计将寄存器操作的细节完全封装，开发者无需记忆 EXTI_PR 的地址或位域定义，只需传递一个 GPIO_Pin 参数即可。更重要的是，它强制执行了“先检查、再清除”的安全范式，避免了因误清除其他引脚中断标志而导致的逻辑错误。

4.3 第三层：用户回调函数（Callback）

这是开发者真正编写业务逻辑的地方，位于用户自己的 main.c 或独立的 app_gpio.c 中。它通过重定义 HAL_GPIO_EXTI_Callback 来实现：

void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)
{
  if(GPIO_Pin == GPIO_PIN_0)
  {
    /* 这里是你的业务代码：例如，记录按键按下时间戳 */
    last_key_press_time = HAL_GetTick();
    /* 或者，设置一个标志位，供主循环处理 */
    key_pressed_flag = 1;
  }
}

回调函数的设计哲学是 异步与解耦 。它不应执行任何阻塞操作（如 HAL_Delay ），也不应进行复杂的计算。最佳实践是：在此处仅做最轻量级的操作——更新一个全局变量、设置一个事件标志、或向FreeRTOS队列/信号量发送一个通知。所有耗时的业务处理，都应在主循环（ while(1) ）或一个专门的任务中完成。这种分离确保了中断服务函数的“短小精悍”，将实时性压力从ISR转移到了主程序流中，是构建稳定嵌入式系统的关键。

5. 中断优先级配置实战：从理论到代码

在STM32F103项目中，中断优先级的配置绝非一蹴而就，而是一个需要通盘考虑、分步实施的系统工程。其核心目标是： 在满足系统实时性要求的前提下，最小化中断嵌套深度，最大化主程序的执行时间片 。

5.1 优先级分组的全局设定

HAL_NVIC_SetPriorityGrouping() 是整个中断系统的“宪法”，必须在 main() 函数的最开始、任何外设初始化之前调用。一旦设定，其效果将持续至下次系统复位。HAL库提供了5种预定义的分组模式：
- NVIC_PRIORITYGROUP_0 : 0位抢占，4位子优先级（仅16级子优先级）
- NVIC_PRIORITYGROUP_1 : 1位抢占，3位子优先级（2级抢占 × 8级子）
- NVIC_PRIORITYGROUP_2 : 2位抢占，2位子优先级（4级抢占 × 4级子）
- NVIC_PRIORITYGROUP_3 : 3位抢占，1位子优先级（8级抢占 × 2级子）
- NVIC_PRIORITYGROUP_4 : 4位抢占，0位子优先级（16级抢占）

对于绝大多数F103应用， NVIC_PRIORITYGROUP_2 （即 HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_2) ）是最佳选择。它提供了4个清晰的抢占等级，足以区分系统滴答、通信中断、定时器中断和低速外设中断，同时保留了足够的子优先级用于同级微调。

5.2 具体中断的优先级赋值

在完成分组设定后，即可为每个启用的中断单独配置其抢占和子优先级。函数原型为：

void HAL_NVIC_SetPriority(IRQn_Type IRQn, uint32_t PreemptPriority, uint32_t SubPriority);

其中 IRQn_Type 是来自 core_cm3.h 的枚举类型，如 EXTI0_IRQn , TIM2_IRQn , USART1_IRQn 。

一个典型的配置示例如下：

// 1. 配置系统滴答，最高抢占优先级，确保调度器精准
HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);

// 2. 配置USB中断，次高抢占优先级，保障高速数据流
HAL_NVIC_SetPriority(USB_HP_CAN_TX_IRQn, 1, 0);

// 3. 配置TIM2定时器中断，用于周期性采样，中等抢占优先级
HAL_NVIC_SetPriority(TIM2_IRQn, 2, 0);

// 4. 配置EXTI0外部中断（按键），最低抢占优先级，避免干扰其他任务
HAL_NVIC_SetPriority(EXTI0_IRQn, 3, 0);

// 5. 最后，使能中断
HAL_NVIC_EnableIRQ(EXTI0_IRQn);
HAL_NVIC_EnableIRQ(TIM2_IRQn);

此处的数字 0, 1, 2, 3 并非绝对数值，而是相对于所选分组模式的有效范围。在 GROUP_2 下，抢占优先级有效范围是 0-3 ，因此上述配置是合法且最优的。

5.3 中断使能与失能的精确控制

HAL_NVIC_EnableIRQ() 和 HAL_NVIC_DisableIRQ() 是控制中断“闸门”的开关。它们操作的是NVIC的 ISER （Interrupt Set-Enable Register）和 ICER （Interrupt Clear-Enable Register）。一个常见的工程陷阱是：在中断服务函数中，错误地使用 __disable_irq() 或 HAL_NVIC_DisableIRQ() 来试图阻止自身被重入。

正确的做法是： 利用NVIC的硬件特性，而非软件锁 。当一个中断正在执行时，NVIC会自动禁止所有抢占优先级相同或更低的中断。因此，若 EXTI0_IRQHandler 的抢占优先级为3，那么在它执行期间，所有抢占优先级为3或更低的中断（如另一个 EXTI ）将被硬件屏蔽，无需手动干预。手动禁用中断不仅增加了代码复杂度，还可能因疏忽导致中断被永久关闭，引发系统死锁。

6. 工程实践：按键中断的完整实现剖析

一个看似简单的按键中断，是检验工程师对中断系统理解深度的最佳试金石。下面以STM32F103的 EXTI0 为例，展示一个工业级的实现方案，它超越了教科书式的“点亮LED”，直面真实世界的挑战。

6.1 硬件设计考量

按键直接连接到 PA0 引脚，必须配备硬件消抖电路。最简单有效的方式是在按键与地之间串联一个10kΩ上拉电阻，并在 PA0 与地之间并联一个100nF陶瓷电容。该电容能吸收按键弹跳产生的高频毛刺，将一个持续数毫秒的机械抖动，滤波为一个干净的、上升沿有效的数字信号。没有这个硬件基础，任何软件消抖算法都将事倍功半。

6.2 初始化：从时钟到GPIO的完整链路

中断的初始化是一个环环相扣的链条，任何一环缺失都将导致中断失效：

void MX_GPIO_Init(void)
{
  GPIO_InitTypeDef GPIO_InitStruct = {0};

  /* 1. 使能GPIOA时钟 —— 这是第一步，也是最容易被遗忘的一步 */
  __HAL_RCC_GPIOA_CLK_ENABLE();

  /* 2. 配置PA0为浮空输入模式，触发外部中断 */
  GPIO_InitStruct.Pin = GPIO_PIN_0;
  GPIO_InitStruct.Mode = GPIO_MODE_IT_RISING; // 上升沿触发
  GPIO_InitStruct.Pull = GPIO_NOPULL;          // 无上下拉，由外部电路决定
  HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

  /* 3. 配置NVIC：设置分组、优先级、并使能 */
  HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_2);
  HAL_NVIC_SetPriority(EXTI0_IRQn, 3, 0); // 抢占3，子0
  HAL_NVIC_EnableIRQ(EXTI0_IRQn);
}

注意 __HAL_RCC_GPIOA_CLK_ENABLE() 这行代码。它是整个GPIO外设工作的前提。如果忘记使能时钟， HAL_GPIO_Init 将无法正确配置寄存器， PA0 将始终处于高阻态，外部中断永远不会被触发。这是新手最常见的“找不到原因”的Bug来源。

6.3 中断服务与业务逻辑的优雅分离

在 stm32f103xb_it.c 中，我们重定义 EXTI0_IRQHandler ：

extern volatile uint32_t key_press_count;

void EXTI0_IRQHandler(void)
{
  HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_0);
}

void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)
{
  if(GPIO_Pin == GPIO_PIN_0)
  {
    /* 关键：仅在此处做最轻量级操作 */
    key_press_count++; // 原子计数，记录按键次数
    /* 更好的做法是：设置一个volatile标志，或向FreeRTOS队列发送消息 */
  }
}

而在 main.c 的主循环中，我们进行业务处理：

int main(void)
{
  HAL_Init();
  SystemClock_Config();
  MX_GPIO_Init();

  while (1)
  {
    /* 主循环：处理所有非实时性任务 */
    if(key_press_count > 0)
    {
      /* 执行耗时操作：例如，通过UART发送一条日志 */
      char log[32];
      sprintf(log, "Key pressed %lu times\r\n", key_press_count);
      HAL_UART_Transmit(&huart1, (uint8_t*)log, strlen(log), HAL_MAX_DELAY);
      key_press_count = 0; // 清零
    }

    /* 其他任务... */
    HAL_Delay(10); // 10ms任务调度周期
  }
}

这种将“事件捕获”与“事件处理”分离的模式，是构建大型嵌入式系统的基础。它确保了中断服务函数的执行时间恒定且极短（通常<1us），而将所有不确定性的、耗时的业务逻辑放在主循环中，由开发者完全掌控其执行时机和资源消耗。

7. 常见陷阱与调试经验

在多年的STM32开发中，我踩过无数次中断相关的坑。以下是最具代表性的几个，它们往往不会导致编译错误，却能让系统陷入难以捉摸的诡异状态。

7.1 “中断不触发”的元凶：时钟与模式的双重校验

当 EXTI0_IRQHandler 死活不进时，90%的概率源于两个配置项的遗漏：
1. GPIO时钟未使能 ： __HAL_RCC_GPIOA_CLK_ENABLE() 。
2. SYSCFG时钟未使能 ： __HAL_RCC_SYSCFG_CLK_ENABLE() 。这是最容易被忽略的一点！ EXTI 线需要通过 SYSCFG_EXTICR 寄存器将GPIO端口（A/B/C/D/E）映射到具体的EXTI线上。如果 SYSCFG 时钟关闭， HAL_GPIO_Init 中对 SYSCFG_EXTICR 的写入将无效， PA0 永远不会被连接到 EXTI0 。

调试方法：在 MX_GPIO_Init 函数末尾，添加一行 __HAL_GPIO_EXTI_GET_FLAG(GPIO_PIN_0) ，并在调试器中单步执行，观察其返回值。若为 RESET ，说明映射失败。

7.2 “中断丢失”的根源：未清除中断标志

这是一个经典的竞态条件。假设在 EXTI0_IRQHandler 中，你写了这样的代码：

void EXTI0_IRQHandler(void)
{
  // 错误示范：没有清除中断标志！
  key_pressed_flag = 1;
}

由于 EXTI->PR 寄存器中的挂起位从未被清零，CPU在退出中断后，会立刻再次检测到该位为1，于是马上又进入 EXTI0_IRQHandler ，形成一个永不停止的中断风暴。此时，主程序 while(1) 将完全得不到执行时间，系统“假死”。

解决方案：永远信任HAL库的 HAL_GPIO_EXTI_IRQHandler ，它内部完成了清除操作。或者，如果你必须手写，务必在函数开头或结尾加入：

EXTI->PR = EXTI_PR_PR0; // 清除EXTI Line0的挂起位

7.3 “优先级混乱”的调试利器：NVIC寄存器快照

当多个中断行为不符合预期时，最直接的方法是查看NVIC的实时状态。在STM32CubeIDE的调试界面中，打开 Peripherals -> NVIC 视图，你可以直观地看到：
- ISER （中断使能寄存器）：哪些中断当前是开启的。
- IPR （中断优先级寄存器）：每个中断当前配置的抢占和子优先级值。
- IABR （中断活跃寄存器）：哪些中断当前正在执行中。

通过比对这些寄存器的实际值与代码中 HAL_NVIC_SetPriority 的期望值，可以瞬间定位是配置代码未生效，还是被其他地方的代码意外修改。

我在一个电机控制项目中曾遇到过类似问题： TIM1_UP_IRQHandler 的抢占优先级被意外设为了0，导致它频繁打断 SysTick ，使FreeRTOS的 xTaskGetTickCount() 返回值严重失真。通过直接查看 IPR 寄存器，发现其值为 0x00000000 ，而预期应为 0x00000040 （抢占2，子0），最终追溯到一段被注释掉的旧代码中残留的 HAL_NVIC_SetPriority(TIM1_UP_IRQn, 0, 0) 调用。