STM32 RS485通讯实战：硬件接线、方向控制与常见故障排查

简介：基于STM32F103RCT6的RS485通讯完整工程源码包，面向嵌入式开发者、工业自动化与物联网通信学习者，解决STM32平台下RS485收发控制与串口协议移植的实际问题。源码在江协串口代码基础上完成裸机移植，覆盖UART配置、中断接收、缓冲区管理和波特率设置等关键环节。包体共80个文件，以C源文件和头文件为主，并含标准外设库、OLED显示驱动、RS485收发模块、启动文件及Keil工程配置，整体仅341KB，便于快速下载与直接编译；目前已有243人学习/下载。内容兼具教学与工程参考价值，可查看RS485_USART1、RS485_Resive等模块驱动实现，理解差分信号传输、多点通信与终端匹配等物理层细节；也可参考串口代码从标准库到硬件的移植过程，掌握中断服务程序编写、数据帧解析与地址识别等实用技能，为工业控制、智能楼宇和物联网项目的快速复用提供清晰路径。 我第一次调RS485，是在一间只能放下两个焊台的实验室里。那会儿我刚把STM32的串口收发折腾明白，心想RS485不就是把TTL串口信号通过一个芯片转成两根线嘛，能有多难。结果A接A、B接B，波特率也和上位机设成一致的9600，发过去的指令就是石沉大海，上位机里一个字节都收不到。折腾了快三个小时，最后发现是方向控制引脚一直停在高电平发送态，芯片压根没切回接收。就是从那一刻起我意识到，搞RS485通信，硬件电路和软件协议各占一半，少一环都跑不通。

你拿到的这个zip包，解压出来基本就是一套能直接编译的STM32工程：收发电路图、串口驱动、一组通讯例程，外加这份说明。这篇文章就顺着“为什么这么接线、程序为什么这么写、出了问题怎么查”把整个RS485通讯拆开讲一遍。适合正在做毕业设计、刚从裸机编程转向工业通讯、或者在产线上被485调得焦头烂额的人。看懂之后，你不仅能把这个demo跑起来，还能自己改波特率、扩容到多机，甚至移植到其他型号的板子上。

1. 先用大白话理解RS485：为什么它比串口更抗造

1.1 差分信号：把“地”这个不稳定因素踢出去

普通UART串口是单端信号，靠一根信号线和一根地线来传数据。接收端判断电平，是拿信号脚和本地GND比较的。问题就在这：一旦两台设备距离拉远，两边的地电位会有偏差，本来该是3.3V的高电平，到远端可能变成2.0V、1.5V，误码率直线上升。这就像两个人隔着一百米的操场喊话，各自的“安静标准”不一样，对面说什么只能靠猜。

RS485改用A、B两根线传一组差分信号，接收端看的是A和B之间的电压差。A比B高200mV以上判为逻辑1，A比B低200mV以上判为逻辑0。外部干扰进来，通常是同时叠加在两根线上的共模干扰，A和B的差值不变，数据照样能解出来。所以RS485在工业现场能拉到1200米，而RS232一般超过15米就开始出问题，根源就在这个差分结构上。RS485的“抗造”，不是玄学，是物理结构决定的。

1.2 半双工：RS485和普通串口的本质区别

很多人把RS485理解成“串口加了根线”，这没错，但少说了一个关键点：RS485是半双工的。

所谓半双工，就是同一时刻总线上只能有一个设备在发送，其余设备都在听。A、B两根线既用来发也用来收，所以收发器芯片必须有一个方向控制逻辑——发送时把驱动器接到总线，接收时把驱动器断开、把接收器接上。这个切换动作，在程序里就是拉高或拉低一个引脚的事，但很多人第一次写485程序时会在这一步翻车：发完数据急着切回接收，结果最后一个字节还没完全从移位寄存器里送出去，被半路截断，对端收到的帧就是不完整的。后面我会专门讲这个时序问题。

理解了半双工，就能解释很多现场怪象：为什么两个设备同时往总线上发数据就会乱码？因为485总线在物理层不提供“碰撞检测”，两个设备同时驱动A、B线，电平互相打架，数据必坏。所以485通讯一定是要么主从轮询，要么分时调度，绝对不能像网线那样想发就发。

1.3 组网能力：一根总线挂几十个设备

RS485的另一个大优势是组网。标准的RS485收发器（比如MAX485、SP3485）一般标称能挂32个标准负载，如果选1/8负载的收发器，理论上可以挂到256个节点。实际项目中，一条总线上挂二三十个传感器、仪表、变频器是非常常见的。

