树莓派串口通信实战：全双工与半双工到底怎么选？

你有没有遇到过这种情况：树莓派连上一个传感器，代码写得没问题，可数据就是收不到？或者在调试Modbus时，主机发完命令后从机没反应，一查才发现是方向切换太仓促，最后一两个字节还没送出就切回接收了——这种“卡点失败”其实不是运气差，而是对串口通信模式的本质理解不到位。

今天我们就抛开教科书式的定义，用一线开发者的视角，带你真正搞懂树莓派上的全双工和半双工通信。不只是讲“是什么”，更要告诉你“为什么这么设计”、“坑在哪”、“怎么绕过去”。

从硬件说起：TXD 和 RXD 到底是谁的命脉？

先来看最基础的问题：树莓派的UART长什么样？

几乎所有型号的树莓派都至少提供一组原生UART接口，对应GPIO引脚14（TXD）和15（RXD）。这组接口默认映射到/dev/ttyS0或/dev/ttyAMA0，支持标准异步串行通信协议（8N1、波特率可调等），天生就是为全双工准备的。

什么意思？简单说：

你能一边说话，我也能一边听，互不干扰。

就像打电话，你说一句“收到”，我马上回“明白”，中间不需要等对方闭嘴。这就是全双工的优势——低延迟、高效率。

但如果你换到RS-485总线场景，比如要控制十几个温湿度传感器挂在同一根线上，你会发现：不能再靠这两根线搞定一切了。因为RS-485是差分信号 + 半双工架构，所有设备共用一对A/B线传输数据，谁想说话就得先抢通道。

这时候你就得加个芯片，比如经典的MAX485，它有四个关键引脚：
- A、B：连接总线
- RO：接收输出（接树莓派RXD）
- DI：发送输入（接树莓派TXD）
-DE/RE：方向控制！这才是半双工的灵魂所在

没有这个控制脚，你的树莓派永远不知道该“说”还是该“听”。

所以你看，同样是“串口通信”，底层逻辑完全不同。一个是天然并发，一个是有序轮询。选错模式，轻则丢包重试，重则整个系统瘫痪。

全双工实战：什么时候用？怎么配？

哪些设备适合全双工？

典型代表：
- GPS模块（如NEO-6M）
- 蓝牙串口模块（HC-05）
- 小型显示屏（串口屏）
- Arduino点对点通信

这些设备基本都是“一对一”连接，通信频率不高但要求实时响应。比如GPS每秒输出一条NMEA语句，同时你还可能随时下发配置指令（比如更改波特率或定位模式）。这种双向频繁交互的场景，非全双工莫属。

配置要点：别让蓝牙抢走你的串口！

这里有个大坑很多人踩过：树莓派3及以后版本，默认把/dev/ttyAMA0给了蓝牙模块！

你以为打开的是主UART，结果其实是辅助串口（性能受限的/dev/ttyS0），导致通信不稳定甚至无法工作。

解决办法很简单：

sudo raspi-config

进入：

Interface Options → Serial Port

然后选择：
-No（不启用登录shell over serial）
-Yes（启用硬件串口）

保存重启后，你会看到/dev/ttyAMA0回归本源，可以稳定跑115200甚至更高波特率。

C语言示例：真正的“边发边收”

下面这段代码不是玩具，是我实际项目中提炼出来的核心片段：

#include <stdio.h> #include <unistd.h> #include <fcntl.h> #include <termios.h> int setup_uart(const char* port) { int fd = open(port, O_RDWR | O_NOCTTY); if (fd < 0) return -1; struct termios opt; tcgetattr(fd, &opt); cfsetispeed(&opt, B115200); cfsetospeed(&opt, B115200); opt.c_cflag = CS8 | CLOCAL | CREAD; opt.c_cflag &= ~(PARENB | PARODD | CSTOPB | CRTSCTS); // 8N1，无流控 opt.c_iflag = IGNPAR; // 忽略奇偶校验错误 opt.c_lflag = 0; opt.c_oflag = 0; opt.c_cc[VTIME] = 10; // 1秒超时 opt.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd, TCSANOW, &opt); return fd; }

重点来了——如何实现“同时读写”？

