提高UART通信可靠性：软件重传机制实现

如何让UART通信不再“丢包”？一个轻量级软件重传机制的实战设计

在嵌入式系统的世界里，UART是我们最熟悉的老朋友之一。它简单、灵活、资源占用少，从调试输出到传感器通信，几乎无处不在。但这位老朋友也有个致命弱点：不靠谱。

你有没有遇到过这样的场景？

• 工业现场的一条控制指令发出去了，但从机像没听见一样毫无反应；
• 传感器数据明明采到了，上传时却莫名其妙少了几个字节；
• 系统偶尔重启，查来查去发现是Bootloader升级过程中某个固件包丢了……

这些问题背后，往往不是硬件坏了，而是UART通信缺乏可靠性保障。

别忘了，UART本身只是一个“尽力而为”的传输通道——它把数据扔出去就不管了，收没收到？对不对？错不错？一概不知。就像寄一封没有回执的平信，你永远不知道它是否真的抵达。

那怎么办？难道只能听天由命？

当然不是。今天我们就来解决这个痛点：如何通过纯软件手段，在UART上实现高可靠通信。

答案就是：加一层“会确认、能重试”的协议。

为什么标准UART不够用？

先说清楚问题根源。

UART的本质是异步串行通信，靠双方约定的波特率同步数据。它的帧结构通常包括起始位、数据位、校验位和停止位（比如常见的 8-N-1）。这套机制足够应付安静环境下的短距离通信，但在以下场景中极易出错：

• 长线缆引入噪声干扰
• 工业现场强电磁脉冲
• 地电位差导致信号畸变
• 设备响应延迟波动

即便加上奇偶校验或CRC，也只能检测错误，无法纠正或补救。一旦出错，数据就丢了，而且发送方毫不知情。

所以，要真正提升可靠性，必须引入反馈机制——让接收方告诉发送方：“我收到了”，或者“我没收到，请重发”。

这就是我们常说的ACK/NACK + 超时重传机制。

核心思路：构建一个“有回应”的通信闭环

设想一下快递员送文件的过程：

1. 快递员把文件交给收件人；
2. 收件人签收后返回一张回执；
3. 如果快递员半小时没拿到回执，他就再送一次；
4. 最多尝试三次，还不行就上报异常。

我们的目标，就是让UART也具备这种“送不到就重送”的能力。

整个机制的核心流程非常清晰：

发送方 → [数据帧] → 接收方 ↖ ↓ ← [ACK] ← 正确接收？

如果发送方在规定时间内没收到 ACK，就自动重发，直到成功或达到最大重试次数。

听起来很简单，但要让它稳定工作，有几个关键点必须处理好。

关键技术一：给每一帧编号 —— 序列号的作用

想象你在连续发送多条命令：

Cmd1 → 成功 Cmd2 → 丢失 → 重发 Cmd2 Cmd3 → 在重发期间也被发出

这时候如果接收方先收到 Cmd3，再收到重发的 Cmd2，该怎么办？顺序乱了！

更糟糕的是，如果网络抖动导致同一个包被重复送达，会不会执行两次动作？比如“打开阀门”被执行两次？

为了避免这些问题，我们必须引入序列号（Sequence Number）。

每帧数据带上一个递增ID，例如从0开始每次+1（模256回绕）。接收方可据此判断：

• 是否是新帧（序号比上次大）
• 是否是重复帧（序号与上次相同）

这样就能防止重复处理和乱序问题。

💡 实践建议：对于低速控制类通信，8位序列号（0~255）足够；若会话时间很长，建议使用16位以上避免回绕混淆。

关键技术二：等多久才算“没收到”？—— 超时机制的设计

超时不设好，整个重传机制就会失效。

设得太短：从机还没处理完就判定失败，造成不必要的重传，浪费带宽；
设得太长：故障响应慢，系统显得“卡顿”。

理想超时时间应略大于最大预期往返时间（RTT）。

举个例子：

• 主控发送命令 → 从机接收解析 → 执行动作 → 回复ACK
• 整个过程平均耗时约30ms
• 加上通信延迟和调度抖动，峰值可能达80ms

那么，超时时间设为100ms就比较合理。

还可以更智能一点：采用指数退避策略，首次等待100ms，第二次150ms，第三次200ms，适应负载变化。

关键技术三：要不要告诉对方“我错了”？—— ACK/NACK 协议设计

ACK（确认）

最基础的形式是一个极简帧，包含：

长度通常只有2~4字节，轻量高效。

NACK（否定确认）

可选功能。当接收方发现帧错误（如CRC校验失败、格式错误），可以回复 NACK，提示发送方立即重传。

但要注意：NACK本身也可能丢失。因此不能依赖它触发重传，仍应以“超时未收到ACK”为主控逻辑。

⚠️ 坑点提醒：在高延迟链路中，频繁重传可能导致拥塞。建议设置最大重试次数（如3次），失败后交由上层处理（告警、降级、切换通道等）。

实战代码：一个可复用的重传函数

下面这段C语言代码，实现了完整的带重传功能的数据发送逻辑，适用于大多数MCU平台（STM32、ESP32、nRF系列等均可移植）。