组网的时候，每个设备需要一个唯一的地址。通讯采用“主机点名、从机应答”的方式：主机叫1号，1号回话；主机叫2号，2号回话，其他设备虽然也能收到数据，但发现地址不是自己，就继续沉默。这样一条双绞线就能把一堆设备串起来，省线、省串口、省事。这种“一主多从、轮询点名”的模式，就是RS485在工业控制里几十年没被淘汰的核心原因。

2. 拿到zip先看电路：RS485收发电路的几个关键选择

2.1 芯片引脚接法：TX、RX、DE/RE别乱接

先看芯片。STM32引出的UART引脚，经过收发器芯片转换成A/B差分信号，最常用的芯片是SP3485、MAX3485、MAX485这几颗，都很便宜，几毛钱一颗。以3.3V供电的SP3485为例，引脚逻辑很简单：

• RO（接收输出）接STM32的RX引脚，芯片把总线上的差分信号转成TTL电平给MCU收。
• DI（发送输入）接STM32的TX引脚，MCU把要发的数据送给芯片驱动总线。
• DE（发送使能）和RE（接收使能）是两个方向控制脚，DE高电平允许发送，RE低电平允许接收。因为发送和接收不会同时进行，所以实际电路里经常把DE和RE直接并在一起，用一根GPIO线控制——输出高就是发送态，输出低就是接收态。

这是一张常见的接线关系表，照着接基本不会错：

有两点容易踩坑。第一是RO和DI接反，很多人画板子时图省事按芯片引脚顺序排，结果收发的数据全乱。第二是方向引脚必须选一个真正的推挽输出GPIO，别选到开漏输出还忘了加上拉，否则DE/RE电平不确定，芯片就一直处于随机收发状态。检查电路时，先用万用表量一下DE/RE的电压，发送时接近3.3V、接收时接近0V，这一步正常再谈软件。

2.2 方向控制：GPIO控制还是自动收发电路

方向控制有两条路线：一是用MCU的GPIO直接控制DE/RE，二是用自动收发电路，让芯片根据TXD的电平自己切换方向。

GPIO控制是最稳妥的方案。程序里发送前拉高方向脚，发完等移位寄存器彻底吐干净，再拉低回到接收态。逻辑清晰，时间可控，出问题也好查。缺点是每次通信要额外操作一个引脚，稍微多写几行代码。

自动收发电路很诱人，因为它不需要MCU管方向，硬件上用一个三极管和几个电阻，根据TXD状态自动切换DE/RE。比如TXD为低电平时驱动芯片进入发送态，TXD为高电平时回到接收态。这个电路在低速、短距离的场景下确实能用，省了一个GPIO。但我在实际项目里踩过坑：波特率拉到115200之后，TXD由低跳高的瞬间，三极管的开关延迟会导致最后一个位的发送被提前切换掉，总线上帧尾被切掉一格，对端就报CRC错误或者干脆不回包。排查这种问题特别耗时，因为波形看起来只有一点点毛刺，不仔细看根本发现不了。

所以我的建议很直接：你的MCU引脚没那么紧张，就老老实实用GPIO控制方向。自动收发电路适合TTL转RS485模块那种固定场景，不适合你在自己板子上做可靠通讯。

2.3 终端电阻、偏置电阻和保护电路怎么摆

先讲终端电阻。RS485总线的特性阻抗一般是120Ω，当信号传到总线末端时，如果末端阻抗不匹配，信号会反射回来，产生振铃，干扰后面进来的数据。解决的办法就是在总线的最远两端各接一个120Ω的匹配电阻。注意是“最远两端”，不是每个设备都接。如果每个节点都并一个120Ω，总线负载直接被打到很低，驱动能力不够，反而更收不到数据。

偏置电阻的争议更大一点。它的作用是在总线上没有设备发送时，让A、B之间保持一个确定的电平，避免接收端把悬浮状态误判成数据起始位。标准做法是在A线上拉到VCC、B线拉到GND，典型阻值比如4.7kΩ、10kΩ。什么情况下需要加？总线上有从机一上电就开始乱收乱报、或者主机发完请求后一直收不到稳定应答，而示波器量A/B电压差接近0V，这就是缺偏置的典型症状。加了偏置电阻之后，空闲电平就稳定了，从机也不会再“幻觉”数据。

保护电路这块更对。工业现场长线缆，最怕的是雷击浪涌和静电。最低成本的保护是TVS管并接在A、B对地之间，再串两个电阻进门。如果场景更恶劣，比如跨建筑、走户外，可以升级成TVS加气体放电管的组合，或者加共模电感抑制共模干扰。电源侧最好用DC-DC隔离供电，避免地环路。实验室里短距离可以不那么讲究，但一旦要上产线、上设备，保护电路绝不能省。