void loop_communicate(int fd) { char tx_buf[] = "AT+QUERY\r\n"; char rx_buf[256]; while (1) { // 发送请求（非阻塞） write(fd, tx_buf, strlen(tx_buf)); printf(">> Sent: %s", tx_buf); // 立即开始监听回复 ssize_t n = read(fd, rx_buf, sizeof(rx_buf)-1); if (n > 0) { rx_buf[n] = '\0'; printf("<< Recv: %s", rx_buf); } sleep(1); // 模拟周期任务 } }

注意：这里的read()使用了非阻塞模式（通过VMIN=0, VTIME=10设置），意味着不会死等数据到来，而是快速返回继续循环。这样即使没有收到回应，也不会影响下一轮发送。

这才是全双工的精髓：物理层独立，软件层自由调度。

半双工挑战：为何多一个GPIO就能撬动整个工厂？

现在我们换个战场：工业现场。

假设你要做一个中央控制器，管理10台电表、5个温控器、3个电机驱动器，全都通过RS-485接入。如果每个都单独拉线，布线成本爆炸不说，维护也成噩梦。

于是工程师发明了总线式通信——所有设备挂在同一对A/B线上，靠地址识别身份。而通信方式必须是半双工：同一时间只能有一个设备说话。

关键问题：谁来决定“现在轮到谁说”？

答案是主机（也就是你的树莓派）。但它不能直接喊话，必须先告诉MAX485：“我要开始说了，请打开发送使能。”

这就引出了最关键的一行代码：

digitalWrite(DE_PIN, HIGH); // 打开发送模式 usleep(50); // 等待硬件稳定 write(uart_fd, data, len); tcdrain(uart_fd); // 等待最后一个bit发出 digitalWrite(DE_PIN, LOW); // 切回接收模式

其中tcdrain(fd)是最容易被忽略的关键函数！

很多开发者以为write()返回就代表数据发完了，其实不然。Linux的串口驱动是有缓冲区的，write()只是把数据扔进内核队列，真正发送还在后台进行。如果不等tcdrain()完成就切换方向，最后几个字节会被截断，造成从机收不到完整帧。

我曾在一个项目中花了三天排查Modbus CRC错误，最后发现就是因为少了这一行tcdrain()。

完整通信流程拆解

以 Modbus RTU 主机为例，一次完整的查询过程如下：

1. 准备阶段
   - 清空接收缓冲区
   - 设置目标设备地址、功能码、寄存器范围

2. 发送阶段
   - GPIO置高 → 启动发送模式
   - 写入Modbus请求帧（如0x01 0x03 0x00 0x00 0x00 0x02 CRC）
   - 调用tcdrain()确保全部发出

3. 切换阶段
   - GPIO置低 → 进入接收模式
   - 延时100μs（防止反射信号干扰）

4. 接收阶段
   - 启动select()或poll()监听数据到达
   - 设定1秒超时，避免无限等待
   - 收到数据后验证地址、CRC、长度是否匹配

5. 处理与轮询
   - 解析数据并更新本地状态
   - 延迟片刻，进入下一个设备查询

整个过程像一场精密的舞蹈，每一步节奏都不能乱。

实战建议：五个你必须知道的秘籍

秘籍一：永远不要裸奔write()

无论全双工还是半双工，只要涉及可靠通信，记住这条铁律：

write()≠ 数据已发出

要用tcdrain(fd)来确认物理层完成发送，尤其是在半双工切换前。

秘籍二：波特率设置要一致，更要“靠谱”

常见波特率有9600、19200、115200。虽然看起来越高越好，但在长距离RS-485上传输时，过高波特率会导致信号畸变。

经验法则：
- 1200米距离 → 最高9600 bps
- 100米以内 → 可尝试115200 bps
- 中间情况 → 19200 或 38400 更稳妥

秘籍三：电平转换不可省

树莓派GPIO是3.3V TTL，而很多工业设备使用5V CMOS或RS-485差分电平。

直接对接？轻则通信不稳定，重则烧毁SoC。

解决方案：
- TTL转5V：用74LVC245或专用电平转换模块
- 接RS-485：必须使用带隔离的MAX485模块（如ADM2483），防浪涌、抗干扰

秘籍四：善用select()实现高效监听

比起死循环read()浪费CPU，更优雅的方式是使用select()实现带超时的阻塞读取：

fd_set fds; struct timeval tv = {1, 0}; // 1秒超时 FD_ZERO(&fds); FD_SET(fd, &fds); int ret = select(fd + 1, &fds, NULL, NULL, &tv); if (ret > 0 && FD_ISSET(fd, &fds)) { int n = read(fd, buf, size); // 处理数据 } else if (ret == 0) { printf("Timeout: no response\n"); }

这种方式既能及时响应数据，又能避免忙等待，特别适合做轮询系统。

秘籍五：CRC校验不是摆设

Modbus、自定义协议都强调CRC。别图省事跳过校验，否则一个小干扰就会让你误判数据。

推荐使用现成库（如libmodbus）或预生成CRC表，提高效率。

总结：选型决策清单

当你面对一个新的通信需求时，不妨问自己这几个问题：

最终结论很清晰：

全双工用于简洁高效的点对点通信，半双工用于复杂可靠的多节点系统。

两者不是替代关系，而是互补工具箱里的两把利器。

如果你正在做一个智能家居网关、农业监测站，或是小型PLC控制系统，希望这篇文章能帮你避开那些看似微小却致命的通信陷阱。

毕竟，在嵌入式世界里，不是代码越复杂越好，而是越稳越好。

你在项目中遇到过哪些串口通信的奇葩问题？欢迎在评论区分享，我们一起排雷。