硬件流控信号解析：RTS/CTS在UART中的应用说明

深入理解 UART 硬件流控：RTS/CTS 如何让串口通信更可靠？

你有没有遇到过这种情况：MCU 正在高速发送数据给 Wi-Fi 模块，突然一部分配置信息“消失”了？或者 GPS 模块在高波特率下偶尔丢星、定位漂移？排除接线和电源问题后，真相往往藏在一个不起眼的细节里—— 没有启用硬件流控（RTS/CTS） 。

在嵌入式开发中，UART 是最常用的通信接口之一。结构简单、实现方便，但一旦涉及 大数据量传输 或 实时性要求高 的场景，它的短板就暴露无遗：接收端稍有延迟，缓冲区瞬间溢出，数据无声无息地被丢弃。

而解决这个问题的关键钥匙，就是 RTS/CTS 硬件流控机制 。它不像软件流控那样“打补丁”，而是通过专用信号线构建了一个真正的“交通指挥系统”。本文将带你从工程实践的角度，彻底搞懂 RTS/CTS 是如何工作的、为什么必须用、以及在真实项目中该如何正确配置与调试。

为什么需要流控？一个被低估的通信隐患

我们先来看一组真实数据：

当波特率达到 921600 或更高时，每两个字节之间的间隔还不到 11 微秒。如果接收方因为中断延迟、任务调度或处理耗时稍长一点，哪怕只是几十微秒，就会错过至少一个字节。

传统无流控 UART 的工作模式是“我说你听”，完全依赖接收端及时读取 DR 寄存器。一旦跟不上节奏，数据直接覆盖 FIFO 或寄存器， 没有任何警告机制 。

这就是为什么很多开发者发现：“低速时正常，一提速就出错。” 而硬件流控的作用，正是为这个“盲发”过程加上一套实时反馈控制系统。

RTS/CTS 到底是什么？不只是两根控制线那么简单

核心角色定义

RTS/CTS 是一种基于电平信号的硬件握手协议，包含两条独立控制线：

• RTS（Request to Send） ：由发送方主动拉低，表示“我准备好要发数据了，请准备接收”。
• CTS（Clear to Send） ：由接收方响应拉低，表示“我现在可以收，你可以开始发”。

注意：这里的“发送”和“接收”是 相对于当前设备而言的 。比如 MCU 向 ESP32 发送数据时：
- MCU 控制 RTS 输出；
- ESP32 监听 CTS 输入，并根据自身