3. 软件实现要点：把方向控制写成可靠的收发流程

3.1 初始化配置：先保证数据格式完全一致

代码部分从串口初始化开始。RS485物理层本身不规定数据格式，所以波特率、数据位、停止位、校验位必须通讯双方完全一致，这就是很多新手遇到的“传输格式不正确”报错的最常见来源。比如上位机软件设的是9600、8、N、1，板子这边初始化用的却是19200、8、E、1，两边永远鸡同鸭讲。

用STM32的HAL库配置USART2收发，并启用DMA接收，是一个非常典型的组合。DMA用于接收的好处是：数据到了自动搬进缓冲区，MCU不需要一个字节一个字节地去中断处理，CPU负载低，也不会丢字节。发送这边用阻塞式就行，因为485一帧数据通常很短，几十个字节，阻塞几百微秒完全可接受。初始化方向引脚要记得先拉低，让芯片默认处于接收态，防止上电瞬间误发数据。

3.2 发送流程：为什么必须等TC标志而不是TXE

这是485编程里最重要的一个细节。发送完成标志有两个：TXE表示发送数据寄存器已空，你写入的下一个字节随时可以进寄存器；TC表示移位寄存器已经完整把一帧数据送出去了。如果你只等TXE就切回接收，那最后一个字节可能还在移位寄存器里往外出，方向引脚一拉低，收发器把驱动器断开了，总线上的后半帧直接消失。

正确流程是先拉高方向脚，调用串口发送函数，然后等待TC标志置位，再补一个极短的延时（比如2~5微秒）兜底，最后拉低方向脚。这个短延时是为了覆盖芯片引脚的翻转延迟和总线电平建立时间。别小看这几微秒，它能让你少踩一个非常隐蔽的坑。

以HAL库为例，核心发送代码长这样：

