简介：本资源是一份面向嵌入式初学者与STM32开发者的RS485工业通信实战指南，聚焦STM32F103微控制器（Cortex-M3内核）与土壤温湿度传感器的485协议对接，解决多节点、长距离、抗干扰场景下的串口通信难题。文档以Word格式（.docx）呈现，共1个文件，大小1.22MB，内容涵盖RS485硬件原理（含DE使能线控制逻辑）、STM32 UART2初始化配置、收发函数实现（RS485_Send_Data/Receive_Data）、主程序流程（含TFTLCD数据显示）、关键头文件定义及完整代码注释，覆盖从引脚分配、中断优先级设置到温湿度数据解析的全链路实践。已有2628人学习下载，读者可直接复用代码框架，快速掌握半双工通信模式切换、传感器指令交互（如Modbus-RTU读取命令0x01 0x03）、接收缓冲管理及LCD实时显示等核心技能，是理论结合工程落地的典型学习范例。

1. RS485在STM32上不是“接上线就能通”：半双工切换失败时，90%的通信异常根本收不到一个字节

你手里的STM32F103开发板，UART2引脚已经连好485芯片（比如MAX485），传感器也挂上了总线，RS485_Send_Data()调用后示波器能看到TX线上有波形，但RS485_Receive_Data()永远返回len=0——这不是线没接牢，也不是波特率错了，而是RS485物理层的使能控制逻辑被软件彻底绕过了。这份《STM32F103 RS485传感器.docx》文档里那几行看似平淡的RS485_TX_EN=1; delay_ms(1); ... RS485_TX_EN=0;，恰恰是整个通信链路的“生死开关”。它不处理，数据就卡在发送端的驱动器里出不去；它关早了，接收端刚把起始位采样完，DE线就拉低，后续字节全被丢弃；它关晚了，又可能干扰下一次接收。更隐蔽的是，中断服务程序USART2_IRQHandler里那段“收到一字节就立刻回发”的逻辑，表面看是调试用，实则暴露了RS485协议栈最底层的时序脆弱性：没有严格的DE信号与UART移位寄存器状态的同步，任何微小的delay偏差都会让总线陷入“发送未结束、接收已开启”的竞争态。搞懂这个机制，不是为了写个能跑的Demo，而是为了在工业现场——电磁干扰强、节点多、线缆长、响应时间严苛的场景下，让通信从“偶尔能通”变成“每次必通”。这背后牵扯的，是GPIO翻转与UART硬件状态机的精确对齐，是中断延迟与总线电气特性的硬约束，更是嵌入式开发者必须亲手掐住的“确定性咽喉”。

2. RS485半双工的本质：DE信号不是开关，而是UART硬件状态的“影子同步器”

RS485物理层本身不定义协议，它只提供一种差分、平衡、多点的电气传输能力。真正决定“谁说话、谁听讲”的，是连接在UART TX/RX和485收发器之间的那个DE（Driver Enable）/RE（Receiver Enable）控制信号。在STM32F103这类没有原生RS485模式的MCU上，这个信号必须由软件通过GPIO精确操控——它不是简单的高低电平开关，而是UART硬件状态的影子同步器（Shadow Synchronizer）。它的翻转时机，必须严格匹配UART发送移位寄存器（TDR）的清空完成时刻和接收移位寄存器（RDR）的数据稳定窗口。否则，就会出现“发送未完成，DE已拉低”，导致最后一字节的停止位被截断，或者“DE拉高过早”，让485驱动器在UART尚未准备好数据时就强行输出，造成总线冲突。

2.1 DE信号的硬件绑定与GPIO配置真相

在文档的RS485_Init()函数中，关键一行是：

GPIO_InitStructure.GPIO_Pin=GPIO_Pin_3; //CS-485 GPIO_InitStructure.GPIO_Mode=GPIO_Mode_Out_PP; //推挽输出 GPIO_Init(GPIOG,&GPIO_InitStructure);

