简介：这份资源面向嵌入式开发初学者与工业控制方向工程师，围绕STM32F103平台讲解RS485通信的完整实现思路，可解决长距离、多节点串行通信中收发使能控制与总线冲突等典型问题。压缩包共122个文件，约826KB，以C源码与头文件为主体，包含38个c、39个h，覆盖UART、GPIO、定时器、RCC等外设驱动，另有33个汇编启动文件、Keil工程文件（uvproj、uvopt）、hex烧录文件及说明文档，便于直接编译验证。资源中结合MAX485驱动器给出硬件连接与DE/RE使能控制方案，并涉及波特率配置、收发中断处理、错误检测与串口助手调试等要点，还提示终端电阻匹配与节点地址识别等注意事项。目前已有5516人学习下载，适合希望快速搭建RS485通信实验、理解半双工总线收发时序的读者参考借鉴。

1. 从一块工控板说起：为什么STM32的485通信值得单独拆一遍

去年帮一个做环境监测的朋友调一块采集板，STM32F103加MAX485，原理图看着没问题，代码也是网上抄的例程，结果上电后主机轮询十次能丢三次，偶尔还整条总线“锁死”，必须断电重启。折腾了两天才发现，问题不在USART配置，而在收发方向切换的时序和总线空闲判定上——这类坑，几乎每个第一次碰RS485的人都踩过。STM32实现485通信这件事，说简单也简单，一个USART加一个GPIO控制DE/RE就能收发；说难也难，半双工总线的方向切换、多机冲突、超时重传、终端匹配，每一项都能让现场调试变成玄学。这份资源就是围绕STM32的USART外设驱动RS485收发器，把从底层寄存器配置到上层帧协议解析的完整链路拆开讲清楚。它适合正在做工业采集、多机通信、Modbus RTU从站的嵌入式开发者，也适合刚学完串口、想搞明白“为什么我的485总丢包”的新手。下面我按“先跑通、再拆解、最后能改”的顺序，把这份代码里的关键实现一段段过一遍。

2. 项目结构与硬件链路：先搞清楚数据从哪来到哪去

2.1 目录组织与模块划分

拿到一份STM32工程，我习惯先看目录，因为目录结构基本暴露了作者的抽象层次。这份485通信项目的组织方式比较典型，按“硬件抽象—驱动—协议—应用”四层切开：

Project/ ├── CMSIS/ # 内核启动与外设寄存器定义 ├── STM32F10x_StdPeriph_Driver/ ├── User/ │ ├── main.c # 应用入口，轮询/中断调度 │ ├── stm32f10x_it.c # 中断服务函数 │ └── rs485_app.c # 业务帧处理 ├── Hardware/ │ ├── rs485.c # 485收发控制、方向切换 │ ├── rs485.h │ ├── usart.c # USART初始化与中断配置 │ └── timer.c # 超时定时器 └── Protocol/ ├── modbus_slave.c # 帧解析、CRC校验 └── modbus_slave.h

这个划分的好处是：Hardware/rs485.c只关心“什么时候拉高DE、什么时候拉低”，Protocol/只关心“这一帧数据合不合法”，两边通过一个收发缓冲队列解耦。二次开发时想换协议（比如从Modbus换成自定义帧），只动Protocol层就行，不用碰底层时序。

2.2 RS485收发器的硬件连接

RS485是半双工差分总线，STM32本身只出TTL串口，中间必须挂一颗收发器芯片（常见的是MAX485、SP3485、ADM2483等）。典型接法是：

关键点在DE和RE：多数收发器把这两个脚做成互补，DE高电平使能发送，RE低电平使能接收。工程里通常把DE和RE短接，用一个GPIO统一控制——拉高进发送态，拉低进接收态。这里有个血泪经验：方向切换必须在最后一个字节真正移出移位寄存器之后，否则会把帧尾截断。很多例程用USART_SendData发完就立刻拉低DE，结果对方收到的最后一字节是残的。

2.3 时钟与波特率配置

STM32F103的USART挂在APB2（USART1）或APB1（USART2/3）上，配置前先使能对应时钟。波特率由USART_InitStructure.USART_BaudRate决定，底层会根据PCLK和波特率算BRR寄存器。工业现场常用9600或19200，抗干扰余量大；短距离高速可以用115200。这里要注意：485总线上所有节点的波特率、数据位、停止位、校验位必须完全一致，一个节点配错，整条总线都会间歇性出错。

