基于HAL_UART_RxCpltCallback的双串口同步接收方案

用好一个回调函数，让双串口通信不再“丢包”——HAL库下高效接收实战

你有没有遇到过这样的场景：STM32一边通过串口1跟上位机通信，一边通过串口2读传感器数据。结果主循环里一加个delay()或者处理点复杂逻辑，串口2的数据就丢了？查了半天发现是缓冲区溢出了——RXNE标志没及时清，硬件把新字节覆盖了旧的。

这在传统轮询方式中几乎是无解的痛点。而真正能破局的，其实就藏在你工程里每天调用却未必深究的那个函数：HAL_UART_RxCpltCallback。

今天我们就来拆解如何利用这个看似简单的回调函数，构建一套稳定、高效、可扩展的双串口同步接收系统。不是理论堆砌，而是从实际问题出发，一步步带你写出工业级可用的代码。

为什么轮询不行？中断才是出路

先说清楚一个问题：什么叫“同步接收”？

它不是指两个串口在同一纳秒收到数据，而是说——无论哪个口先来数据，都能被完整捕获，彼此不干扰，也不因对方忙而漏收。这才是嵌入式系统真正需要的“软同步”。

如果你还在用下面这种方式收数据：

while (1) { if (__HAL_UART_GET_FLAG(&huart1, UART_FLAG_RXNE)) { rx_buf[rx_len++] = huart1.Instance->RDR; // ...处理逻辑 } }

那你已经把自己放在了“数据丢失”的悬崖边上。CPU只要稍微去干点别的事（比如算个PID、刷个屏幕），串口引脚上的字节就会像雨点一样打进来，但没人接——直到缓冲区满，最后几个字节把前面的努力全冲掉。

解决办法只有一个：让硬件主动叫你。这就是中断的意义。

HAL_UART_RxCpltCallback 到底是谁触发的？

很多人知道要重写这个函数，但不清楚它背后的完整链条。我们来捋一遍真实执行流：

1. 你调用HAL_UART_Receive_IT(&huart1, buf, 64);
2. HAL 库开启 USART1 的接收中断（RXNEIE 置位）
3. 每当一个字节到达，UART 硬件拉高中断线 → NVIC 跳转到USART1_IRQHandler()
4. 这个 ISR 函数又会调用通用处理函数HAL_UART_IRQHandler(&huart1)
5. 在这里，HAL 逐字节搬运数据到你的缓冲区
6. 当第64个字节收完，自动调用HAL_UART_RxCpltCallback(&huart1)

关键点来了：这个回调只在“成功接收指定长度”后才触发。也就是说，它是“帧完成事件”，而不是“每字节事件”。这对协议设计非常友好——比如你每次想收一包64字节的配置命令，正好用它做分界。

但也正因如此，你必须记住一件事：

🔁每次回调结束后，必须重新调用HAL_UART_Receive_IT()，否则再无后续！

否则就像开了扇门让人进屋，人进来后你把钥匙扔了，下一波人只能敲窗。

双串口怎么共用一个回调？靠的是句柄判别

STM32 的多个 UART 外设都会走同一个回调入口。那怎么知道当前是谁在说话？答案就在传入的参数里：

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)

这个huart指针指向不同的实例。你可以这样区分：

if (huart == &huart1) { // 是串口1完成了接收 } else if (huart == &huart2) { // 是串口2 }

也可以比对寄存器基地址：

if (huart->Instance == USART1) { ... }

两者等价，但比较指针更快更安全（避免宏定义冲突）。

于是我们可以写出最核心的框架：

#define RX_BUFFER_SIZE 64 uint8_t uart1_rx_buf[RX_BUFFER_SIZE]; uint8_t uart2_rx_buf[RX_BUFFER_SIZE]; void StartDualUartReception(void) { HAL_UART_Receive_IT(&huart1, uart1_rx_buf, RX_BUFFER_SIZE); HAL_UART_Receive_IT(&huart2, uart2_rx_buf, RX_BUFFER_SIZE); } void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart == &huart1) { ProcessReceivedFrame(uart1_rx_buf, RX_BUFFER_SIZE); // 处理数据 HAL_UART_Receive_IT(huart, uart1_rx_buf, RX_BUFFER_SIZE); // 重启 } else if (huart == &huart2) { ProcessReceivedFrame(uart2_rx_buf, RX_BUFFER_SIZE); HAL_UART_Receive_IT(huart, uart2_rx_buf, RX_BUFFER_SIZE); } }

就这么简单？没错。但这只是起点。真正决定系统健壮性的，是你对以下几个细节的把握。

回调里能做什么？不能做什么？

这是最容易踩坑的地方。

❌ 错误做法：在回调里长时间处理

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart == &huart1) { // 千万别在这里做这些： HAL_Delay(100); // 阻塞整个系统 printf("Received: %s\n", buf); // 调用半主机或重定向输出 slow_algorithm_analysis(buf); // 复杂计算 } }

中断上下文应尽可能快地退出。上述操作会导致其他中断被延迟响应，严重时可能造成另一路串口丢帧。

✅ 正确姿势：发信号，交由任务处理

尤其是在使用 FreeRTOS 的项目中，最佳实践是：回调只负责“通知”和“重启”。

// 假设已创建两个二值信号量 extern SemaphoreHandle_t xUart1RxDone; extern SemaphoreHandle_t xUart2RxDone; void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { BaseType_t xHigherPriorityTaskWoken = pdFALSE; if (huart == &huart1) { xSemaphoreGiveFromISR(xUart1RxDone, &xHigherPriorityTaskWoken); HAL_UART_Receive_IT(huart, uart1_rx_buf, RX_BUFFER_SIZE); } else if (huart == &huart2) { xSemaphoreGiveFromISR(xUart2RxDone, &xHigherPriorityTaskWoken); HAL_UART_Receive_IT(huart, uart2_rx_buf, RX_BUFFER_SIZE); } portYIELD_FROM_ISR(xHigherPriorityTaskWoken); }

然后在独立任务中等待信号量：

void Uart1ProcessingTask(void *pvParameters) { while (1) { if (xSemaphoreTake(xUart1RxDone, portMAX_DELAY) == pdTRUE) { ProcessUart1Data(uart1_rx_buf, RX_BUFFER_SIZE); // 可以慢一点 } } }

这样一来，中断迅速返回，处理逻辑在任务上下文中安全运行，系统整体响应性和稳定性大幅提升。

如何应对不定长帧？IDLE 中断了解一下

上面的例子假设每帧固定64字节。但如果对方发的是 Modbus RTU 帧呢？长度可变，怎么办？

这时候你需要启用另一个利器：空闲线检测（IDLE Line Detection）。

原理很简单：当串口总线上连续一段时间没有新数据到来（即处于“空闲”状态），硬件会产生 IDLE 标志，触发中断。这时你就可以认为“一帧结束了”。

配合 DMA 使用效果更佳，但即使不用 DMA，也能通过中断+定时器模拟实现。

不过对于本方案而言，如果不想引入 DMA，仍可通过以下策略折中：

• 设定最大帧长（如256字节），用HAL_UART_Receive_IT()启动接收；
• 收到回调后，在处理函数中解析实际有效数据长度；
• 若需实时性极高，则监听 IDLE 中断并自行管理缓冲区。

这部分内容较深，后续可单独开篇详解。当前方案更适合定长或最大长度明确的协议。

实战技巧：这些细节决定成败

1. 缓冲区大小怎么定？

不要拍脑袋写64或128。问问自己：
- 对端设备一次最多发多少字节？
- 波特率多高？两个字节间隔多久？
- 我的主循环最长阻塞时间是多少？

举个例子：波特率115200，约11.5kB/s。若主循环最长停顿50ms，则理论上最多积压 576 字节。所以缓冲区至少得大于这个值，建议取2倍余量——即设置为1024字节。

当然，RAM有限的话可以用环形缓冲优化。

2. 两路串口优先级怎么设？

如果一路是紧急控制指令（如急停信号），另一路是普通日志上报，显然前者应该优先响应。

在 STM32CubeMX 中设置 NVIC 优先级即可：

HAL_NVIC_SetPriority(USART1_IRQn, 0, 0); // 主控通道，高优先级 HAL_NVIC_SetPriority(USART2_IRQn, 2, 0); // 辅助通道，低优先级

数值越小，优先级越高。

3. 怎么防止重启失败？

有时你会发现某次接收之后再也进不了回调。排查方向通常是：

• 是否在错误处理中遗漏了重启？
• 是否发生了帧错误（Framing Error）导致中断挂起？

务必实现错误回调：

void HAL_UART_ErrorCallback(UART_HandleTypeDef *huart) { if (huart == &huart1) { __HAL_UART_CLEAR_FLAG(&huart1, UART_CLEAR_OREF | UART_CLEAR_NEF | UART_CLEAR_FEF); HAL_UART_Receive_IT(&huart1, uart1_rx_buf, RX_BUFFER_SIZE); // 出错也要重启 } }

清除溢出、噪声、帧错误标志，并立即重启接收，避免死锁。

工程化建议：封装成模块，复用无忧

别每次都复制粘贴。把这个机制封装成一个通用模块：

typedef struct { UART_HandleTypeDef *huart; uint8_t *buffer; uint16_t size; void (*on_receive)(uint8_t*, uint16_t); } UartRxChannel; static UartRxChannel channels[2]; // 支持两路 void UartRxChannel_Start(UartRxChannel *ch) { HAL_UART_Receive_IT(ch->huart, ch->buffer, ch->size); } void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { for (int i = 0; i < 2; i++) { if (channels[i].huart == huart) { channels[i].on_receive(channels[i].buffer, channels[i].size); UartRxChannel_Start(&channels[i]); // 自动重启 break; } } }

初始化时注册通道和回调函数，从此新增串口只需添加配置，无需改动底层逻辑。

写在最后：掌握本质，才能灵活应变

HAL_UART_RxCpltCallback看似只是一个回调函数，但它背后体现的是现代嵌入式开发的核心思想：事件驱动 + 异步处理 + 资源解耦。

当你学会把“数据到达”当作一个事件来响应，而不是靠眼睛盯着寄存器轮询，你就迈出了成为高级嵌入式工程师的关键一步。

这套双串口方案已在多个工业项目中验证：
- 某智能网关同时接入 GPS 模块与 LoRa 透传设备；
- 医疗监护仪同步采集心电数据与护士站指令；
- 音频播放终端分离音频流与触控面板通信。

它们共同的特点是：数据源独立、节奏不同、不容丢失。而这套基于回调的机制，正是保障其稳定运行的基石。

如果你也在做类似项目，不妨试试这个模式。也许下次调试时，你会笑着对自己说：“这次，一个字都没丢。”

有问题欢迎留言讨论，我们一起打磨更健壮的通信架构。