简介本资源是基于STM32F103微控制器的RS-485通信实战项目面向嵌入式初学者与工业通信开发人员聚焦解决UART转RS-485硬件接口设计、半双工通信控制及抗干扰总线协议实现等核心问题。压缩包共84个文件含38个头文件.h用于外设与模块声明、37个源文件.c涵盖HAL库驱动、RS485收发逻辑、usmart调试组件及系统底层配置另有工程配置文件.uvprojx/.uvoptx、启动脚本.bat、可执行固件.hex及说明文档.txt整体体积仅368KB结构清晰、模块分明便于快速理解与二次开发。已有110人学习下载资源完整包含硬件连接要点、MAX485收发器控制逻辑、GPIO方向切换时序、终端电阻配置建议及UART中断收发处理范例特别适合掌握工业现场总线通信原理与STM32底层驱动协同开发的实践者。 提到工业通信485大概是出场率最高的一个词。把STM32F103和485放在一起基本就能拼出一个典型的工业控制节点单片机负责逻辑485负责把数据送到几十米甚至上千米外的上位机、PLC、变频器或者伺服驱动器。我这些年做过的项目里用这个组合干过温度采集、伺服控制、仪表抄表也跟西门子PLC、欧姆龙温控器、托利多称重仪表都打过交道。这篇文章我把这套东西从硬件电路到软件协议再到现场调试踩坑的完整经验整理出来给正在搞485通讯、STM32F103开发或者被收发切换、总线波形畸变折磨的朋友一份能直接抄作业的参考。1. 先把485和STM32F103这对组合搞清楚1.1 485到底是什么为什么总在工业现场出现RS-485其实只规定了电气层标准它没有定义帧格式、没有定义协议只解决“信号怎么在两根线上传输”这件事。它用A、B两根线之间的电压差来表达逻辑A-B电压差大于200mV视为逻辑1也就是空闲态小于-200mV视为逻辑0起始位和数据位0。因为走的是差分信号两根线上感应的共模干扰在接收端会被抵消掉所以抗干扰能力比单端的RS-232强得多传输距离在标准条件下能到1200米一条总线上还能挂最多32个标准负载。这几点凑在一起让485成了工业现场最皮实的通信方式。传感器采集、变频器控制、伺服驱动、仪表抄表、PLC组网能走485的基本都走485。它不需要高成本的专用芯片STM32这类MCU天生带UART外设外接一颗便宜的收发芯片就能组网几十块钱就能做一个可靠节点。1.2 STM32F103在485节点里扮演的角色STM32F103本身并没有专用的485控制器它做485靠的是片上UART串口加外部的收发芯片。UART负责把数据转成TTL电平的串行波形收发芯片负责把TTL电平转成485总线上的差分信号。选STM32F103的原因很实在便宜、好买、资料铺天盖地标准库和HAL库都能用片上外设还全。一个485节点通常不只是收发电文还要做采集、控制比如PWM输出、ADC采集、SPI读传感器、CAN通讯STM32F103一个芯片全都能顶上。很多设备的主控板就是STM32F103最小系统加几个通信接口485只是其中一路。1.3 什么人、什么场景需要这套方案结合我平时收到的咨询做这套方案的大概分三类人。第一类是刚接触单片机的学生或转行者毕业设计常见题目就是“STM32F103与上位机485通讯”或者自己DIY一个数据采集模块用485把传感器数据传到电脑上。第二类是做设备改造的工程师设备上原有仪表、变频器、伺服驱动器带485接口但PLC点位不够或上位机要统一采集就用STM32F103做一个协议转换网关把Modbus RTU数据重新组织转发。第三类是产品开发人员做温控器、电力仪表、电机控制器这类工业设备主控就是STM32F103485是标配通信口。这三类人遇到的问题高度重合电路怎么搭、收发切换怎么处理、数据收不到怎么办、和别人的设备怎么对上协议。下面我按硬件、软件、调试、扩展应用四条线展开。2. 硬件设计最小系统与485收发电路2.1 STM32F103最小系统设计要点网上搜“stm32f103最小系统”能看到一大堆原理图核心元件其实就那几样但细节没做好后面会非常难受。第一是电源。STM32F103需要3.3V供电LDO前端一般接5V或12V。数字电源和模拟电源引脚注意分开走线VDDA和VSSA要加滤波电容否则ADC采样会飘。每个电源引脚旁边放一个100nF去耦电容这是最容易被忽视的。第二是时钟。8MHz晶振加两个22pF左右的负载电容晶振底下不要走其它信号线。如果你用HAL库且开了RTC还要注意32.768kHz晶振的布局。晶振起振失败是“程序下载进去没反应”的常见原因之一排查时先量一下OSC_OUT引脚有没有振荡波形。第三是启动配置。BOOT0和BOOT1都要拉低让芯片从Flash启动。如果BOOT0悬空引脚内部有下拉还好但为了稳妥量产板子上还是要加电阻明确拉低。第四是复位电路。NRST引脚接一个100nF电容到地再加一个10k电阻上拉到3.3V手动复位按键并联在电容两端就行。这个电路简单也成熟不用另外想花样。这些看起来基础但485通信往往是主机主动发问、从机被动回复一旦MCU跑飞或复位不稳定整条总线上的通信都会变得间歇性抽风。我调试过一块板子现象是“通信偶尔断流”最后查出来是复位电容虚焊MCU不定时复位。所以说最小系统的可靠性是485通信稳定的地基。2.2 485收发芯片选型与基本电路485收发芯片最常用的是MAX485、SP3485、MAX3485这几颗。选型时的核心区别是供电电平。MAX485是5V供电输出高电平接近5V直接接STM32F103的RX引脚虽然大多数情况下能工作但属于电平不匹配稳妥做法是加转换电路或选3.3V版本。SP3485和MAX3485都是3.3V供电可以直接和STM32F103的GPIO对接不需要电平转换我用SP3485比较多。芯片引脚功能很简单引脚功能接法DI数据输入接STM32的TX引脚如PA9RO接收输出接STM32的RX引脚如PA10DE发送使能高电平有效接方向控制GPIO或与RE并联RE接收使能低电平有效接方向控制GPIO或与DE并联A差分正端接总线A线B差分负端接总线B线实际电路里DE和RE通常短接在一起用一个GPIO控制拉高进入发送模式拉低进入接收模式。这样最简单逻辑也清晰。在DE/RE引脚上要加一个10k下拉电阻防止MCU复位期间该引脚悬空导致芯片误进发送模式把总线拉死。2.3 自动收发电路到底该不该用关于485自动收发电路网上讨论很多。它的原理是用三极管或MOS管检测TX信号发送逻辑0时让DE变高、进入发送模式发送逻辑1时让DE变低、回到接收模式。这样软件里就不用单独控制方向引脚发送时看起来省了一步。但我个人的经验是这个电路能用但只适合特定场合。第一它在发送逻辑1时实际上不驱动总线总线靠上拉电阻和终端电阻维持空闲高电平所以波形会变丑距离长了或波特率高了容易误码。第二它对每个字节都要做一次收发切换连续发大包时中间容易出问题。我的建议是如果应用场景是“只发不收”或“非常低速短距离”可以用自动收发省一根GPIO如果是正经的Modbus RTU主从通信还是老老实实用GPIO控制方向这也是绝大多数工业设备采用的做法。方向控制本身不难难的是切换时机这部分在软件章节细说。2.4 总线末端处理终端电阻与上下拉485总线的末端处理是很多通信不稳定问题的根源。讲透这个能省掉一大半现场排障时间。终端电阻双绞线的特性阻抗大约120Ω为了消除反射应该在总线的最远两端各接一个120Ω电阻。注意是“两端”不是每个节点都接。如果每个设备都加120Ω总线等效负载会很小信号幅度被拉低反而容易出问题。我的经验是主机端加一个最远端从机加一个中间设备不加。接线时电阻直接并在A、B线之间。上下拉偏置电阻485总线空闲时应该稳定在逻辑1但如果所有节点都处于接收状态、没有设备驱动总线A、B之间没有压差接收端会读出乱码。解决办法是在主机端给A线上拉、B线下拉常见阻值4.7k到10k。这两个偏置电阻同时也能给无源状态的从机一个确定电平。我自己做开发板时会在主机端默认加上120Ω终端电阻和A上拉B下拉偏置从机端不加、预留焊盘。这样一套配置出去绝大多数现场直接就能通。3. 软件实现串口配置与485收发方向切换3.1 USART初始化与引脚复用配置485通信的软件基础是UART串口。STM32F103的USART1默认引脚就是PA9TX和PA10RX不需要重映射。这个也是大家搜“stm32f103 pa9 pa10 哪个是tx rx”时最关心的问题记牢PA9是发送TXPA10是接收RX。用HAL库配置先把GPIO和USART初始化好/* PA9 - TX推挽复用PA10 - RX浮空或上拉输入 */ GPIO_InitTypeDef GPIO_InitStruct {0}; __HAL_RCC_GPIOA_CLK_ENABLE(); __HAL_RCC_USART1_CLK_ENABLE(); GPIO_InitStruct.Pin GPIO_PIN_9; GPIO_InitStruct.Mode GPIO_MODE_AF_PP; GPIO_InitStruct.Speed GPIO_SPEED_FREQ_HIGH; HAL_GPIO_Init(GPIOA, GPIO_InitStruct); GPIO_InitStruct.Pin GPIO_PIN_10; GPIO_InitStruct.Mode GPIO_MODE_INPUT; GPIO_InitStruct.Pull GPIO_PULLUP; HAL_GPIO_Init(GPIOA, GPIO_InitStruct); huart1.Instance USART1; huart1.Init.BaudRate 9600; // Modbus RTU最常见 huart1.Init.WordLength UART_WORDLENGTH_8B; huart1.Init.StopBits UART_STOPBITS_1; huart1.Init.Parity UART_PARITY_NONE; huart1.Init.Mode UART_MODE_TX_RX; huart1.Init.HwFlowCtl UART_HWCONTROL_NONE; HAL_UART_Init(huart1); /* 使能接收中断并启动接收 */ HAL_UART_Receive_IT(huart1, rx_byte, 1);波特率、数据位、停止位、校验位这四个参数必须和总线上其它设备完全一致一个不对就是满屏乱码。Modbus RTU最常用的组合就是9600、8、N、1默认按这个来实在不对再试19200、115200。3.2 发送方向的切换时机485最坑的地方485是半双工发送和接收不能同时进行。方向切换的时机是485软件里最容易被坑的地方也是最常见的“发不完整帧”问题根源。正确流程是发送前把DE拉高让芯片进入发送模式然后逐字节送数据必须等最后一个字节的停止位彻底从移位寄存器发出去才能把DE拉低切回接收模式。如果提前拉低最后一个字节会被截断对端收到的帧就差那么一两个位CRC校验直接失败表现为“通信时好时坏”。判断“最后一个字节发完”有两种方法。第一是查TC标志表示发送移位寄存器已经空停止位已经发完。HAL库的HAL_UART_Transmit是阻塞发送它返回时就代表数据已经从移位寄存器移到线上了实际是等待了TC所以返回后立刻切方向是安全的。第二是自己延时按波特率估算一个字节的时间数据位8位加起始位停止位共10bit9600波特率下一个字节约1.04ms发完最后再延时1个字节时间再切向。这个方法简单但浪费CPU推荐用TC标志。我常用的发送函数长这样#define RS485_DIR_PORT GPIOA #define RS485_DIR_PIN GPIO_PIN_8 // 方向控制脚自己定义 static void RS485_Set_DIR(uint8_t tx_mode) { HAL_GPIO_WritePin(RS485_DIR_PORT, RS485_DIR_PIN, tx_mode ? GPIO_PIN_SET : GPIO_PIN_RESET); } void RS485_Send(uint8_t *buf, uint16_t len) { RS485_Set_DIR(1); // 切发送 HAL_UART_Transmit(huart1, buf, len, 1000); // 发完返回 while (__HAL_UART_GET_FLAG(huart1, UART_FLAG_TC) ! SET); RS485_Set_DIR(0); // 切接收 }这里有个细节HAL_UART_Transmit内部已经会等TC我再用while卡一下纯粹是为了保险防止某些库版本行为不一致。实际项目里这段代码后面再加个3~5ms的延时再处理接收也没问题因为Modbus主机轮询本来就不会立刻收到从机回复。3.3 接收处理中断、DMA与帧超时判断接收侧我的做法是逐字节中断接收配合一个定时器做帧超时判断。这是Modbus RTU解析的标准姿势。Modbus RTU规定一帧内字节间隔不能超过3.5个字符时间超过就认为一帧结束。9600波特率下3.5个字符时间大约是4ms。具体实现每收到一个字节就重启一个1ms定时器定时器到4ms没有新字节就认为一帧完整了开始解析。用HAL库的接收中断每次收一个字节void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART1) { rx_buffer[rx_len] rx_byte; if (rx_len sizeof(rx_buffer)) rx_len 0; // 防溢出 __HAL_TIM_SET_COUNTER(htim6, 0); // 复位帧超时定时器 HAL_TIM_Base_Start_IT(htim6); HAL_UART_Receive_IT(huart1, rx_byte, 1); // 继续收 } } void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) { if (htim-Instance TIM6) { HAL_TIM_Base_Stop_IT(htim6); // 到这里就是完整一帧置标志位让主循环去解析 frame_ready 1; } }如果要发大包或数据速率很高可以换DMA加空闲中断代码复杂度上一个台阶。但大多数485从机应用逐字节中断加超时已经足够稳定也容易调试。3.4 Modbus RTU最小实现要点485上跑得最多的协议就是Modbus RTU。它本身就是为RS-485这种半双工总线设计的主从模式从机地址0~247地址0是广播地址。帧格式地址码 功能码 数据 CRC16校验低字节在前。常见功能码就几个03读保持寄存器、06写单个寄存器、0x10写多个寄存器、01读线圈、05写单线圈。做从机时先把这几个功能码实现好大部分设备都能对接。CRC16的计算要自己写标准的Modbus多项式0xA001uint16_t Modbus_CRC16(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; }注意发送时CRC是低字节在前。我第一次写Modbus从机时就是高低字节顺序反了调试助手一直报错CRC校验失败查了好久。这个坑几乎人人都踩。收帧时也要自己算一遍CRC再和报文里的CRC比对不一致就丢帧不回复。4. 调试实战用波形和调试助手定位问题4.1 485调试助手的正确用法搜“485调试助手”能找到一堆串口工具我常用的组合是USB转485模块加PC端软件。模块选CH340加SP485的成品就行要注意有的模块默认不带终端电阻和偏置和长总线对接时要自己补上。PC端软件我习惯用Modbus Poll主站模拟和Modbus Slave从站模拟这一对组合。做从机时用Modbus Poll模拟主机发送读取指令做主机时用Modbus Slave模拟设备回复先把MCU侧的逻辑调通再对接真实设备。这个流程能省掉大量“不知道是硬件问题还是协议问题”的排查时间。如果只是简单看数据XCOM、sscom这类串口调试助手就行。但注意它们只能发原始十六进制数据CRC要自己算好填进去用起来没有Modbus Poll方便。4.2 用示波器看485总线波形很多通信问题用眼睛看波形比瞎猜快得多。485是差分信号示波器最好是差分探头没有的话用两通道分别接A和B再用数学通道算A减B。正常的485波形在总线上应该是这样的空闲态A-B电压为正通常几百毫伏到几伏不等起始位A-B电压翻转为负表示一帧开始数据位按波特率一位一位翻转0是负电平1是正电平停止位回复到正电平直到下一帧开始如果看到波形的摆幅很小比如只有几十毫伏检查终端电阻是不是接太多、总线是不是过长、偏置电阻是否没加。如果看到波形边缘有严重的过冲和振铃检查终端电阻有没有接在正确位置。如果波形杂乱、一帧里电平乱跳大概率是A、B接反或波特率不对。4.3 常见问题排查速查表把我在现场和开发中遇到的高频问题整理成一张表直接按图索骥现象可能原因排查方法完全收不到数据TX/RX接反A/B接反DE/RE没拉对用示波器查TTL侧和总线侧波形数据乱码波特率、校验位不一致确认双方参数完全一致帧发不完整方向切换过早停止位被截断发送完等TC标志再拉低总线空闲时收到乱码帧A/B缺偏置电阻总线浮空主机端加4.7k上拉A、下拉B多机通信间歇性失败从机地址重复或终端电阻加多了检查每个从机地址确认终端电阻只加两端通信距离长了就不稳定没做屏蔽、没终端电阻、地电位差大换双绞屏蔽线正确终端匹配必要时加隔离和USB转485连不上模块本身没有独立供电或地没共确认模块地和设备地连接4.4 现场排障的通用套路我总结了一套排障顺序基本能覆盖90%的485问题。第一步本地自查。把MCU的TX直接短接到RX自发自收确认UART本身没问题。注意这个测试绕过了485芯片但如果自发自收都不通单片机串口配置一定有bug。第二步芯片级测试。把DE/RE固定为接收模式用USB转485模块主动发数据用示波器或逻辑分析仪看485芯片RO引脚有没有对应的TTL波形输出。这一步能确认收发芯片是否正常。第三步总线级联调。MCU和USB转485模块都接到总线上先近距离点对点通再逐步增加距离和设备数量。每加一台设备都看一次通信是否正常哪个设备一加进去就出问题重点检查那台的地址、接线和终端电阻。这三步走完绝大多数问题都能定位到具体环节而不是在原地瞎猜。5. 扩展玩法PWM输出、伺服电机与PLC变频器对接5.1 STM32F103的PWM输出配置实例搜“stm32f103的pwm输出配置”的人多半是拿PWM去调速电机、控制舵机或者做信号发生器。PWM的原理是定时器计数到ARR后翻转CCR决定高电平持续时间。频率和占空比的计算公式是PWM频率 定时器时钟 / ((PSC1) * (ARR1))占空比 CCR / (ARR1)STM32F103的定时器时钟在系统主频72MHz时TIM1挂APB2为72MHzTIM2/3/4挂APB1但会倍频到72MHz。所以做PWM配置时直接按72MHz算就行。举个例子用TIM3_CH1在PA6上输出50Hz、占空比50%的PWMTIM_HandleTypeDef htim3; TIM_OC_InitTypeDef sConfigOC; __HAL_RCC_TIM3_CLK_ENABLE(); htim3.Instance TIM3; htim3.Init.Prescaler 1439; // PSC htim3.Init.CounterMode TIM_COUNTERMODE_UP; htim3.Init.Period 999; // ARR htim3.Init.ClockDivision TIM_CLOCKDIVISION_DIV1; HAL_TIM_PWM_Init(htim3); sConfigOC.OCMode TIM_OCMODE_PWM1; sConfigOC.Pulse 500; // CCR占空比50% sConfigOC.OCPolarity TIM_OCPOLARITY_HIGH; HAL_TIM_PWM_ConfigChannel(htim3, sConfigOC, TIM_CHANNEL_1); HAL_TIM_PWM_Start(htim3, TIM_CHANNEL_1);计算验证72MHz / ((14391) * (9991)) 72000000 / 1440000 50Hz。想调频率就改PSC和ARR想调占空比就改CCR。注意改CCR时用HAL_TIM_PWM_SetCompare不要整个重新初始化否则输出会闪一下。5.2 通过485控制伺服电机的完整流程搜“stm32控制伺服电机485”和“三菱fx1n怎么通过485读取伺服驱动绝对值编码器位置”这两类问题本质上都是在问同一件事怎么用Modbus RTU去操作伺服驱动器。先明确概念对伺服驱动器来说485控制是上位机用Modbus RTU报文读写驱动器的寄存器驱动器内部固件再去执行启停、调速、读位置这些动作。STM32处理器不需要直接“知道”伺服怎么换向它只需要把正确的寄存器地址和值写进去。完整流程是查伺服驱动器的通信手册确认它支持Modbus RTU协议找出通信参数设置的菜单项比如从站地址、波特率、校验方式找出控制字寄存器、目标速度寄存器、状态字寄存器和位置读取寄存器的地址。不同品牌差异很大比如台达、松下、三菱都有各自的地址映射必须以官方手册为准网上别人给的地址只能当参考按Modbus RTU报文格式操作。写控制字用06功能码读状态或位置用03功能码批量写参数用0x10功能码把驱动器的使能、模式选择、速度给定这些控制逻辑和单片机内的状态机关联起来形成完整的启停流程这里最容易踩的坑是字节序。不同伺服驱动器的Modbus寄存器里多字节数据可能是高字节在前也可能是低字节在前还有的会交换16位寄存器内的高低字节。对接不上时把手册里数据格式部分反复读几遍再做几个读写测试用返回数据反推。5.3 和西门子S7-1200、G120XA变频器通讯的经验热词里有一条“西门子1200plc和西门子g120xa变频器485通讯”说明做自动化集成的朋友经常遇到西门子设备之间的485对接。S7-1200本体不带RS485口需要加通信模块CM1241 RS485或者用CB1241通信板然后在TIA Portal里组态用MB_COMM_LOAD和MB_MASTER这些Modbus指令块去配置和轮询从站。G120XA变频器的控制单元上自带RS485端子通过参数P2020系列配置协议选择、波特率和站地址可以选择Modbus RTU或USS协议。这里有个经验西门子变频器如果用USS协议报文格式和Modbus完全不一样调试时先确认双方选的是同一个协议。如果用Modbus RTU就和普通Modbus设备一样按寄存器地址去操作。G120XA的很多运行参数和命令都可以通过Modbus寄存器映射实现具体地址在变频器操作说明书的通信章节有附表。STM32F103要接入这套系统时通常是扮演Modbus从机设备或者承担协议转换网关的角色。它不需要关心西门子的内部协议只要按Modbus RTU的帧格式和寄存器定义去通信就行。5.4 温控器、仪表等常见设备的485对接收纳工业现场除了伺服和变频器还有大量带485接口的仪表比如欧姆龙E5CC温控器、托利多称重仪表、斯菲尔电力仪表。欧姆龙E5CC温控器的RS-485通信需要在前面板菜单里设置通信协议可选Modbus或CompoWay/F、单元号也就是Modbus站号、波特率、通信格式。E5CC的Modbus支持读取过程值和设定值、写入目标设定值等操作寄存器地址在手册里查。这里提醒一点改完通信参数后要重新上电或按特定操作确认参数才会生效否则改了等于没改。托利多称重仪表的485寄存器地址也是在仪表说明书的通信附录里定义不同型号的协议实现有差异。我做对接时一般先用Modbus Poll扫描功能读几个常见寄存器看看返回数据是否合理再根据仪表显示值反推地址和换算关系。斯菲尔电力仪表很多人问“485通讯地址是相同的吗”答案是每台设备地址必须唯一。多个斯菲尔仪表挂同一条总线时如果地址相同主机读取时两台设备同时应答总线上直接冲突数据全乱。现场如果发现读取数据跳变、时好时坏先查地址是不是重了。还有一个有意思的搜索词是“电动自行车电路图上的485通讯线”现在很多电动车的控制器、仪表、BMS之间也走这类差分通信。原理和工业485完全一样只是传输速率和应用层协议不同看电路图时识别出A、B两根差分线量一下总线空闲电平思路就通了。6. 实操路上的经验小结写到这里我把自己实际折腾485和STM32F103的几条核心体会再说一下。方向控制引脚我见过很多初学者图省事直接悬空或者只初始化不复位结果芯片上电瞬间DE是高电平把总线钳制在发送状态整条线上其它设备全被拖死。方向引脚必须加下拉电阻软件里先初始化成接收模式再考虑发送。自动收发电路能少一根控制线但别把它当万能方案。我之前在客户现场用自动收发做过一个38400波特率的数据采集器短距离测试没问题拉到实际布线上就出现偶发误码后来改成GPIO方向控制才彻底解决。能用硬件控制线的地方别省。调试485时逻辑分析仪和示波器是最值得信任的工具。有时候软件看了半天没发现逻辑问题量一下总线波形发现A、B接反了或者终端电阻虚焊了瞬间真相大白。工具没有好坏会看波形才是核心竞争力。最后提一下量产层面的细节485设备之间长距离传输建议用双绞屏蔽线屏蔽层单端接地现场有电机、变频器这些大干扰源时总线两端加TVS管必要时用带隔离的485收发芯片比如ADM2483直接把地环路切断。这些措施在开发阶段可以不做但到了现场每一条都可能是你被客户半夜叫起来的抢救点。本文还有配套的精品资源点击获取