三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

STM32串口中断编程实战：从阻塞到高效响应

发布时间：2026/8/13 16:17:55 三亩地 编程学习日记
STM32串口中断编程实战：从阻塞到高效响应

1. 从阻塞到中断：为什么你的STM32串口程序需要重构

如果你刚开始玩STM32，用HAL库的HAL_UART_Transmit和HAL_UART_Receive这两个函数来收发串口数据，感觉简直不要太爽。代码简单，逻辑清晰，一调用就能把数据发出去或者等着收数据。但当你试图让单片机同时干点别的，比如点个灯、读个传感器，或者处理一下按键，你就会发现整个世界都“卡”住了——程序会死死地等在HAL_UART_Receive那里，直到收到指定长度的数据才会继续往下走。这种“阻塞式”的收发方式，在简单的演示中没问题，但在真实的、需要“一心多用”的嵌入式项目里，它就成了最大的性能瓶颈和体验杀手。

这时，“中断”就该登场了。它不是让CPU傻等，而是告诉串口外设：“嘿，你帮我盯着点，有数据来了或者数据发完了，就赶紧打断我一下，我处理完马上回来干别的。”这样，CPU的绝大部分时间都可以自由地执行其他任务，只在数据到来的瞬间被“中断”一下去处理数据，处理完立刻返回。整个系统的响应速度和效率会有质的提升。今天，我就以一个踩过无数坑的过来人身份，带你用STM32CubeMX和HAL库，从零开始，手把手配置一个稳定、高效的串口中断收发框架。我会把原理讲透，把步骤拆细，更会把那些官方手册里不会写、但实际开发中一定会遇到的“坑”和“技巧”毫无保留地分享给你。

2. 工程创建与CubeMX基础配置：奠定好地基

万事开头难，但开头对了，后面就顺了。使用STM32CubeMX进行初始化配置，是现代STM32开发的标准姿势，它能帮你生成正确的时钟、引脚和中断初始化代码，避免很多低级错误。

2.1 芯片选型与工程创建

首先，打开STM32CubeMX，点击“New Project”。在芯片选择器里，输入你的具体型号，比如我手头这块板子是STM32F103C8T6，就搜它。选中后，右侧会显示芯片的引脚图和基本资源。这里有个关键点：务必确认你芯片的封装型号。同样是STM32F103C8T6，可能有LQFP48、TSSOP20等不同封装，引脚数量和外设分布完全不同。选错了，后面配置的引脚可能根本不存在于你的实物芯片上。确认无误后，点击“Start Project”。

项目创建好后，我们首先要解决系统的“心跳”问题——时钟。

2.2 时钟树（Clock Tree）配置：让芯片跑起来

在左侧边栏找到“Clock Configuration”标签页。这里看起来像一棵树，决定了CPU核心、总线以及各个外设的运行速度。对于串口通信，波特率的精度直接依赖于时钟源的稳定性。

对于F1系列，通常使用外部高速时钟（HSE）。在图形界面上，找到“HSE”选择框，将其设置为“Crystal/Ceramic Resonator”。然后，在“PLL Source Mux”处，选择HSE作为PLL的时钟源。接着，调整PLL的倍频系数，使系统时钟（SYSCLK）达到芯片允许的最高频率（对于F103C8T6是72MHz）。CubeMX会自动计算并填充分频系数，使APB1总线时钟（PCLK1）和APB2总线时钟（PCLK2）也得到合理配置。

注意：串口1（USART1）挂在APB2总线下，而串口2/3（USART2/3）挂在APB1下。总线的时钟频率会直接影响你最终计算出的波特率是否准确。配置完时钟树后，一定要看一眼右上角的“HCLK”是不是你期望的系统主频（比如72MHz），这步错了，后面一切通信时序都会乱套。

2.3 GPIO引脚模式配置：不仅仅是“Alternate Function”

转到“Pinout & Configuration”标签页。在芯片引脚图上，找到你想要用作串口TX（发送）和RX（接收）的引脚。例如，对于USART1，通常是PA9（TX）和PA10（RX）。点击对应的引脚，会弹出功能选择菜单。