这里将PG3配置为推挽输出，用作RS485_TX_EN（即DE信号）。但注意：它没有启用任何复用功能，也没有配置为开漏。这是刻意为之——因为MAX485等典型485芯片的DE引脚是TTL电平兼容的，且要求驱动能力强（需快速拉升/拉低总线驱动器的使能端）。推挽输出能提供足够的灌电流和拉电流，确保DE信号边沿陡峭，避免因上升/下降时间过长导致485驱动器处于不确定的高阻态（此时总线既不发送也不接收，极易引入噪声）。

提示：若使用某些低功耗485芯片（如SN65HVD72），其DE引脚可能要求开漏+上拉，此时必须改用GPIO_Mode_Out_OD并外接10kΩ上拉电阻，否则DE无法可靠拉高。

2.2 UART状态标志与DE翻转的精确时序锚点

RS485_Send_Data()函数的核心逻辑是：

RS485_TX_EN=1; // 拉高DE，进入发送模式 for(t=0;t<len;t++) { while(USART_GetFlagStatus(USART2, USART_FLAG_TC) == RESET); // 等待上一字节发送完成 USART_SendData(USART2,buf[t]); // 写入下一字节到TDR } while(USART_GetFlagStatus(USART2, USART_FLAG_TC) == RESET); // 等待最后一字节的停止位发送完毕 RS485_RX_CNT=0; RS485_TX_EN=0; // 拉低DE，切回接收模式

这里的USART_FLAG_TC（Transmit Complete）是唯一可靠的DE翻转锚点。它表示“当前写入TDR的数据已全部移出，包括停止位，且TDR和移位寄存器均为空”。很多初学者误用USART_FLAG_TXE（Transmit Data Register Empty），它只表示TDR空了，但移位寄存器还在发！如果在此刻拉低DE，最后一字节的停止位会被强制截断，接收端看到的就是一个帧错误（Framing Error）。

我们来验证这个时序：假设波特率9600，1字节=10位（1起始+8数据+1停止），发送1字节需约1.04ms。TC标志在第10位（停止位）的末尾置位。而TXE在第1位（起始位）开始移出后就置位（约0.1ms后）。两者相差近1ms——这1ms，就是DE信号必须保持高电平的最小安全窗口。文档中delay_ms(1)的硬延时，正是对这个窗口的保守补偿，但它掩盖了TC标志才是真正的硬件依据。

2.3 中断服务程序中的“伪回环”陷阱与真实目的

USART2_IRQHandler里的这段代码常被误解为“调试回环”：

if(USART_GetITStatus(USART2, USART_IT_RXNE) != RESET) { res = USART_ReceiveData(USART2); RS485_TX_EN=1; delay_ms(1); USART_SendData(USART2,res); while(USART_GetFlagStatus(USART2,USART_FLAG_TC)!=1); delay_ms(2); RS485_TX_EN=0; }

它看起来像把收到的字节原样发回去，但实际并非如此。RS485_SendData()函数本身已包含完整的DE控制逻辑，而此处的发送是裸操作：没有等待TC，没有清空接收计数器，甚至没有检查发送缓冲区是否就绪。它的真正作用，是强制触发一次DE信号的完整切换周期，用于验证硬件连接和基础时序。当传感器返回数据时，主循环调用RS485_Receive_Data()，该函数依赖RS485_RX_CNT变量。而RS485_RX_CNT的更新，恰恰来自这个中断服务程序——它每收到一字节，就执行一次RS485_TX_EN=1; ... RS485_TX_EN=0;，这个过程会间接影响RS485_RX_CNT的累加逻辑（虽然文档中未显式写出累加代码，但RS485_RX_BUF的填充必然发生在此处）。因此，这个看似多余的“回环”，实则是整个接收流程的启动触发器。去掉它，RS485_RX_CNT将永远为0。

3. 接收逻辑的致命盲区：为什么RS485_Receive_Data()永远等不到“接收完成”？

