2026/9/10 14:27:57
FEATURED · 精选文章 
简介基于STM32F103的HAL库UART2中断收发完整工程包面向需要借助STM32CubeMX与HAL库实现串口通信的嵌入式工程师与学生。工程内以STM32CubeMX生成的.ioc配置为核心包含339个C源码、108个头文件及43个汇编文件并附有IAR链接脚本.icf与Keil工程文件压缩包共528个文件大小约12.82MB可直接打开工程编译调试。针对实时性要求较高的串口通信场景代码清晰演示了HAL_UART_Transmit_IT与HAL_UART_Receive_IT的中断收发启动流程以及TxCpltCallback、RxCpltCallback回调函数的处理逻辑同时覆盖中断优先级、FIFO、错误处理等设计要点有助于读者掌握UART2中断机制并快速移植到自身项目。目前已有538人学习下载可作为串口模块的开发模板与排错参考。1. 为什么 UART2 中断收发会成为 HAL 库开发的第一道坎很多从标准外设库转到 STM32 HAL 库的工程师第一次写串口中断收发时都会碰壁代码明明照着例程敲的发送正常可接收就是只进一次中断之后再也不动了。问题不在芯片而在对 HAL 库中断机制的理解上——HAL 库用回调函数把中断处理“包了一层”如果你不了解HAL_UART_RxCpltCallback的触发条件和生命周期很容易把它当成普通中断服务函数来用。HAL 库的 UART 中断收发本质上是“中断使能 回调分发”的封装模式硬件中断触发后HAL 库先做状态清理和标志位处理再调用用户编写的回调函数。而回调函数里如果没有重新开启下一次接收中断链就会断掉。这种设计让代码更安全但也要求开发者转变思维每一帧数据的接收都需要主动“预约”。本文围绕 UART2 讲透这条链路从 CubeMX 初始化到中断回调的完整实现再到不定长数据接收的进阶方案。新手能照着搭通最小工程老手也能在中断优先级、临界区保护和 DMA 协同这些边界参数上找到值得推敲的细节。2. 深入 HAL 库 UART 中断机制接收“一次性”背后的设计逻辑2.1 中断收发在 HAL 库中的完整链路HAL 库的 UART 中断收发由两个层面配合完成。硬件层面UART 外设检测到 RXNE接收数据寄存器非空或 TXE发送数据寄存器空事件后触发对应的中断向量。HAL 库则将中断向量统一导向UART_IRQHandler由它调用HAL_UART_IRQHandler这个公共入口函数。HAL_UART_IRQHandler内部做了大量工作判断中断类型、清除标志位、校验传输状态、更新huart-RxXferCount等计数变量。当一帧数据接收完成收到指定字节数后它会调用HAL_UART_RxCpltCallback。这个回调函数运行在中断上下文所以执行时间必须短不能做耗时操作。接收“只跑一次”的根因就在这儿——HAL_UART_Receive_IT函数本质上只是“预约一次接收”它设置好接收缓冲区指针和期望字节数然后使能接收中断。当接收完成后中断被关闭回调函数被调用。如果你想继续接收下一帧就必须在回调函数里重新调用HAL_UART_Receive_IT。2.2 中断方式与轮询、DMA 的边界划分传输方式适用场景CPU 占用实时性实现难度轮询Blocking短帧、低频、非实时高阻塞等待差低中断IT中短帧、事件驱动低仅在收发时打断良好中DMA长帧、高频、批量传输极低取决于 DMA 配置较高选择中断方式的前提是单次收发帧长不过长通常不超过 256 字节且接收频率可控。如果一秒钟要接收上千帧短数据中断方式会导致 CPU 频繁进出中断此时 DMA 更合适。但中断方式的优势在于——每次收发完成都有回调通知逻辑上更容易做成“一帧一处理”适合协议解析类的应用。2.3 宏定义与配置参数对中断行为的影响cubeMX 生成的代码里stm32f1xx_hal_conf.h中有几个关键宏#define HAL_UART_MODULE_ENABLED #define HAL_UART_IT_ENABLEDHAL_UART_IT_ENABLED必须开启否则.c文件里的中断处理函数会被条件编译排除。这个宏对应的是 UART 全局中断在NVIC中的使能状态CubeMX 勾选USART2 global interrupt后会自动生成。手动移植代码时最容易漏掉这一点导致HAL_UART_IRQHandler根本不会被调用。另一个需要确认的是huart-Init.Parity参数。如果使能了奇偶校验HAL 库接收的数据长度会是数据位 校验位这意味着你配置了 8 位数据加偶校验实际每一帧会占用 9 位硬件存储空间。很多人接收数据总是差一位或乱码排查半天发现是这里没对齐。3. UART2 初始化全程实录从 CubeMX 到最小中断工程3.1 CubeMX 中 UART2 的关键配置项打开 STM32CubeMX选择芯片型号后在Connectivity分类下找到USART2。这里重点设置四个参数Mode选择Asynchronous同时开启收发引脚映射Baud Rate按实际需求填写9600、115200、460800 是常见档位Word Length选择8 Bits多数传感器和协议默认 8 位NVIC Settings标签页勾选USART2 global interrupt波特率的选择直接影响通信稳定性。115200 是绝大多数场景的安全选项。如果使用更高的 460800要求双方时钟误差在 2% 以内HSE 晶振的频率偏差和 PLL 配置误差会被放大。CubeMX 会自动计算 USARTDIV 分频系数生成后可以打开stm32f1xx_hal_uart.c查看huart2.Init.BaudRate的实际值确保和设计值一致。引脚映射需要根据芯片封装确认STM32F103C8T6 的 UART2 默认在 PA2TX和 PA3RX。如果引脚冲突比如同时用作 SPI 或 I2CCubeMX 会用黄色警告标出此时可以尝试复用功能重映射到 PB10/PB11但这需要额外开启AFIO时钟。3.2 初始化代码的 HAL 层解读生成工程后MX_USART2_UART_Init函数会放在main.c中void MX_USART2_UART_Init(void) { huart2.Instance USART2; huart2.Init.BaudRate 115200; huart2.Init.WordLength UART_WORDLENGTH_8B; huart2.Init.StopBits UART_STOPBITS_1; huart2.Init.Parity UART_PARITY_NONE; huart2.Init.Mode UART_MODE_TX_RX; huart2.Init.HwFlowCtl UART_HWCONTROL_NONE; huart2.Init.OverSampling UART_OVERSAMPLING_16; if (HAL_UART_Init(huart2) ! HAL_OK) { Error_Handler(); } }OverSampling这个参数容易被忽略。默认OVERSAMPLING_16表示每个数据位采样 16 次抗干扰能力强OVERSAMPLING_8可以提升到更高波特率但对信号质量要求更高。低速场景保持 16 倍过采样即可。HAL_UART_Init内部还会调用HAL_UART_MspInit这个函数是 CubeMX 自动生成的完成时钟使能和 GPIO 配置。它通常在stm32f1xx_hal_msp.c文件中需要检查 GPIO 的Alternate是否设置为GPIO_AF7_USART2F1 系列是GPIO_AF_USART2。如果这里配置成普通推挽输出TX 引脚就发不出数据。3.3 最小中断收发代码框架/* 定义接收缓冲区和发送缓冲区 */ uint8_t aRxBuffer[1]; uint8_t aTxBuffer[] UART2 Ready\n; int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_USART2_UART_Init(); /* 预约第一次接收监听 1 字节 */ HAL_UART_Receive_IT(huart2, aRxBuffer, 1); /* 发送测试字符串 */ HAL_UART_Transmit(huart2, aTxBuffer, strlen((char*)aTxBuffer), 1000); while (1) { /* 主循环不做串口处理 */ } } /* 接收完成回调每收到 1 字节进入一次 */ void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART2) { /* 把收到的字节回传形成回环 */ HAL_UART_Transmit(huart2, aRxBuffer, 1, 100); /* 重新预约下一次接收 */ HAL_UART_Receive_IT(huart2, aRxBuffer, 1); } }HAL_UART_Receive_IT(huart2, aRxBuffer, 1)表示“期望接收 1 个字节存入 aRxBuffer”。注意第一个参数传的是huart2而不是USART2因为 HAL 库需要整个句柄来记录状态。第三个参数是接收长度设置为 1 意味着每来一个字节就会触发一次回调适合逐字节处理。这个代码的神奇之处在于主循环里什么都不用管接收和发送全由中断驱动。发送部分HAL_UART_Transmit虽然是阻塞模式但在回调里延时极短1 字节在 115200 波特率下约 87 微秒不会造成明显阻塞。如果发送长帧建议改为HAL_UART_Transmit_IT否则回调函数会卡在等待发送完成的循环里导致后续中断堆积。3.4 中断优先级配置与回调执行时长的权衡HAL_NVIC_SetPriority(USART2_IRQn, 0, 0)这个参数直接影响系统实时性。CubeMX 默认生成的优先级是0,0最高但如果系统里还有定时器中断或外部中断不建议把所有中断都设为最高优先级。在 F1 系列中NVIC_PriorityGroup_4意味着 4 位全用于抢占优先级没有子优先级。此时 USART2 设置为 1 或 2 更合理。如果设置成最高优先级而回调函数里又调用了HAL_Delay这类依赖于 Systick 中断的函数就会造成死锁——高优先级打断了 Systick而HAL_Delay在等 Systick 计满。回调函数的最佳实践是只做数据搬运和标志位设置把真正的处理逻辑放回主循环。volatile uint8_t uart2_rx_flag 0; void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART2) { uart2_rx_flag 1; HAL_UART_Receive_IT(huart2, aRxBuffer, 1); } } int main(void) { /* ... 初始化省略 ... */ while (1) { if (uart2_rx_flag) { uart2_rx_flag 0; /* 这里处理接收到的数据 */ process_byte(aRxBuffer[0]); } } }volatile关键字在这里必不可少——它告诉编译器这个变量可能被中断修改禁止优化到寄存器中。如果不加主循环可能永远读不到更新后的值这是嵌入式开发最常见的“灵异现象”之一。4. 中断接收“只收一次”的根因与多场景排错指南4.1 为什么必须重新调用 HAL_UART_Receive_ITHAL 库 UART 中断接收的本质是“单次请求模式”。回顾HAL_UART_Receive_IT的源码逻辑它把huart-RxState置为HAL_UART_STATE_BUSY_RX使能 RXNE 中断然后注册回调。当 RXNE 置位中断进入HAL_UART_IRQHandler读取一个字节存入缓冲区RxXferCount 减一。当RxXferCount减到 0即接收完成HAL 库执行__HAL_UART_DISABLE_IT(huart, UART_IT_RXNE)关闭接收中断然后调用回调函数。关闭中断这一步是自动完成的不会因为你在回调里读取了数据就重新打开。所以如果你在回调函数里没有重新调用HAL_UART_Receive_ITRXNE 中断就一直处于关闭状态之后再来的数据只会置位 RXNE 标志但不会触发中断。你的程序就“死”在第一次接收完成了。4.2 三个高频问题定位方法第一个常见现象第一帧数据能正常接收第二帧开始丢失。检查回调函数里是否有耗时操作——如果回调里做了字符串处理、浮点运算或打印时间过长下一帧数据到达时 RXNE 已置位但中断还未重新打开数据就被覆盖了。第二个高频问题是数据乱码。先排查波特率用示波器量 TX 引脚的波形测量一位的时间宽度和理论值对比。115200 波特率下一位约 8.68 微秒如果实测偏差超过 3%检查时钟配置。F1 系列在SystemClock_Config中如果 HSE 起振失败会自动切换到 HSI此时系统时钟从 72MHz 掉到 8MHz波特率会严重偏移串口输出全是乱码。建议在初始化后读取RCC_GetFlagStatus(RCC_FLAG_HSERDY)确认 HSE 状态。第三个现象是中断一直进但回调里收到的数据是 0x00 或 0xFF。这往往是 RX 引脚悬空导致的。UART 空闲时 RX 线应保持高电平如果外部设备没有共地RX 引脚电平不确定会产生大量噪声帧。此时应该检查硬件连接而不是改代码。4.3 常见的错误回调函数写法/* 错误写法 1在回调里调用 HAL_UART_Receive 阻塞接收 */ void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { HAL_UART_Receive(huart2, buffer, len, 1000); // 阻塞等待但是中断已经关了 } /* 错误写法 2回调里做浮点和打印 */ void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { float temp (float)rx_data / 100.0f; // 浮点运算在中断里开销极大 printf(Temp: %.2f\n, temp); // printf 重定向后可能触发另一个中断 }第一种写法的问题在于HAL_UART_Receive是阻塞轮询模式它依赖标志位RXNE去判断数据是否到达但此时接收中断已经被 HAL 库关闭如果后续数据没有及时到来这个函数会一直阻塞到超时。看起来像是程序卡死了。第二种写法的风险在printf——如果启用半主机模式printf会触发调试相关的异常在中断上下文里不得使用。4.4 验证中断链路是否畅通的调试手段在回调函数入口处翻转一个 GPIO用示波器看波形void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { HAL_GPIO_TogglePin(GPIOC, GPIO_PIN_13); // 板载 LED 引脚 HAL_UART_Receive_IT(huart2, aRxBuffer, 1); }如果 LED 在每收到一个字节时翻转一次说明中断链路正常。如果 LED 只翻转一次就静止说明第二次HAL_UART_Receive_IT没有被正确执行——要么是huart2句柄不对要么是huart1在中断里被修改。用这个手段可以快速把问题定位到“硬件没数据”还是“软件没预约”。5. 从固定字节到任意长度空闲中断实现 UART2 不定长接收5.1 为什么需要空闲中断IDLE固定长度接收只能应对“每帧字节数相同”的场景比如传感器按固定协议上报数据。但实际项目里大量遇到的是帧长不固定通过帧头帧尾或超时判定一帧结束。HAL 库没有直接提供“不定长接收”的 API常见做法有两种第一种使用HAL_UARTEx_ReceiveToIdle_IT这是 HAL 库 V1.12 以后版本新增的接口底层使用 IDLE 中断——当总线上出现一个字节时间的空闲时触发。这个方法的优势在于不需要外部定时器辅助判断帧结束时间能精确捕捉到“对方停顿”的时刻。第二种是使用HAL_UART_Receive_IT逐字节接收配合一个定时器实现超时判定。每收到一个字节就重置定时器定时器溢出说明帧结束。这个方案兼容性最好但消耗一个定时器资源。推荐使用第一种方式。5.2 基于 IDLE 中断的接收代码实现CubeMX 里需要额外开启USART2 global interrupt之外的空闲中断。打开生成的stm32f1xx_it.c在USART2_IRQHandler中增加 IDLE 判断void USART2_IRQHandler(void) { if (__HAL_UART_GET_FLAG(huart2, UART_FLAG_IDLE) ! RESET) { __HAL_UART_CLEAR_IDLEFLAG(huart2); // 必须先清标志否则会反复进入 HAL_UARTEx_RxEventCallback(huart2, rx_buffer, rx_len); } HAL_UART_IRQHandler(huart2); }在初始化和回调中配合使用uint8_t rx_buffer[256]; uint16_t rx_len 0; /* 主循环初始化时调用一次 */ HAL_UARTEx_ReceiveToIdle_IT(huart2, rx_buffer, sizeof(rx_buffer)); /* 事件回调 */ void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) { if (huart-Instance USART2) { rx_len Size; process_frame(rx_buffer, rx_len); HAL_UARTEx_ReceiveToIdle_IT(huart2, rx_buffer, sizeof(rx_buffer)); } }HAL_UARTEx_ReceiveToIdle_IT的第一个参数是句柄第二个是缓冲区指针第三个是缓冲区大小。它的行为和HAL_UART_Receive_IT不同不是“收到指定字节数”就结束而是“要么收到缓冲区满要么出现空闲事件”。回调函数里 Size 参数是实际收到的字节数这是回调函数参数表里多出来的内容。5.2.1 空闲间隔与波特率的换算关系IDLE 事件检测的是“一个字节宽度的时间内没有新数据”。在 115200 波特率、8N1 格式下一帧空闲时间约 86.8 微秒。如果发送方在帧中间有大于这个间隔的停顿接收方会把一帧误拆成两帧。此时需要通过帧头帧尾校验来丢弃不完整帧或者在发送端保证连续发送。如果发送端是两个字节之间插入间隔式发送的设计建议把缓冲区调小让“整包超时”替代“字节级空闲”。例如缓冲区大小设为 32超过 32 字节未满时会主动触发一次回调防止数据堆积。5.3 同步与互斥中断接收和主循环处理的并发问题当回调里把数据交给process_frame处理时实际上是一个生产者-消费者模型中断是生产者主循环是消费者。缓冲区只有一份主循环在处理期间新的数据又在写入这就会造成数据覆盖。一个稳妥的双缓冲方案是定义两组缓冲区中断写 A 时主循环读 B中断写 B 时主循环读 Auint8_t rx_buf_a[128]; uint8_t rx_buf_b[128]; uint8_t *current_buf rx_buf_a; uint8_t *process_buf rx_buf_b; void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) { /* 交换缓冲区 */ process_buf current_buf; current_buf (current_buf rx_buf_a) ? rx_buf_b : rx_buf_a; HAL_UARTEx_ReceiveToIdle_IT(huart2, current_buf, sizeof(rx_buf_a)); /* 通知主循环处理 process_buf 中的 Size 字节 */ }这个技巧的核心价值在于中断永远只写current_buf而主循环处理的是上一轮的process_buf两者指向不同的内存区域天然避免了互斥问题。代价是内存占用翻倍但对于 128 字节的缓冲区这在绝大多数 MCU 上都是可接受的。5.4 中断发送的坑与 HAL_UART_Transmit_IT 的正确使用发送侧同样不建议在中断回调里直接调用阻塞式HAL_UART_Transmit。正确做法是用HAL_UART_Transmit_IT关联一个HAL_UART_TxCpltCallbackuint8_t tx_buffer[64]; uint8_t tx_ready 1; void send_data(uint8_t *data, uint8_t len) { while (!tx_ready); // 等上一次发送完成 memcpy(tx_buffer, data, len); tx_ready 0; HAL_UART_Transmit_IT(huart2, tx_buffer, len); } void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART2) { tx_ready 1; } }这个方法把发送缓冲区复制到专用数组后再启动中断发送避免调用方传入的指针在被发送中途失效。tx_ready标志保证了不会出现前一次发送未完成就启动下一次发送的情况——HAL 库在同一时刻只允许一个中断发送任务。5.5 430 字节长帧的 UART2 中断接收优化当帧长超过 256 字节时HAL 库的默认缓冲区大小不够用。有两种扩展思路。第一种直接把缓冲区数组定义为大数组比如uint8_t rx_buffer[1024]同时修改HAL_UARTEx_ReceiveToIdle_IT的第二个参数长度。第二种做法是改用 DMA 空闲中断的组合这一步涉及 DMA 通道配置UART2 在 F1 系列上对应的 DMA 通道为 DMA1_Channel6TX和 DMA1_Channel7RX。DMA 方案的核心代码在于初始化时使用HAL_UART_Receive_DMA开启 DMA 接收然后在 DMA 传输完成或空闲中断时读取剩余计数。这种方式适合大数据量的通信场景比如固件升级和文件传输。如果只是普通指令交互中断方式已经足够。5.6 判断总线上是否真的有数据逻辑分析仪的辅助验证调试串口问题时串口调试助手是最直接的工具。连接好 USB 转 TTL 模块注意 RX 接 TX、TX 接 RX、共地打开串口助手软件波特率选 115200数据位 8停止位 1无校验。如果串口助手里能看到数据但单板上的程序收不到使用逻辑分析仪挂 RX 引脚抓波形对比帧格式是否正确。有一种隐蔽问题CH340 驱动在 Windows 下默认不开启“刷新频率”选项会导致高速数据丢失。通用排查顺序是先确认驱动版本再确认串口号映射然后用逻辑分析仪看电平波形最后才考虑程序问题。本文还有配套的精品资源点击获取
STM32 HAL库UART2中断接收全解析：从回调机制到空闲中断
简介基于STM32F103的HAL库UART2中断收发完整工程包面向需要借助STM32CubeMX与HAL库实现串口通信的嵌入式工程师与学生。工程内以STM32CubeMX生成的.ioc配置为核心包含339个C源码、108个头文件及43个汇编文件并附有IAR链接脚本.icf与Keil工程文件压缩包共528个文件大小约12.82MB可直接打开工程编译调试。针对实时性要求较高的串口通信场景代码清晰演示了HAL_UART_Transmit_IT与HAL_UART_Receive_IT的中断收发启动流程以及TxCpltCallback、RxCpltCallback回调函数的处理逻辑同时覆盖中断优先级、FIFO、错误处理等设计要点有助于读者掌握UART2中断机制并快速移植到自身项目。目前已有538人学习下载可作为串口模块的开发模板与排错参考。1. 为什么 UART2 中断收发会成为 HAL 库开发的第一道坎很多从标准外设库转到 STM32 HAL 库的工程师第一次写串口中断收发时都会碰壁代码明明照着例程敲的发送正常可接收就是只进一次中断之后再也不动了。问题不在芯片而在对 HAL 库中断机制的理解上——HAL 库用回调函数把中断处理“包了一层”如果你不了解HAL_UART_RxCpltCallback的触发条件和生命周期很容易把它当成普通中断服务函数来用。HAL 库的 UART 中断收发本质上是“中断使能 回调分发”的封装模式硬件中断触发后HAL 库先做状态清理和标志位处理再调用用户编写的回调函数。而回调函数里如果没有重新开启下一次接收中断链就会断掉。这种设计让代码更安全但也要求开发者转变思维每一帧数据的接收都需要主动“预约”。本文围绕 UART2 讲透这条链路从 CubeMX 初始化到中断回调的完整实现再到不定长数据接收的进阶方案。新手能照着搭通最小工程老手也能在中断优先级、临界区保护和 DMA 协同这些边界参数上找到值得推敲的细节。2. 深入 HAL 库 UART 中断机制接收“一次性”背后的设计逻辑2.1 中断收发在 HAL 库中的完整链路HAL 库的 UART 中断收发由两个层面配合完成。硬件层面UART 外设检测到 RXNE接收数据寄存器非空或 TXE发送数据寄存器空事件后触发对应的中断向量。HAL 库则将中断向量统一导向UART_IRQHandler由它调用HAL_UART_IRQHandler这个公共入口函数。HAL_UART_IRQHandler内部做了大量工作判断中断类型、清除标志位、校验传输状态、更新huart-RxXferCount等计数变量。当一帧数据接收完成收到指定字节数后它会调用HAL_UART_RxCpltCallback。这个回调函数运行在中断上下文所以执行时间必须短不能做耗时操作。接收“只跑一次”的根因就在这儿——HAL_UART_Receive_IT函数本质上只是“预约一次接收”它设置好接收缓冲区指针和期望字节数然后使能接收中断。当接收完成后中断被关闭回调函数被调用。如果你想继续接收下一帧就必须在回调函数里重新调用HAL_UART_Receive_IT。2.2 中断方式与轮询、DMA 的边界划分传输方式适用场景CPU 占用实时性实现难度轮询Blocking短帧、低频、非实时高阻塞等待差低中断IT中短帧、事件驱动低仅在收发时打断良好中DMA长帧、高频、批量传输极低取决于 DMA 配置较高选择中断方式的前提是单次收发帧长不过长通常不超过 256 字节且接收频率可控。如果一秒钟要接收上千帧短数据中断方式会导致 CPU 频繁进出中断此时 DMA 更合适。但中断方式的优势在于——每次收发完成都有回调通知逻辑上更容易做成“一帧一处理”适合协议解析类的应用。2.3 宏定义与配置参数对中断行为的影响cubeMX 生成的代码里stm32f1xx_hal_conf.h中有几个关键宏#define HAL_UART_MODULE_ENABLED #define HAL_UART_IT_ENABLEDHAL_UART_IT_ENABLED必须开启否则.c文件里的中断处理函数会被条件编译排除。这个宏对应的是 UART 全局中断在NVIC中的使能状态CubeMX 勾选USART2 global interrupt后会自动生成。手动移植代码时最容易漏掉这一点导致HAL_UART_IRQHandler根本不会被调用。另一个需要确认的是huart-Init.Parity参数。如果使能了奇偶校验HAL 库接收的数据长度会是数据位 校验位这意味着你配置了 8 位数据加偶校验实际每一帧会占用 9 位硬件存储空间。很多人接收数据总是差一位或乱码排查半天发现是这里没对齐。3. UART2 初始化全程实录从 CubeMX 到最小中断工程3.1 CubeMX 中 UART2 的关键配置项打开 STM32CubeMX选择芯片型号后在Connectivity分类下找到USART2。这里重点设置四个参数Mode选择Asynchronous同时开启收发引脚映射Baud Rate按实际需求填写9600、115200、460800 是常见档位Word Length选择8 Bits多数传感器和协议默认 8 位NVIC Settings标签页勾选USART2 global interrupt波特率的选择直接影响通信稳定性。115200 是绝大多数场景的安全选项。如果使用更高的 460800要求双方时钟误差在 2% 以内HSE 晶振的频率偏差和 PLL 配置误差会被放大。CubeMX 会自动计算 USARTDIV 分频系数生成后可以打开stm32f1xx_hal_uart.c查看huart2.Init.BaudRate的实际值确保和设计值一致。引脚映射需要根据芯片封装确认STM32F103C8T6 的 UART2 默认在 PA2TX和 PA3RX。如果引脚冲突比如同时用作 SPI 或 I2CCubeMX 会用黄色警告标出此时可以尝试复用功能重映射到 PB10/PB11但这需要额外开启AFIO时钟。3.2 初始化代码的 HAL 层解读生成工程后MX_USART2_UART_Init函数会放在main.c中void MX_USART2_UART_Init(void) { huart2.Instance USART2; huart2.Init.BaudRate 115200; huart2.Init.WordLength UART_WORDLENGTH_8B; huart2.Init.StopBits UART_STOPBITS_1; huart2.Init.Parity UART_PARITY_NONE; huart2.Init.Mode UART_MODE_TX_RX; huart2.Init.HwFlowCtl UART_HWCONTROL_NONE; huart2.Init.OverSampling UART_OVERSAMPLING_16; if (HAL_UART_Init(huart2) ! HAL_OK) { Error_Handler(); } }OverSampling这个参数容易被忽略。默认OVERSAMPLING_16表示每个数据位采样 16 次抗干扰能力强OVERSAMPLING_8可以提升到更高波特率但对信号质量要求更高。低速场景保持 16 倍过采样即可。HAL_UART_Init内部还会调用HAL_UART_MspInit这个函数是 CubeMX 自动生成的完成时钟使能和 GPIO 配置。它通常在stm32f1xx_hal_msp.c文件中需要检查 GPIO 的Alternate是否设置为GPIO_AF7_USART2F1 系列是GPIO_AF_USART2。如果这里配置成普通推挽输出TX 引脚就发不出数据。3.3 最小中断收发代码框架/* 定义接收缓冲区和发送缓冲区 */ uint8_t aRxBuffer[1]; uint8_t aTxBuffer[] UART2 Ready\n; int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_USART2_UART_Init(); /* 预约第一次接收监听 1 字节 */ HAL_UART_Receive_IT(huart2, aRxBuffer, 1); /* 发送测试字符串 */ HAL_UART_Transmit(huart2, aTxBuffer, strlen((char*)aTxBuffer), 1000); while (1) { /* 主循环不做串口处理 */ } } /* 接收完成回调每收到 1 字节进入一次 */ void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART2) { /* 把收到的字节回传形成回环 */ HAL_UART_Transmit(huart2, aRxBuffer, 1, 100); /* 重新预约下一次接收 */ HAL_UART_Receive_IT(huart2, aRxBuffer, 1); } }HAL_UART_Receive_IT(huart2, aRxBuffer, 1)表示“期望接收 1 个字节存入 aRxBuffer”。注意第一个参数传的是huart2而不是USART2因为 HAL 库需要整个句柄来记录状态。第三个参数是接收长度设置为 1 意味着每来一个字节就会触发一次回调适合逐字节处理。这个代码的神奇之处在于主循环里什么都不用管接收和发送全由中断驱动。发送部分HAL_UART_Transmit虽然是阻塞模式但在回调里延时极短1 字节在 115200 波特率下约 87 微秒不会造成明显阻塞。如果发送长帧建议改为HAL_UART_Transmit_IT否则回调函数会卡在等待发送完成的循环里导致后续中断堆积。3.4 中断优先级配置与回调执行时长的权衡HAL_NVIC_SetPriority(USART2_IRQn, 0, 0)这个参数直接影响系统实时性。CubeMX 默认生成的优先级是0,0最高但如果系统里还有定时器中断或外部中断不建议把所有中断都设为最高优先级。在 F1 系列中NVIC_PriorityGroup_4意味着 4 位全用于抢占优先级没有子优先级。此时 USART2 设置为 1 或 2 更合理。如果设置成最高优先级而回调函数里又调用了HAL_Delay这类依赖于 Systick 中断的函数就会造成死锁——高优先级打断了 Systick而HAL_Delay在等 Systick 计满。回调函数的最佳实践是只做数据搬运和标志位设置把真正的处理逻辑放回主循环。volatile uint8_t uart2_rx_flag 0; void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART2) { uart2_rx_flag 1; HAL_UART_Receive_IT(huart2, aRxBuffer, 1); } } int main(void) { /* ... 初始化省略 ... */ while (1) { if (uart2_rx_flag) { uart2_rx_flag 0; /* 这里处理接收到的数据 */ process_byte(aRxBuffer[0]); } } }volatile关键字在这里必不可少——它告诉编译器这个变量可能被中断修改禁止优化到寄存器中。如果不加主循环可能永远读不到更新后的值这是嵌入式开发最常见的“灵异现象”之一。4. 中断接收“只收一次”的根因与多场景排错指南4.1 为什么必须重新调用 HAL_UART_Receive_ITHAL 库 UART 中断接收的本质是“单次请求模式”。回顾HAL_UART_Receive_IT的源码逻辑它把huart-RxState置为HAL_UART_STATE_BUSY_RX使能 RXNE 中断然后注册回调。当 RXNE 置位中断进入HAL_UART_IRQHandler读取一个字节存入缓冲区RxXferCount 减一。当RxXferCount减到 0即接收完成HAL 库执行__HAL_UART_DISABLE_IT(huart, UART_IT_RXNE)关闭接收中断然后调用回调函数。关闭中断这一步是自动完成的不会因为你在回调里读取了数据就重新打开。所以如果你在回调函数里没有重新调用HAL_UART_Receive_ITRXNE 中断就一直处于关闭状态之后再来的数据只会置位 RXNE 标志但不会触发中断。你的程序就“死”在第一次接收完成了。4.2 三个高频问题定位方法第一个常见现象第一帧数据能正常接收第二帧开始丢失。检查回调函数里是否有耗时操作——如果回调里做了字符串处理、浮点运算或打印时间过长下一帧数据到达时 RXNE 已置位但中断还未重新打开数据就被覆盖了。第二个高频问题是数据乱码。先排查波特率用示波器量 TX 引脚的波形测量一位的时间宽度和理论值对比。115200 波特率下一位约 8.68 微秒如果实测偏差超过 3%检查时钟配置。F1 系列在SystemClock_Config中如果 HSE 起振失败会自动切换到 HSI此时系统时钟从 72MHz 掉到 8MHz波特率会严重偏移串口输出全是乱码。建议在初始化后读取RCC_GetFlagStatus(RCC_FLAG_HSERDY)确认 HSE 状态。第三个现象是中断一直进但回调里收到的数据是 0x00 或 0xFF。这往往是 RX 引脚悬空导致的。UART 空闲时 RX 线应保持高电平如果外部设备没有共地RX 引脚电平不确定会产生大量噪声帧。此时应该检查硬件连接而不是改代码。4.3 常见的错误回调函数写法/* 错误写法 1在回调里调用 HAL_UART_Receive 阻塞接收 */ void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { HAL_UART_Receive(huart2, buffer, len, 1000); // 阻塞等待但是中断已经关了 } /* 错误写法 2回调里做浮点和打印 */ void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { float temp (float)rx_data / 100.0f; // 浮点运算在中断里开销极大 printf(Temp: %.2f\n, temp); // printf 重定向后可能触发另一个中断 }第一种写法的问题在于HAL_UART_Receive是阻塞轮询模式它依赖标志位RXNE去判断数据是否到达但此时接收中断已经被 HAL 库关闭如果后续数据没有及时到来这个函数会一直阻塞到超时。看起来像是程序卡死了。第二种写法的风险在printf——如果启用半主机模式printf会触发调试相关的异常在中断上下文里不得使用。4.4 验证中断链路是否畅通的调试手段在回调函数入口处翻转一个 GPIO用示波器看波形void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { HAL_GPIO_TogglePin(GPIOC, GPIO_PIN_13); // 板载 LED 引脚 HAL_UART_Receive_IT(huart2, aRxBuffer, 1); }如果 LED 在每收到一个字节时翻转一次说明中断链路正常。如果 LED 只翻转一次就静止说明第二次HAL_UART_Receive_IT没有被正确执行——要么是huart2句柄不对要么是huart1在中断里被修改。用这个手段可以快速把问题定位到“硬件没数据”还是“软件没预约”。5. 从固定字节到任意长度空闲中断实现 UART2 不定长接收5.1 为什么需要空闲中断IDLE固定长度接收只能应对“每帧字节数相同”的场景比如传感器按固定协议上报数据。但实际项目里大量遇到的是帧长不固定通过帧头帧尾或超时判定一帧结束。HAL 库没有直接提供“不定长接收”的 API常见做法有两种第一种使用HAL_UARTEx_ReceiveToIdle_IT这是 HAL 库 V1.12 以后版本新增的接口底层使用 IDLE 中断——当总线上出现一个字节时间的空闲时触发。这个方法的优势在于不需要外部定时器辅助判断帧结束时间能精确捕捉到“对方停顿”的时刻。第二种是使用HAL_UART_Receive_IT逐字节接收配合一个定时器实现超时判定。每收到一个字节就重置定时器定时器溢出说明帧结束。这个方案兼容性最好但消耗一个定时器资源。推荐使用第一种方式。5.2 基于 IDLE 中断的接收代码实现CubeMX 里需要额外开启USART2 global interrupt之外的空闲中断。打开生成的stm32f1xx_it.c在USART2_IRQHandler中增加 IDLE 判断void USART2_IRQHandler(void) { if (__HAL_UART_GET_FLAG(huart2, UART_FLAG_IDLE) ! RESET) { __HAL_UART_CLEAR_IDLEFLAG(huart2); // 必须先清标志否则会反复进入 HAL_UARTEx_RxEventCallback(huart2, rx_buffer, rx_len); } HAL_UART_IRQHandler(huart2); }在初始化和回调中配合使用uint8_t rx_buffer[256]; uint16_t rx_len 0; /* 主循环初始化时调用一次 */ HAL_UARTEx_ReceiveToIdle_IT(huart2, rx_buffer, sizeof(rx_buffer)); /* 事件回调 */ void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) { if (huart-Instance USART2) { rx_len Size; process_frame(rx_buffer, rx_len); HAL_UARTEx_ReceiveToIdle_IT(huart2, rx_buffer, sizeof(rx_buffer)); } }HAL_UARTEx_ReceiveToIdle_IT的第一个参数是句柄第二个是缓冲区指针第三个是缓冲区大小。它的行为和HAL_UART_Receive_IT不同不是“收到指定字节数”就结束而是“要么收到缓冲区满要么出现空闲事件”。回调函数里 Size 参数是实际收到的字节数这是回调函数参数表里多出来的内容。5.2.1 空闲间隔与波特率的换算关系IDLE 事件检测的是“一个字节宽度的时间内没有新数据”。在 115200 波特率、8N1 格式下一帧空闲时间约 86.8 微秒。如果发送方在帧中间有大于这个间隔的停顿接收方会把一帧误拆成两帧。此时需要通过帧头帧尾校验来丢弃不完整帧或者在发送端保证连续发送。如果发送端是两个字节之间插入间隔式发送的设计建议把缓冲区调小让“整包超时”替代“字节级空闲”。例如缓冲区大小设为 32超过 32 字节未满时会主动触发一次回调防止数据堆积。5.3 同步与互斥中断接收和主循环处理的并发问题当回调里把数据交给process_frame处理时实际上是一个生产者-消费者模型中断是生产者主循环是消费者。缓冲区只有一份主循环在处理期间新的数据又在写入这就会造成数据覆盖。一个稳妥的双缓冲方案是定义两组缓冲区中断写 A 时主循环读 B中断写 B 时主循环读 Auint8_t rx_buf_a[128]; uint8_t rx_buf_b[128]; uint8_t *current_buf rx_buf_a; uint8_t *process_buf rx_buf_b; void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) { /* 交换缓冲区 */ process_buf current_buf; current_buf (current_buf rx_buf_a) ? rx_buf_b : rx_buf_a; HAL_UARTEx_ReceiveToIdle_IT(huart2, current_buf, sizeof(rx_buf_a)); /* 通知主循环处理 process_buf 中的 Size 字节 */ }这个技巧的核心价值在于中断永远只写current_buf而主循环处理的是上一轮的process_buf两者指向不同的内存区域天然避免了互斥问题。代价是内存占用翻倍但对于 128 字节的缓冲区这在绝大多数 MCU 上都是可接受的。5.4 中断发送的坑与 HAL_UART_Transmit_IT 的正确使用发送侧同样不建议在中断回调里直接调用阻塞式HAL_UART_Transmit。正确做法是用HAL_UART_Transmit_IT关联一个HAL_UART_TxCpltCallbackuint8_t tx_buffer[64]; uint8_t tx_ready 1; void send_data(uint8_t *data, uint8_t len) { while (!tx_ready); // 等上一次发送完成 memcpy(tx_buffer, data, len); tx_ready 0; HAL_UART_Transmit_IT(huart2, tx_buffer, len); } void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART2) { tx_ready 1; } }这个方法把发送缓冲区复制到专用数组后再启动中断发送避免调用方传入的指针在被发送中途失效。tx_ready标志保证了不会出现前一次发送未完成就启动下一次发送的情况——HAL 库在同一时刻只允许一个中断发送任务。5.5 430 字节长帧的 UART2 中断接收优化当帧长超过 256 字节时HAL 库的默认缓冲区大小不够用。有两种扩展思路。第一种直接把缓冲区数组定义为大数组比如uint8_t rx_buffer[1024]同时修改HAL_UARTEx_ReceiveToIdle_IT的第二个参数长度。第二种做法是改用 DMA 空闲中断的组合这一步涉及 DMA 通道配置UART2 在 F1 系列上对应的 DMA 通道为 DMA1_Channel6TX和 DMA1_Channel7RX。DMA 方案的核心代码在于初始化时使用HAL_UART_Receive_DMA开启 DMA 接收然后在 DMA 传输完成或空闲中断时读取剩余计数。这种方式适合大数据量的通信场景比如固件升级和文件传输。如果只是普通指令交互中断方式已经足够。5.6 判断总线上是否真的有数据逻辑分析仪的辅助验证调试串口问题时串口调试助手是最直接的工具。连接好 USB 转 TTL 模块注意 RX 接 TX、TX 接 RX、共地打开串口助手软件波特率选 115200数据位 8停止位 1无校验。如果串口助手里能看到数据但单板上的程序收不到使用逻辑分析仪挂 RX 引脚抓波形对比帧格式是否正确。有一种隐蔽问题CH340 驱动在 Windows 下默认不开启“刷新频率”选项会导致高速数据丢失。通用排查顺序是先确认驱动版本再确认串口号映射然后用逻辑分析仪看电平波形最后才考虑程序问题。本文还有配套的精品资源点击获取 
