简介：本资源是一份面向嵌入式初学者与STM32开发者的RS485工业通信实战指南，聚焦STM32F103微控制器（Cortex-M3内核）在土壤温湿度传感器数据采集场景中的RS485半双工通信实现。文档完整覆盖硬件原理（DE/RE使能控制、总线拓扑）、驱动开发（UART2初始化、收发状态切换、中断配置）、协议解析（Modbus RTU读取指令0x01 0x03）及LCD数据显示全流程，并附可直接移植的C语言源码（main.c、rs485.h/.c）与关键函数说明。资源为单文件DOCX文档，大小1.22MB，内容含原理图、引脚定义、代码节选与注释详解，结构清晰，便于边学边练。已有2628人学习下载，适合零基础入门RS485通信、理解STM32外设协同控制、掌握传感器数据采集闭环开发的实践者。
1. 这不是“串口改个线就能通”的玄学项目：一个能直接驱动土壤传感器、带完整LCD显示闭环的STM32F103 RS485工业通信实战包
你手头刚焊好一块STM32F103ZET6最小系统板，接上MAX485芯片，连了根双绞线到某款标称“Modbus RTU兼容”的土壤温湿度传感器——结果串口助手上只看到乱码，或者干脆没响应。查资料发现满屏都是“DE/RE引脚怎么接”“为什么发出去收不回来”“中断一开就卡死”，甚至有人把RS485当成UART直连调试，烧掉三片MAX485才明白：RS485不是UART的平替，而是带状态机、有时序、要抢总线、得手动切方向的半双工黑匣子。这个项目就是为这种场景而生的：它不讲抽象协议栈，不画大饼式架构图，而是一份从RS485_TX_EN=1那行GPIO控制开始，到LCD上实时刷出WD:23.5℃ SD:48%为止的端到端可运行工程。它用最朴素的轮询+中断混合模式，跑在经典F103平台，适配TFTLCD屏幕，所有代码基于标准外设库（SPL），无HAL、无CubeMX生成痕迹，新手照着引脚定义接线、改两处波特率、烧进板子就能看到数据；老手则能一眼看穿方向控制时序漏洞、接收超时判定逻辑缺陷、以及Modbus CRC校验缺失带来的现场翻车风险。如果你正被“RS485通讯方式原理”文档里那些波形图和真值表绕晕，又不想花三天啃完《RS-485标准物理层规范》，这份带实测传感器数据解析、含完整.docx原理图说明的源码包，就是你今天该下载并跑起来的那个。
2. 硬件链路与协议栈拆解：从PA2/PA3/PG3到Modbus RTU帧的完整映射
2.1 STM32F103ZET6的RS485硬件连接真相：DE/RE不是可有可无的装饰线
RS485芯片（如MAX485）的DE（Driver Enable）和RE（Receiver Enable）引脚，绝非某些教程里轻描淡写的“接个电阻到VCC就行”。在这个项目中，它们被严格绑定到PG3（即RS485_TX_ENPDout(7)宏定义中的PDout(7)，实际对应GPIOG Pin3）——这是整个通信可靠性的第一道闸门。我们来还原真实接线逻辑：
- PA2（USART2_TX） → MAX485 DI引脚：发送数据通道，仅当DE=1时生效
- PA3（USART2_RX） → MAX485 RO引脚：接收数据通道，仅当RE=0时生效
- PG3（GPIOG Pin3） → MAX485 DE & RE 引脚：关键！项目采用DE/RE共用设计（即DE=RE），通过
RS485_TX_EN=1拉高PG3使能发送，RS485_TX_EN=0拉低PG3使能接收
提示：这种DE/RE共用接法虽简化电路，但要求软件必须严格保证“发送完成→延时→切回接收”的时序。若DE未及时拉低，总线将被持续占用，其他节点无法响应——这正是工业现场“单点故障导致全网瘫痪”的典型起因。
2.2 Modbus RTU帧结构与传感器指令硬编码：TR_Read[8]数组里的秘密
项目中u8 TR_Read[8]={0x01,0x03,0x00,0x06,0x00,0x02,0xc4,0x38};并非随机字节，而是标准Modbus RTU读保持寄存器（Function Code 0x03）请求帧：
| 字节位置 | 值 | 含义说明 |
|---|---|---|
| 0 | 0x01 | 从站地址（Sensor ID），此处设为1，需与传感器拨码开关一致 |
| 1 | 0x03 | 功能码：读保持寄存器（Read Holding Registers） |
| 2-3 | 0x00,0x06 | 起始寄存器地址（0x0006），对应传感器手册中“温度值寄存器”地址 |
| 4-5 | 0x00,0x02 | 寄存器数量（2个），即读取温度+湿度共2个16位寄存器 |
| 6-7 | 0xc4,0x38 | CRC16校验码（低位在前），由前6字节计算得出，项目未提供计算函数，此值为静态预置 |
注意：CRC校验缺失是本项目的重大隐患。若传感器返回数据被干扰，程序会无条件解析
rs485buf[3]~rs485buf[6]，导致显示乱值。实际工程中必须在RS485_Receive_Data()后插入CRC校验步骤，否则等于裸奔。
2.3 USART2外设初始化关键参数：为什么必须禁用硬件流控且停用TC中断
RS485_Init()函数中对USART2的配置，每一项都直指RS485半双工特性：
USART_InitStructure.USART_BaudRate = bound; // 波特率：9600（传感器要求） USART_InitStructure.USART_WordLength = USART_WordLength_8b; // 8数据位（Modbus RTU强制要求） USART_InitStructure.USART_StopBits = USART_StopBits_1; // 1停止位（同上） USART_InitStructure.USART_Parity = USART_Parity_No; // 无校验（Modbus RTU明文规定） USART_InitStructure.USART_HardwareFlowControl = USART_HardwareFlowControl_None; // 必须禁用！RS485无RTS/CTS概念 USART_InitStructure.USART_Mode = USART_Mode_Rx | USART_Mode_Tx; // 收发双工（物理层），但逻辑层靠DE切换特别注意USART_HardwareFlowControl_None——若误设为USART_HardwareFlowControl_RTS，USART2将尝试控制RTS引脚，而PA3已被复用为RX，必然导致引脚冲突和通信失败。此外，USART_ITConfig(USART2, USART_IT_RXNE, ENABLE)仅开启接收中断（RXNE），未启用发送完成中断（TC），因为发送流程完全由RS485_Send_Data()中的轮询USART_FLAG_TC实现，避免中断嵌套复杂度。
2.4 接收缓冲区管理机制：RS485_RX_BUF[64]与RS485_RX_CNT的生存周期
项目采用全局缓冲区+计数器的极简方案，而非DMA或环形队列：
extern u8 RS485_RX_BUF[64]; // 静态分配64字节接收缓冲区 extern u8 RS485_RX_CNT; // 实时记录已接收字节数其工作流程在USART2_IRQHandler()中体现：
- 每收到1字节，
USART_ReceiveData()读取并存入RS485_RX_BUF[RS485_RX_CNT++] RS485_RX_CNT达到64时不会自动清零或丢弃，而是继续累加——这将导致后续接收数据覆盖缓冲区前部，引发解析错位RS485_Receive_Data()函数通过delay_ms(10)判断“空闲10ms即认为一帧结束”，但未重置RS485_RX_CNT，仅在RS485_Send_Data()末尾执行RS485_RX_CNT=0
这种设计在单次查询场景下可行，但若传感器支持连续上报（如0x03功能码轮询），
RS485_RX_CNT溢出将成定时炸弹。合格做法应是在每次RS485_Receive_Data()入口处强制if(RS485_RX_CNT>=64) RS485_RX_CNT=0;。
3. 核心通信模块逐行解析：RS485_Send_Data与RS485_Receive_Data的时序陷阱
3.1 发送函数RS485_Send_Data：三重延时构成的脆弱时序链
void RS485_Send_Data(u8 *buf,u8 len){ u8 t; RS485_TX_EN=1; // ① 拉高DE/RE，进入发送模式 for(t=0;t<len;t++){ while(USART_GetFlagStatus(USART2, USART_FLAG_TC) == RESET); // ② 等待上一字节发送完成 USART_SendData(USART2,buf[t]); // ③ 写入当前字节 } while(USART_GetFlagStatus(USART2, USART_FLAG_TC) == RESET); // ④ 等待最后一字节发送完成 RS485_RX_CNT=0; // ⑤ 清空接收计数器（但未清空缓冲区！） RS485_TX_EN=0; // ⑥ 拉低DE/RE，切回接收模式 }这段代码表面简洁，实则埋着三个致命时序坑：
坑1：DE拉高时机过早
RS485_TX_EN=1在for循环前执行，但USART2的TX引脚（PA2）需等待USART_Cmd(USART2, ENABLE)后才真正输出。若此时总线有其他设备正在发送，本机DE提前激活将导致信号冲突。正确做法：在写入第一个字节前10μs再拉高DE（需用NOP或微秒级延时）。坑2：TC标志等待逻辑缺陷
while(USART_GetFlagStatus(...)==RESET)在USART_SendData()后立即执行，但USART_SendData()只是将数据写入发送移位寄存器（TDR），TC标志需等移位完成才置位。若波特率9600（bit时间≈104μs），8位数据+1停止位≈1ms，轮询TC可能耗时过长。更优解：使用发送完成中断（TC IRQ），或至少添加超时保护（如while循环超过100次break）。坑3：DE拉低延迟不足
RS485_TX_EN=0在最后一字节TC置位后立即执行，但MAX485芯片从DE下降沿到RO引脚真正使能接收存在传播延迟（典型值200ns~2μs）。若此时传感器立刻回传数据，前几个bit将丢失。工业级实践：TC置位后插入delay_us(5)再拉低DE。
3.2 接收函数RS485_Receive_Data：10ms空闲判定的反模式设计
void RS485_Receive_Data(u8 *buf,u8 *len){ u8 rxlen=RS485_RX_CNT; u8 i=0; *len=0; delay_ms(10); // 关键：等待10ms空闲期 if(rxlen==RS485_RX_CNT&&rxlen){ // 若10ms内RX_CNT未变，认为接收完成 for(i=0;i<rxlen;i++){ buf[i]=RS485_RX_BUF[i]; } *len=RS485_RX_CNT; RS485_RX_CNT=0; // 清零计数器 } }这个delay_ms(10)是典型“经验主义”设计，问题在于：
- Modbus RTU帧间最小间隔为3.5字符时间（9600bps下≈3.5×104μs≈364μs），10ms远超此值，导致响应延迟过高
- 若传感器因干扰发送错误帧，
RS485_RX_CNT可能卡在非零值，delay_ms(10)后仍满足rxlen==RS485_RX_CNT，程序误判为有效帧 - 无法区分“帧结束”和“总线空闲”，在多节点轮询场景下易将其他节点的帧头误认为本机数据
正确做法：在
USART2_IRQHandler()中增加帧头检测（如连续接收0x01字节），结合字符间超时（如每字节间隔>1.5字符时间）判定帧结束，而非依赖固定delay_ms。
3.3 中断服务程序USART2_IRQHandler：隐藏的接收数据污染源
void USART2_IRQHandler(void){ u8 res; if(USART_GetITStatus(USART2, USART_IT_RXNE) != RESET){ res =USART_ReceiveData(USART2); RS485_TX_EN=1; // ❌ 错误！在接收中断中强行切发送模式 delay_ms(1); // ❌ 1ms延时在中断中极其危险 USART_SendData(USART2,res); // ❌ 向总线回传单字节？无意义且破坏协议 while(USART_GetFlagStatus(USART2,USART_FLAG_TC)!=1); delay_ms(2); RS485_TX_EN=0; } USART_ClearFlag(USART2,USART_FLAG_TC); }这段代码存在严重逻辑错误：
- 功能错位：
USART2_IRQHandler本应专注接收，却执行了发送操作，违背RS485主从通信模型（主机发查询帧，从机回响应帧） - 中断内延时：
delay_ms(1)和delay_ms(2)在中断中调用，将阻塞所有其他中断，违反实时性原则 - 数据污染：
USART_SendData(USART2,res)向总线发送单个接收到的字节，这既非Modbus响应也非心跳包，纯属干扰信号
此函数应被彻底删除。RS485通信的发送动作必须在
main()循环中由RS485_Send_Data()统一调度，中断仅负责将接收到的字节存入RS485_RX_BUF并更新RS485_RX_CNT。
4. LCD数据显示与传感器数据解析：从原始字节到温湿度数值的转换逻辑
4.1TR_Read指令响应数据结构：rs485buf[]中每个字节的物理意义
当TR_Read指令发出后，传感器返回的标准Modbus RTU响应帧（以WD=23.5℃, SD=48%为例）如下：
rs485buf[i] | 值 | 含义说明 |
|---|---|---|
| 0 | 0x01 | 从站地址（回显） |
| 1 | 0x03 | 功能码（回显） |
| 2 | 0x04 | 数据字节数（2个寄存器×2字节=4字节） |
| 3 | 0x00 | 温度高字节（Temperature High Byte） |
| 4 | 0xXX | 温度低字节（Temperature Low Byte），组合为`(0x00<<8) |
| 5 | 0xYY | 湿度高字节（Humidity High Byte） |
| 6 | 0xZZ | 湿度低字节（Humidity Low Byte），组合为`(0xYY<<8) |
| 7-8 | 0x??,0x?? | CRC16校验码（低位在前） |
项目中解析逻辑为：
WD=(rs485buf[3]*256+rs485buf[4])/100; // 温度：高位×256+低位，再除以100得℃值 SD=(rs485buf[5]*256+rs485buf[6])/10; // 湿度：高位×256+低位，再除以10得%值注意：此计算假设传感器返回的是整型原始值（如2350代表23.50℃），但不同厂商寄存器格式可能为BCD码或浮点数。若显示异常，需查阅传感器手册确认寄存器数据格式，并调整解析公式。
4.2 TFTLCD显示函数LCD_ShowxNum参数详解：数字对齐与字体大小的硬编码陷阱
LCD_ShowxNum(30,190,WD,4,24,0)中各参数含义：
| 参数 | 值 | 说明 |
|---|---|---|
| 1 | 30 | X坐标（像素），从屏幕左边缘起算 |
| 2 | 190 | Y坐标（像素），从屏幕顶边缘起算（注意：部分TFTLCD坐标系Y轴向下为正） |
| 3 | WD | 要显示的整数变量 |
| 4 | 4 | 显示位数（不足补0），此处WD=2350显示为2350，WD=5显示为0005 |
| 5 | 24 | 字体大小（点阵高度），24号字体对应约12×24像素的ASCII字符 |
| 6 | 0 | 符号位处理：0=不显示符号，1=显示负号（但土壤传感器温度无负值，此参数冗余） |
风险提示：
LCD_ShowxNum函数内部若未做边界检查，当WD值过大（如WD=10000）时，4位显示将截断为0000。建议在调用前添加范围校验：if(WD>9999) WD=9999;。
4.3 主循环while(1)中的时序节奏：300ms发送 + 3000ms刷新的合理性分析
while(1){ RS485_Send_Data(TR_Read,8); // 发送查询指令 delay_ms(300); // 等待传感器响应（典型响应时间<100ms，300ms足够） RS485_Receive_Data(rs485buf,&len); // 接收响应 if(len){ /* 解析并显示 */ } delay_ms(3000); // 整体刷新周期3秒 }此节奏设计符合工业传感器常规要求：
- 300ms等待：覆盖9600bps下最长响应（10字节×104μs/bit×10bit≈104ms）并留足余量
- 3000ms刷新：避免频繁轮询消耗总线资源，同时满足环境监测类应用秒级更新需求
但需注意：若总线挂载多个传感器（如地址0x01/0x02/0x03），此循环需扩展为地址遍历，且每个地址间需插入delay_ms(50)以上间隔，防止地址切换时的电气冲突。
5. 避坑指南：STM32F103 RS485项目中踩过的5个真实血泪坑
5.1 现象：串口助手能看到发送数据，但传感器无任何响应
原因：PA2（TX）与PA3（RX）接反，或MAX485的DI/RO引脚与MCU接反。更隐蔽的情况是PG3（DE/RE）未接或虚焊，导致RS485芯片始终处于接收态，无法发送。
解决：用万用表测量PG3电压——发送时应为3.3V，接收时应为0V；若恒为0V，检查RS485_TX_EN宏定义是否指向正确GPIO（本项目为PDout(7)即GPIOG Pin3），并确认RS485_Init()中GPIO_Init(GPIOG,&GPIO_InitStructure)已执行。
5.2 现象：LCD显示温湿度数值跳变剧烈（如23℃→9999℃→12℃）
原因：RS485_Receive_Data()未校验CRC，将受干扰的错误帧当作有效数据解析。例如CRC校验失败的帧中rs485buf[3]为0xFF，导致WD=(0xFF*256+rs485buf[4])/100溢出为极大值。
解决：在RS485_Receive_Data()解析前插入CRC16校验函数。参考Modbus RTU标准，对rs485buf[0]到rs485buf[len-3]（排除最后2字节CRC）计算CRC，比对rs485buf[len-2]（低字节）和rs485buf[len-1]（高字节）。校验失败则*len=0并清空缓冲区。
5.3 现象：程序运行一段时间后卡死在while(USART_GetFlagStatus(...)==RESET)
原因：RS485_Send_Data()中TC标志等待无限循环。常见于USART2时钟未使能（RCC_APB1PeriphClockCmd(RCC_APB1Periph_USART2,ENABLE)遗漏）或波特率设置错误导致TC永不置位。
解决：在while循环内添加计数器超时保护：
u16 timeout = 0; while((USART_GetFlagStatus(USART2, USART_FLAG_TC) == RESET) && (timeout++ < 0xFFFF)); if(timeout >= 0xFFFF) { /* 处理超时错误 */ }5.4 现象：多台传感器挂同一总线时，仅地址0x01响应，其余无反应
原因：TR_Read数组中从站地址写死为0x01，未根据目标传感器动态修改。更严重的是，RS485_Send_Data()发送后未等待足够时间（≥1.5字符时间）再切回接收，导致后续传感器的响应被本机DE信号屏蔽。
解决：将TR_Read[0]改为变量slave_addr，在发送前赋值；并在RS485_Send_Data()末尾RS485_TX_EN=0后插入delay_us(500)（9600bps下1.5字符时间≈156μs，500μs足够）。
5.5 现象：LCD显示乱码或花屏，但串口通信正常
原因：LCD_Init()初始化时序与所用TFTLCD型号不匹配。本项目默认适配ILI9341控制器，若实际使用ST7735或SSD1306，则LCD_Init()中SPI/FSMC配置、初始化指令序列均需重写。
解决：确认LCD型号，替换lcd.c中LCD_Init()函数为对应驱动。重点检查LCD_WR_REG()和LCD_WR_DATA()底层写函数——若为SPI接口，需确保SPI_I2S_SendData()调用正确；若为8080并口，需验证LCD_RS/LCD_WR/LCD_RD等控制线时序。
6. 二次开发实战：从单传感器轮询到多节点Modbus主站的改造路径
6.1 多地址轮询框架：构建地址数组与状态机驱动的查询引擎
要支持挂载5个不同地址的传感器（0x01~0x05），需重构主循环为状态机：
#define SENSOR_NUM 5 u8 sensor_addr[SENSOR_NUM] = {0x01,0x02,0x03,0x04,0x05}; u8 current_sensor = 0; // 当前查询索引 u8 query_state = 0; // 0=空闲, 1=已发送, 2=等待响应, 3=解析完成 while(1){ switch(query_state){ case 0: // 准备发送 TR_Read[0] = sensor_addr[current_sensor]; // 动态设置从站地址 RS485_Send_Data(TR_Read,8); query_state = 1; break; case 1: // 等待响应（300ms） if(ms_timer_flag){ // 基于SysTick的毫秒标志 ms_timer_flag = 0; query_state = 2; } break; case 2: // 接收并解析 RS485_Receive_Data(rs485buf,&len); if(len && verify_crc(rs485buf,len)){ // CRC校验通过 parse_sensor_data(rs485buf, current_sensor); // 解析到sensor_data[current_sensor] query_state = 3; } else { query_state = 0; // 丢弃错误帧，重试当前地址 } break; case 3: // 显示并切换下一地址 display_sensor_data(current_sensor); current_sensor = (current_sensor + 1) % SENSOR_NUM; query_state = 0; break; } delay_ms(10); // 状态机最小步进 }关键点：
verify_crc()必须实现标准Modbus CRC16算法（初始值0xFFFF，多项式0xA001），parse_sensor_data()需根据地址索引存储到独立结构体，避免rs485buf被覆盖。
6.2 接收缓冲区升级：从静态数组到环形缓冲区的平滑迁移
为支撑多节点轮询和未来扩展，将RS485_RX_BUF[64]升级为环形缓冲区：
#define RS485_RX_BUFFER_SIZE 256 typedef struct { u8 buffer[RS485_RX_BUFFER_SIZE]; volatile u16 head; // 下一个写入位置 volatile u16 tail; // 下一个读取位置 } rs485_ring_buffer_t; rs485_ring_buffer_t rs485_rx_buf; // 中断中写入 void USART2_IRQHandler(void){ if(USART_GetITStatus(USART2, USART_IT_RXNE) != RESET){ u8 data = USART_ReceiveData(USART2); u16 next_head = (rs485_rx_buf.head + 1) % RS485_RX_BUFFER_SIZE; if(next_head != rs485_rx_buf.tail){ // 缓冲区未满 rs485_rx_buf.buffer[rs485_rx_buf.head] = data; rs485_rx_buf.head = next_head; } } } // 主循环中读取（按帧解析） u8 rs485_ring_read_frame(u8 *frame, u8 *len){ u16 available = (rs485_rx_buf.head >= rs485_rx_buf.tail) ? (rs485_rx_buf.head - rs485_rx_buf.tail) : (RS485_RX_BUFFER_SIZE - rs485_rx_buf.tail + rs485_rx_buf.head); if(available < 5) return 0; // 至少5字节（地址+功能码+字节数+1数据+CRC） // 扫描帧头（0x01~0x04等合法地址） for(u16 i=rs485_rx_buf.tail; i!=rs485_rx_buf.head; i=(i+1)%RS485_RX_BUFFER_SIZE){ if(rs485_rx_buf.buffer[i] >= 0x01 && rs485_rx_buf.buffer[i] <= 0x04){ // 找到地址，检查后续长度... break; } } return 1; }改造收益：彻底解决
RS485_RX_CNT溢出风险，支持任意长度帧接收，为后续接入Modbus TCP网关预留接口。
6.3 工业级健壮性增强：添加超时重传与错误统计
在query_state==2分支中加入重传机制：
u8 retry_count = 0; #define MAX_RETRY 3 case 2: if(retry_count < MAX_RETRY){ RS485_Receive_Data(rs485buf,&len); if(len && verify_crc(rs485buf,len)){ parse_sensor_data(rs485buf, current_sensor); retry_count = 0; // 成功则清零重试计数 query_state = 3; } else { retry_count++; if(retry_count >= MAX_RETRY){ sensor_error_count[current_sensor]++; // 记录错误次数 query_state = 0; // 切换下一传感器，避免死锁 } } } else { query_state = 0; } break;这种设计让系统具备自愈能力：单次通信失败不影响整体轮询，错误累积到阈值可触发告警（如LED闪烁、UART日志输出），符合工业设备“故障隔离”原则。
从那以后我每次接手RS485项目，都会先用示波器抓DE引脚波形，确认方向切换时序是否满足芯片手册要求；再用逻辑分析仪解码总线数据，验证CRC和寄存器地址是否正确；最后才动LCD显示代码。因为方向控制错了，后面所有解析都是空中楼阁。希望帮到你。
本文还有配套的精品资源，点击获取
