简介：一份面向嵌入式开发者的RS485串行通信协议参考代码包，围绕工业控制与电力通讯场景，系统梳理了RS-232、RS-422、RS-485的发展脉络与各自特点，并对差分信号传输、抗共模干扰、支持多发送器与多接收器协同通信等核心要点做了简明讲解。资源内含STM32平台上的UART硬件连接方式、软件配置步骤、中断服务程序写法，以及两个STM32设备间收发数据的完整示例代码，有助于开发者在实际项目中快速完成RS485通信功能验证与调试。压缩包为zip格式，共3个文件，以可交互的HTML代码页和inscode配置为主，附带gitignore工程文件，整体仅6KB，轻量便于对照学习。目前已有267人学习下载，适合正在入门工业总线通信或需要在嵌入式项目中落地RS485应用的开发者参考查阅。
1. RS485 通信协议：它根本不定义协议，你踩的坑多半在这
接手一台老工业设备时，我遇到过最典型的场景：设备端明明输出 RS485 电平，拿 USB 转 485 模块接上 PC，串口助手打开，发什么都是乱码或干脆没响应。查到最后，问题不是协议，而是 A/B 线接反、终端电阻缺失加上收发切换时序不对，三件事叠在一起。RS485 通信协议这个叫法其实有误导——它只是一种电气层标准，规定的是电压差、线缆、拓扑和收发器行为，跑在它上面的数据帧仍然是 UART 格式。换句话说，你要解决的不是"协议怎么解析"，而是"电平和时序怎么伺候好"。这篇文章面向需要实际调试 RS485 总线的工程师，从物理层细节、C 代码实现、参数设定到现场排错，给你一套能照着抄的落地路径。
2. RS485 物理层与选型：差分信号、终端电阻和 A/B 极性
2.1 差分信号为什么能在强干扰环境里活下来
RS485 的底层逻辑是差分传输：数据不靠单根线的对地电压判断，而是由 A、B 两线之间的电压差决定。发送端驱动 A-B 电压为正时代表逻辑 1（通常 +2V 到 +6V），为负时代表逻辑 0（-2V 到 -6V）。接收端只需要检测这个差值，共模干扰如果同时作用在两根线上，差值基本不受影响——这就是它在电机、变频器、长距离线缆场景中依然可靠的根本原因。
从选型角度理解，RS485 收发器（比如常见的 SP3485、MAX485 这类芯片）内部就是"一个差分驱动器 + 一个差分接收器"的组合，大多还带方向控制脚 DE/RE。为什么很多工程师直接用 UART 的 TX/RX 接上去就完事？因为 RS485 数据帧确实就是 UART 帧，只是物理层从单端变成了差分对。真正的坑在于：UART 是双工的，TX 和 RX 是独立通道，而 RS485 是半双工的，同一对线要么发要么收，方向切换全靠软件控制那个 DE 引脚。这决定了代码层面必须把"发送"和"接收"做成互斥操作，稍有不慎就会自己收自己发的内容。
2.2 终端电阻与偏置电阻：阻抗匹配的边界在哪里
RS485 总线末端需要匹配电阻，标准做法是在总线物理两端各接一个 120Ω 电阻，用来吸收信号到达末端时的反射。原理是双绞线的特征阻抗大约在 120Ω 附近，始端和末端都匹配上，信号就不会在端点弹回来叠加成振铃。短距离低速下（比如 10 米内、9600bps），很多人不接终端电阻也能通，那是因为信号反射还没到影响判决电平的程度；一旦线长超过 30 米，或波特率提高，反射就会表现为波形过冲、数据偶发误码。
120Ω 不是越大越好，也不是越小越好。电阻偏大会让反射吸收不充分，偏小会加重发送器负载，导致差分电压幅值被拉低。一个常见误区是"整条总线只在一端接一个 120Ω"——这只能算半匹配，另一端反射仍然存在。正确做法是只在最远两端各接一个，中间节点绝对不加。如果板上没有预留终端电阻位置，我一般会在接线端子旁边焊一个 120Ω 的直插电阻，方便现场拆装测试。
偏置电阻是另一件事。当总线处于空闲状态时，没有任何节点驱动 A/B 线，此时差分电压接近 0，接收器会因无法判定电平而输出随机数据。解决方式是在 A 线上拉到高电平、B 线拉到低电平，用 5V 电源串 330Ω 到 1kΩ 左右的电阻给总线一个弱偏置。很多现场"一上电就收到乱码"的问题，根源不是协议不是波特率，而是缺了这对偏置电阻。注意：加了偏置电阻会略微改变终端匹配效果，实际调试时先确认波形再决定偏置阻值。
2.3 隔离与非隔离：为何现场烧芯片
RS485 最隐蔽的杀手是地电位差。长距离两端设备各有自己的电源地，两地之间可能存在几伏甚至几十伏的电位差，这个压差会通过总线形成共模回路，超过收发器共模输入范围（标准是 -7V 到 +12V）后直接损坏芯片。症状往往是：设备单独测试正常，一条总线接上后某个节点的 485 芯片冒烟，或者通信随机中断。
解决路径有三个层次。最低成本的是用带 TVS 管和自恢复保险丝的成熟 485 隔离模块，比如把收发器替换成内置磁隔离的型号，成本增加但换来的是一劳永逸。其次是在总线入口并联 TVS 管（双向，钳位电压选 6.5V 到 7V 左右）做浪涌保护。最后是现场施工上注意所有节点的信号地，必要时用单点接地把总线屏蔽层或隔离地统一接到一个真正的大地接点。我自己的原则是：跨设备、跨房间、跨电柜的通信一律选带隔离的模块，省下来的隔离钱不够烧一片芯片的。
3. 用 UART 驱动 RS485：最简代码与收发切换的时机
3.1 半双工模型：DE 引脚控制的本质
RS485 节点上通常只需要三根线接到 MCU：UART 的 TX/RX，外加一个 GPIO 控制收发器的 DE 引脚。DE 为高时芯片处于发送模式，TX 信号经过驱动器变成差分对输出；DE 为低时驱动器释放总线，接收器开始工作，RX 引脚接收到线上数据并传给 MCU 的 UART 外设。
这段逻辑看似简单，但工程实现上有个关键：发送操作不是写完数据就结束，必须等最后一个字节的每一位都真正从移位寄存器推出去，才能把 DE 拉低。如果提前释放总线，最后一个字节的停止位会被截断，接收端因为停止位错误直接把这帧丢弃，表现为"总是丢最后一个字节"或"偶尔多收一个非法字节"。这个坑几乎每个做 485 的人都踩过，下面用代码展示正确时序。
3.2 一个最小可用的轮询收发代码
以常见的 STM32 HAL 库为例，写一个最简的阻塞式收发函数：
/* rs485_driver.h */ typedef struct { UART_HandleTypeDef *huart; /* 指向已初始化的 UART 句柄 */ GPIO_TypeDef *de_port; /* DE 引脚所在 GPIO 端口 */ uint16_t de_pin; /* DE 引脚编号 */ uint32_t baudrate; /* 当前波特率，用于计算位时间 */ } RS485_Handle; /* rs485_driver.c */ void RS485_WriteEnable(RS485_Handle *dev, uint8_t enable) { HAL_GPIO_WritePin(dev->de_port, dev->de_pin, enable ? GPIO_PIN_SET : GPIO_PIN_RESET); } void RS485_SendBytes(RS485_Handle *dev, uint8_t *buf, uint16_t len) { /* 1. 切换为发送模式 */ RS485_WriteEnable(dev, 1); /* 2. 阻塞式发送，HAL 内部会等待每个字节的 TXE 标志 */ HAL_UART_Transmit(dev->huart, buf, len, 1000); /* 3. 等待最后一个字节的 TC 标志置位，确保移位寄存器已完全输出 */ while (__HAL_UART_GET_FLAG(dev->huart, UART_FLAG_TC) == RESET); /* 4. 再补一个位时间的延时，彻底释放总线 */ uint32_t bit_time_us = 1000000 / dev->baudrate; delay_us(bit_time_us * 10); /* 10 个位时间，约 1 个字节长度 */ /* 5. 切回接收模式 */ RS485_WriteEnable(dev, 0); }这段代码里，第 2 步的HAL_UART_Transmit在阻塞模式下会等待发送完成，但为了保险，第 3 步专门等待 TC 标志。TC 置位意味着最后一位（停止位）已经在物理线上输出完毕。第 4 步的延时再给总线一个充分的缓冲，防止某些收发器在切换瞬间出现短暂的驱动残余。实际工程中，如果 DE 切换由同一颗 MCU 完成，这个延时可以缩短到 1-2 个位时间，但初版代码建议按 10 个位时间跑，稳定后再逐步压缩。
接收侧更简单。半双工模式下，只要 DE=0，接收器就一直在监听总线，MCU 的 UART 中断会收到每个字节。问题在于怎么判断一帧结束。RS485 没有像 Modbus 那样自带帧分隔符时，常见做法是"空闲判断"：连续 3.5 个字符时间内没有新字节到达，就认为当前帧接收完毕。这个逻辑可以用定时器实现，也可以用 MCU 的 UART 空闲中断（IDLE）实现。
3.3 用中断或 DMA 发送时，切换时机必须放到回调里
轮询方式虽然简单，但发送大数据块时会阻塞 CPU。实际项目中更多用中断或 DMA 发送，这时必须在传输完成回调函数里切换 DE，否则又会出现截断：
/* 假设使用 HAL 库的 UART DMA 发送 */ uint8_t tx_buf[64]; volatile uint8_t rs485_tx_busy = 0; void RS485_SendDMA(RS485_Handle *dev, uint8_t *data, uint16_t len) { while (rs485_tx_busy) { /* 如果上一次发送还没完成，等待，避免多任务下同时操作总线 */ } memcpy(tx_buf, data, len); /* 拷贝到专用缓存，防止发送期间被改写 */ RS485_WriteEnable(dev, 1); /* 先切发送模式 */ rs485_tx_busy = 1; HAL_UART_Transmit_DMA(dev->huart, tx_buf, len); } void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart) { /* DMA 全部搬运完成，但最后一个字节可能还在移位寄存器里 */ uint32_t bit_time_us = 1000000 / huart->Init.BaudRate; delay_us(bit_time_us * 10); RS485_WriteEnable(dev, 0); /* 这里才释放总线 */ rs485_tx_busy = 0; }关键点在于：DMA 完成中断对应的是 DMA 把数据全部交给了 UART 外设，并不代表数据已经从 TX 引脚输出完毕。所以回调里依然需要等待 TC 标志或做位时间延时。我见过不少产品在现场一帧一帧地丢尾部字节，最后定位原因就是"回调里只切了 DE，没补延时"。另外，DMA 发送必须用专用缓存区，因为 DMA 是异步的，发送函数返回后缓存区若被复用，会引发数据错乱。
3.4 波特率、校验位与停止位的参数选择
RS485 的帧格式依然是 UART 帧，常见配置是 8 数据位、无校验、1 停止位（8N1），波特率从 9600 到 115200 都有。波特率选择要同时看线长和节点数：短距离（几十米内）115200 毫无压力；超过 200 米建议降到 38400 以下；500 米以上一般只跑 9600。这不是协议限制，而是信号在长线缆上的上升沿变缓、眼图变小，盲目提波特率只会换来误码率飙升。
校验位的选择有一个容易被忽略的点：Modbus RTU 协议本身规定了 CRC16 校验，所以帧的完整性有保障，此时 UART 层完全可以不用奇偶校验位，减少数据量。如果跑的是自定义协议且没有 CRC，可以考虑 UART 层的偶校验兜底，但千万别只依赖奇偶校验而不做帧校验——奇偶校验只能检测单比特翻转，连偶数位翻转都发现不了。停止位选 1 还是 2，影响不大，多数从设备要求 1 停止位，2 停止位主要用于兼容老旧设备，不必默认设 2。
波特率误差也要心里有数。MCU 的时钟源如果是内部 RC 振荡器，温度漂移可能导致波特率偏差超过 2%，长字节帧时累积误差会直接导致停止位采样失败。现象是"短报文通，长报文偶发错帧"。解决方式是使用外部晶振或校准内部 RC。
4. RS485 现场排查与避坑：从烧了三块板子总结的经验
4.1 现象：完全收不到数据，但发送端波形正常
原因：A/B 线极性接反。RS485 的 A、B 定义在历史上存在混乱，有的设备把 A 当正、B 当负，有的反过来。最直观的判断方法：接反时总线空闲电平是反的，接收端会一直认为线上有数据，表现为接收脚持续产生乱码或中断风暴。
解决：先用万用表量总线空闲电压，正常偏置下 A 相对 B 应为正（约 2V 到 5V），如果 A-B 为负，说明有一端的 A/B 接反了。调整其中一个设备侧的接线，把所有设备统一到同一极性约定上。我踩过的坑是：两台设备单独对测正常，并到第三条总线上就全部乱码，排查半天发现是第三台设备的 A/B 丝印和实际定义相反。
4.2 现象：发送数据总是丢最后一个字节
原因：DE 切换过早，停止位被截断。这在轮询发送时偶尔出现，在 DMA/中断发送时几乎是必然，因为很多工程师误以为"发送完成中断=物理线上输出完毕"。
解决：在发送完成回调里检查 TC 标志（或做 1 个字节位时间的延时）后再拉低 DE。补充一点：有些收发器在 DE 切换瞬间会产生毛刺，如果在发送完成后立即把 DE 拉低并紧接着开始接收，MCU 可能把自己发出的最后一个字节的回声当成有效数据，这就需要在时序上留出至少几个位时间的间隔。
4.3 现象：总线偶尔整片乱码，重启后恢复
原因：电缆过长且没有终端电阻，信号在末端反射后叠加，导致超过接收器判决阈值。典型场景是现场临时加了 50 米线，原本没有终端电阻的总线开始出现零星误码。
解决：在总线最远端两端各并联 120Ω 电阻。我有一次在模拟项目上用示波器看 A/B 对 GND 的波形，传输线末端出现了明显的振铃，加了终端电阻后振铃幅度下降了一半以上。没有示波器时，可以用"总线不接终端电阻时必须能通过短距离自测"这个现象做反向判断。
4.4 现象：一个节点掉电，整个总线瘫痪
原因：节点收发器在掉电后呈高阻态，但如果该节点上还并接了终结电阻或偏置电阻，掉电反而把总线拉死。更糟的情况是某些劣质 485 芯片在掉电状态下引脚漏电流过大，等效于在总线上挂了个大负载。
解决：每个节点设计时考虑"掉电隔离"。选支持高阻输出的收发器（如带 /SHDN 引脚的型号），或现场排查时逐一断开节点定位"捣乱者"。同时确认终端电阻只装在最远两端节点上，中间节点即使板上有预留，也把电阻拆掉。
4.5 现象：自发自收测试通过，接上真实设备就乱
原因：回环测试时把 A/B 直接短接，或者接了本机回环收发器，信号路径短且纯净，掩盖了现场的真实问题。真实总线上有长线缆、多节点、终端和不匹配的偏置，回环测试无法覆盖这些工况。
解决：搭一个最小真实拓扑，用三台设备加 10 米以上的线缆做联调，至少包含一条超过 30 米的链路，再验证波形和误码率。回环测试只能证明 MCU 的 UART 和收发器本身没问题，证明不了总线设计没问题。
5. 用示波器与两个节点快速验证链路：一个排查手法的自述
RS485 调试最怕没有抓手，我习惯按"先链路、后协议、再时序"的次序推进。第一步是验证物理链路：不用接任何协议逻辑，直接用两个 USB 转 485 模块对连，A-A、B-B，加上终端电阻，一端发 0x55（二进制 01010101，波形最规整），另一端把收到的数据打出来。这步过了，说明电气链路是通的，问题在时序或协议层。
第二步看时序：重点观察 DE 引脚和 TX 引脚的相对关系。理想波形应该是 DE 先拉高，然后 TX 输出完整字节，最后一个停止位结束后 DE 才拉低，且拉低前要保证 TC 完成。用示波器同时抓 DE 和 A-B 差分波形，能看到 DE 下降沿是否落在最后一个字节的停止位之后。大部分"丢最后一位"的问题在这一步原形毕露。
第三步验证多节点下的偏置和终端：断开一个节点，量总线空载时的 A-B 电压，应该在 200mV 以上，降到 50mV 以下时接收器很容易受干扰误判。我遇到过某设备在总线上"静默"时持续产生中断，就是因为空闲电平太接近判决阈值，后来在主机端加了 820Ω 偏置电阻，问题彻底消失。
最后的习惯动作是：在板上留一个调试用的终端电阻焊盘，和一个单点跳线用来快速断开节点。现场调试时先只挂两台设备跑通，再逐步增加节点，每加一个节点就观察一次误码率变化。很多玄学问题（比如"接了 8 台就乱，接 6 台就正常"）其实是节点负载加上终端偏置分配不均导致的，逐步接入是最快的定位方式。希望这些经验能帮你在 RS485 总线上少烧几块板子、少熬几个夜。
本文还有配套的精品资源，点击获取
