简介：基于STM32F103RCT6芯片的RS485通信工程源码，面向嵌入式学习者和工业通信开发人员，解决串口转差分信号、多节点通信以及代码移植等问题。工程以江协串口代码的裸机移植为基础，完整实现数据收发逻辑，并附带移植参考链接，便于对照学习寄存器配置、中断服务程序编写、缓冲区管理和波特率精确设置等关键细节。压缩包共有八十个文件，以三十三个头文件和三十二个源文件为主体，另有八个启动文件、工程配置以及烧录辅助文件，整体大小约为三百四十一千字节，结构清晰，可直接在集成开发环境中打开查阅。目前已有二百四十七人学习。通过该项目能够掌握串行通信协议在嵌入式平台上的实现方法，内容包括串口收发、屏幕数据显示、标准外设库调用等，从物理层到应用层均有完整示例，适合用于工业控制、智能建筑等场景的二次开发，是串口驱动移植和通信协议落地的实用参考。
1. 基于STM32的RS485通讯：代码不是难点，物理层才是多数人卡住的地方
工控现场跑数据，RS485依然是绕不开的总线之一：几十个节点、几百米线缆，配上Modbus这类成熟协议，稳定又便宜。但很多人在STM32上第一次移植RS485通讯就翻车，现象还挺统一——上位机收不到回包、最后一字节丢失、总线空载时示波器上全是毛刺。这份“基于STM32实现RS485通讯”资源包，胜在把可用的收发例程、引脚配置和帧解析逻辑整理成了能直接套用的工程模板，适合正在做批量产设备的嵌入式工程师、刚接手工控BMS或传感器项目的开发者。它能帮你把整条链路的问题从「猜」变成「查」，从电平关系到收发时序，按步骤还原现场，省掉反复试错的时间。
2. 先从电平与拓扑说起：为什么RS485能跑一公里而不翻车
2.1 差分信号与A/B线：噪声抑制的真相
RS485的本质是差分传输。收发器把MCU的TTL电平转换成A、B两线之间的电压差，接收端只关心这两根线谁比谁高，不再依赖地线作为参考。逻辑1表现为A高于B至少200mV，逻辑0则反过来。典型驱动芯片在带负载时输出差分电压能达到±1.5V，而接收器只需要识别±200mV的差值即可，这个电压余量保证了长线衰减之后依然能可靠判定。
实际工程里，电磁干扰往往同时叠加在两根线上，差分接收天然做了一次共模对消。同样的噪声灌进单端信号里，接收端看到的电平会被污染，但在差分链路上，A和B同时被抬高或拉低，两者之差几乎不变。这也是为什么RS232到了十几米就力不从心，而RS485在9600bps标称能跑1200米。
接线时注意：A接A、B接B，A和B不要交叉。RS232那种“收发交叉”的惯性在这里不能套用，A、B接反最典型的现象就是完全不通讯，或者通讯时好时坏。如果总线两端设备的A/B没有统一规范，还容易出现设备间互相乱发数据的情况，排查时先把万用表量一遍A对A、B对B的连通性。
2.2 半双工与方向切换：死锁在DE引脚的开关之间
RS485是半双工总线，同一时刻只允许一个节点占用链路。因此常用收发器芯片内置了方向控制逻辑：DE脚拉高时驱动A、B线，RE脚拉低时接收总线数据。很多项目会直接把DE和RE短接，用一颗GPIO同时控制收发方向，这是最常见接法，也是RS485调试中最容易出问题的位置。
方向切换逻辑可以总结为三个步骤：发数据之前先把DE拉高，数据全部从移位寄存器送出去之后，再把DE拉低。很多人死于第二步——数据看着发送函数已经返回，实际最后一个字节还卡在移位寄存器里没发完，DE就被拉低了，于是对端永远少收一个字节。另一个常见问题是DE拉低太早导致帧末尾电平跳变被对方当成噪声，引发CRC错误或帧解析错位。
还有一个容易忽略的点：总线空闲时，所有节点的收发器都处于接收状态，如果总线上没有一个确定的空闲电平，接收端会不停收到随机电平变化，具体表现为收进来一堆0xFF或0x00。后面的偏置电阻部分会专门处理这个问题。
2.3 终端电阻与偏置电阻：两个120Ω加一组上下拉，解决尾部的反射和空载毛刺
双绞线的特征阻抗约为120Ω，当信号走到线缆末端时，如果末端阻抗不匹配，反射波会叠加在原信号上形成振铃。振铃严重时会导致接收端误判电平，尤其在线缆超过几十米之后更明显。标准做法是在总线物理最远的两端各接入一个120Ω电阻，中间的节点一律不加。很多新手在每个设备上都焊了终端电阻，结果总线负载被拉低，信号幅度变小，通讯反而更不稳定。
终端电阻的位置也有讲究：不是接在离MCU最近的地方，而是接在线缆拓扑的最远两端。如果布线是手拉手的链式结构，主机一端一个，最后一台从机端一个，中间的设备不需要。
偏置电阻则是为了保证SCL空闲状态稳定。通常在主机的A线上加一个上拉电阻到VCC，B线上加一个下拉电阻到GND，阻值常在560Ω到1kΩ之间，具体数值看总线上挂了多少设备。偏置过大会增加收发器负载，过小又拉不动总线电平。实际调的时候可以边量A-B间电压边换阻值，目标是让空闲时A对B的电压稳定高于200mV。
3. STM32接线与CubeMX配置：把USART变成可用的RS485节点
3.1 最小驱动电路：收发器的8个引脚怎么接
选一个常见的8引脚RS485收发器，外围电路非常精简。RO引脚接STM32的RX，DI引脚接STM32的TX，RE和DE短接后由一颗普通GPIO控制，A接总线A，B接总线B，VCC和GND之间加一个0.1uF去耦电容，这就是完整的节点电路。
一个值得注意的细节：RE和DE短接之后，这颗GPIO输出低电平时，收发器处于接收使能状态；输出高电平时进入发送状态。所以CubeMX里要把这颗GPIO初始化为推挽输出、默认低电平。如果初始化为高电平，板子一上电就抢占总线，整个链路上的其它设备都会被噪声干扰。
如果用在有地电位差的现场环境，比如两个设备相隔几十米分别供电，建议把收发器的VCC和GND与MCU侧做隔离。低成本做法是加一颗隔离电源模块和数字隔离芯片，收发器供电放在隔离侧。资源包里给出的例程默认是共地模式，这种简化适合实验室和同电源柜内的设备，跨配电柜场景需要自行加隔离层。
3.2 CubeMX参数：9600/8/N/1 与方向控制引脚的配置顺序
打开CubeMX，选择USART1并配置为异步模式。参数面板里波特率填9600，字长8位，停止位1位，校验位None。9600是工控现场最常用的速率之一，走线长、抗干扰好；如果通讯距离只有几米且数据量较大，可以提到115200，但线缆超过50米后误码率会明显上升，建议先用9600跑通再提速率。
方向控制引脚在GPIO标签页里做配置。找到挂载DE/RE的引脚，比如PA8或PD7，模式设为GPIO_Output，初始电平设为Low。这里有个容易踩的坑：如果初始化顺序是先开USART中断再配置方向引脚，板子上电瞬间GPIO可能处于高阻态，收发器方向不定，导致外部设备一开机就收到垃圾数据。建议CubeMX生成的代码不要手动调整初始化顺序，保持MX_GPIO_Init先于MX_USARTx_UART_Init执行，因为GPIO初始化完DE是低电平，收发器默认接收状态，这时再开UART中断才是安全顺序。
数据位和校验位的选择涉及一个实际矛盾：工控协议里Modbus RTU默认8数据位、偶校验或者无校验。这里选None不是拍脑袋，因为后续协议层会加CRC16校验，CRC能识别比单个校验位更可靠的错误，链路层再用一位校验意义不大。如果对接的是某个现成设备且对方强制偶校验，那么CubeMX里就要改成Even，同时协议栈里不要再额外叠加CRC，否则双方算法不匹配。
3.3 为什么我不用STM32的硬件半双工模式
STM32的USART支持单线半双工模式，内部会把TX和RX短接到同一个引脚，硬件通过数据方向位自动切换收发状态。乍一看似乎可以省掉DE控制，直接一根线接收发器DI就能用。但这里有个实际问题：不同厂商的RS485收发器对DE时序的要求并不一致，硬件半双工模式切换方向的时机并不能覆盖所有芯片。
我一般建议不开启单线半双工，坚持用标准异步模式加GPIO手动控制DE。虽然多占用一个引脚，但换收发器型号时不用改代码架构，只需要调整DE拉高、拉低的延时。批量产项目中不同批次收发器供货厂家可能不同，软件统一控制方向能降低不可控因素。
如果确实想用硬件半双工，可以在CubeMX里把Mode选为Single Wire，但必须确认收发器的DE引脚接法：有些芯片DE和RE分开，半双工模式下RE固定接地，DE还需要软件或额外硬件控制，反而比GPIO直接控制更绕。
4. 代码实现：三段式方向切换与状态机接收
4.1 发送的最后一个字节：为什么必须等TC而不是TXE
HAL库的HAL_UART_Transmit函数返回时，只能保证最后一个字节已经被写入发送数据寄存器，但不能保证它已经从移位寄存器里完全送出去。对于RS485来说，如果在此时立刻拉低DE，总线会强行切断最后一个字节的发送，对端就丢尾巴。底层细节是：TXE标志表示数据寄存器已空，TC标志表示移位寄存器已空，数据真正从TXD引脚完成发送，必须等TC。
因此发送函数的最后一步，一定要多做一个轮询等待TC标志的循环。这也是资源包里驱动层和网上很多简化代码的核心区别。
void rs485_send_frame(uint8_t *buf, uint16_t len) { // 1. 切换为发送模式：DE拉高，驱动A/B总线 HAL_GPIO_WritePin(RS485_DE_PORT, RS485_DE_PIN, GPIO_PIN_SET); // 2. 阻塞发送len个字节，超时设为100ms HAL_UART_Transmit(&huart1, buf, len, 100); // 3. 等待移位寄存器完全清空，再释放总线 while (__HAL_UART_GET_FLAG(&huart1, UART_FLAG_TC) == RESET); // 4. 切回接收模式，让出总线 HAL_GPIO_WritePin(RS485_DE_PORT, RS485_DE_PIN, GPIO_PIN_RESET); }要点是第3步的循环不能被优化掉，也不能换成TXE。TXE在最后一个字节写入数据寄存器后就置位，而且HAL_UART_Transmit内部调试状态下可能返回得更早。TC标志没有置位说明线路上还有数据在跑，此刻切方向必出问题。
第1步和第4步之间的顺序也不要反：先拉高DE再调用发送函数，确保总线被驱动到发送态后再启动UART发送。如果先调用HAL_UART_Transmit再拉DE，某些收发器内部建立驱动需要时间，前导字节可能被吃。
4.2 接收初始化：先开启中断再进主循环
接收侧更常用的方式是字节中断加状态机解析。先初始化一个缓冲区，然后调用HAL_UART_Receive_IT开启单字节接收：
uint8_t g_rx_byte; uint8_t g_rx_buf[64]; uint8_t g_rx_index = 0; // 开启UART1的单个字节接收中断 HAL_UART_Receive_IT(&huart1, &g_rx_byte, 1);开启后，每收到一个字节，硬件会触发中断，并通过HAL库回调把字节送进UART_RxCpltCallback。由于是单字节方式，回调函数里必须再次调用HAL_UART_Receive_IT，否则只收一次便不再接收。常见做法是把这一行重新调用放在回调末尾。
中断里只做一件事：把字节放进缓冲区，然后返回，尽量不做长任务处理。帧的完整性判断和校验放到主循环或者低优先级任务里，避免在中断里跑CRC计算，占用中断时间过长会丢下一个字节。
4.3 帧解析状态机：从裸字节到可靠报文
简单的缓存判断法不适合多变现场，因为总线上的噪声会插入随机字节，如果只是“收到5个字节就算一帧”，会出现帧错位。更可靠的是状态机解析帧头、长度、CRC。假设协议帧格式为：帧头0xAA、从机地址、功能码、数据长度、数据、CRC16低字节、CRC16高字节。
状态机实现如下：
typedef enum { FRAME_WAIT_HEAD, FRAME_WAIT_ADDR, FRAME_WAIT_FUNC, FRAME_WAIT_LEN, FRAME_WAIT_DATA, FRAME_WAIT_CRC_L, FRAME_WAIT_CRC_H } FrameState; FrameState g_state = FRAME_WAIT_HEAD; uint8_t g_frame[16]; uint8_t g_frame_len = 0; uint8_t g_expect_len = 0; uint16_t g_crc_calc = 0xFFFF; void parse_rx_byte(uint8_t byte) { switch (g_state) { case FRAME_WAIT_HEAD: if (byte == 0xAA) { g_state = FRAME_WAIT_ADDR; g_frame_len = 0; g_crc_calc = 0xFFFF; } break; case FRAME_WAIT_ADDR: // 如果不是本机地址，直接回到等帧头 if (byte != 0x01) { g_state = FRAME_WAIT_HEAD; } else { g_frame[g_frame_len++] = byte; g_state = FRAME_WAIT_FUNC; } break; case FRAME_WAIT_FUNC: g_frame[g_frame_len++] = byte; g_state = FRAME_WAIT_LEN; break; case FRAME_WAIT_LEN: g_frame[g_frame_len++] = byte; g_expect_len = byte; g_state = FRAME_WAIT_DATA; break; case FRAME_WAIT_DATA: g_frame[g_frame_len++] = byte; if (g_frame_len - 4 >= g_expect_len) { g_state = FRAME_WAIT_CRC_L; } break; case FRAME_WAIT_CRC_L: g_frame[g_frame_len++] = byte; g_state = FRAME_WAIT_CRC_H; break; case FRAME_WAIT_CRC_H: g_frame[g_frame_len++] = byte; // 校验CRC后处理完整帧 process_valid_frame(g_frame, g_frame_len); g_state = FRAME_WAIT_HEAD; break; } }状态机的好处是坏字节骚扰时能自动回到等帧头状态，不会把残缺帧当成有效数据。g_expect_len用来约束数据域长度，避免缓冲区越界。
CRC计算建议用查表法替代逐位计算，逐位计算在9600波特率、每帧十几个字节的中断里虽然也够用，但高波特率下会明显拖慢中断。资源包里的CRC16实现可以直接抄，替换成查表表后，代码量会多几十字节，换来的是每次计算省下几百个CPU周期。
5. 避坑指南：RS485开发中最常见的五个翻车现场
5.1 数据链路层的坑：丢尾、乱码、帧错位
现象1：每次通讯都是最后一字节丢失，主机发出的命令帧从机收不到，但从机直接把命令长度减一又有时能通。
原因：DE释放（拉低）的时机早于USART移位寄存器发完最后一个bit。HAL_UART_Transmit返回不表示线路空闲。TXE和TC的区别没吃透。
解决：发送函数里等待TC标志置位后再拉低DE。如果等待时间还不够，在TC后加一个µs级小延时，比如2到5微秒，让总线电平完全回到空闲状态，再释放DE。
现象2：自己写的代码在两块开发板之间通讯正常，接现场第三方设备就全部乱码，甚至收不到任何应答。
原因：第三方设备配置的是偶校验或标记校验，而工程里初始化成无校验；或者第三方设备波特率标称9600实际上晶振有偏差，双方采样点错位。
解决：先用逻辑分析仪抓一下对方发出的帧，确认实际波特率和数据位格式。如果对方固定使用偶校验，CubeMX里改为Even，协议栈去掉CRC，双方以偶校验作为唯一错误检测。如果对方波特率有偏差，把USART的BRR寄存器重新计算或改用更高精度晶振。
现象3：总线上所有设备正常通讯时，偶尔能收到一段连续的0xFF垃圾字节，而且只在设备上电瞬间出现。
原因：某个从机上电时GPIO处于高阻态，DE/RE引脚悬空，收发器方向不定，把总线拉乱。或者某个节点的收发器在供电不稳时产生毛刺。
解决：确认每个节点的DE/RE控制引脚在MCU初始化之前就被硬件下拉到地或默认拉低。初始化代码顺序上，GPIO_Init必须在UART_Init前面跑，保证上电后第一时刻处于接收状态。
5.2 物理层和拓扑结构的坑：毛刺、误码、不共地
现象4：线缆一延伸，从开始的偶尔误码变成频繁丢帧，示波器看波形边沿有台阶，信号上升沿之后跟了一圈阻尼振动。
原因：总线末端没有终端电阻，或者终端电阻加错了位置。反射信号叠加在数据信号上，接收端采样时正好撞上振铃，产生误判。
解决：在总线物理最远两个端点各接一个120Ω电阻，从机节点上不再重复添加。如果总线拓扑里存在明显的星型分支，把分支线尽量缩短，做不到就换手拉手的链式布线。整改之后用示波器看波形，台阶和振铃会明显收敛。
现象5：不同供电设备的RS485接口互相连接，雷雨天气或者大功率设备启停时频繁烧接口或误码严重。
原因：各个设备的GND之间存在电位差，RS485虽然靠差分传输抗共模干扰，但共模电压超过收发器的允许范围（一般是-7V到+12V）时，芯片会进入闩扣状态甚至损坏。
解决：各设备的GND用一根线连接起来，让共模电压处于芯片承受范围之内。如果距离远且现场电位差大，改为隔离方案：MCU侧和总线侧之间加数字隔离芯片，总线侧用隔离电源单独供电。隔离不意味着可以不共地，隔离只是把共模环路断开，两侧仍需各自有明确的参考点。
6. 不接串口也能验证：用差分波形和多节点压力测试收尾
RS485开发不能只靠逻辑分析仪抓协议，协议层正常不代表物理层可靠。我习惯在联调前先做一轮示波器检查，主机的A接探头CH1，B接CH2，数学通道设CH1减CH2，这样看到的是A、B之间的差分电平。
检查四个关键点：第一，空闲时差分电压必须是稳定的高电平，数值通常在200mV到1V之间，这代表总线有明显空闲态，不会把噪声误判成起始位；第二，帧起始的下降沿应该单一干净，没有台阶和多次抖动；第三，数据位中间的过冲幅度不要超过信号幅度的20%到30%，过冲过大说明终端匹配或布线拓扑还有问题；第四，两帧之间的间隔稳定，如果有总线竞争导致的毛刺，能看到波形在空闲电平中间出现非正常抖动。
波形检查通过之后，做一次多节点轮询测试。主机广播地址帧，从机各自回ACK，看有没有冲突和延迟。CRC16校验能兜住随机误码，但不能兜住总线竞争。
// 标准CRC16-Modbus查表法实现，用于从机回复帧校验 static const uint16_t crc16_modbus_tab[256] = { 0x0000, 0xC0C1, 0xC181, 0x0140, 0xC301, 0x03C0, 0x0281, 0xC240, // ... 省略完整256项表，工程模板里补充完整 }; uint16_t crc16_modbus(uint8_t *data, uint16_t len) { uint16_t crc = 0xFFFF; for (uint16_t i = 0; i < len; i++) { uint8_t idx = (crc ^ data[i]) & 0xFF; crc = (crc >> 8) ^ crc16_modbus_tab[idx]; } return crc; }CRC表项你可以直接从RTU规范里把256个数值一次性拷进来，查表法比逐位运算快很多，在主频72MHz的芯片上几乎不占时间。从那以后，我每次布RS485总线都会先画一张拓扑图，标出终端电阻和主机位置，再用示波器量一圈差分波形，最后才碰代码。这个习惯帮我躲掉了好几次现场返工，希望帮到你。
本文还有配套的精品资源，点击获取