这里有一个极易忽略的细节：当你选择“USART1_TX”或“USART1_RX”后，CubeMX默认的GPIO模式（GPIO Mode）可能是“Alternate Function Push Pull”。对于TX引脚，这没问题。但对于RX引脚，这通常不够！RX引脚是输入引脚，它的正确模式应该是“Alternate Function Open Drain”吗？不，更常见的、也是我推荐的做法是：将RX引脚的GPIO模式手动改为“Alternate Function”即可，HAL库底层会根据需要配置上下拉。但为了绝对可靠，特别是当你的RX线路上没有外部上拉电阻时，你应该在后续的GPIO配置中，明确将RX引脚的上拉（Pull-up）模式启用，以防止引脚悬空产生噪声误触发中断。我们可以在生成代码后，在MX_GPIO_Init函数里找到对应引脚的初始化结构体进行修改。

3. USART外设深度配置：中断的核心开关

点击左侧边栏“Connectivity”下的USART1（或你使用的串口）。

3.1 基本参数设置：波特率、字长、停止位、校验位

在“Parameter Settings”选项卡中，配置通信的基本参数：

  • Baud Rate: 根据你的通信对象设置，常用115200或9600。这里填写的值，CubeMX会根据你前面配置的时钟自动计算分频值，确保精度。
  • Word Length: 数据位长度，通常选8位（包含校验位时选9位）。
  • Parity: 校验位，根据需求选择“None”（无）、“Even”（偶校验）或“Odd”（奇校验）。
  • Stop Bits: 停止位，通常选1位。
  • Data Direction: 数据方向，既然我们要收发，就选“Receive and Transmit”。
  • Over Sampling: 过采样率，通常保持默认的“16倍”即可，它能提供更好的抗噪性能。

这些参数必须与通信对端（如电脑串口助手、另一个单片机）的设置完全一致，否则收到的将是乱码。

3.2 中断与DMA配置：开启“响应”能力

这是本章节的重中之重，转到“NVIC Settings”选项卡。

  1. 找到“USART1 global interrupt”，勾选前面的“Enabled”复选框。这一步是启用USART1的全局中断，意味着所有USART1的事件（发送完成、接收完成、出错等）都会触发中断。
  2. 勾选后，下方可以设置中断的“Preemption Priority”（抢占优先级）和“SubPriority”（子优先级）。对于简单的单串口应用，可以都设为0。但如果你的系统中有多个中断源（如定时器中断、外部按键中断），就需要合理规划优先级，确保更紧急的任务能打断正在执行的不太紧急的中断服务程序。

关键技巧：很多人配置到这里就以为万事大吉，其实还差一步。仅仅开启全局中断，我们只能处理像“发送完成”、“接收完成”这样的特定事件。而要实现“每收到一个字节就触发中断”，还需要在代码中使能特定的中断源，即“接收寄存器非空中断”（RXNE interrupt）。这个开关不在CubeMX里，需要在生成的代码中，调用HAL_UART_Receive_IT函数来开启。CubeMX帮我们搭好了中断的“舞台”（NVIC配置），但上台表演的“演员”（具体哪个事件触发中断）需要我们自己邀请。

为什么不在这里配置DMA？本文聚焦中断模式。DMA是比中断更高级的“免打扰”方式，它可以让数据在外设和内存之间自动搬运，完全不需要CPU参与每次字节的传输。对于高速、大数据量的串口通信，DMA是终极解决方案。但中断是理解DMA的基础，且在很多低速率、交互性强的场景（如AT指令解析）中，中断模式反而更直观、可控。我们先掌握中断，再挑战DMA。

配置完成后，点击右上角的“Project Manager”选项卡，给项目起个名字，选择好IDE（如MDK-ARM V5），设置好代码生成路径。关键点在于“Code Generator”部分：我强烈建议勾选“Generate peripheral initialization as a pair of ‘.c/.h’ files per peripheral”，这样每个外设的初始化代码会单独成对的文件，结构更清晰。然后点击“GENERATE CODE”，生成工程。

4. 代码实战：编写中断收发核心逻辑

打开生成的工程（例如Keil MDK），你会发现CubeMX已经生成了main.c，usart.c，gpio.c等文件，并且完成了时钟、GPIO、USART的初始化（在MX_USART1_UART_Init函数中）。我们的工作是在此骨架上添加血肉。

4.1 发送数据：非阻塞与回调机制

首先看发送。HAL库提供了中断方式的发送函数：HAL_UART_Transmit_IT(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size)。

  • huart: 你的串口句柄，例如&huart1。
  • pData: 要发送的数据缓冲区首地址。
  • Size: 要发送的字节数。

当你调用这个函数时，它并不会等待数据全部发完，而是启动发送第一个字节，然后立即返回。剩下的字节会在“发送完成中断”里自动处理。数据全部发送完毕后，会触发一个发送完成回调函数。