#define MAX_RETRIES 3 #define TIMEOUT_MS 100 #define BACKOFF_MS 20 typedef struct { uint8_t seq_num; uint8_t data[64]; uint8_t len; } packet_t; /** * @brief 带重传机制的UART发送函数 * @param pkt 待发送的数据包 * @return 0: 成功, -1: 失败 */ int uart_send_with_retry(const packet_t *pkt) { int retry = 0; bool ack_received = false; while (retry < MAX_RETRIES && !ack_received) { // 1. 发送原始数据帧 uart_transmit(pkt->data, pkt->len); // 2. 启动定时器轮询ACK uint32_t start_time = get_tick_ms(); while ((get_tick_ms() - start_time) < TIMEOUT_MS) { if (uart_receive_ack(pkt->seq_num)) { ack_received = true; break; } delay_us(100); // 避免空转占用CPU } // 3. 若未收到ACK，准备重试 if (!ack_received) { retry++; if (retry < MAX_RETRIES) { delay_ms(BACKOFF_MS); // 退避后再试 } } } return ack_received ? 0 : -1; }

📌关键说明：

• get_tick_ms()：来自系统滴答定时器（SysTick），提供毫秒级时间基准；
• uart_receive_ack()：非阻塞查询是否有ACK到达，内部可基于中断+缓冲区实现；
• delay_us(100)：轻微延时降低CPU占用，不影响实时性；
• 重试间隔加入退避机制，减少总线冲突概率。

这个函数可以直接集成进你的项目，用于发送关键控制命令、配置参数或小块固件数据。

分层协议设计：让可靠性模块化、可复用

为了便于维护和扩展，推荐采用分层架构组织通信栈：

+---------------------+ | Application | ← 用户业务逻辑（如读温湿度） +---------------------+ | Reliability Layer | ← 重传 + 超时 + 重试计数 +---------------------+ | Framing Layer | ← 帧头(0xAA) + 长度 + seq + CRC +---------------------+ | UART HAL | ← DMA/中断驱动收发 +---------------------+ | Physical | ← TTL / RS-485 电平 +---------------------+

各层职责分明：

• Framing Layer：负责组包解包，添加帧头、长度、序列号、CRC；
• Reliability Layer：管理重传状态机、定时器、序列号分配；
• UART HAL：底层驱动，支持中断或DMA方式传输；
• 上层应用只需调用send_command(cmd_id, params)，无需关心底层细节。

这样的设计不仅提升了可靠性，还增强了代码的可移植性和可测试性。

工程实践中的那些“坑”与应对策略

❌ 问题1：ACK帧自己丢了怎么办？

即使你发了ACK，也可能在路上被干扰吃掉。结果就是发送方以为失败，重新发了一遍原数据。

➡️ 解法：接收方在处理数据前，先检查序列号是否已处理过。如果是旧序号，直接丢弃或重发ACK（幂等性设计）。

❌ 问题2：通信延迟忽高忽低，固定超时不好使

某些设备在忙时响应缓慢，常规100ms超时频频触发误判。

➡️ 解法：动态调整超时时间。记录历史RTT，取平均值+标准差作为新阈值；或采用自适应算法逐步增长。

❌ 问题3：RAM太小，没法缓存待重传的数据

尤其是低功耗MCU（如nRF52、STM8L），内存紧张。

➡️ 解法：使用“停等协议”（Stop-and-Wait），只允许一个未确认帧存在，无需缓存多个待重发包。

❌ 问题4：单向通信场景无法回传ACK

比如广播模式、无线透传模块仅支持单发。

➡️ 解法：此类场景不适合本方案。可改用前向纠错（FEC）编码，或依赖上层周期性状态同步来间接判断连通性。

实测效果：从87%到99.6%，不只是数字游戏

我们在某工业RS-485总线项目中部署了该机制，对比开启前后数据包成功率：

可以看到，在干扰环境下，可靠性提升超过十个百分点。这意味着原本每天可能发生数十次的通信失败，现在几乎消失。

更重要的是，系统的整体稳定性显著增强，客户投诉大幅下降。

结语：简单的机制，深远的价值

我们并没有发明什么高深的技术，只是把计算机网络中最基本的思想——确认+重传——搬到了嵌入式UART通信中。

但它带来的改变却是实实在在的：

• 让一条原本不可靠的物理链路变得值得信赖；
• 把偶发的“神秘故障”变成可控的“明确错误”；
• 提升产品鲁棒性的同时，降低了后期维护成本。

对于从事工业控制、远程监控、低功耗传感的开发者来说，掌握这套轻量级可靠性增强方法，已经成为一项必备技能。

下一步，你可以尝试将它扩展为支持滑动窗口的多帧并发传输，进一步提高吞吐率；也可以结合Modbus协议进行兼容改造，实现即插即用的高可靠通信模块。

如果你正在为UART通信不稳定而头疼，不妨试试这个方案。也许只需要几百字节RAM和几十行代码，就能彻底告别“丢包焦虑”。

欢迎在评论区分享你的应用场景或优化经验，我们一起打造更可靠的嵌入式系统。