RS485_Receive_Data()函数的实现是典型的“超时判断法”：

void RS485_Receive_Data(u8 *buf,u8 *len){ u8 rxlen=RS485_RX_CNT; u8 i=0; *len=0; delay_ms(10); // 等待10ms,连续超过10ms没有接收到一个数据,则认为接收结束 if(rxlen==RS485_RX_CNT&&rxlen) { // 接收到了数据,且接收完成了 for(i=0;i<rxlen;i++){ buf[i]=RS485_RX_BUF[i]; } *len=RS485_RX_CNT; RS485_RX_CNT=0; } }

这个设计在单字节或固定长度响应（如Modbus RTU的5字节错误响应）下尚可工作，但面对土壤温湿度传感器返回的变长数据帧（文档中TR_Read指令预期返回8字节，但实际可能因干扰、地址错而返回更短或更长的乱码），它存在三个致命盲区，直接导致len始终为0。

3.1 盲区一：RS485_RX_CNT的更新非原子性与竞态条件

RS485_RX_CNT是一个全局变量，由中断服务程序USART2_IRQHandler在RXNE中断中递增：

// 假设在中断中，有类似这样的代码（文档未给出，但逻辑必然存在） if(USART_GetITStatus(USART2, USART_IT_RXNE) != RESET) { res = USART_ReceiveData(USART2); RS485_RX_BUF[RS485_RX_CNT++] = res; // 关键：非原子操作！ ... }

RS485_RX_CNT++在C语言中编译为多条汇编指令（读内存、加1、写回内存）。如果主循环执行u8 rxlen=RS485_RX_CNT;时，恰好中断正在执行RS485_RX_CNT++的中间步骤，主循环读到的就是一个撕裂值（Torn Value）。例如，RS485_RX_CNT原为0x00FF，中断读取低字节得0xFF，主循环此时读取，得到0xFF；中断接着加1变为0x0100，写回高字节0x01；主循环再读RS485_RX_CNT，得到0x01FF（高字节新、低字节旧）。于是rxlen（0xFF）与RS485_RX_CNT（0x01FF）永远不相等，if(rxlen==RS485_RX_CNT&&rxlen)条件永不成立。

3.2 盲区二：10ms超时窗口与RS485总线电气特性的根本冲突

RS485标准规定，两个字符间的最大间隔（Inter-Character Gap）可达多个字符时间。例如，在9600波特率下，一个字符1.04ms，标准允许间隔长达10ms以上。而文档中delay_ms(10)的硬超时，是基于“传感器响应快”的经验假设。但在真实工业环境，传感器可能因内部ADC转换、EEPROM读取或电源波动，导致响应延迟达20~50ms。此时，RS485_Receive_Data()在第一个字节到达后10ms就判定“接收结束”，而后续字节还在路上，RS485_RX_CNT仍在增长，rxlen（初始值）与RS485_RX_CNT（新值）自然不等，函数直接返回len=0。

3.3 盲区三：无帧头/帧尾识别，无法区分有效数据与总线噪声

RS485总线是共享的，任何节点发送都会被所有节点监听。RS485_RX_BUF缓存的是所有经过PA3引脚的电平变化，包括：

• 其他节点的正常通信（地址不匹配，但电平依然被采样）
• 总线上的瞬态干扰（ESD、电机启停产生的毛刺）
• 485芯片上电/掉电时的输出抖动 这些噪声会被RXNE中断捕获，写入RS485_RX_BUF，导致RS485_RX_CNT非零。但RS485_Receive_Data()没有做任何校验（如Modbus CRC、起始字节0x01判断），它只机械地比较rxlen和RS485_RX_CNT。结果就是：噪声填满了缓冲区，RS485_RX_CNT很大，但rxlen（第一次读的值）很小，条件不满足，函数返回len=0，而真正的有效数据早已被噪声覆盖。

4. 避坑：STM32F103 RS485通信中5个血泪换来的硬核排查清单

这些坑，每一个都曾让某开发者在凌晨三点对着示波器抓狂。它们不是理论问题，而是真实踩出来的“玄学”故障，根源全在软硬件时序的毫秒级博弈。

4.1 现象：发送指令后，示波器看到TX线上有波形，但485芯片A/B线无差分信号

原因：RS485_TX_EN（DE信号）未正确拉高，或拉高时刻错误。常见于RS485_Init()中GPIO初始化顺序错误——先配置了PA2/PA3，但忘记使能GPIOG时钟（RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOG, ENABLE)），导致PG3（DE）始终为高阻态，无法驱动485芯片。
解决：用万用表测量PG3引脚电压。空闲时应为0V（接收模式），发送时应跳变为3.3V。若始终为0V，检查RCC_APB2PeriphClockCmd是否遗漏GPIOG；若始终为3.3V，检查RS485_TX_EN=0;是否被意外注释或覆盖。

