STM32实现RS485通信：从硬件接线到Modbus轮询完整指南

简介这是一份基于STM32F103的RS485通信完整工程示例面向嵌入式初学者与工业现场应用开发者解决UART转RS485通信中的电平转换、收发切换与多节点组网问题可迁移至远程监控、数据采集等场景。工程共122个文件、压缩包826KB主体为STM32标准外设库的C源码、H头文件以及汇编启动文件覆盖定时器、USART、GPIO等驱动模块另含Keil工程配置、hex烧录文件、PDF原理说明和串口调试参考便于直接编译烧录。开发中涉及的485驱动器如MAX485接线、DE/RE方向控制、波特率初始化以及中断收发流程在代码与文档中均有对应呈现。目前已有5516人学习下载适合希望结合完整模板理解软硬件配合、并快速验证RS485通信逻辑的开发者。1. 有的项目跑了一年还在靠点表沟通STM32 的 485 通信到底难在哪某次去一个现场调试环境监测设备80 米外配电柜里的 6 块仪表要读数据RS-232 拉不过去Wi-Fi 在地下室完全没有信号。我拿一块 STM32 最小系统板加一片 485 收发器连夜把「STM32 实现 485 通信」这套工程跑通第二天采集链路就上线了。485 协议本身不算新东西可真让 STM32 的收发稳定下来细节全在方向切换那一两百微秒里——DE 拉早了抢不到总线拉晚了丢帧尾这是第一次上手 485 翻车最集中的地方。这套工程覆盖硬件接线、CubeMX 初始化、串口收发、帧拼包和 Modbus 轮询的完整写法适合正在做工控采集、或者想从串口调试切到现场总线通信的开发者参考。2. 架构设计从 STM32 串口到 485 总线的完整信号链路动手写代码前先把 485 到底是什么、为什么 STM32 接它要多一根控制线这件事理清楚。很多半路转工控的开发者习惯把 485 当成「串口的延长线」结果代码写得像 RS-232一上总线就各种玄学问题。实际上 485 和 STM32 内部那个 UART 外设之间隔着一层负责电平转换和方向控制的物理层芯片搞清楚这层芯片后面所有代码才好写。2.1 为什么选 485 而不选 TTL、RS-232 或 CAN先把几种接口放在一起比就知道为什么工控现场天天见 485。TTL 电平距离近、抗干扰差只能板内通信RS-232 是单端电平标称 15 米左右现场拉线根本不现实CAN 总线在确定性和速率上确实更强但要额外处理显性隐性电平、仲裁和隔离对「读一批仪表采集数据」这种需求来说设计和成本都偏高。485 用差分信号传数据两条线一正一反共模干扰被差分接收抵消所以能把距离拉到 1000 米以上一条总线还能挂 32 个节点这正是大多数工控采集场景的甜区。接口电平方式节点数典型距离典型速率典型场景TTL单端 3.3V/5V1 对 1几十厘米随意板内通信RS-232单端 ±12V1 对 1约 15 米115.2kbps 以内近距离点对点RS-485差分最多 32 节点约 1200 米10Mbps 以内工业总线、多机采集CAN差分可达上百节点约 1000 米1Mbps 常规车载、自动化控制这套工程里我采用最常见的组合STM32F103 系列芯片加上一颗 MAX485/SP3485 收发器模块。模块把 UART 的 TX/RX 单端信号转成 A/B 差分信号同时输出一个方向控制脚。有些模块自带光耦隔离和 DC-DC 隔离电源现场地电位混乱的时候我一般会直接用隔离型几十块钱换一块收发器不被烧掉算下来很值。2.2 关键信号链路DE/RE、RO、DI 与方向切换原理MAX485 这类收发器有四个关键信号RO 是接收输出接 STM32 的 RXDI 是发送输入接 STM32 的 TXDE 是发送使能高电平有效RE 是接收使能低电平有效。常用模块会把 DE 和 RE 合并成一个引脚一根线控制收发方向高电平走发送低电平走接收。这就是 485 比普通串口多出的那根「脖子上的绳」。485 模块引脚接 STM32 引脚作用说明ROPA10 / USART1_RX总线差分信号转为 TTL 后送给串口接收DIPA9 / USART1_TX串口发送数据进入收发器转成差分信号上总线DE/REPB1任意 GPIO高电平发送、低电平接收半双工方向切换VCC/GND3.3V 或 5V 供电确认模块电平兼容隔离型还要接隔离侧电源A/B总线两根差分线A 接 A、B 接 B末端加 120Ω 终端电阻半双工的本质是同一时刻只能收或发所以 DE 切换必须和串口发送完成时刻严丝合缝。DB9 串口有专门握手线做流控485 没有DE 完全由软件控制。这里有个常见误区发送函数返回不代表数据已经发完串口外设里还有一个移位寄存器它把数据一位一位移出总线是需要时间的如果 DE 切换早了帧尾就被自己掐掉切换晚了又可能错过对端响应。这就是我在开头说的「那一两百微秒」。总线布线也要提一句。末端那两颗 120Ω 终端电阻不是摆设长线传输时信号会在末端反射终端电阻做阻抗匹配吸收反射波波形才干净。另外总线空闲时 A/B 之间要有偏置否则线路悬空接收端会随机读到 0xFF 垃圾字节表现为「没数据时不停地收到 0xFF」。大多数成品模块已经焊了偏置电阻自己搭电路时按数据手册加上拉下拉即可。3. 核心代码拆解一个请求从发送到收到响应的完整链路芯片和接线定下来代码分三段走初始化、发送、接收。这套工程用 HAL 库实现CubeMX 生成底层配置业务层只留 RS485 驱动和协议处理。下面这段代码就是整个工程的核心可以直接抄到自己的工程里改引脚和串口编号。3.1 初始化串口参数与 485 方向引脚的配置先看 GPIO 初始化。485 方向引脚是个普通推挽输出但有一个细节很多人忽略上电瞬间默认应该拉低让收发器处于接收态。理由很简单STM32 启动过程中 GPIO 状态不确定如果 DE 被拉高板子一上电就开始占用总线总线上其他节点全部发不出数据。/* 485 方向控制引脚 PB1高电平发送低电平接收 */ void RS485_GPIO_Init(void) { GPIO_InitTypeDef GPIO_InitStruct {0}; __HAL_RCC_GPIOB_CLK_ENABLE(); GPIO_InitStruct.Pin GPIO_PIN_1; GPIO_InitStruct.Mode GPIO_MODE_OUTPUT_PP; /* 推挽输出 */ GPIO_InitStruct.Pull GPIO_PULLUP; /* 默认上拉 */ GPIO_InitStruct.Speed GPIO_SPEED_FREQ_HIGH; /* 高速翻转 */ HAL_GPIO_Init(GPIOB, GPIO_InitStruct); /* 上电默认进入接收态避免抢占总线 */ HAL_GPIO_WritePin(GPIOB, GPIO_PIN_1, GPIO_PIN_RESET); }参数说明推挽输出是必须的开漏输出拉不高电平速度选 High保证 DE 翻转沿够陡低速模式在长线下可能让方向切换沿变缓偶发第一字节丢失默认上拉配合上电拉低让模块上电后先保持接收。串口本身的初始化由 CubeMX 生成波特率 9600、8 位数据、无校验、1 停止位这是工控仪表最常见的默认参数后面第四章会列完整配置。3.2 发送流程先切方向、再发数据、确认发完再切回发送函数是整个工程最关键的部分。简化后的逻辑只有四步拉高 DE、等方向稳定、发数据、等发送真正完成、拉低 DE。第四步常常被写丢。void RS485_Send(uint8_t *buf, uint16_t len) { /* 1. 切到发送模式DE 拉高 */ HAL_GPIO_WritePin(GPIOB, GPIO_PIN_1, GPIO_PIN_SET); /* 2. 等待收发器内部方向切换稳定常见做法是延时 50us */ delay_us(50); /* 3. 阻塞发送超时 1 秒 */ HAL_UART_Transmit(huart1, buf, len, 1000); /* 4. 等移位寄存器真正把最后一位移出TC 置位才说明发完了 */ while (__HAL_UART_GET_FLAG(huart1, UART_FLAG_TC) RESET); /* 5. 切回接收态等待对端应答 */ HAL_GPIO_WritePin(GPIOB, GPIO_PIN_1, GPIO_PIN_RESET); }逻辑说明第 2 步的延时给收发器留出使能时间MAX485 的驱动器从使能到信号稳定在微秒量级50us 算保守值够用也简单。第 4 步是血泪经验的集中点——HAL_UART_Transmit 返回只表示数据进了发送数据寄存器不代表移位寄存器已经清空尤其 9600 波特率下一个字节就要约 1ms。不同版本 HAL 的 Transmit 实现有差异有的只等到 TXE 就返回有的会等到 TC与其赌库的版本行为不如显式轮询 TC。TC 置位后再拉低 DE帧尾一个字都不会丢。如果发送改用 DMA方向切换逻辑移到发送完成中断回调里做即 HAL_UART_TxCpltCallback 中拉低 DE。用 DMA 的好处是 CPU 不被阻塞代价是回调里切 DE 的时机同样要遵循「TC 再切」的原则DMA 完成中断发生时数据已经移出这里反而比阻塞版更自然。3.3 接收流程中断逐字节拼帧与帧完成判定接收用串口中断逐字节收。为什么不用 HAL_UART_Receive_IT 一次性收一长串因为 485 是半双工帧长度不固定收方根本不知道对端要发多少字节。逐字节接收的好处是能记录每个字节的时间戳用空闲间隔判断一帧是否结束这套办法在 Modbus RTU 场景里很实用。volatile uint8_t rs485_rx_buf[256]; /* 接收缓冲区 */ volatile uint16_t rs485_rx_len 0; /* 当前帧长度 */ volatile uint32_t last_rx_tick 0; /* 上个字节到达时间 */ void RS485_StartReceive(void) { rs485_rx_len 0; HAL_UART_Receive_IT(huart1, (uint8_t *)rs485_rx_buf[0], 1); } void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART1) { uint32_t now HAL_GetTick(); /* 距上个字节超过帧间隔阈值认为是一帧新开始 */ if (now - last_rx_tick frame_gap_ms) { rs485_rx_len 0; } last_rx_tick now; if (rs485_rx_len sizeof(rs485_rx_buf) - 1) { rs485_rx_len; } /* 继续接收下一字节 */ HAL_UART_Receive_IT(huart1, (uint8_t *)rs485_rx_buf[rs485_rx_len - 1], 1); } }逻辑说明每收一字节进入回调先看它与上一字节的时间差。如果间隔超过 frame_gap_ms说明这是一帧新数据的开始把长度清零重新计数。Modbus RTU 的规范是帧内字符间隔小于 1.5 个字符时间、帧间间隔大于 3.5 个字符时间9600 波特率下 3.5 个字符约 3.6ms所以 frame_gap_ms 设 4 足够。用 HAL_GetTick 做粗粒度判断适合 9600 波特率如果换到 115200 这种高速率字符时间缩短到 0.1ms 量级毫秒级 Tick 就不够精细了那时我一般会改用定时器计数器或者串口 IDLE 空闲中断收整帧代码复杂度上一个台阶。接收回调里还有个隐藏问题每次重新调用 HAL_UART_Receive_IT 传入的地址要和当前长度对应否则新字节会覆盖旧字节。上面代码里先递增长度再以rs485_rx_buf[rs485_rx_len - 1]为地址就是保证每个字节各就各位。实际工程里我还会在回调里加一个 overrun 保护收到 255 字节还没断帧就从协议上判定非法帧强制清空。4. 跑通工程CubeMX 配置、回环测试与点对点通信验证代码有了接下来把工程从零跑起来。这一章按顺序写实际操作步骤先配置 CubeMX再做回环测试验证链路最后两板点对点通信。每一步验证通过再走下一步避免出了错不知道是硬件还是软件问题。4.1 CubeMX 工程初始化的参数速查CubeMX 里需要重点确认的是串口参数、方向引脚、时钟源和中断开关。以下配置是按这套工程来的如果你的板子引脚不同改引脚映射即可参数本身可以直接抄。配置项值说明USART1 模式Asynchronous异步串口不使能硬件流控波特率9600先低速调通再拉高到 115200 验证数据位/校验/停止位8 / None / 1标准 8N1工控仪表通用PB1 GPIOOutput Push-Pull, Pull-up, High Speed485 方向控制脚时钟源HSE 外部晶振 - PLL - 72MHz别用内部 RC 时钟高速下波特率会偏NVIC开启 USART1 全局中断接收依赖串口中断不开回调永远不触发时钟源这条单独强调。STM32 内部 RC 振荡器精度在 1% 左右9600 波特率下影响不大但上了 115200 后累计误差会超过 UART 容错范围表现为偶发乱码或者 CRC 校验频繁失败。所以时钟树一定要走外部晶振这也是排查「代码看起来没问题但就是跑不稳」时的第一检查项。GPIO 初始化代码在第三章已经给了CubeMX 生成的MX_GPIO_Init和MX_USART1_UART_Init不用手动改只需要把 PB1 的配置核对一致然后在用户代码区调用RS485_GPIO_Init和RS485_StartReceive即可。4.2 先把模块自己收自己回环调试技巧485 是差分总线最直接的链路验证方法是让收发器自己收自己——把模块的 A、B 端子直接短接或者用杜邦线把 A 和 A、B 和 B 连成一个环路。这时模块发送的差分信号立刻回到自己的接收端相当于把总线短路成一条自环。配合电脑端的 USB 转 485 模块可以做单向验证。操作步骤分三步第一步电脑的 USB 转 485 模块 A 接板子 485 模块 AB 接 B串口助手打开对应 COM 口参数设 9600/8N1。第二步让板子循环发送一帧已知数据比如01 03 00 00 00 05如果电脑串口助手收到一模一样的内容说明「板子发送 - 差分线 - 电脑接收」这段链路通。第三步电脑串口助手手动发一帧在 STM32 调试器里观察 rs485_rx_buf 是否出现对应字节通的话「电脑发送 - 板子接收」也验证完毕。注意电脑端的 USB 转 485 模块尽量选带方向自动切换或跳线可配置的廉价模块方向切换硬编码在固件里帧间间隔会插入杂码这种干扰会让人误以为板子代码有问题。如果手头只有这种模块可以在电脑侧发完一帧后手动加几百毫秒间隔再发下一帧。4.3 点对点实测两块板子一问一答回环验证通过以后把总线上的自环拆掉用一块板子做主机、另一块做从机写最简协议验证一问一答。主机发送查询帧从机收到后先判断是不是发给自己的地址再回一帧应答数据。从机侧代码只要在第四章的接收回调后面追加一个协议处理函数帧收齐后检查首字节地址匹配则调用 RS485_Send 回帧。这一阶段最容易出的问题是主机发完查询帧后立刻把 DE 切回接收态但总线上的信号还没完全消失主机可能收到自己发送的残留帧这在短距离测试时尤其明显。解决方法是协议层加一个简单的地址过滤只有从机地址匹配的帧才处理主机收到自己的残留帧直接丢弃。另外帧间间隔要留足从机从收到帧到调用 RS485_Send 之间需要做 CRC 校验和协议解析我一般会在主机侧等 5ms 以上再发下一帧给从机留出处理时间也避免总线冲突。两块板子距离很近的时候终端电阻其实不接也能通信但波形会有明显过冲接上 120Ω 终端电阻后波形干净很多。养成习惯从第一块板子开始就把终端电阻放在总线的物理两端和距离无关。5. 避坑指南485 调试里常见的 5 个现场问题下面这五条全是实际调过的坑每条按「现象、原因、解决」写基本覆盖了从焊接到底层驱动的多数问题。5.1 帧尾巴被自己的 DE 拉断现象主机和从机都能收发但主机收到的响应帧最后总缺一两个字节CRC 校验永远不过或者从机收到主机的查询帧长度时对时错。原因发送函数返回后立刻把 DE 拉低UART 移位寄存器还没把最后一个字节完全移出总线帧尾被自己切断了。前面 3.2 节说过HAL_UART_Transmit 的返回时机取决于库版本有的只等到 TXE数据还在移位寄存器里。解决在拉低 DE 之前显式等待 TC 标志置位或者延时一个字节的传输时间再加余量。用代码块表述就是while (__HAL_UART_GET_FLAG(huart1, UART_FLAG_TC) RESET);这一行。从那以后我每写一个 485 发送函数第一件事就是确认 TC 等待有写。5.2 A/B 极性接反导致数据全是乱码现象万用表量 A/B 都有电压变化示波器能看到波形但串口助手收到的全是乱码或者干脆收不到任何数据。原因485 是差分信号逻辑 1 和 0 靠 A、B 之间的压差方向表示A/B 接反后差分方向反转1 变 0、0 变 1。有的调试者把 A 接 B、B 接 A或者两端的模块一端正一端反都会出现这种「有信号但全是错」的玄学问题。解决统一约定 A 接 A、B 接 B两端用同一线色。好的 485 模块会有收/发指示灯发送时 TX 灯闪、接收时 RX 灯闪通过灯的状态能确认方向是否正确。实在不方便拆线的时候也可以在软件里实现 AB 反接兼容即在初始化时允许通过配置项交换映射但正常产品还是要从接线端解决。5.3 终端电阻和偏置电阻叠加导致信号畸形现象总线上挂了三块板子每块都接了 120Ω 终端电阻通信距离一长就误码总线空闲时会持续收到 0xFF。原因终端电阻的目的是让总线末端阻抗匹配只在物理两端各放一个多放会把差分信号幅值拉低接收端电平余量不足空闲偏置则是保证 A/B 悬空时不进入不定态没有偏置或偏置太弱接收端会随机输出高电平表现为一堆 0xFF 垃圾字节。解决检查总线上终端电阻的位置拆掉中间节点的 120Ω只保留物理两端各一个。如果模块没有自带偏置在 A 线到 VCC 加一个 4.7kΩ 上拉、B 线到 GND 加一个 4.7kΩ 下拉给空闲总线一个确定的空闲电平。5.4 内部 RC 时钟误差导致高速波特率错帧现象9600 波特率下一切正常改成 115200 后偶发帧错误和乱码用逻辑分析仪抓波形发现每一位宽度有偏差。原因内部 RC 时钟精度约 1%低速下容错空间大高速下一位的时间误差累加起来超过 UART 接收端的采样容错范围导致起始位或停止位采样错误。这属于典型的「板子能跑但运行不稳定」。解决时钟树改用外部晶振通过 PLL 倍频到 72MHzUSART 时钟经过分频后波特率误差降到 0.1% 以内。改完时钟后注意重新配置 USART 波特率寄存器CubeMX 会在时钟变化后自动重新计算但如果你手写寄存器配置要重新算 BRR 值。5.5 节点间不共地导致收发器烧毁现象两块板子单独通信正常挂到同一个总线上以后偶尔某块板子的 485 收发器发烫甚至损坏通信中断。原因485 的差分特性只保证 A/B 两线之间的信号有效但每块板子的 GND 如果不连各节点地电位不一致共模电压可能超过收发器的允许范围通常 -7V 到 12V轻则误码重则击穿收发器。这是「485 是差分就不需要共地」这个认知误区踩出来的坑。解决短距离、节点数量少时直接把各板子的 GND 连到总线形成单点共地现场地电位复杂时改用隔离型 485 收发器。隔离型模块内部用数字隔离器加隔离 DC-DC把通信侧和 MCU 侧的地完全分开共模电压被隔离层吸收这也是我前面提到的「直接上隔离模块更省心」的出处。最好在设计和选型阶段就决定是否隔离产品运行几个月后换收发器是最折腾的事。6. 二次开发从点对点到 Modbus RTU 多机轮询的工程改造点对点问答应答跑通后离「可用的采集网关」还差一步把总线从两块板子扩到多块从机。改造路线按三步走第一步在帧里加地址字段从机只在地址匹配时响应第二步做 CRC16-Modbus 校验保证反复的现场环境里误码不会被当成有效数据第三步主机维护一张设备地址表按顺序轮询超时则跳到下一台设备。这套改造有一个很关键的状态机思维主机永远以固定节奏发查询、等应答、收超时就跳过从机永远处于被动接收状态。CRC16-Modbus 是应用层协议绕不开的底料工程里直接用查表法最快。生成多项式是 0xA001初始值为 0xFFFF逐字节查表更新。核心实现如下uint16_t CRC16_Modbus(uint8_t *buf, uint16_t len) { uint16_t crc 0xFFFF; for (uint16_t i 0; i len; i) { crc ^ buf[i]; /* 异或进新字节 */ for (uint8_t bit 0; bit 8; bit) { if (crc 0x0001) { crc (crc 1) ^ 0xA001; /* 多项式 */ } else { crc 1; } } } return crc; }逻辑说明每一次只要最低位是 1 就右移并异或多项式否则直接右移查表法本质上就是这张移位表的预计算版本。发送时把 CRC 低字节放前面、高字节放后面这是 Modbus 的字节序约定和很多人习惯的高字节在前正好相反写协议解析时注意别掉坑里。多机轮询的主机代码其实不复杂一个轮询状态机加一张设备地址表就够。核心是「超时即跳过」这个原则一台设备掉线不能阻塞整条总线超时时间按响应帧长度加余量计算9600 波特率下我一般设 100ms既能给从机留够处理时间又不会让整轮轮询太慢。调试时打开串口日志把「发查询、等应答、收超时」三个事件都打印出来整个网络的健康状态一眼就能看清。说到底485 的二次开发难点不在协议算法本身而在「用总线思维代替串口思维」。串口天然是点对点双向自由通信485 半双工必须由一个角色主导总线节奏谁发、何时发、发完多久切听、超时多久跳过这些时序都要提前定好。这是我做这套工程最大的教训不要一上来就写应用逻辑先把方向切换时序图和轮询状态机画清楚再让代码往里填。从那以后我每次做 485 通信工程都会强制自己先写一个回环测试脚本再往上叠业务帧。希望帮到你。本文还有配套的精品资源点击获取