标准库要求用户直接编写完整的中断服务函数（例如 TIM2_IRQHandler），所有逻辑（包括标志位判断、清除、业务处理）都需要在这个函数中手动实现，没有 “回调函数” 的概念。

例如，标准库实现 TIM2 定时中断的结构是：
// 标准库：中断服务函数需用户完全手动编写
void TIM2_IRQHandler(void)
{
    // 1. 判断中断标志
    if (TIM_GetITStatus(TIM2, TIM_IT_Update) == SET)
    {
        // 2. 清除中断标志
        TIM_ClearITPendingBit(TIM2, TIM_IT_Update);
        
        // 3. 业务逻辑（如LED翻转）
        GPIO_TogglePin(GPIOE, GPIO_Pin_15);
    }
}
如何判断是否产生了中断重叠现象？

就是刚进中断就清除标志位，中断退出之前，再检查一下标志位，如果又置1了，说明中断重叠。

如何得知定时中断执行的时长？

只需要在函数退出之前，读取一下计数器

定时器——HAL库

HAL 库的回调函数机制：

        HAL 库通过 “底层中断服务函数 + 上层回调函数” 的分层设计，

        将通用逻辑（标志判断、清除）封装在 HAL 库内部（如 HAL_TIM_IRQHandler），

        用户只需实现回调函数（如 HAL_TIM_PeriodElapsedCallback）来处理业务逻辑，无需关心底层细节。

在HAL 库环境下，不需要也不建议使用 TIM_GetITStatus(TIM2, TIM_IT_Update) == SET 来判断中断；

HAL 库的 HAL_TIM_IRQHandler 函数会自动完成所有已使能的定时器中断标志位的判断与清除，用户在回调函数（如 HAL_TIM_PeriodElapsedCallback）中无需再处理标志位，只需专注于业务逻辑（如 LED 翻转、数据读取等）即可。

记得开启中断，初始化阶段完成
//手动开启TIM2定时器中断（关键步骤）
HAL_TIM_Base_Start_IT(&htim2);

void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
{
    if (htim == (&htim2))
    {
	   ID++;
    }
}

void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
{

    if (htim->Instance == TIM2)
    {
        ID++;
    }
}

1. htim->Instance == TIM2

htim 是 TIM_HandleTypeDef 类型的指针，它的 Instance 成员直接指向定时器的硬件寄存器基地址（例如 TIM2 对应的寄存器基地址是 TIM2 这个宏定义）。
这种写法是通过寄存器基地址来判断定时器实例，是 HAL 库中更 “底层” 且通用的判断方式，适用于所有定时器外设。

2. htim == &htim2

htim2 是用户在初始化时定义的 TIM_HandleTypeDef 类型的结构体变量（例如 TIM_HandleTypeDef htim2;）。
这种写法是通过比较结构体变量的地址来判断，要求用户在代码中明确定义了对应的 htim2 变量，且该变量是 TIM2 的配置句柄。

区别与选择建议

对比项 htim->Instance == TIM2 htim == &htim2
依赖条件仅依赖定时器的寄存器基地址（由芯片定义）依赖用户定义的 TIM_HandleTypeDef 变量（如 htim2）
通用性更高（适用于所有定时器，无需关心变量名）较低（需确保变量名与定时器实例一一对应）
代码可读性直接体现 “判断定时器硬件实例” 的意图需结合变量定义才能明确对应关系

对比项	`htim->Instance == TIM2`	`htim == &htim2`
依赖条件	仅依赖定时器的寄存器基地址（由芯片定义）	依赖用户定义的 `TIM_HandleTypeDef` 变量（如 `htim2`）
通用性	更高（适用于所有定时器，无需关心变量名）	较低（需确保变量名与定时器实例一一对应）
代码可读性	直接体现 “判断定时器硬件实例” 的意图	需结合变量定义才能明确对应关系

GPIO(按鍵)的中断回调——HAL库

触发条件

对比项	External Interrupt Mode（中断模式）	External Event Mode（事件模式）
CPU 参与度	需要 CPU 响应中断，执行回调函数	无 CPU 参与，纯硬件联动外设
延迟性	存在中断响应延迟（微秒级）	硬件级触发，延迟极低（纳秒级）
应用场景	需要 CPU 处理逻辑（如状态判断、数据解析）	仅需硬件联动外设（如定时器启动、DMA 触发）

在 CubeMX 完成配置后，无需在函数中手动初始化中断的底层硬件逻辑（如 EXTI 寄存器、NVIC 优先级等），这些都由 CubeMX 生成的代码自动完成。你只需关注使能中断和实现回调函数这两个关键步骤，具体如下：

使能外部中断（CubeMX 生成代码已包含，无需手动写）

CubeMX 生成的MX_GPIO_Init()函数会自动初始化 A1 引脚的中断配置，包括：

配置 GPIO 为外部中断模式（上升沿 / 下降沿触发）前提记得先上下拉；
NVIC中配置 EXTI 控制器的中断线映射；
配置 NVIC 的中断使能和优先级（即你在 CubeMX NVIC 界面中设置的参数）。