// 示例：在main函数中发送字符串 uint8_t tx_buffer[] = "Hello, UART!\r\n"; HAL_UART_Transmit_IT(&huart1, tx_buffer, sizeof(tx_buffer) - 1); // 注意长度减1，不发送字符串结束符'\0'

那么，如何知道数据发完了呢？你需要重写（Override）发送完成回调函数。在main.c文件里，找到/* USER CODE BEGIN 4 */和/* USER CODE END 4 */之间（这是CubeMX为用户代码保留的安全区，重新生成代码不会覆盖），添加以下函数：

/* USER CODE BEGIN 4 */ void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart) { // 判断是哪个串口发送完成 if(huart->Instance == USART1) { // 可以在这里置位一个标志位，通知主循环发送完成 // 例如：uart1_tx_done_flag = 1; // 或者准备下一次发送 } } /* USER CODE END 4 */

踩坑点1：缓冲区生命周期。HAL_UART_Transmit_IT函数只是记录了缓冲区的地址和长度，在中断发送完成前，你必须确保tx_buffer数组一直有效，且内容不被修改。如果你在函数中定义了一个局部数组作为缓冲区，函数返回后数组内存可能被释放或重用，导致发送乱码或程序崩溃。因此，发送缓冲区应使用全局数组或静态局部数组。

4.2 接收数据：开启“监听”模式与数据缓存

接收是中断模式的核心。对应的函数是HAL_UART_Receive_IT(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size)。

  • 参数意义同发送函数。
  • 调用此函数后，串口就会开始“监听”。每收到一个字节，就会产生一次中断，HAL库的中断服务程序（在stm32f1xx_it.c中，你无需修改）会把这个字节存到你提供的pData缓冲区，并将期望接收的计数器减1。当收到指定数量（Size）的字节后，会触发接收完成回调函数。

听起来很简单？但这里有一个经典陷阱：如果你在回调函数里处理数据，然后再次调用HAL_UART_Receive_IT开启下一轮接收，那么在处理数据和重新开启接收的极短间隙内，如果又有新数据到来，就会丢失。对于连续不断的串口数据流（如传感器数据），这是不可接受的。

解决方案：双缓冲（Ping-Pong Buffer）或循环队列（Ring Buffer）。更简单实用的方法是：只开启一次接收，但接收一个很大的缓冲区（比如200字节），在回调函数里并不实际处理数据，而是设置一个标志，通知主循环来处理。同时，立即重新开启接收，指向另一个缓冲区或原缓冲区的剩余空间。但HAL库的机制要求我们必须在回调函数内或之后重新调用HAL_UART_Receive_IT。

一个稳健的实践模式如下：

  1. 定义全局变量：

    /* USER CODE BEGIN PV */ uint8_t uart_rx_buffer[256]; // 接收缓冲区 volatile uint8_t uart_rx_len = 0; // 实际接收到的数据长度 volatile uint8_t uart_rx_flag = 0; // 接收完成标志，用volatile防止编译器优化 /* USER CODE END PV */

  2. 在main函数初始化后，开启第一轮接收：

    /* USER CODE BEGIN 2 */ // 启动串口中断接收，期望最大接收256字节，但实际可能通过超时等方式判断一帧结束 HAL_UART_Receive_IT(&huart1, uart_rx_buffer, 256); /* USER CODE END 2 */

  3. 实现接收完成回调函数：

    void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if(huart->Instance == USART1) { // 获取当前已经接收到的数据长度 // 注意：HAL库的Size参数是期望接收数，我们需要计算实际接收数。 // 更常见的做法是：我们开启接收1个字节，每收到一个字节就触发一次这个回调。 // 这样我们就能在回调里处理每一个字节。 } }

    等等，这里出现了问题。HAL_UART_Receive_IT配合HAL_UART_RxCpltCallback是在收满指定长度后才回调的，不适合处理不定长数据。对于不定长数据（例如以回车换行符\r\n结尾的一帧数据），我们需要更精细的控制。

4.3 处理不定长数据：利用“空闲中断”（Idle Interrupt）

这才是工业级串口中断收发的灵魂。STM32的USART有一个“空闲线路检测”（Idle Line Detection）功能。当串口总线在至少一个完整字符时间（波特率决定）内没有收到任何新数据时，就会产生“空闲中断”（Idle Interrupt）。这完美标志着一帧数据的结束。

配置步骤（部分需在生成代码后手动添加）：

  1. 在CubeMX中使能空闲中断（可选，也可在代码中开启）：在USART配置的“NVIC Settings”中，你可能找不到独立的“Idle Interrupt”。通常需要在代码中手动开启。
  2. 在MX_USART1_UART_Init函数后，手动开启空闲中断：
    /* USER CODE BEGIN USART1_Init 2 */ // 使能USART1的空闲线路中断 __HAL_UART_ENABLE_IT(&huart1, UART_IT_IDLE); /* USER CODE END USART1_Init 2 */
  3. 修改中断服务程序：我们需要修改stm32f1xx_it.c中的USART1_IRQHandler函数，添加对空闲中断的处理。注意：CubeMX重新生成代码会覆盖此文件，所以最好将修改放在/* USER CODE BEGIN USART1_IRQn 0 */和/* USER CODE END USART1_IRQn 0 */之间。
    // 在 stm32f1xx_it.c 中找到 USART1_IRQHandler 函数 void USART1_IRQHandler(void) { /* USER CODE BEGIN USART1_IRQn 0 */ // 判断是否是空闲中断 if((__HAL_UART_GET_FLAG(&huart1, UART_FLAG_IDLE) != RESET) && (__HAL_UART_GET_IT_SOURCE(&huart1, UART_IT_IDLE) != RESET)) { // 清除空闲中断标志（重要！通过读SR和DR寄存器来清除） __HAL_UART_CLEAR_IDLEFLAG(&huart1); // 计算本次接收到的数据长度 // 当前数据长度 = 期望接收长度 - 剩余待接收长度 uart_rx_len = 256 - huart1.RxXferCount; // 设置接收完成标志 uart_rx_flag = 1; // 重新启动接收，准备接收下一帧数据 // 先停止当前DMA/中断接收（如果是中断模式） // HAL_UART_AbortReceive(&huart1); // 可选，确保状态机复位 huart1.RxState = HAL_UART_STATE_READY; // 关键！将串口句柄状态重置为就绪 HAL_UART_Receive_IT(&huart1, uart_rx_buffer, 256); } /* USER CODE END USART1_IRQn 0 */ HAL_UART_IRQHandler(&huart1); /* USER CODE BEGIN USART1_IRQn 1 */ /* USER CODE END USART1_IRQn 1 */ }
  4. 在主循环中处理数据：
    while (1) { /* USER CODE END WHILE */ /* USER CODE BEGIN 3 */ if(uart_rx_flag == 1) { uart_rx_flag = 0; // 清除标志 // 此时，uart_rx_buffer 中存放了刚收到的一帧数据，长度为 uart_rx_len // 你可以在这里进行数据解析、校验、响应等操作 // 例如，回显数据 HAL_UART_Transmit_IT(&huart1, uart_rx_buffer, uart_rx_len); // 处理完成后，缓冲区可以被下一帧数据覆盖 // 注意：如果处理时间很长，需要考虑缓冲区冲突问题 } // 主循环可以执行其他任务，如闪烁LED HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin); HAL_Delay(500); }

踩坑点2：句柄状态机。HAL库为每个外设维护了一个状态机（RxState,TxState）。如果你在回调函数或中断中处理不当，没有将状态重置为HAL_UART_STATE_READY，再次调用HAL_UART_Receive_IT时会失败（返回HAL_BUSY）。上面的代码中手动重置huart1.RxState是一个关键技巧。

踩坑点3：中断服务程序中的重入。在USART1_IRQHandler中，我们添加了自定义代码后，仍然调用了HAL_UART_IRQHandler(&huart1)。这个HAL库的通用中断处理函数会处理其他中断（如RXNE, TXE等）。我们的自定义代码和它要协同工作，注意不要破坏HAL库内部的状态。确保先处理空闲中断，并清除标志，再调用通用处理函数。

5. 调试、排错与性能优化实战

代码写完了，下载到板子，打开串口助手，却发现没反应，或者数据不对？别急，我们一步步来。

5.1 硬件连接与基础检查

  1. 线序确认：TX接RX，RX接TX，GND接GND。这是老生常谈，但依然是新手第一坑。用USB-TTL模块时，务必确认其VCC电压与你的单片机IO电压匹配（通常是3.3V），不要接错烧坏芯片。
  2. 波特率等参数：确保单片机程序设置的波特率、数据位、停止位、校验位与串口助手的设置一字不差。115200和9600差很远，8N1和8E1也完全不同。
  3. 电源与地线：确保共地。如果使用两个独立的USB端口（一个给板子供电，一个接USB-TTL模块），必须用导线将两者的GND连接起来，否则电势差会导致通信失败。

5.2 软件调试：从灯开始

  1. 先让灯闪起来：在main函数的while循环里加一个LED闪烁的程序。如果灯不闪，说明程序根本没跑起来，可能是时钟配置错误、下载方式不对（Boot引脚）或复位电路问题。
  2. 简化测试：先注释掉复杂的中断接收逻辑，只测试发送。在main循环里每隔1秒发送一个固定的字符串。如果串口助手能收到，说明发送通路、基本配置和硬件连接是好的。
  3. 测试接收中断：将接收模式改为最简单的“定长接收”。例如，开启接收3个字节的中断（HAL_UART_Receive_IT(&huart1, rx_buf, 3)），在HAL_UART_RxCpltCallback里将收到的3个字节回发出来。从串口助手发送恰好3个字符（如“abc”），看是否能正确回显。这可以验证接收中断是否正常触发。
  4. 加入空闲中断：在定长接收测试成功后，再加入空闲中断的代码。发送一帧不定长数据（如“hello\r\n”），观察是否能正确触发空闲中断，并回显整帧数据。

5.3 常见问题与解决方案

  • 问题：只能收到第一个字节，或者收不全。
    • 排查：检查是否在接收完成回调函数中重新启动了接收（HAL_UART_Receive_IT）。检查接收缓冲区是否定义得太小，或者被意外修改。检查串口句柄的状态huart.RxState，确保在重启接收前它是HAL_UART_STATE_READY。
  • 问题：空闲中断只触发一次，后续数据不触发。
    • 排查：这是最典型的问题。必须确保在空闲中断处理程序中清除了空闲中断标志。使用__HAL_UART_CLEAR_IDLEFLAG(&huart1)。同时，检查是否在中断中正确地重置了句柄状态并重启了接收。
  • 问题：程序运行一段时间后卡死。
    • 排查：可能是中断服务程序执行时间过长，导致其他更高优先级的中断无法响应，或者发生了中断嵌套问题。检查中断优先级（NVIC）配置。确保在中断服务程序里只做最必要的操作（如设置标志、拷贝数据），耗时的解析工作放到主循环中。另外，检查是否有缓冲区溢出，或者指针越界访问。
    • 使用volatile：用于在中断和主循环之间共享的标志变量（如uart_rx_flag），一定要用volatile关键字修饰，防止编译器优化导致读写不同步。
  • 问题：发送大量数据时，偶尔丢数据。
    • 排查：中断发送虽然是非阻塞的，但其速度仍受限于波特率。如果你在主循环里以极快的速度连续调用HAL_UART_Transmit_IT，而前一次发送还没完成（huart.TxState != HAL_UART_STATE_READY），后一次的调用就会失败。解决方案是：在HAL_UART_TxCpltCallback中设置一个“发送空闲”标志，主循环检查这个标志为真时才启动下一次发送，实现简单的流控。或者，使用DMA进行发送。

5.4 进阶优化：稳定性与效率

  1. 环形缓冲区（Ring Buffer）：对于高速率数据流，前述的“空闲中断+大数组”方案在数据解析较慢时，可能在新数据到来时覆盖旧数据。实现一个环形缓冲区是更专业的做法。在空闲中断中，将收到的数据存入环形缓冲区尾指针处，并移动尾指针。主循环从环形缓冲区头指针处取出数据进行处理。这样实现了生产（中断）和消费（主循环）的解耦。
  2. DMA接收：将HAL_UART_Receive_IT替换为HAL_UART_Receive_DMA。DMA控制器会自动将串口接收到的数据搬运到你指定的大缓冲区中，完全无需CPU干预每字节的接收。你仍然可以开启空闲中断，在空闲中断里计算本次DMA接收了多少数据。这是处理高速、大数据量串口通信的终极方案，能极大解放CPU。
  3. 协议设计：在实际项目中，纯靠空闲中断判断帧结束有时不可靠，特别是在有噪声的环境中。通常会在数据帧中加入帧头、帧尾、长度、校验和。在中断或主循环解析时，先寻找帧头，然后根据长度字段提取指定字节数，最后校验帧尾和校验和，确保帧的完整性。
编程学习 学习日记 实战经验
← 返回列表