简介面向嵌入式开发者与自动化工程师提供STM32F103实现RS485通信的完整工程源码包。工程基于标准外设库实现了UART初始化、波特率与数据位配置、485方向引脚DE/RE自动切换、发送完成与接收中断处理并包含超时/溢出等错误检测逻辑读者可据此掌握RS485半双工通信的收发时序控制方法。资源共122个文件以C源码、H头文件、启动汇编、Keil工程配置为主附带可直接烧录的hex文件、PDF与doc说明文档、清除编译中间文件的bat脚本资源包大小约826KB。已有5507人学习。压缩包内目录结构清晰演示了结合MAX485芯片从硬件连接到软件配置、再到串口助手调试的完整流程并提示终端电阻匹配、总线冲突避免、多节点地址识别等工程注意事项适合竞赛备赛、课程设计和实际项目快速移植。 不知道你有没有经历过这种情况在车间里调一台伺服驱动器电脑和PLC都在总线上你的STM32开发板插上去数据发不出去偶尔收到一堆乱码甚至整个总线都被“拉死”。把波特率改低、把线重新接一遍还是不行。折腾一晚上最后发现是方向控制引脚没拉对或者A、B两根线接反了。这种场景在工业现场太常见了而它背后的主角就是RS485。RS485这些年几乎成了工业通信的默认选项我的STM32项目里十个有八个都要用到它从Modbus仪表、伺服驱动器、变频器到温湿度传感器、电表、条码枪只要是长距离、多节点、抗干扰要求高的场景基本都是485上场。这篇就围绕STM32如何实现485通信来写从硬件电路选型到软件收发状态机再到现场调试最容易踩的坑一次说清。1. RS485为什么这么多项目在用设计前要想清楚什么1.1 485相比232、422、I2C、SPI到底强在哪先说个最容易混淆的点RS485不是一种像SPI、I2C那样的完整通信协议它只是物理层标准。你跑在RS485上的还是UART那套数据帧格式波特率、起始位、数据位、停止位这些和串口一模一样。所以你在STM32上做485本质就是调一个UART外设再额外控制一下收发方向。那为什么不用RS232主要差在三点。第一是距离RS232一般15米就到头了RS485在低速情况下能到1200米工厂车间几十米上百米的布线非常常见。第二是多节点RS232天生只能点对点RS485通过总线挂载标准负载下能挂32个节点。第三是抗干扰RS485用差分信号传输两根线A和B互为参考外界噪声同时叠加到两根线上接收端只判断A-B的电压差共模干扰被抵消掉这在变频器、电机旁边尤其重要。和I2C、SPI这类板级总线比485的优势在于它把物理层放到了外部收发器芯片上电平是差分信号不是单端电平所以能长距离传输。SPI的SCLK、MISO、MOSI三根线跑到半米开外就各种丢数据485上百米还能稳定运行。说到底选485不是因为它的协议有多先进而是它在工业现场这种恶劣条件下用最少的线两根和最便宜的成本实现了可靠的长距离多点通信。这就是它几十年还没被淘汰的根本原因。1.2 半双工的方向控制是整个设计的核心矛盾485总线是半双工工作方式同一时刻总线上只能有一个节点在发送其他节点都在接收。如果两个节点同时拉高发送总线就会冲突数据全乱。这就是为什么每个485节点都要有一个方向控制的概念。收发器芯片内部其实有两个放大器一个把总线上的差分信号转换为单端信号送给STM32的RX引脚另一个把STM32的TX引脚的信号转换为差分信号输出到总线。这两个放大器由芯片上的DE引脚和RE引脚控制。DE是发送使能高电平有效RE是接收使能低电平有效。很多芯片像MAX485、SP3485内部已经把DE和RE逻辑反相处理好了所以你可以把DE和RE直接短接成一个引脚拉高就是发送模式拉低就是接收模式。这里有一个设计方案的选择可以用GPIO软件控制方向也可以用带自动方向检测功能的收发器比如MAX13487来自动切换。自动方向芯片看起来省事少占一个GPIO但在高速、长线、总线节点多的场景下方向切换时序不完全受控偶尔会出莫名其妙的丢帧。我自己的习惯是用GPIO手动控制方向代码只多两行但每一个时序细节都在自己手里排查问题的时候心里有底。后面所有代码和电路都按手动GPIO控制方向的方案来讲。2. 硬件电路这么接才不容易翻车2.1 收发器芯片选型与外围电路做STM32项目时收发器芯片一般从MAX485、SP3485、MAX3485里选。STM32是3.3V供电所以最推荐SP3485或者MAX3485它们是3.3V供电版本RO和DI电平可以直接和STM32的GPIO对接不需要电平转换电路。MAX485是5V供电的如果系统里本来就有5V电源也能用但RO输出高电平是5V直接进STM32的RX引脚会有风险最好串联电阻或者用分压处理。节约成本没问题但稳定性优先的话选3.3V版本最省心。典型的外围电路这样接STM32的TX引脚接收发器的DIRX引脚接收发器的RO。收发器的RE和DE短接后接一个STM32的空闲GPIO比如PB0。A和B两根线引出到接线端子A接双绞线的一根B接另一根。在A和B之间加一个120欧终端电阻。在A线上加一个上拉电阻到3.3VB线上加一个下拉电阻到GND一般用1k到10k。这个偏置电阻的作用是保证总线空闲时A-B的电压差不在不确定区否则接收端会输出随机电平产生乱码。A、B线上各串一个TVS管到GND保护收发器芯片不被静电或浪涌打坏。终端电阻和偏置电阻的取舍值得展开说一下。120欧终端电阻是为了匹配双绞线的特性阻抗减少信号反射。但它只应该加在总线物理线路的两端不是每个节点都加。如果你的STM32节点正好位于总线末端那就在你的板子上加如果在中间就别加加了反而会增大负载拉低信号幅度。一个典型的Modbus总线最远端的两个设备各加一个120欧就对了。偏置电阻很多人会忽略但它恰恰是发数据正常空闲时乱码这类问题的关键。阻值选多大取决于总线上挂了多少个节点因为每个节点的收发器都有输入阻抗会分压。标准做法是让总线上所有偏置电阻并联后在A-B之间形成的静态压差大于200mV。按经验一个节点典型偏置用10k到20k也能工作但如果总线长、节点多建议用1k到4.7k更稳。我通常直接用2k效果稳定。2.2 与STM32的接线及共地问题接线端子这里有个特别容易踩的坑RS485连接必须A对A、B对B不能像RS232那样交叉。很多人第一次用485转USB工具接STM32板子顺手按232的习惯把A接B、B接A结果数据完全不通还以为是波特率问题。用万用表量一下波形就明白了A、B接反时波形是反相的接收到的数据全是乱码。共地问题更要重视。RS485虽然是差分传输但两个通信节点之间仍然需要一个共同的参考地。工业现场经常出现的情况是两个设备分别接了不同的开关电源GND之间压差达到几伏甚至几十伏这时候A、B线上的共模电压会超过收发器的承受范围轻则通信不正常重则直接烧掉收发器芯片。所以你的STM32板子和对端设备之间除了A、B两根线还必须拉一根GND线把两个系统的地兜在一起。记住这句话485隔离的是设备之间的信号干扰不是地电位地线该接还得接。3. 软件部分状态机、时序、代码实现3.1 用CubeMX配置USART和方向控制引脚软件部分用STM32的HAL库来做。CubeMX里配置很简单以USART1为例打开USART1模式选Asynchronous异步波特率按你的从机设备要求来一般Modbus设备默认9600或1152008位数据、无校验、1位停止位8N1是标准配置。使能USART1全局中断。PB0配置为GPIO_Output初始电平设为低电平。这里的关键是初始状态必须是低电平也就是接收模式。如果初始化为高电平STM32一上电就会让收发器进入发送模式把总线占住其他节点全被拉死这就是常见的一种总线异常现象的根源。生成工程后在main.c里把方向控制引脚的设置写成宏定义方便后面调用。3.2 发送逻辑先拉方向再发数据发完再拉回来发送的过程很简单但顺序绝对错不得先拉高方向引脚、再发数据、等发送彻底完成、最后拉低方向引脚。只要顺序错一步就会出现最后一字节被截断或总线一直被占用的问题。基础的阻塞发送函数这样写#define RS485_DE_HIGH() HAL_GPIO_WritePin(RS485_DE_GPIO_Port, RS485_DE_Pin, GPIO_PIN_SET) #define RS485_DE_LOW() HAL_GPIO_WritePin(RS485_DE_GPIO_Port, RS485_DE_Pin, GPIO_PIN_RESET) void RS485_Send_Data(uint8_t *data, uint16_t len) { RS485_DE_HIGH(); HAL_UART_Transmit(huart1, data, len, 100); HAL_Delay(1); RS485_DE_LOW(); }HAL_UART_Transmit是阻塞发送内部会等待发送完成标志TCTransmission Complete也就是最后一个字节已经从移位寄存器里完全挪出去了。但为什么发完之后还要加个HAL_Delay(1)再拉低方向因为我实际测试下来虽然TC已经置位但在高速主频下UART外设和GPIO之间还有一点硬件动作余量个别芯片在发送完成后立即切换方向时最后一个字节的停止位仍然会被切掉。保险起见加一两个字节的发送时间再切方向。波特率9600时一个字节约1ms115200时约0.1msDelay(1)完全够用。如果对实时性要求高你完全可以用DWT计数器做一个微秒级延时去掉这个1ms但大多数场景没必要。如果你用的是中断发送或DMA发送那就不能在函数尾部拉低方向因为数据可能还在DMA搬运中函数已经返回了。这时候要在HAL_UART_TxCpltCallback发送完成回调里拉低方向。这是新手最容易搞错的地方必须单独强调。3.3 接收逻辑中断接收加空闲判断凑成一帧接收部分用中断方式循环接收再用串口空闲中断IDLE来判定一帧数据结束。它的原理是485总线上一帧数据内部的字节间隔很短总线空闲状态超过一个阈值时UART外设会产生IDLE中断。这样你不需要知道这一帧有多长只要总线上安静了就认为当前这一帧已经收完。先定义几个缓冲区变量uint8_t rx_buffer[256]; volatile uint16_t rx_len 0; volatile uint8_t frame_ready 0; uint8_t rx_byte;接着在初始化里启动接收HAL_UART_Receive_IT(huart1, rx_byte, 1);然后实现接收完成回调和中断服务函数void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART1) { if (rx_len sizeof(rx_buffer)) { rx_buffer[rx_len] rx_byte; } else { rx_len 0; } HAL_UART_Receive_IT(huart1, rx_byte, 1); } } void USART1_IRQHandler(void) { HAL_UART_IRQHandler(huart1); if (__HAL_UART_GET_FLAG(huart1, UART_FLAG_IDLE)) { __HAL_UART_CLEAR_IDLEFLAG(huart1); if (rx_len 0) { frame_ready 1; } rx_len 0; } }接收流程是这样的每来一个字节中断一次RxCpltCallback里把字节放进rx_buffer同时重新开启单字节接收。当总线上静默一个字节多的时间UART外设产生IDLE中断此时rx_len里攒着的数据就是一整帧置frame_ready标志主循环检测到这个标志就处理数据。这里有一个HAL库的坑必须提__HAL_UART_CLEAR_IDLEFLAG这个宏在不同的HAL库版本里行为不一致。保险的做法是像下面这样手动清标志volatile uint32_t dummy; dummy huart1.Instance-SR; dummy huart1.Instance-DR;读SR再读DR是清UART各种标志最原始也最可靠的方式。遇到IDLE中断一直触发或者清了之后再也不触发的怪问题换成这段代码基本就解决了。如果是做Modbus RTU协议更规范的办法是用3.5个字符时间窗口来判断帧结束逻辑比IDLE中断稍微复杂一点但容错性更好。可以先跑通中断加IDLE的方式再按协议需求优化。3.4 主循环里的帧处理与应答逻辑主循环的结构保持简单只处理标志位while (1) { if (frame_ready) { frame_ready 0; // 在这里解析接收到的帧数据 // 如果是Modbus请求则组帧回复 // 调用RS485_Send_Data()发送应答 } // 其他业务代码 }如果这个STM32节点要做Modbus从站你可以在解析到正确地址和功能码后调用前面写的RS485_Send_Data把响应帧发出去。要注意的是回复时也要遵守先拉高方向、再发数据、发完拉低的顺序和普通发送完全一样不存在特殊处理。4. 实际调试中的问题、解决和速查4.1 三个最让人头大的调试现象及真实解决过程现象一STM32发送出去对端485转USB工具收不到任何数据但直接测STM32的TX引脚有波形。这个问题我遇到不下五次万用表量一下波形就能定位。如果STM32的TX有波形说明问题出在方向切换或A/B接线。用示波器看方向控制引脚的波形如果发送期间方向引脚始终是低电平说明软件压根没进发送函数或者GPIO映射错了。如果方向引脚在高电平期间同时看A、B两线上有输出那就是A/B线序错了对调一下就通。现象二接收端能收到数据但是乱码或者第一个字节丢失、最后一字节被截断。乱码先查波特率Emphasis这个是最常见的。波特率对不上时收到的字节几乎全是错位的十六进制值。排除波特率后再查共地线。如果你的STM32板和对端设备用两个独立的开关电源供电先把GND连通试一下。最后一字节被截断基本就是方向切换太早把HAL_Delay(1)加上去或者改用TC标志加延时一般就好了。现象三STM32能给从机发送命令从机也执行了动作但从不回复数据。这种情况说明发送链路是通的问题出在接收链路或者从机根本没收到正确的帧。先用485转USB工具挂到总线上人为给从机发一帧测试指令看从机有没有响应。如果有响应说明从机没问题问题回到STM32的接收侧。检查STM32有没有进接收中断用调试器在HAL_UART_RxCpltCallback里打断点如果断点不进检查中断优先级和NVIC配置如果断点进去了但frame_ready始终不置位那就是IDLE中断没有产生换成读SR加DR的清标志方式再试。4.2 总线异常恢复与稳定性设计485总线上有一个很揪心的问题是某个节点发完数据后忘了把方向引脚拉回低电平导致该节点一直占住总线其他所有节点全都无法通信。这种情况表现为整个系统全线瘫痪而且很难定位是哪台设备出了问题因为总线已经被拉死了。在STM32的代码里我自己习惯加一道保护逻辑。每次新数据发送之前先强制把方向引脚拉低再拉高这样即使上一次发送过程被异常中断、方向引脚停留在高电平下一轮发送也能先从接收态重新走一遍相当于把总线状态恢复了一遍。再配一个超时重发机制发送一帧命令后如果在规定时间内没收到应答就重新初始化一次UART或者把GPIO重新写一遍强制释放总线。这种软复位不需要重启单片机但对现场稳定性提升巨大。还有一个上电保护STM32复位期间GPIO引脚默认是浮空输入状态方向控制引脚如果没有下拉电阻外部电平不确定收发器有可能在上电瞬间进入发送模式。处理办法有两个硬件上一是在DE/RE引脚对地加一个10k下拉电阻二是软件上在main函数一开始就立即执行RS485_DE_LOW()把方向锁定在接收状态。两种都做最稳。4.3 常见问题速查表我把这几年调试485遇到的问题整理成一张速查表方便你在现场对照排查现象可能原因解决方案上电就乱码DE/RE初始电平不确定方向引脚加下拉电阻初始化拉低最后一字节被截断发送完立即切方向等TC标志加延时再拉低收到大量乱码波特率不匹配核对两端波特率A/B接反A对B、B对AA接A、B接B不要交叉通信距离一远就丢包终端电阻缺失、线径太细总线两端各加120欧终端换屏蔽双绞线某节点接入后总线瘫痪节点方向引脚卡在发送态检查该节点软件方向逻辑从机不回复地址错、帧格式错、从机本身问题用485转USB工具单独调试从机IDLE中断反复触发清标志方式不对读SR再读DR清除标志DMA发送不完整发送未完成就切方向在DMA发送完成回调中拉低方向供电不同地导致通信异常节点之间地电位差大节点间连接GND线最后分享一点我自己调485的习惯只要能手动控制方向就绝不依赖自动方向芯片代码多两行但现场少一堆坑。每一帧收发结束之后都让电路回到接收态这是整个485稳定通信的基本原则。总线空闲的时候永远不要让它悬空上拉下拉电阻和终端电阻这些几毛钱的电路该加就得加不然省下来的成本都会变成现场的调试时间。还有一个小技巧调试485最痛苦的是不知道总线上到底在传什么所以我会在STM32板子上额外留一路空闲的UART接一个蓝牙模块或者直接接一根TTL转USB线把收发数据实时打印到电脑上人就能看见总线数据流排查起来效率翻倍。这套做法在我做过的伺服控制、Modbus数据采集、多设备联动项目里一直都很管用。本文还有配套的精品资源点击获取
STM32实现RS485通信：从硬件电路到软件调试全解析
简介面向嵌入式开发者与自动化工程师提供STM32F103实现RS485通信的完整工程源码包。工程基于标准外设库实现了UART初始化、波特率与数据位配置、485方向引脚DE/RE自动切换、发送完成与接收中断处理并包含超时/溢出等错误检测逻辑读者可据此掌握RS485半双工通信的收发时序控制方法。资源共122个文件以C源码、H头文件、启动汇编、Keil工程配置为主附带可直接烧录的hex文件、PDF与doc说明文档、清除编译中间文件的bat脚本资源包大小约826KB。已有5507人学习。压缩包内目录结构清晰演示了结合MAX485芯片从硬件连接到软件配置、再到串口助手调试的完整流程并提示终端电阻匹配、总线冲突避免、多节点地址识别等工程注意事项适合竞赛备赛、课程设计和实际项目快速移植。 不知道你有没有经历过这种情况在车间里调一台伺服驱动器电脑和PLC都在总线上你的STM32开发板插上去数据发不出去偶尔收到一堆乱码甚至整个总线都被“拉死”。把波特率改低、把线重新接一遍还是不行。折腾一晚上最后发现是方向控制引脚没拉对或者A、B两根线接反了。这种场景在工业现场太常见了而它背后的主角就是RS485。RS485这些年几乎成了工业通信的默认选项我的STM32项目里十个有八个都要用到它从Modbus仪表、伺服驱动器、变频器到温湿度传感器、电表、条码枪只要是长距离、多节点、抗干扰要求高的场景基本都是485上场。这篇就围绕STM32如何实现485通信来写从硬件电路选型到软件收发状态机再到现场调试最容易踩的坑一次说清。1. RS485为什么这么多项目在用设计前要想清楚什么1.1 485相比232、422、I2C、SPI到底强在哪先说个最容易混淆的点RS485不是一种像SPI、I2C那样的完整通信协议它只是物理层标准。你跑在RS485上的还是UART那套数据帧格式波特率、起始位、数据位、停止位这些和串口一模一样。所以你在STM32上做485本质就是调一个UART外设再额外控制一下收发方向。那为什么不用RS232主要差在三点。第一是距离RS232一般15米就到头了RS485在低速情况下能到1200米工厂车间几十米上百米的布线非常常见。第二是多节点RS232天生只能点对点RS485通过总线挂载标准负载下能挂32个节点。第三是抗干扰RS485用差分信号传输两根线A和B互为参考外界噪声同时叠加到两根线上接收端只判断A-B的电压差共模干扰被抵消掉这在变频器、电机旁边尤其重要。和I2C、SPI这类板级总线比485的优势在于它把物理层放到了外部收发器芯片上电平是差分信号不是单端电平所以能长距离传输。SPI的SCLK、MISO、MOSI三根线跑到半米开外就各种丢数据485上百米还能稳定运行。说到底选485不是因为它的协议有多先进而是它在工业现场这种恶劣条件下用最少的线两根和最便宜的成本实现了可靠的长距离多点通信。这就是它几十年还没被淘汰的根本原因。1.2 半双工的方向控制是整个设计的核心矛盾485总线是半双工工作方式同一时刻总线上只能有一个节点在发送其他节点都在接收。如果两个节点同时拉高发送总线就会冲突数据全乱。这就是为什么每个485节点都要有一个方向控制的概念。收发器芯片内部其实有两个放大器一个把总线上的差分信号转换为单端信号送给STM32的RX引脚另一个把STM32的TX引脚的信号转换为差分信号输出到总线。这两个放大器由芯片上的DE引脚和RE引脚控制。DE是发送使能高电平有效RE是接收使能低电平有效。很多芯片像MAX485、SP3485内部已经把DE和RE逻辑反相处理好了所以你可以把DE和RE直接短接成一个引脚拉高就是发送模式拉低就是接收模式。这里有一个设计方案的选择可以用GPIO软件控制方向也可以用带自动方向检测功能的收发器比如MAX13487来自动切换。自动方向芯片看起来省事少占一个GPIO但在高速、长线、总线节点多的场景下方向切换时序不完全受控偶尔会出莫名其妙的丢帧。我自己的习惯是用GPIO手动控制方向代码只多两行但每一个时序细节都在自己手里排查问题的时候心里有底。后面所有代码和电路都按手动GPIO控制方向的方案来讲。2. 硬件电路这么接才不容易翻车2.1 收发器芯片选型与外围电路做STM32项目时收发器芯片一般从MAX485、SP3485、MAX3485里选。STM32是3.3V供电所以最推荐SP3485或者MAX3485它们是3.3V供电版本RO和DI电平可以直接和STM32的GPIO对接不需要电平转换电路。MAX485是5V供电的如果系统里本来就有5V电源也能用但RO输出高电平是5V直接进STM32的RX引脚会有风险最好串联电阻或者用分压处理。节约成本没问题但稳定性优先的话选3.3V版本最省心。典型的外围电路这样接STM32的TX引脚接收发器的DIRX引脚接收发器的RO。收发器的RE和DE短接后接一个STM32的空闲GPIO比如PB0。A和B两根线引出到接线端子A接双绞线的一根B接另一根。在A和B之间加一个120欧终端电阻。在A线上加一个上拉电阻到3.3VB线上加一个下拉电阻到GND一般用1k到10k。这个偏置电阻的作用是保证总线空闲时A-B的电压差不在不确定区否则接收端会输出随机电平产生乱码。A、B线上各串一个TVS管到GND保护收发器芯片不被静电或浪涌打坏。终端电阻和偏置电阻的取舍值得展开说一下。120欧终端电阻是为了匹配双绞线的特性阻抗减少信号反射。但它只应该加在总线物理线路的两端不是每个节点都加。如果你的STM32节点正好位于总线末端那就在你的板子上加如果在中间就别加加了反而会增大负载拉低信号幅度。一个典型的Modbus总线最远端的两个设备各加一个120欧就对了。偏置电阻很多人会忽略但它恰恰是发数据正常空闲时乱码这类问题的关键。阻值选多大取决于总线上挂了多少个节点因为每个节点的收发器都有输入阻抗会分压。标准做法是让总线上所有偏置电阻并联后在A-B之间形成的静态压差大于200mV。按经验一个节点典型偏置用10k到20k也能工作但如果总线长、节点多建议用1k到4.7k更稳。我通常直接用2k效果稳定。2.2 与STM32的接线及共地问题接线端子这里有个特别容易踩的坑RS485连接必须A对A、B对B不能像RS232那样交叉。很多人第一次用485转USB工具接STM32板子顺手按232的习惯把A接B、B接A结果数据完全不通还以为是波特率问题。用万用表量一下波形就明白了A、B接反时波形是反相的接收到的数据全是乱码。共地问题更要重视。RS485虽然是差分传输但两个通信节点之间仍然需要一个共同的参考地。工业现场经常出现的情况是两个设备分别接了不同的开关电源GND之间压差达到几伏甚至几十伏这时候A、B线上的共模电压会超过收发器的承受范围轻则通信不正常重则直接烧掉收发器芯片。所以你的STM32板子和对端设备之间除了A、B两根线还必须拉一根GND线把两个系统的地兜在一起。记住这句话485隔离的是设备之间的信号干扰不是地电位地线该接还得接。3. 软件部分状态机、时序、代码实现3.1 用CubeMX配置USART和方向控制引脚软件部分用STM32的HAL库来做。CubeMX里配置很简单以USART1为例打开USART1模式选Asynchronous异步波特率按你的从机设备要求来一般Modbus设备默认9600或1152008位数据、无校验、1位停止位8N1是标准配置。使能USART1全局中断。PB0配置为GPIO_Output初始电平设为低电平。这里的关键是初始状态必须是低电平也就是接收模式。如果初始化为高电平STM32一上电就会让收发器进入发送模式把总线占住其他节点全被拉死这就是常见的一种总线异常现象的根源。生成工程后在main.c里把方向控制引脚的设置写成宏定义方便后面调用。3.2 发送逻辑先拉方向再发数据发完再拉回来发送的过程很简单但顺序绝对错不得先拉高方向引脚、再发数据、等发送彻底完成、最后拉低方向引脚。只要顺序错一步就会出现最后一字节被截断或总线一直被占用的问题。基础的阻塞发送函数这样写#define RS485_DE_HIGH() HAL_GPIO_WritePin(RS485_DE_GPIO_Port, RS485_DE_Pin, GPIO_PIN_SET) #define RS485_DE_LOW() HAL_GPIO_WritePin(RS485_DE_GPIO_Port, RS485_DE_Pin, GPIO_PIN_RESET) void RS485_Send_Data(uint8_t *data, uint16_t len) { RS485_DE_HIGH(); HAL_UART_Transmit(huart1, data, len, 100); HAL_Delay(1); RS485_DE_LOW(); }HAL_UART_Transmit是阻塞发送内部会等待发送完成标志TCTransmission Complete也就是最后一个字节已经从移位寄存器里完全挪出去了。但为什么发完之后还要加个HAL_Delay(1)再拉低方向因为我实际测试下来虽然TC已经置位但在高速主频下UART外设和GPIO之间还有一点硬件动作余量个别芯片在发送完成后立即切换方向时最后一个字节的停止位仍然会被切掉。保险起见加一两个字节的发送时间再切方向。波特率9600时一个字节约1ms115200时约0.1msDelay(1)完全够用。如果对实时性要求高你完全可以用DWT计数器做一个微秒级延时去掉这个1ms但大多数场景没必要。如果你用的是中断发送或DMA发送那就不能在函数尾部拉低方向因为数据可能还在DMA搬运中函数已经返回了。这时候要在HAL_UART_TxCpltCallback发送完成回调里拉低方向。这是新手最容易搞错的地方必须单独强调。3.3 接收逻辑中断接收加空闲判断凑成一帧接收部分用中断方式循环接收再用串口空闲中断IDLE来判定一帧数据结束。它的原理是485总线上一帧数据内部的字节间隔很短总线空闲状态超过一个阈值时UART外设会产生IDLE中断。这样你不需要知道这一帧有多长只要总线上安静了就认为当前这一帧已经收完。先定义几个缓冲区变量uint8_t rx_buffer[256]; volatile uint16_t rx_len 0; volatile uint8_t frame_ready 0; uint8_t rx_byte;接着在初始化里启动接收HAL_UART_Receive_IT(huart1, rx_byte, 1);然后实现接收完成回调和中断服务函数void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART1) { if (rx_len sizeof(rx_buffer)) { rx_buffer[rx_len] rx_byte; } else { rx_len 0; } HAL_UART_Receive_IT(huart1, rx_byte, 1); } } void USART1_IRQHandler(void) { HAL_UART_IRQHandler(huart1); if (__HAL_UART_GET_FLAG(huart1, UART_FLAG_IDLE)) { __HAL_UART_CLEAR_IDLEFLAG(huart1); if (rx_len 0) { frame_ready 1; } rx_len 0; } }接收流程是这样的每来一个字节中断一次RxCpltCallback里把字节放进rx_buffer同时重新开启单字节接收。当总线上静默一个字节多的时间UART外设产生IDLE中断此时rx_len里攒着的数据就是一整帧置frame_ready标志主循环检测到这个标志就处理数据。这里有一个HAL库的坑必须提__HAL_UART_CLEAR_IDLEFLAG这个宏在不同的HAL库版本里行为不一致。保险的做法是像下面这样手动清标志volatile uint32_t dummy; dummy huart1.Instance-SR; dummy huart1.Instance-DR;读SR再读DR是清UART各种标志最原始也最可靠的方式。遇到IDLE中断一直触发或者清了之后再也不触发的怪问题换成这段代码基本就解决了。如果是做Modbus RTU协议更规范的办法是用3.5个字符时间窗口来判断帧结束逻辑比IDLE中断稍微复杂一点但容错性更好。可以先跑通中断加IDLE的方式再按协议需求优化。3.4 主循环里的帧处理与应答逻辑主循环的结构保持简单只处理标志位while (1) { if (frame_ready) { frame_ready 0; // 在这里解析接收到的帧数据 // 如果是Modbus请求则组帧回复 // 调用RS485_Send_Data()发送应答 } // 其他业务代码 }如果这个STM32节点要做Modbus从站你可以在解析到正确地址和功能码后调用前面写的RS485_Send_Data把响应帧发出去。要注意的是回复时也要遵守先拉高方向、再发数据、发完拉低的顺序和普通发送完全一样不存在特殊处理。4. 实际调试中的问题、解决和速查4.1 三个最让人头大的调试现象及真实解决过程现象一STM32发送出去对端485转USB工具收不到任何数据但直接测STM32的TX引脚有波形。这个问题我遇到不下五次万用表量一下波形就能定位。如果STM32的TX有波形说明问题出在方向切换或A/B接线。用示波器看方向控制引脚的波形如果发送期间方向引脚始终是低电平说明软件压根没进发送函数或者GPIO映射错了。如果方向引脚在高电平期间同时看A、B两线上有输出那就是A/B线序错了对调一下就通。现象二接收端能收到数据但是乱码或者第一个字节丢失、最后一字节被截断。乱码先查波特率Emphasis这个是最常见的。波特率对不上时收到的字节几乎全是错位的十六进制值。排除波特率后再查共地线。如果你的STM32板和对端设备用两个独立的开关电源供电先把GND连通试一下。最后一字节被截断基本就是方向切换太早把HAL_Delay(1)加上去或者改用TC标志加延时一般就好了。现象三STM32能给从机发送命令从机也执行了动作但从不回复数据。这种情况说明发送链路是通的问题出在接收链路或者从机根本没收到正确的帧。先用485转USB工具挂到总线上人为给从机发一帧测试指令看从机有没有响应。如果有响应说明从机没问题问题回到STM32的接收侧。检查STM32有没有进接收中断用调试器在HAL_UART_RxCpltCallback里打断点如果断点不进检查中断优先级和NVIC配置如果断点进去了但frame_ready始终不置位那就是IDLE中断没有产生换成读SR加DR的清标志方式再试。4.2 总线异常恢复与稳定性设计485总线上有一个很揪心的问题是某个节点发完数据后忘了把方向引脚拉回低电平导致该节点一直占住总线其他所有节点全都无法通信。这种情况表现为整个系统全线瘫痪而且很难定位是哪台设备出了问题因为总线已经被拉死了。在STM32的代码里我自己习惯加一道保护逻辑。每次新数据发送之前先强制把方向引脚拉低再拉高这样即使上一次发送过程被异常中断、方向引脚停留在高电平下一轮发送也能先从接收态重新走一遍相当于把总线状态恢复了一遍。再配一个超时重发机制发送一帧命令后如果在规定时间内没收到应答就重新初始化一次UART或者把GPIO重新写一遍强制释放总线。这种软复位不需要重启单片机但对现场稳定性提升巨大。还有一个上电保护STM32复位期间GPIO引脚默认是浮空输入状态方向控制引脚如果没有下拉电阻外部电平不确定收发器有可能在上电瞬间进入发送模式。处理办法有两个硬件上一是在DE/RE引脚对地加一个10k下拉电阻二是软件上在main函数一开始就立即执行RS485_DE_LOW()把方向锁定在接收状态。两种都做最稳。4.3 常见问题速查表我把这几年调试485遇到的问题整理成一张速查表方便你在现场对照排查现象可能原因解决方案上电就乱码DE/RE初始电平不确定方向引脚加下拉电阻初始化拉低最后一字节被截断发送完立即切方向等TC标志加延时再拉低收到大量乱码波特率不匹配核对两端波特率A/B接反A对B、B对AA接A、B接B不要交叉通信距离一远就丢包终端电阻缺失、线径太细总线两端各加120欧终端换屏蔽双绞线某节点接入后总线瘫痪节点方向引脚卡在发送态检查该节点软件方向逻辑从机不回复地址错、帧格式错、从机本身问题用485转USB工具单独调试从机IDLE中断反复触发清标志方式不对读SR再读DR清除标志DMA发送不完整发送未完成就切方向在DMA发送完成回调中拉低方向供电不同地导致通信异常节点之间地电位差大节点间连接GND线最后分享一点我自己调485的习惯只要能手动控制方向就绝不依赖自动方向芯片代码多两行但现场少一堆坑。每一帧收发结束之后都让电路回到接收态这是整个485稳定通信的基本原则。总线空闲的时候永远不要让它悬空上拉下拉电阻和终端电阻这些几毛钱的电路该加就得加不然省下来的成本都会变成现场的调试时间。还有一个小技巧调试485最痛苦的是不知道总线上到底在传什么所以我会在STM32板子上额外留一路空闲的UART接一个蓝牙模块或者直接接一根TTL转USB线把收发数据实时打印到电脑上人就能看见总线数据流排查起来效率翻倍。这套做法在我做过的伺服控制、Modbus数据采集、多设备联动项目里一直都很管用。本文还有配套的精品资源点击获取