4.2 现象：能收到数据，但WD和SD显示乱码（如9999、-1）

原因：数据解析逻辑与传感器实际响应帧格式不匹配。文档中TR_Read指令{0x01,0x03,0x00,0x06,0x00,0x02,0xc4,0x38}是标准Modbus RTU读保持寄存器命令（地址0x01，起始寄存器0x0006，读2个寄存器），但传感器可能返回：

• 6字节：{0x01,0x03,0x04,0xXX,0xXX,0xYY,0xYY,0xZZ,0xZZ}（其中0x04是字节数，后4字节是温湿度）
• 而代码却固执地取rs485buf[3]和rs485buf[4]（假设为温度高/低字节），若传感器返回6字节，rs485buf[4]可能是校验位，导致计算错误。
  解决：用逻辑分析仪捕获真实响应帧，确认字节数和数据位置。修改解析逻辑，先检查rs485buf[2]（字节数字段），再按此长度安全读取。

4.3 现象：通信初期正常，运行数小时后突然卡死，RS485_Receive_Data()不再返回

原因：RS485_RX_CNT变量溢出。RS485_RX_CNT定义为u8（0~255），当总线持续受干扰，RXNE中断不断触发，RS485_RX_CNT从255溢出回0。此时RS485_RX_BUF[0]被新数据覆盖，而RS485_Receive_Data()中rxlen=RS485_RX_CNT（0）与RS485_RX_CNT（0）相等，但rxlen为0，if(rxlen==RS485_RX_CNT&&rxlen)条件因&&rxlen失败，函数返回len=0，RS485_RX_CNT卡在0，再也无法累加。
解决：将RS485_RX_CNT改为u16，并在USART2_IRQHandler中增加溢出保护：if(RS485_RX_CNT < sizeof(RS485_RX_BUF)) RS485_RX_CNT++;。

4.4 现象：多节点总线中，仅特定地址的传感器能通信，其他全失败

原因：485终端电阻缺失或位置错误。RS485要求总线两端各接一个120Ω终端电阻，以消除信号反射。若只在主控端接，或在中间节点接，会导致远端节点信号畸变，RXNE中断无法可靠触发。示波器看A/B线，远端波形应是干净方波，若呈圆弧状或振铃，则为反射。
解决：仅在物理总线的最左端和最右端（即距离最远的两个节点）各焊一个120Ω贴片电阻，跨接在A/B线之间。主控板和传感器板上的电阻必须共用同一组，不能每个板都焊。

4.5 现象：LCD显示数据跳变剧烈，温湿度值在合理范围外疯狂抖动

原因：RS485_Receive_Data()未做数据有效性校验，将噪声或部分接收的帧当作有效数据解析。例如，rs485buf[3]本应是温度高字节，但若只收到前3字节，rs485buf[3]是随机值（未初始化的RAM内容），导致WD=(rs485buf[3]*256+rs485buf[4])/100计算出荒谬结果。
解决：在RS485_Receive_Data()返回有效len后，增加校验：