void RS485_SendFrame(uint8_t* buf, uint16_t len) { RS485_DIR_HIGH(); // 进入发送模式 HAL_UART_Transmit(&huart2, buf, len, 100); // 实际数据送入移位寄存器 while (__HAL_UART_GET_FLAG(&huart2, UART_FLAG_TC) == RESET); // 等最后一个字节发完 delay_us(2); // 兜底延时，补齐收发切换间隙 RS485_DIR_LOW(); // 切回接收模式 }

标准库也是同样的逻辑，只是标志位的宏定义不同。这个函数看起来简单，但在我的项目里，光“TC vs TXE”这一点，就至少帮三个同事排查过“最后一字节丢失”的问题。

3.3 接收流程：空闲中断+DMA判断一帧结束

发送方向控制解决了，接收也要有章法。485通讯的从机不知道主机什么时候会发数据，所以接收必须一直在后台跑着。用串口空闲中断加DMA接收，是最优雅的姿势：DMA负责把总线上的数据一个字节一个字节搬进缓冲区，当总线上出现一段空闲期（也就是一帧发完了），串口会产生空闲中断，在中断回调里根据DMA剩余计数算出这一帧收到了多少个字节。

// 初始化里使能空闲中断 __HAL_UART_ENABLE_IT(&huart2, UART_IT_IDLE); // 中断回调 void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart->Instance == USART2) { rxLen = RX_BUF_SIZE - huart->hdmarx->Instance->NDTR; // 实际收到的字节数 // 此时rxBuf就放着完整一帧数据，可以交给协议解析 } }

这种用法的好处是，不需要预先知道帧长度，数据什么时候来都能接住，帧结束就触发一次处理。要注意的是，空闲中断触发后，要记得清掉空闲标志，否则下一帧数据进来时不会再触发中断，接收就卡死了。另外，DMA要设置成循环模式，否则缓冲区满了之后DMA停止搬运，后面的数据全丢。

如果你不想用DMA，用传统的接收中断配合超时判断也可以：每收到一个字节就更新一个计时器，超过3.5个字节时间没有新数据就算一帧结束。这种方式在中断里做的事情多一些，但逻辑也好理解，适合数据量小的场合。两种方案选一种即可，思路是相同的：判断“帧结束”，而不是死板地等固定长度。

3.4 一帧数据长什么样：建议的最小帧格式

直接发原始数据最方便，但也是最脆弱的。总线上一个干扰脉冲，就可能把一个字节变成另一个字节，接收方根本不知道对不对。所以一个成熟的485程序，必须有帧格式和校验。

最简单的可靠帧格式可以这样设计：地址字节 + 功能码 + 数据长度 + 数据区 + CRC校验。地址字节用来区分总线上多个从机；功能码表示这条指令是读还是写；数据长度方便接收方知道数据区有多少字节；CRC校验用来判断整帧数据有没有被干扰。如果项目不复杂，也可以从0x55 0xAA这种帧头开始，再跟上长度和累加和校验，但能上CRC16就尽量上，累加和对付随机干扰还是弱了点。

Modbus-RTU是工业上最通用的选择，本质就是“地址+功能码+数据+CRC16”。如果你不打算自己设计协议，直接用Modbus-RTU就行，上位机和各类组态软件都能直接对接。自己在项目中写协议时，也要模仿这种结构，别让接收方去猜数据从哪里开始、到哪里结束。

4. 通讯调不通时的完整排查链路

4.1 物理层：接线、极性、供电、共地

485通讯调不通，我从来不会一上来就翻代码，而是从物理层开始查。顺序大概是这样的：

先查接线。A接A、B接B，这个大家都知道，但总有反的时候。很多DB9转485的端子或者接线端子没有明确标识，或者标了半天你用的是焊好的线，结果就是A、B接反。不要靠自己记忆判断，用万用表蜂鸣档顺着线头量一遍。

再查供电。收发器芯片的VCC有没有电、是不是3.3V而不是5V，芯片型号和供电电压要匹配。如果SP3485按5V供电，芯片直接就冒烟，而这种问题往往烧的是芯片本身，MCU还好好的，程序还能跑但就是发不出数据。

然后查共地。RS485差分信号虽然不依赖地线判断电平，但收发器芯片的工作电压是以本地GND为参考的，两边的地电位差太大，超出发送器的共模输出范围，接收端照样收不到。如果是长距离跨设备，别指望细线能扛住电流，最好直接用带隔离的收发方案。

4.2 参数层：“传输格式不正确”的真实原因

上位机软件弹“传输格式不正确”，或者设备不回包，最常见的原因是通讯参数不一致。很多初学者把波特率设置为9600，但上位机的停止位或校验位设的和板子不一样，结果就是乱码或者干脆无响应。

排查手段很暴力也很有效：把逻辑分析仪或者示波器接在TTL侧的RX引脚，也就是收发器RO输出到MCU的那根线，然后让对端发一帧已知数据。看波形，数一下一个字符有几个位，起始位、数据位、停止位占的宽度对不对。如果波特率对，波形宽度肯定对；如果数据位设置不同，波形个数一看就能数出来。这个方法比对着代码找半天参数快得多。

4.3 波形层：用示波器/逻辑分析仪直接看A/B

到这一步的时候，如果程序看起来没问题，接线也对，就要看总线上的“真面目”了。示波器探头夹在A、B之间，地线夹在GND上，让主机持续发帧。正常情况下，你应该看到波特率对应的方波波形，幅度大概在±1.5V到±5V之间，看收发器驱动力和终端电阻而定。

如果波形幅度很小，只有几百毫伏，多半是总线负载过重。数一数总线上是不是不小心挂了太多终端电阻，或者某个设备把A、B接成了A、A。如果波形一点反应都没有，芯片可能根本没在发，回头看DI引脚有没有数据输入，方向引脚有没有拉高。波形能看到但接收端还是收不到，就顺着接收路径再查：RO到MCU RX引脚之间有没有断路，或者RX引脚有没有被复用成别的功能。

示波器的价值在于，它直接把物理层的答案摆在你面前，不用猜。我曾经遇到一个“时好时坏”的485通讯，最后就是靠示波器抓到总线上有回波振铃，才想起来远端终端电阻焊盘虚焊了。

4.4 程序层：方向引脚、中断和超时

物理层、波形层都没问题，那就开始怀疑软件。常见的有四类问题。

方向引脚没切回接收。发送完没有拉低DE，芯片一直占着总线，不仅自己收不到数据，还会把整个总线的电平拖住，其他设备也别想通信。这种问题最常见，查法也简单：用万用表量DE/RE引脚电压，如果一直稳定在高电平，那就说明程序在发完数据后没做切换。

中断优先级设置不合理。空闲中断和DMA中断的优先级如果低于其他频繁触发的中断，偶尔会被打断，一帧数据可能来不及处理，下一帧就到了。调高串口相关中断的优先级，一般能解决。

超时时间设置太短。从机响应需要时间，主机的重发超时设得太短，就会在从机还没回的时候已经重发了好几遍，把总线的节奏全部打乱。超时时间要按帧长度和波特率算：9600波特率下，一个字节大约1.15ms，一帧10个字节就得预留至少15~20ms的等待时间，再算上从机处理时间，超时定在50ms比较稳妥。115200波特率下，字节传输时间缩短到约0.1ms，超时就可以缩到5~10ms。

接收缓冲区的处理逻辑不对。尤其是DMA循环模式下，如果不及时把数据从缓冲区拿走，或者没有正确区分“新收的一帧”和“上一次残留数据”，就会出现通讯偶发错误。解决办法是每帧处理完清零标志位，或者用双缓冲区轮换。

4.5 烧录器报错时的快速分流

很多人调着调着，会遇到“error: no stm32 target found”这种报错，以为是调试器坏了。其实这和485通讯没有直接关系，多半是板子本身的问题。

最快的排查路线是这样的：第一步量3.3V电源，RS485收发芯片如果有问题，比如电源和地短路，会导致整个板子供电异常，调试器自然连不上；第二步量SWDIO和SWCLK这两根线的连接，杜邦线松动是常事；第三步检查BOOT0，如果是高电平状态下点下载，MCU会进Bootloader模式，SWD不一定连得上；第四步，如果以上都正常，按住复位键，点下载的瞬间松开复位，这叫“刷死芯片抢救法”，很多时候能救回误设置成debug authentication锁死的片子。

这个报错本身不可怕，养成“先查电源、再查调试口、最后怀疑芯片”的顺序，几分钟就能定位。

5. 从Demo走向工程：多机组网、轮询和超时重发

5.1 主机轮询从机：一次只允许一个节点说话

等单机收发跑通了，再往组网走一步。真实项目里很少只有两台设备，多数情况是一个主机（触摸屏、上位机、PLC）带着几十个从机（传感器、仪表、执行器）。这时整个系统要遵循一个原则：总线上只有主机能主动发命令，从机不允许主动上报，接到命令后才回一帧。主机按从机地址轮询，1号问完问2号，2号问完问3号，一轮问完再从头开始。

这个机制保证了任意时刻总线上只有一个设备在发，从物理层就避免了数据碰撞。从机侧的程序核心就是解析地址：收完一帧后，先看地址字段是不是自己，不是就丢弃，是才继续解析功能码和数据部分。这样哪怕总线上数据满天飞，每个从机也只是在“听”，不会乱插嘴。

5.2 超时和重发：抗干扰的最后一道防线

工业现场电磁环境复杂，偶发的一帧数据被干扰吞掉，是不可避免的事。所以主机侧的轮询循环不能是“问完就等，等不到就卡死”，必须有超时和重发机制。

主机的标准流程是：发送请求帧 → 启动超时计时 → 等待从机应答。超时时间到了还没收到有效应答，就把同一个请求重发一遍，一般重发3次。3次都没有应答，才判定这个从机离线，然后继续轮询下一个从机，不能让系统整个停下来。从机侧的软件也要注意，收到CRC错误的帧时，直接静默丢弃，千万不要尝试回一个错误帧——两个设备同时回数据，又是一次总线冲突。

超时时间定多少，取决于帧长度、波特率和从机处理速度。我一般习惯在理论传输时间的基础上乘以3作为最小超时，再往下取整到整数毫秒。9600波特率、一帧请求8字节时，理论传输约9.2ms，超时取50ms比较合理；115200波特率时可以取5~10ms。这个值不用太精确，留足余量比算得正好更重要。

5.3 工程化落地要点与个人体会

从Demo到能上线的工程，还需要注意几件小事。

总线布线尽量用双绞屏蔽线，屏蔽层单端接地。分支线要尽量短，避免长支线造成反射，影响波形质量。组网时每隔一段距离检查一下终端电阻，120Ω的匹配电阻只放总线两端，中间节点千万别加。这是很多系统“时好时坏”的根源之一。

如果你用的是国产替代芯片，比如APM32或者GD32系列，很多情况下STM32的HAL库工程经过简单适配就能直接跑通，串口外设地址和引脚基本一致，RS485收发逻辑完全通用。这样既降低了成本，也避免了对单一芯片的依赖。

我也见过有人用CH348L这种一拖八的串口扩展芯片，把八个串口全部转成RS485，一台主机带几百个设备，本质上也是同一套原理：地址区分、分时轮询。硬件规模变了，软件逻辑是一样的。

最后分享一条我自己的亲身教训：调试RS485，永远要把“先看物理层、再查参数、最后怀疑协议”这个顺序刻在脑子里。很多大师傅眼神一扫就能找出问题，不是因为他们记忆力好，而是他们已经把这条链路走成了本能。等你在示波器上亲眼看到一次完整的A/B差分波形，再亲手把方向切换的时序调对，这个通讯你就真正拿下了。

本文还有配套的精品资源，点击获取