实现中断回调函数（需要用户手动写）

在用户代码中重写HAL_GPIO_EXTI_Callback函数，处理 A1 引脚中断触发后的逻辑：

void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)
{
    if (GPIO_Pin == GPIO_PIN_1)  // 判断是A1引脚触发的中断
    {
        // 在这里编写中断触发后的业务逻辑，例如：
        // 读取引脚电平、控制LED、执行特定任务等
        HAL_GPIO_TogglePin(GPIOE, GPIO_PIN_15);  // 示例：翻转PE15的LED
    }
}

邊沿檢測很快，一般不用延遲，另外，可能有一个问题：

中断回调函数必须 “快进快出”，不能包含任何阻塞操作（如HAL_Delay()），否则会导致系统卡死。

HAL_Delay()是基于系统滴答定时器（SysTick）的延时函数，

        其原理是：等待 SysTick 定时器产生指定次数的中断（每 1ms 一次），通过计数递减实现延时。

        但中断回调函数运行时，系统会关闭同优先级或更低优先级的中断（包括 SysTick 中断）。

        因此，在HAL_GPIO_EXTI_Callback中调用HAL_Delay(10)时： SysTick 中断被阻塞，无法正常产生 1ms 定时，HAL_Delay()会陷入无限等待（永远等不到计数结束）。导致整个中断回调函数无法退出，系统卡死（主循环和其他中断都无法执行）。

void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)  // 重写中断回调函数
{
  // 清除中断标志位在这之前已经进行
 
  // 先判断是否是EXTO10传来的中断请求
  if (GPIO_Pin == KEY3_Pin)
  {
    // 消抖延时
    HAL_Delay(10);
 
    // 如果还是高电平就翻转LED1
    if (HAL_GPIO_ReadPin(GPIOF, GPIO_Pin) == GPIO_PIN_SET)
    {
      HAL_GPIO_TogglePin(GPIOA, LED1_Pin);
    }    
  }
}

不消抖，直接使用：

void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)
{
    if (GPIO_Pin == GPIO_PIN_3)  // �ж���A1���Ŵ������ж�
    {
			if (HAL_GPIO_ReadPin(GPIOE, GPIO_PIN_3) == GPIO_PIN_RESET)
			{
        HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_5); 			
			}
    }
    if (GPIO_Pin == GPIO_PIN_4)  // �ж���A1���Ŵ������ж�
    {
			if (HAL_GPIO_ReadPin(GPIOE, GPIO_PIN_4) == GPIO_PIN_RESET)
			{
        HAL_GPIO_TogglePin(GPIOE, GPIO_PIN_5); 			
			}
    }
}

串口——HAL库

配置

找定义，进去后一直往下翻，找串口接受的回调函数

串口接收的中断回调函数实现：

回调函数
void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)
{
  if (huart->Instance == USART1) // ???????????? USART1
  {
    /*    任务！！    */
    HAL_UART_Receive_IT(&huart1, (uint8_t*)rx_data, sizeof(rx_data)); // ???? UART ????
  }
}
记得重新开启接收中断：HAL_UART_Receive_IT(...)

由于 HAL 库的串口中断接收是 “一次性” 的（每次接收完成后会自动关闭中断），必须在回调函数末尾重新调用该函数，才能保证后续数据能继续触发接收中断，实现持续接收。

初始化：

记得在主函数住启用串口中断，如下
// 在main函数初始化后调用，启动USART1的中断接收（接收1字节到rx_data缓冲区）
HAL_UART_Receive_IT(&huart1, (uint8_t*)rx_data, 1);
使能串口接收中断，当接收到指定长度（如 1 字节）数据后，自动触发 HAL_UART_RxCpltCallback 回调函数。

串口发送的中断

发送的函数也可以配合接收的一些函数去使用，但是注意理清楚状态

  HAL_UART_TxCpltCallback 是串口发送完成后的通知机制。当 HAL_UART_Transmit_IT 启动的异步发送过程全部完成（所有字节发送完毕），HAL 库会自动调用该回调函数，用于：

        告知用户 “数据已发送完成”（例如设置发送完成标志位 tx_done = 1）；

        触发后续操作（例如发送下一包数据、释放缓冲区、更新状态指示灯等）。

// 1. 启动异步发送
HAL_UART_Transmit_IT(&huart1, (uint8_t*)tx_data, len);  // 启动发送，立即返回

// 2. 发送过程由硬件中断自动完成（无需CPU干预）

// 3. 发送完成后，HAL库自动调用回调函数
void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart)
{
    if (huart->Instance == USART1)  // 确认是USART1的发送完成
    {
        // 例如：标记发送完成，用于主循环判断
        tx_complete_flag = 1;
        
        // 例如：继续发送下一包数据
        // HAL_UART_Transmit_IT(&huart1, next_tx_data, next_len);
    }
}