if(*len >= 8 && rs485buf[0]==0x01 && rs485buf[1]==0x03) { // Modbus地址+功能码校验 u16 crc_calc = Modbus_CRC16(rs485buf, *len-2); // 计算CRC if(crc_calc == (rs485buf[*len-2] | (rs485buf[*len-1]<<8))) { // 校验成功 WD = (rs485buf[3]<<8) | rs485buf[4]; // 安全取值 SD = (rs485buf[5]<<8) | rs485buf[6]; } }

5. 从“能通”到“必通”：RS485驱动设计的三个不可妥协的工程取舍

把一份能点亮LED的代码，打磨成能在工厂车间7×24小时稳定运行的驱动，核心不在加多少功能，而在做对哪几个关键取舍。这些取舍，文档里不会明说，但源码的每一行都在无声诉说。

5.1 取舍一：用TC标志而非TXE标志——放弃“发送更快”的幻觉，拥抱硬件确定性

很多开发者追求极致效率，试图用TXE标志实现“流水线发送”：TXE一置位就写入下一字节，让TDR始终保持非空。这在UART直连PC的场景下可行，但在RS485上是灾难。因为TXE只保证TDR空，不保证移位寄存器空。TC标志虽慢（多等1个字符时间），但它提供的硬件级完成信号，是DE信号切换的唯一可信依据。放弃TXE，等于放弃了1ms的发送吞吐量，但换来了100%的帧完整性。在工业通信中，一个字节的丢失，代价远高于1ms的延迟。我从那以后，每次写RS485发送函数，第一行必是while(!USART_GetFlagStatus(USARTx, USART_FLAG_TC));，哪怕它让代码看起来“不够酷”。

5.2 取舍二：用环形缓冲区（Ring Buffer）替代全局数组——用40行代码，消灭90%的竞态风险

RS485_RX_BUF和RS485_RX_CNT的原始设计，是竞态的温床。正确的解法是采用环形缓冲区，并用原子操作管理读写指针。以下是精简版实现：

#define RS485_RX_BUF_SIZE 64 u8 RS485_RX_BUF[RS485_RX_BUF_SIZE]; volatile u16 RS485_RX_WR_PTR = 0; // 写指针，由中断修改 volatile u16 RS485_RX_RD_PTR = 0; // 读指针，由主循环修改 // 中断中安全写入（只需保证WR_PTR自增原子） void USART2_IRQHandler(void) { if(USART_GetITStatus(USART2, USART_IT_RXNE) != RESET) { u8 res = USART_ReceiveData(USART2); u16 next_wr = (RS485_RX_WR_PTR + 1) % RS485_RX_BUF_SIZE; if(next_wr != RS485_RX_RD_PTR) { // 缓冲区未满 RS485_RX_BUF[RS485_RX_WR_PTR] = res; __DSB(); // 数据同步屏障，确保写入完成 RS485_RX_WR_PTR = next_wr; // 原子更新指针（u16在Cortex-M3上是原子的） } } } // 主循环中安全读取 u8 RS485_Receive_Data(u8 *buf, u8 *len) { u16 rd = RS485_RX_RD_PTR; u16 wr = RS485_RX_WR_PTR; u16 count = (wr >= rd) ? (wr - rd) : (RS485_RX_BUF_SIZE - rd + wr); if(count == 0) return 0; *len = (count > 20) ? 20 : count; // 限制最大读取长度 for(u8 i=0; i<*len; i++) { buf[i] = RS485_RX_BUF[rd]; rd = (rd + 1) % RS485_RX_BUF_SIZE; } RS485_RX_RD_PTR = rd; // 更新读指针 return *len; }

这40行代码，用环形缓冲区消除了RS485_RX_CNT溢出和撕裂问题，用__DSB()屏障确保内存写入顺序，用指针差值计算长度规避了竞态。它比原始设计多占几字节RAM，但换来的是绝对的可靠性。希望帮到你。

本文还有配套的精品资源，点击获取