void RS485_Init(uint32_t baud) { GPIO_InitTypeDef gpio; USART_InitTypeDef usart; // 使能USART1和GPIOA时钟 RCC_APB2PeriphClockCmd(RCC_APB2Periph_USART1 | RCC_APB2Periph_GPIOA, ENABLE); // PA9 复用推挽输出（TX） gpio.GPIO_Pin = GPIO_Pin_9; gpio.GPIO_Mode = GPIO_Mode_AF_PP; gpio.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOA, &gpio); // PA10 浮空输入（RX） gpio.GPIO_Pin = GPIO_Pin_10; gpio.GPIO_Mode = GPIO_Mode_IN_FLOATING; GPIO_Init(GPIOA, &gpio); // PA8 推挽输出，控制DE/RE，默认拉低进接收态 gpio.GPIO_Pin = GPIO_Pin_8; gpio.GPIO_Mode = GPIO_Mode_Out_PP; GPIO_Init(GPIOA, &gpio); GPIO_ResetBits(GPIOA, GPIO_Pin_8); // USART参数：8数据位、1停止位、无校验、无流控 usart.USART_BaudRate = baud; usart.USART_WordLength = USART_WordLength_8b; usart.USART_StopBits = USART_StopBits_1; usart.USART_Parity = USART_Parity_No; usart.USART_HardwareFlowControl = USART_HardwareFlowControl_None; usart.USART_Mode = USART_Mode_Rx | USART_Mode_Tx; USART_Init(USART1, &usart); USART_ITConfig(USART1, USART_IT_RXNE, ENABLE); // 开接收中断 USART_Cmd(USART1, ENABLE); }

这段初始化里，GPIO_Mode_AF_PP是TX必须的复用推挽，RX用浮空输入即可（外部收发器已经驱动了电平）。PA8默认拉低，保证上电就处于接收态，避免总线上电瞬间误发数据。USART_IT_RXNE打开接收非空中断，后面收帧就靠它。

3. 核心模块拆解：方向切换、中断收帧与超时判定

3.1 发送流程与DE引脚时序

发送是485最容易翻车的地方。正确顺序是：拉高DE → 等一小段时间让收发器稳定 → 写数据到DR → 等TC（发送完成）标志 → 拉低DE。很多人漏掉“等TC”，只等TXE（发送数据寄存器空），结果最后一个字节还在移位寄存器里就把方向切回接收，帧尾就丢了。

void RS485_SendBytes(uint8_t *buf, uint16_t len) { uint16_t i; RS485_TX_EN(); // 拉高DE，进入发送态 delay_us(10); // 等收发器方向稳定，具体值看芯片手册 for (i = 0; i < len; i++) { while (USART_GetFlagStatus(USART1, USART_FLAG_TXE) == RESET); USART_SendData(USART1, buf[i]); } // 关键：等最后一个字节完全移出，才允许切回接收 while (USART_GetFlagStatus(USART1, USART_FLAG_TC) == RESET); RS485_RX_EN(); // 拉低DE，回到接收态 }

RS485_TX_EN()和RS485_RX_EN()就是对PA8的置位/复位宏。delay_us(10)这个稳定延时不是可有可无，某些收发器方向切换有几百纳秒到几微秒的建立时间，省掉它会在高速波特率下出现首字节错误。USART_FLAG_TC是发送完成标志，只有它置位才代表移位寄存器空了，这是和TXE的本质区别。

3.2 接收中断与帧缓冲

接收侧用RXNE中断逐字节收，但485是半双工，收的时候DE必须是低。中断里只做一件事：把DR里的字节塞进环形缓冲，然后重置超时定时器。帧的边界不靠中断判断，靠“总线空闲超时”——Modbus RTU规定3.5个字符时间无新字节即认为一帧结束。

#define RX_BUF_SIZE 256 static uint8_t rx_buf[RX_BUF_SIZE]; static uint16_t rx_len = 0; static uint8_t frame_ready = 0; void USART1_IRQHandler(void) { if (USART_GetITStatus(USART1, USART_IT_RXNE) != RESET) { uint8_t ch = USART_ReceiveData(USART1); if (rx_len < RX_BUF_SIZE) { rx_buf[rx_len++] = ch; } TIM_SetCounter(TIM2, 0); // 每收到一个字节就重置超时计数 TIM_Cmd(TIM2, ENABLE); // 启动/重启超时定时器 USART_ClearITPendingBit(USART1, USART_IT_RXNE); } }

rx_len记录当前帧已收字节数，TIM2负责超时。每来一个字节就清零定时器，只要字节间隔小于3.5字符时间，定时器就不会溢出；一旦总线安静超过阈值，TIM2溢出中断里把frame_ready置1，通知主循环“一帧收完了”。这种“中断收字节 + 定时器判帧尾”的组合，是485收帧最稳的做法，比在中断里直接解析协议要干净得多。

3.3 超时定时器与3.5字符时间计算

3.5字符时间跟波特率挂钩。一个字符按11位算（1起始+8数据+1校验+1停止，无校验时是10位），9600波特率下一个字符约1.04ms，3.5字符约3.65ms。定时器配置成这个溢出周期即可。

void RS485_TimeoutTimer_Init(uint32_t baud) { TIM_TimeBaseInitTypeDef tim; // 定时器时钟72MHz，预分频到1MHz，即1us计数一次 uint32_t arr = (uint32_t)(3.5f * 11.0f * 1000000.0f / baud); RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM2, ENABLE); tim.TIM_Prescaler = 72 - 1; tim.TIM_Period = arr - 1; tim.TIM_CounterMode = TIM_CounterMode_Up; tim.TIM_ClockDivision = TIM_CKD_DIV1; TIM_TimeBaseInit(TIM2, &tim); TIM_ITConfig(TIM2, TIM_IT_Update, ENABLE); NVIC_EnableIRQ(TIM2_IRQn); } void TIM2_IRQHandler(void) { if (TIM_GetITStatus(TIM2, TIM_IT_Update) != RESET) { TIM_Cmd(TIM2, DISABLE); // 停表，等下一帧再启动 frame_ready = 1; // 标记一帧接收完成 TIM_ClearITPendingBit(TIM2, TIM_IT_Update); } }

arr按波特率动态算，换波特率不用改代码。定时器只在收到字节时启动，空闲时不占CPU。主循环检测到frame_ready后，把rx_buf和rx_len交给协议层解析，解析完清空缓冲、复位rx_len，准备下一帧。

3.4 协议层：CRC校验与从站应答

帧收齐后进协议层。以Modbus RTU从站为例，先校验地址、功能码，再算CRC16，全对才执行并组应答帧。CRC是485通信里最容易被忽略又最不能省的一环——现场电磁干扰大，没有CRC，错帧会被当成有效命令执行，后果比丢包严重得多。

uint16_t Modbus_CRC16(uint8_t *buf, uint16_t len) { uint16_t crc = 0xFFFF; uint16_t i, j; for (i = 0; i < len; i++) { crc ^= buf[i]; for (j = 0; j < 8; j++) { if (crc & 0x0001) { crc >>= 1; crc ^= 0xA001; // Modbus多项式反向 } else { crc >>= 1; } } } return crc; } void Modbus_Slave_Process(uint8_t *buf, uint16_t len) { uint16_t crc_recv, crc_calc; if (len < 4) return; // 最短帧：地址+功能+CRC if (buf[0] != SLAVE_ADDR) return; // 不是本机地址，丢弃 crc_recv = buf[len - 2] | (buf[len - 1] << 8); crc_calc = Modbus_CRC16(buf, len - 2); if (crc_recv != crc_calc) return; // CRC错，静默丢弃 switch (buf[1]) { case 0x03: Modbus_ReadHolding(buf, len); break; case 0x06: Modbus_WriteSingle(buf, len); break; default: Modbus_Exception(buf[1], 0x01); break; } }

CRC16用0xA001多项式（Modbus标准），低字节在前。Modbus_Slave_Process先判长度、再判地址、再判CRC，任何一步不过就静默丢弃——这是从站该有的行为，不能对错帧做任何应答，否则会污染总线。应答时同样走RS485_SendBytes，方向切换逻辑复用，不用重写。

4. 避坑与排查：485现场调试最常见的5个问题

4.1 丢包、偶发错帧

现象：主机轮询，从站偶尔不应答，或应答数据错位。原因：多数是方向切换时序不对，DE拉低太早截断帧尾；或者波特率误差累积，长帧后半段采样偏移。解决：发送侧严格等USART_FLAG_TC再切方向；用示波器看A/B差分波形，确认帧尾完整；检查双方晶振，STM32用外部8MHz晶振比内部RC准得多，内部RC在115200下误差可能超3%。

4.2 总线“锁死”，必须断电重启

现象：通信跑一段时间后彻底不动，所有节点都不响应。原因：某个节点DE一直保持高电平，占着总线不放；或者收发器损坏把A/B拉死。解决：检查代码里是否存在异常分支没把DE拉低（比如发送函数中途return）；加看门狗，超时未完成发送就强制复位DE；硬件上A/B之间加120Ω终端电阻，但只在总线两端各一个，中间节点不加。

4.3 多机通信时相互干扰

现象：单机测试正常，挂上多个从站后错误率飙升。原因：总线拓扑不是手拉手，而是星形或树形分支，反射严重；或者多个节点同时发送。解决：485必须手拉手菊花链，分支线越短越好；协议上严格主从，从站只有被点名才应答，绝不主动发；必要时加隔离收发器（如ADM2483）切断地环流。

4.4 接收中断丢字节

现象：帧长度对不上，中间少字节。原因：中断里干了太多事（比如直接解析协议、算CRC），耗时超过一个字符时间，下一个字节来了还没退出中断，RXNE被覆盖。解决：中断里只搬字节进缓冲、重置定时器，解析全部放主循环；提高USART中断优先级；缓冲用环形队列，避免rx_len越界。

4.5 上电瞬间误触发

现象：设备上电时总线上冒出一帧乱码，导致主机误判。原因：GPIO初始化前DE处于浮空，收发器可能短暂进入发送态；或者上电时TX引脚电平跳变。解决：硬件上DE加下拉电阻，保证默认接收态；软件初始化时第一件事就是把DE对应GPIO配成推挽输出并拉低，再配USART。

提示：现场调试随身带一个USB转485工具和串口助手，能直接看总线原始字节，比在代码里加一堆打印高效得多。

5. 二次开发改造：从能跑到好用，我一般这么改

把这份代码跑通只是起点，真正上项目还得做几处改造。第一处是收发缓冲改成环形队列。现在的rx_buf是线性数组，收满256字节就丢后续数据，遇到长帧或连续帧会出问题。改成环形队列后，中断只负责入队，主循环出队解析，生产消费解耦，抗突发能力上一个台阶。

typedef struct { uint8_t buf[512]; volatile uint16_t head; // 中断里写 volatile uint16_t tail; // 主循环里读 } ring_t; static ring_t rx_ring; // 中断里入队 void ring_push(ring_t *r, uint8_t ch) { uint16_t next = (r->head + 1) % sizeof(r->buf); if (next != r->tail) { // 队列未满 r->buf[r->head] = ch; r->head = next; } // 满了就丢，绝不阻塞中断 }

head和tail用volatile修饰，因为一个在中断改、一个在主循环改。判断满的条件是(head+1)%size == tail，牺牲一个字节空间换无锁实现，这是嵌入式里最常用的环形队列写法。

第二处是加发送完成回调。现在RS485_SendBytes是阻塞的，发长帧时会卡住主循环。改成中断发送（TXE中断逐字节喂数据，TC中断里拉低DE并回调），主循环就能腾出来干别的。改造时注意：TXE中断里写DR，TC中断里切方向，两个中断标志别搞混。

第三处是协议层做成函数指针表。现在switch(buf[1])写死了功能码，加一个功能就要改一次switch。改成注册表：

typedef void (*handler_t)(uint8_t *buf, uint16_t len); typedef struct { uint8_t func; handler_t handler; } modbus_entry_t; static const modbus_entry_t modbus_table[] = { {0x03, Modbus_ReadHolding}, {0x06, Modbus_WriteSingle}, {0x10, Modbus_WriteMultiple}, }; handler_t Modbus_FindHandler(uint8_t func) { for (uint8_t i = 0; i < sizeof(modbus_table)/sizeof(modbus_table[0]); i++) { if (modbus_table[i].func == func) return modbus_table[i].handler; } return NULL; }

新增功能码只加一行表项，不动分发逻辑，符合开闭原则。验证改造是否成功，我一般用三步：先用串口助手手动发标准帧确认应答正确，再用脚本连续发1000帧统计丢包率（正常应低于0.1%），最后挂上真实从站跑24小时看有没有累积错误。

从那以后我每次改485代码，都强制先用示波器确认DE切换和帧尾对齐，再谈协议逻辑——时序不对，上层写得再漂亮都是空中楼阁。希望这份拆解帮到你，少走我当年那两个通宵的弯路。

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