简介STM32-RS485-Modbus 是一份基于 STM32 HAL 库实现 RS485 通信与 Modbus RTU 协议控制的工程示例核心场景是通过串口发送指令驱动中菱轮毂电机 ZLAC8015D适合有嵌入式基础、想学习工业总线通信、熟悉模块化工程组织的开发者参考。压缩包共 187 个文件、约 1015KB以 .c/.h 源码和 STM32CubeMX 的 .ioc 配置为主线同时包含 CMake 构建脚本、Makefile 辅助文件以及编译生成的 .elf/.hex/.bin 固件头文件提供外设接口声明.c 文件落实 HAL 驱动.ioc 可重新生成初始化代码便于从底层到应用逐层理解。项目内含 RS485_TX 发送相关模块可对照学习串口波特率、校验位等参数配置以及 Modbus RTU 寄存器读写、报文组装与发送逻辑借助 CLion 的 CMake 工程结构还能了解 STM32 项目跨平台构建与调试流程。目前已有 1612 人学习整体工程文件类型多样、组织清晰适合作为 RS485 轮询控制、Modbus 协议分析和 STM32 工程搭建的实践参考资料。 最近在做现场数据采集8路传感器要汇聚到一个用STM32F103做主控的采集器里传感器侧通信链路选的RS485应用层协议定的Modbus RTU。这个组合业内太常见了说实话一开始我有点大意觉得不就是串口通信加个协议嘛结果从硬件电路到帧间隔再到现场联调踩了一路的坑。这篇就把整个STM32-RS485-Modbus项目的设计思路、电路方案、代码实现和调试过程完整写出来给准备做同类项目的朋友参考。这套方案能解决的问题很明确用STM32做主站或从站通过RS485总线在最长1200米的范围内挂接几十个设备按Modbus RTU协议进行可靠的读写操作典型场景包括PLC组网、传感器采集、仪表抄表、楼宇自控、充电桩通信等。后台也有人私信问过类似问题比如单独测试都正常怎么一接起来就不行这类问题大部分出在物理层和时序上跟协议本身关系不大这篇里我会重点讲这些细节。1. 项目整体设计与思路拆解1.1 为什么偏偏是STM32RS485Modbus先说选型逻辑。主控用STM32不是因为它性能多强而是它的UART外设足够丰富F103有3个USARTF407有6个3.3V逻辑电平又能直接接485收发器加上CubeMX可以快速生成初始化代码做工业通信类项目非常顺手。而且这个芯片生态成熟遇到问题资料一抓一大把团队接手成本也低。RS485能在这个项目里胜出核心是三点抗干扰、距离远、支持多点。RS485是差分传输靠A、B两线之间的电压差传数据共模噪声被天然抵消在电机、变频器多的现场比RS232稳得多。传输距离在100kbps下能做到1200米而RS232超过15米基本就废了。多点上标准RS485收发器接32个节点很轻松选低负载芯片可以到128个节点现场扩容不用改线路。相比之下CAN虽然也有差分和多点优势但CAN收发器和协议栈成本更高且主流仪表和PLC对外接口很少直接出CAN通用性不如RS485。Modbus则是应用层协议里最朴素的一个。它不需要额外授权费报文结构简单到可以用一个状态机加一个CRC函数跑完任何单片机都吃得下。更大的优势是生态几乎所有PLC、触摸屏、电力仪表、传感器都支持Modbus RTU或TCPSTM32设备做出来以后可以无缝对接市面上绝大多数上位机和组态软件。这种通用性在现场项目里价值极高也是我最终定这个组合的根本原因。1.2 通信拓扑、波特率与协议模式怎么定Modbus RTU典型拓扑是一主多从。总线设备分主机和从机从机地址范围1到2470是广播地址。所有通信由主机发起从机只能被动应答天然避免总线冲突。这次项目里8个传感器就是从站STM32是主站轮询读取每个传感器。波特率的选择需要权衡速度、距离和稳定性。很多人一上来就喜欢用115200但RS485距离拉长后高速更容易出错。我的经验是现场布线几十米以内、干扰不严重用57600或115200没问题如果走线超过一两百米或者现场有变频器老老实实降到9600或19200。9600看起来慢但Modbus一帧数据也就几个到几十个字节轮询几十个设备完全够用。有一点得提醒从机端尽量避免用DIP开关随意切换波特率调试时一旦主机从机波特率不一致排查起来非常费时间。协议模式上Modbus有RTU、ASCII和TCP三种。RS485串口场景下只用RTU每个字节用二进制传输效率高ASCII是给老系统用的帧长多一倍现在没必要碰TCP走以太网是另一个场景无法直接用RS485承载。所以这个项目不用犹豫直接上Modbus RTU后面所有实现都围绕它展开。2. 硬件电路设计收发器、自动收发与保护电路协议定了物理层也得稳不然什么协议都白搭。RS485硬件电路看着简单就一个收发器芯片加几个电阻但越是简单的东西越容易在细节上翻车。2.1 收发器选型与最小电路收发器芯片的选型表先放出来大家按自己系统电压对号入座芯片型号供电电压默认节点数适用说明SP34853.3V323.3V系统首选STM32直接连接MAX34853.3V32与SP3485基本兼容MAX4855V32经典款需5V供电和电平匹配ISO30825V/3.3V256自带隔离适合强干扰场景STM32是3.3V逻辑最省事的就是SP3485或MAX3485TXD和RXD可以直接接管脚不用额外做电平转换。我这次用的是SP3485单片成本两三块钱采购容易坏了也好替换。最小电路其实就六根线VCC、GND、A、B、RO接MCU_RX、DI接MCU_TX。DE发送使能和RE#接收使能要配合控制方向这个后面细说。A、B之间接120Ω终端电阻如果总线上有多个节点只在最远两端接中间节点不接。A线上拉到VCC、B线下拉到GND的偏置电阻也建议加上原因下一小节详细讲。2.2 方向切换自动收发电路的坑RS485是半双工同一时刻只能收或发所以DE和RE#必须配合控制。先说我的结论从机端我都用GPIO直接控制方向只有少数固定波特率、不需要频繁收发改动的点位才考虑自动收发电路。电商品上常见的自动收发电路核心思路是在TXD发送起始位时通过三极管和RC延时把DE拉高数据发完再自动落回接收态。好处是软件不用动方向引脚省一路GPIO。但它有两个隐患一是波特率高了之后RC参数和字节间隔对不上偶发丢字节或首字节错误二是单片机复位期间IO引脚状态不定DI可能被拉低总线会凭空出现一串0x00把整条链路上的其他设备都干扰到。我在现场就遇到过这种未解之谜最后拆掉自动收发电路换GPIO控制才彻底消失。GPIO控制方向很直接发送前把DE/RE#置高发出全部数据后延时一小段再拉低切回接收。这里有个细节最后一个字节必须等移位寄存器真正发送完再拉低方向脚否则最后一位的停止位会被掐掉。用HAL库的话发完数据要等发送完成标志位置位再延时几十微秒再拉低。数据量不大时这个方向切换的延时开销可以忽略。2.3 终端电阻、偏置电阻和保护电路这一节是我每次都要强调的好多通信不正常的现场问题都出在这几个电阻上。终端电阻必须120Ω这是RS485电缆特性阻抗决定的。长线上不加终端电阻信号到末端会反射回来和后面的信号叠加波形出现过冲和震荡波特率一高就没法看。但终端电阻也不是越多越好一个节点接一个120Ω会把总线负载拉崩。正确做法是物理布线两端各接一个中间节点不接。偏置电阻很多人会漏。RS485接收器的判定阈值只有±200mV空闲时如果总线上没人驱动A、B之间电压差可能落在-200mV到200mV这个不确定区里接收端输出就会乱跳单片机可能频繁进串口中断把帧拆得稀碎。解决办法是A线上拉、B线下拉给总线一个确定的空闲电平。偏置电阻怎么取值简单估算假设VCC3.3V上下拉各取560Ω到620Ω配合两端120Ω终端电阻空闲差分电压能到200mV以上接收器就能稳定判定逻辑1。如果没接终端电阻偏置可以取4.7kΩ到10kΩ。实在拿不准就用示波器量空闲时A、B间的电压差调电阻让它大于250mV最稳。保护电路按场景来。室内短距离A、B各接一个TVS管到地就够了比如SMBJ6.0CA能吸收静电和浪涌。室外或走线长、附近有雷电感应风险时再加气体放电管配合PTC做两级防护。TVS和气体放电管不能简单直接并联要串联PTC做退耦不然毛刺触发后放电管导通会把总线拉死。这个细节手册上一般不写但现场遇到过雷雨天后整条总线通信瘫痪的多半就是防护没做对。3. Modbus RTU协议实现报文、超时与CRC硬件稳定之后协议层就是核心工作。Modbus RTU报文结构非常简单但越简单越考验实现的严谨度。3.1 报文长什么样地址、功能码与寄存器Modbus RTU一帧数据的组成是固定的设备地址1字节 功能码1字节 数据区N字节 CRC16校验2字节低字节在前。看几个实际例子就懂了。读保持寄存器功能码0x03最常用。主机想读从站1、地址0x0000起始的2个寄存器发送的报文是01 03 00 00 00 02 C4 0B其中01是从站地址03是功能码00 00是寄存器起始地址00 02是寄存器数量C4 0B是CRC16校验值发送时低字节C4在前、高字节0B在后。从站正常应答01 03 04 12 34 56 78 0A 11解析一下01地址03功能码04表示后面有4个字节数据12 34是第一个寄存器值56 78是第二个寄存器值最后两个字节是CRC。写单寄存器用功能码0x06报文类似01 06 00 01 00 05加CRC含义是把从站1的寄存器0x0001写成0x0005。批量写用功能码0x10可以一次写多个连续寄存器。Modbus的数据模型分四种线圈Coil位可读写、离散输入Discrete Input位只读、保持寄存器Holding Register16位可读写、输入寄存器Input Register16位只读。传感器采集类项目里几乎只用保持寄存器和输入寄存器。我的做法是把所有采集值和状态信息映射到一段连续保持寄存器里功能码只实现0x03、0x06、0x10三个就够用了。3.2 帧间隔计算与超时判断RTU协议对时序有硬性要求帧内相邻两个字符的间隔不能超过1.5个字符时间两帧之间的间隔必须大于3.5个字符时间。主机发完一帧后从机必须在这个窗口内判断帧结束并解析否则两帧挤在一起从机会把两帧当一帧处理CRC必然出错。3.5个字符时间怎么算一个字符在8N1格式下是1起始位加8数据位加1停止位共10位。9600波特率下1个位的时间约104.17微秒一个字符约1.0417毫秒3.5个字符约3.65毫秒。所以在9600下接收端连续3.65毫秒没收到新字节就认为一帧结束。115200波特率时这个时间只有约0.304毫秒用主循环轮询根本来不及判断。STM32上有三种常见做法。第一种最省事用UART的IDLE中断一帧传输结束总线进入空闲态硬件自动触发中断配合DMA接收几乎不耗CPU我推荐这种。第二种是定时器方案每个字节到达时重置定时器定时器溢出就认为帧结束。第三种是串口中断逐字节接收配合SysTick计时帧结束标志在定时器回调里置位。选哪种取决于波特率115200以上建议DMA加IDLE9600到19200用哪种都行。3.3 从机状态机与CRC16实现协议栈部分建议不要硬编码整个帧而是写一个接收状态机。状态机的好处是不管以后加多少个功能码接收逻辑都不用动。简化版思路typedef enum { IDLE, // 等待地址 RECV_FUNC, // 收到功能码 RECV_DATA, // 接收数据区 RECV_CRC, // 接收CRC } recv_state_t;每个字节进来先塞进接收缓冲区CRC校验通过后根据功能码进入对应的处理函数生成响应数据计算CRC再发送。具体实现时帧长度要根据功能码类型判断比如0x03的请求固定是8字节0x10的请求要通过数据区里的字节数字段来定长度。这个细节要特别小心很多人在这里解错包。CRC16的代码不长但不要自己发明算法直接按标准来。Modbus的CRC16多项式是0x8005反向算法用0xA001初值0xFFFF生成结果低字节在前发送。核心代码如下uint16_t modbus_crc16(const uint8_t *data, uint16_t len) { uint16_t crc 0xFFFF; for (uint16_t i 0; i len; i) { crc ^ data[i]; for (uint8_t j 0; j 8; j) { if (crc 0x0001) crc (crc 1) ^ 0xA001; else crc 1; } } return crc; }如果MCU性能紧张可以把这个函数换成查表法把256个CRC结果提前算好存到Flash里速度能快不少。我通常会在代码里保留两种调试用计算法量产用查表法。CRC位置错了、高低字节搞反是最常见的两个低级错误写完后先用下面要讲的Modbus Poll模拟工具对一遍能少走好多弯路。4. 调试实战从连不上到稳定通信代码写完真正的考验才开始。调试RS485加Modbus这个组合我踩过的坑基本可以归纳成下面几类。4.1 单独测试正常、连上就不正常这个现象很好理解主机从机分别用Modbus Poll、串口助手测都正常一接起来不是没应答就是乱码。八成是下面几个问题按顺序查。第一A、B两根线是不是接反了。485标的是A、B-但有些设备的端子标注方式和你的理解不一致直接用万用表对调一次最快。第二共地问题。RS485是差分没错但收发器输出的共模电压需要参考地总线上各设备最好共GND完全隔离点对点通信还得两端各接一个120Ω终端和偏置。第三参数一致性。主机从机的波特率、数据位、校验位、停止位必须完全一致尤其是校验位从机设了偶校验、主机用无校验帧对不上CRC必错。第四方向切换时序不对从机应答前主机还处于发送态DE没拉下来总线被主机自己拖着从机根本发不出数据。这种整体链路不通的问题最有效的办法是分段验证。先把STM32从机单独接USB转485再连电脑用Modbus Slave模拟从机、Modbus Poll模拟主机确认单端没问题。然后两台设备直连用逻辑分析仪或示波器挂在A、B线看波形确认有正常数据帧。波形有了但协议不通基本就是字节参数或CRC的问题跟物理层无关了。4.2 通信时好时坏、偶发乱码比完全不通信更头疼的是大多数时候正常偶尔抽风。这种情况我的排查顺序是固定的。先查空闲态总线电平。用万用表或示波器量A、B之间电压差正常情况应该在200mV以上且电平稳定。如果接近0或缓慢飘动就是缺偏置电阻补上就好。再查终端电阻是不是只在总线两端各一个中间节点有没有多接特别是有些现成的485模块板上已经焊了120Ω终端现场再并联一个等于把总线阻抗拉低。再查走线和地环路485线不要跟动力电缆绑在一起走屏蔽层选一端接地不要两端都接形成地环路。干扰严重时把波特率降到9600波形明显会干净很多。还有一个隐蔽坑收发方向切换太快或太慢。太快导致最后一位被截断太慢导致响应帧开头被自己接收端回读占用接收缓冲区干扰下一帧解析。用GPIO控制方向的在发送完成后加50到200微秒延时再拉低方向脚基本能覆盖大多数波特率。4.3 调试工具Modbus Poll/Slave和串口助手配合用法调试工具这块Windows下最常用的是Modbus Poll模拟主机和Modbus Slave模拟从站官方有试用版功能够用。再配合一个支持Hex显示的串口助手先把原始报文看清再套协议工具看解析结果。我的调试流程是第一步串口助手直接发十六进制报文比如01 03 00 00 00 02 C4 0B看从站返回什么。返回的原始数据对说明从站UART收发和CRC没问题。第二步再用Modbus Poll配置好串口号、波特率、校验位填写从站地址、功能码、寄存器地址和数量看解析出来的寄存器数值是否正确。第三步如果要测主机端就用Modbus Slave模拟从站设备看STM32主站发过来的请求以及对从站响应的解析。逻辑分析仪在这个场景下比示波器好用便宜、能长时间抓波形、还能解码UART。把探头夹在MCU的TXD和RXD上抓协议层数据夹在A、B线上看物理层波形定位问题非常快。我有一次抓波形发现A、B间差分信号幅值只有120mV怎么调都上不去查了半天是收发器供电脚虚焊这种问题光看协议层是永远发现不了的。4.4 no stm32 target found这类下载调试坑最后补一个和通信无关但和STM32项目强相关的坑。开发过程中用ST-Link给STM32下载程序有时会弹error: no stm32 target found! if your product embeds debug authentication, pl...这种报错连不上目标。刚接触的人容易慌其实排查思路很固定。第一看目标板供电ST-Link给板子供电的3.3V引脚有没有接好。第二看SWDIO、SWCLK两根线有没有接反GND是不是共地。第三ST-Link驱动装没装设备管理器里能不能正常识别。第四目标芯片有没有被读保护或烧过保险位用ST-Link Utility或CubeProgrammer试一下解除读保护。还有个土办法我一直在用按住板子复位键点击下载松开复位键让ST-Link在芯片上电瞬间抢到调试接口对付某些奇怪的连不上特别管用。做这个项目最大的体会是RS485和Modbus这套组合看起来老但它能在工业现场活这么多年靠的就是简单和可靠。真正决定项目成败的往往不是协议栈写得多花哨而是物理层的每一个细节——收发器选型、偏置电阻、终端匹配、方向切换、帧间隔——有没有做到位。如果你也正在调一套485通信建议先把万用表和示波器准备好按这篇文章的顺序把物理层过一遍再回头查协议会省下大量时间。本文还有配套的精品资源点击获取
