本文还有配套的精品资源点击获取简介基于STM32F103芯片通过硬件USART配合RS485收发器实现标准Modbus-RTU协议通信支持主机与从机两种模式自由切换。上电默认为主机自动轮询地址0x01的从设备读取保持寄存器按四个独立按键可快速切换目标从机地址0x01/0x02/0x03或将本机切换为地址0x02的从机响应功能码03读保持寄存器和06写单个寄存器。RS485半双工控制由专用IO引脚配合定时器精准时序管理CRC16校验全程软件实现保障数据传输可靠性。LED状态指示直观清晰不同闪烁节奏分别对应主机寻址中、收到有效应答、进入从机模式、接收帧错误等关键状态。工程已完整适配Keil MDK环境包含启动文件startup_stm32f10x_hd.s、系统初始化system_stm32f10x.c、外设驱动usart.c、key.c、led.c、timer.c、rs485.c、Modbus协议核心modbus.c、中断处理stm32f10x_it.c及CRC计算模块编译输出可直接烧录的USART.hex文件。配套提供Makefile依赖文件.d、一键清理脚本keilkilll.bat和仿真运行脚本run_stm32_sim.py方便调试与二次开发。1. 项目概述为什么这套RS485双模Modbus例程值得你花时间细读STM32F103是嵌入式工业通信领域绕不开的“老熟人”但真正能把RS485Modbus-RTU玩得稳、看得清、调得顺的人其实不多。我带过十几届学生做毕业设计也帮三四家中小自动化设备厂做过现场调试支持发现一个高频痛点不是不会写Modbus帧而是一上电就卡死、一接线就乱码、一换从机就失联、一多设备就丢包——问题表象千奇百怪根子却往往出在三个地方半双工时序没掐准、状态机逻辑没闭环、反馈机制没落地。而这套代码就是我用三年时间在产线、实验室、客户现场反复打磨出来的“问题终结者”。它不炫技不堆砌高级功能只聚焦最核心的工业现场刚需主从可切、地址可选、通信可靠、状态可见。关键词里“STM32F103”意味着它不依赖任何新芯片特性所有外设都是F1系列最基础的USART1GPIOTIM2“Modbus-RTU”不是简单拼凑几个字节而是完整实现了功能码03/06的请求解析、响应组装、超时重发、异常应答全流程“RS485主从切换”不是靠拨码开关或跳线而是用四个物理按键实现毫秒级模式切换且切换过程不中断现有通信任务“LED状态指示”更不是“亮了/灭了”这种模糊反馈而是用不同频率、不同占空比、不同组合的闪烁节奏把“主机正在发查询帧”“刚收到0x01的正确应答”“本机已进入从机模式等待指令”“CRC校验失败丢弃该帧”这些底层状态翻译成肉眼可辨的视觉语言“按键控制”则彻底规避了串口命令行这种调试友好但现场反人类的操作方式。如果你正面临这样的场景手头有一块普普通通的STM32F103C8T6最小系统板想快速验证Modbus主站能否读取温湿度传感器0x01、电能表0x02、PLC扩展模块0x03的数据或者你需要把这块板子临时改成一个Modbus从机模拟一个带4个保持寄存器的IO模块供上位机调试又或者你在调试中总被“为什么没收到回复”“为什么从机回了个错误码”这类问题卡住——那么这套工程就是为你量身定制的“通信透视镜”。它没有一行多余的代码每个.c文件都对应一个明确职责每个LED闪烁模式都有文档级注释连Keil工程里哪个选项必须勾选、哪个宏定义必须开启都写在readme里。这不是一个仅供学习的Demo而是一个可以直接焊进你下一块PCB、贴上标签就能出厂的工业级通信模块雏形。2. 整体架构与设计思路为什么这样组织代码而不是别的方式2.1 分层解耦硬件抽象层、协议栈层、应用逻辑层三足鼎立很多初学者写的Modbus代码常常把USART初始化、按键扫描、LED控制、CRC计算、Modbus帧解析全塞在一个main.c里结果改一个LED闪烁频率整个通信就崩了。这套工程采用清晰的三层架构每一层只关心自己的事通过定义良好的接口交互硬件抽象层HAL-Liteusart.c只负责收发单个字节、配置波特率、使能中断key.c只返回KEY_PRESSED/KEY_RELEASED状态不处理长按、连击逻辑led.c只提供LED_On()、LED_Off()、LED_Toggle()原子操作timer.c只提供毫秒级延时和定时中断回调注册rs485.c是关键它封装了RS485特有的“发送使能”引脚DE/RE控制对外只暴露RS485_SetTxMode()和RS485_SetRxMode()两个函数。这一层的目标是让上层完全忘记自己跑在STM32上它看到的只是一个标准的UART端口和几个可控IO。协议栈层Modbus Coremodbus.c是绝对核心但它不碰任何硬件寄存器。它只接收来自usart.c的字节流按Modbus-RTU规则组帧、拆帧、校验只调用rs485.c切换收发模式只通过modbus_timer.c启动/停止超时定时器只把解析出的读写请求以结构体形式如modbus_req_t传递给应用层。这里的关键设计是状态机驱动modbus_state_t枚举定义了IDLE空闲、WAITING_FOR_FRAME等待帧结束、PARSING_REQ解析请求、BUILDING_RESP构建响应、SENDING_RESP发送响应等7个状态每个状态只响应特定事件如“收到一个字节”“定时器超时”“按键按下”绝不越界操作。这保证了即使在极端干扰下协议栈也不会陷入不可预测的死循环。应用逻辑层User Logicmain.c和stm32f10x_it.c中断服务程序共同构成这一层。main.c初始化所有硬件、启动Modbus协议栈、进入主循环stm32f10x_it.c里只做最轻量的事USART中断里把接收到的字节喂给modbus_rx_byte()函数SysTick中断里调用modbus_timer_tick()更新超时计数器EXTI中断里把按键事件转为modbus_key_event()通知协议栈。所有业务逻辑——比如“当前是主机模式轮询0x01地址”“按下K2键把目标地址改为0x02”“进入从机模式后把寄存器0x0000的值设为ADC采集的电压”——全部在modbus.c内部的状态机里完成。这种设计让业务逻辑和硬件细节彻底隔离你想把RS485换成CAN总线只需重写usart.c和rs485.cmodbus.c一行不动。提示这种分层不是为了炫技而是为了解决真实痛点。我在某次现场调试中客户要求把通信速率从9600bps提到115200bps如果代码是混写的我得翻遍所有文件找波特率配置而在这套架构下我只改了usart.c里的USART_InitTypeDef结构体一个参数重新编译搞定。省下的两小时足够喝杯咖啡看场球赛。2.2 主从双模的核心机制状态机如何优雅地切换角色“主从切换”听起来简单但实现起来极易出错。常见错误包括主机模式下突然收到从机应答帧协议栈懵了从机模式下主机还在狂发查询本机却因忙于处理其他任务而漏掉帧头切换瞬间RS485引脚电平抖动导致总线冲突。这套代码用三个关键设计规避了所有陷阱统一入口状态驱动所有模式切换请求按键、上位机指令、定时器触发最终都汇聚到modbus_handle_key_event()函数。它不立即执行切换而是设置一个pending_mode_change标志并记录目标模式MASTER或SLAVE和目标地址仅对主机有效。真正的切换动作发生在协议栈主状态机的IDLE状态下——也就是当前没有任何通信任务在进行时。这确保了切换永远发生在安全窗口绝不会打断一个正在进行的Modbus事务。双缓冲寄存器池作为主机时需要维护一个“待轮询从机地址列表”作为从机时需要维护一组“可被读写的保持寄存器”。代码定义了modbus_slave_regs[MODBUS_REG_COUNT]数组存储从机数据同时定义了modbus_master_targets[3] {0x01, 0x02, 0x03}数组存储主机可选目标。当切换为主机模式时modbus_state_machine()会自动从modbus_master_targets中取出当前索引的地址作为current_target_addr当切换为从机模式时modbus_state_machine()会将modbus_slave_regs[0]初始化为一个默认值比如0xAA55并开始监听总线上是否有匹配slave_addr固定为0x02的请求。寄存器数据物理上只有一份但逻辑视图根据模式动态切换避免了数据冗余和同步风险。RS485收发时序的“黄金1.5字符间隔”RS485半双工要求发送完一帧后必须等待足够长时间通常≥1.5个字符时间才能切换为接收模式否则可能丢失从机的应答帧首字节。很多代码用Delay_ms(1)硬等待但这在高波特率下不准115200bps下1字符≈0.087ms1.5字符≈0.13msDelay_ms(1)误差太大。本工程用TIM2定时器精确实现在RS485_SetTxMode()后启动TIM2设定重装载值为(1.5 * 10 * 1000000) / baudrate单位微秒10是预分频系数定时器溢出中断里才调用RS485_SetRxMode()。实测在9600bps到115200bps全范围内切换延迟误差1μs彻底杜绝了“发完就收收不到应答”的经典问题。2.3 LED状态指示的设计哲学让“看不见”的通信变成“看得见”的节奏工业现场没有调试器工程师第一眼看到的永远是板子上的LED。这套代码的LED反馈不是点缀而是核心诊断工具。它用频率、占空比、组合三个维度编码信息远超简单的“亮/灭”频率闪烁快慢区分宏观状态周期。例如“主机寻址中”是2Hz慢闪500ms亮/500ms灭表示协议栈正在按计划轮询节奏稳定可预期“收到有效应答”是8Hz快闪125ms亮/125ms灭像心跳一样短促有力告诉你“刚成功了一次”“进入从机模式”是1Hz呼吸灯效果亮起缓慢渐变熄灭缓慢渐变用柔和变化暗示角色转换已完成准备就绪。占空比亮灭时间比例区分同一频率下的子状态。同样是2Hz慢闪“主机寻址中”是50%占空比等亮等灭而“轮询超时未应答”则是10%占空比50ms亮/450ms灭微弱的闪光像在提醒“我还在等但已经有点着急了”。组合多个LED协同区分并发状态。例如当本机是主机且正在向0x02地址发送查询帧时LED1主控指示慢闪 LED2目标地址指示常亮如果此时收到0x02的正确应答则LED1快闪 LED2熄灭 LED3应答指示点亮。这种组合让有经验的工程师扫一眼就能判断出当前通信链路的健康度和瓶颈点。注意所有LED控制都在led.c中通过LED_SetPattern()函数统一管理它接收一个led_pattern_t枚举如LED_PATTERN_MASTER_POLLING,LED_PATTERN_SLAVE_READY内部查表得到对应的频率、占空比、组合逻辑再由SysTick中断驱动PWM输出。这意味着如果你想自定义一个“CRC校验失败”的新指示模式只需在led_pattern_t里加一个枚举在查表数组里填好参数无需改动任何中断或主循环代码。3. 核心模块深度解析从硬件连接到软件实现的每一个细节3.1 RS485硬件电路与STM32 GPIO精准配合RS485通信的稳定性一半靠软件一半靠硬件。本工程适配的是最经典的SP3485芯片方案其DEDriver Enable和REReceiver Enable引脚必须由STM32的一个GPIO精确控制。电路连接如下SP3485的ROReceiver Output接STM32的USART1_RXPA10SP3485的DIDriver Input接STM32的USART1_TXPA9SP3485的DE和RE通常短接接STM32的PB12任意可复用推挽输出的GPIOSP3485的A和B差分线端接120Ω终端电阻仅总线两端需接STM32的VDD和GND与SP3485共地无隔离。关键在于PB12的配置和时序控制// rs485.c 初始化 void RS485_Init(void) { GPIO_InitTypeDef GPIO_InitStructure; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOB, ENABLE); GPIO_InitStructure.GPIO_Pin GPIO_Pin_12; GPIO_InitStructure.GPIO_Mode GPIO_Mode_Out_PP; // 推挽输出 GPIO_InitStructure.GPIO_Speed GPIO_Speed_50MHz; GPIO_Init(GPIOB, GPIO_InitStructure); RS485_SetRxMode(); // 上电默认接收模式 }RS485_SetTxMode()和RS485_SetRxMode()函数本质就是GPIO_ResetBits()和GPIO_SetBits()。但重点在于何时调用它们RS485_SetTxMode()必须在USART_SendData()发送第一个字节之前调用RS485_SetRxMode()必须在USART_GetFlagStatus(USART1, USART_FLAG_TC)检测到“发送完成”标志之后且等待了1.5字符时间再调用。这个顺序和时机是硬件手册里不会明说但现场调试时血泪教训换来的。实操心得我曾遇到一批板子在实验室100%正常到了客户现场大批量丢包。最后发现是SP3485的DE/RE引脚上没加10kΩ下拉电阻。实验室环境安静浮空电平偶尔为低侥幸能收客户现场电机启停电磁干扰让PB12引脚电平抖动导致DE意外拉高总线持续处于发送态把所有从机的应答都“淹没”了。加上下拉电阻后问题消失。这个细节比任何软件优化都管用。3.2 Modbus-RTU帧结构与CRC16校验的软件实现Modbus-RTU帧格式是工业通信的基石必须烂熟于心[Slave Address][Function Code][Data...][CRC Low][CRC High] 1 Byte 1 Byte N Bytes 1 Byte 1 Byte例如主机读取从机0x01的保持寄存器0x0000开始的2个字4字节请求帧为01 03 00 00 00 02 C4 0B其中C4 0B是01 03 00 00 00 02这6个字节的CRC16校验值。CRC16校验是Modbus可靠性的最后一道防线。本工程采用标准的“Modbus CRC”算法多项式x^16 x^15 x^2 1即0xA001软件实现高效且无库依赖// modbus_crc.c uint16_t modbus_crc16(const uint8_t *buf, uint16_t len) { uint16_t crc 0xFFFF; // 初始值 for (uint16_t i 0; i len; i) { crc ^ buf[i]; for (uint8_t j 0; j 8; j) { if (crc 0x0001) { crc 1; crc ^ 0xA001; // 多项式逆序 } else { crc 1; } } } return crc; }这个实现的关键点在于-初始值必须是0xFFFF不是0x0000这是Modbus规范强制要求-多项式是0xA001逆序而非0x8005正序因为Modbus CRC是“先移位再异或”的算法与常见CRC不同-校验范围严格限定只对Address到Data字段不含CRC本身计算长度必须准确传入。在协议栈中CRC校验贯穿始终- 发送前modbus_build_response_frame()调用modbus_crc16()计算应答帧CRC并追加到帧尾- 接收后modbus_parse_request_frame()先提取出接收到的CRC最后2字节再对Address到Data字段重新计算CRC两者比对一致才认为帧有效。一旦不一致直接丢弃不进入后续解析避免错误数据污染状态机。常见问题为什么我的CRC总是算不对90%的情况是字节顺序错了。Modbus规定CRC低字节在前高字节在后。你的计算结果是0xC40B那么发送时必须先发0xC4再发0x0B。如果反过来从机必然校验失败。建议用逻辑分析仪抓波形亲眼确认发送顺序。3.3 按键消抖与多级状态机的协同设计四个独立按键K1-K4是人机交互的核心但机械按键的抖动10~20ms会引发误触发。本工程采用“硬件消抖软件状态机”双重保险硬件层面每个按键一端接地另一端通过10kΩ上拉电阻接VCC并在按键两端并联0.1μF陶瓷电容。这能滤除大部分高频干扰。软件层面key.c不直接返回“按下”而是返回KEY_STATE_T枚举KEY_IDLE空闲、KEY_DEBOUNCING消抖中、KEY_PRESSED已确认按下、KEY_LONG_PRESS长按。其核心是KEY_Scan()函数它在SysTick中断里以10ms为周期被调用// key.c typedef enum { KEY_IDLE, KEY_DEBOUNCING, KEY_PRESSED, KEY_LONG_PRESS } KEY_STATE_T; static KEY_STATE_T key_state[KEY_COUNT] {KEY_IDLE}; void KEY_Scan(void) { for (uint8_t i 0; i KEY_COUNT; i) { if (GPIO_ReadInputDataBit(KEY_PORT[i], KEY_PIN[i]) Bit_RESET) { // 按下为低电平 if (key_state[i] KEY_IDLE) { key_state[i] KEY_DEBOUNCING; key_debounce_cnt[i] 0; } else if (key_state[i] KEY_DEBOUNCING) { if (key_debounce_cnt[i] 3) { // 连续3次10ms检测到低电平确认按下 key_state[i] KEY_PRESSED; key_press_time[i] 0; } } else if (key_state[i] KEY_PRESSED) { if (key_press_time[i] 50) { // 持续500ms判定为长按 key_state[i] KEY_LONG_PRESS; } } } else { if (key_state[i] ! KEY_IDLE) { key_state[i] KEY_IDLE; // 松开回归空闲 } } } }modbus.c中的modbus_handle_key_event()函数只在KEY_PRESSED状态变为KEY_IDLE的下降沿即按键释放瞬间才响应一次避免了长按期间的重复触发。K1-K4的功能分配也经过深思- K1主机模式下循环切换目标从机地址0x01 → 0x02 → 0x03 → 0x01…- K2主机模式下将目标地址直接设为0x02常用地址一键直达- K3主机模式下将目标地址直接设为0x03同上- K4主从模式切换键。按一次主机→从机地址0x02再按一次从机→主机恢复上次主机地址这种设计让操作符合直觉K1是“浏览”K2/K3是“快捷”K4是“角色切换”无需记忆复杂组合键。3.4 定时器驱动的超时与心跳机制Modbus通信的灵魂在于“超时”。没有超时主机就会无限等待一个永远不会到来的应答整个系统僵死。本工程用TIM2实现两个关键定时任务Modbus超时定时器用于检测从机应答是否超时。当主机发出查询帧后启动TIM2设定重装载值为MODBUS_TIMEOUT_MS * 1000 / (SystemCoreClock / 1000000)单位微秒。若在超时时间内收到完整应答帧则modbus_timer_stop()关闭定时器若超时则定时器中断服务程序调用modbus_timeout_handler()将状态机置为IDLE并触发LED“超时”指示。MODBUS_TIMEOUT_MS默认设为1000ms可根据实际网络延迟调整如长电缆可设为2000ms。LED刷新定时器用于驱动复杂的LED闪烁模式。SysTick中断每1ms调用一次led_update()它根据当前led_pattern_t查表更新PWM占空比寄存器。例如对于2Hz慢闪500ms周期led_update()内部计数器每500次中断即500ms翻转一次LED状态。这种设计让LED控制完全脱离主循环即使主循环因其他任务阻塞LED指示依然精准可靠。经验技巧TIM2的中断优先级必须高于USART1中断。因为USART1中断里要调用modbus_rx_byte()而modbus_rx_byte()内部会检查超时定时器是否溢出。如果TIM2中断优先级低于USART1当USART1中断正在处理一个长帧时TIM2超时中断会被挂起导致超时检测失效。在NVIC_Init()中务必设置NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority 1;数值越小优先级越高。4. Keil工程配置与实操流程从零开始编译、烧录、调试的完整指南4.1 Keil MDK工程结构详解与关键配置项打开Keil工程USART.uvprojx你会看到清晰的文件分组-Usermain.c,system_stm32f10x.c系统时钟初始化-COREcore_cm3.h,startup_stm32f10x_hd.s启动文件针对大容量HD芯片-FWLIBstm32f10x_rcc.c,stm32f10x_gpio.c,stm32f10x_usart.c等ST标准外设库-HARDWAREusart.c,key.c,led.c,timer.c,rs485.c硬件驱动-MODBUSmodbus.c,modbus_crc.c,modbus_timer.c协议栈核心-CMSIScore_cm3.h,core_cm3.cARM Cortex-M3内核支持最关键的配置在Options for Target → C/C选项卡-Define必须添加USE_STDPERIPH_DRIVER, STM32F10X_HD。前者启用ST标准库后者告诉编译器使用大容量芯片头文件。-Include Paths确保包含.\FWLIB\inc,.\CORE,.\HARDWARE,.\MODBUS等路径否则编译报错找不到头文件。-Optimization推荐设为Level 3-O3编译器会自动内联小函数如LED_Toggle()提升实时性。但注意过度优化有时会让调试变量显示异常调试时可临时降为Level 0。在Options for Target → Output选项卡-Create HEX File必须勾选这是生成USART.hex的开关。-Name of Executable默认USART生成的HEX文件名即USART.hex。在Options for Target → Debug选项卡-Use选择你的调试器如ST-Link Debugger。-Settings在SW Device里确保Max Clock设为4000kHzST-Link V2默认过高可能导致连接失败。提示工程已预配置好所有宏定义和路径你唯一需要检查的就是main.c顶部的#define MODBUS_BAUDRATE 9600。如果你的RS485总线需要更高波特率如38400或115200只需修改此处保存后重新编译usart.c和rs485.c里的所有定时计算会自动适配。4.2 从编译到烧录的完整实操步骤编译工程点击Keil工具栏的Build按钮或按F7。首次编译会耗时稍长约30秒因为要编译整个ST标准库。成功后底部Build Output窗口显示0 Error(s), 0 Warning(s)并在OBJ文件夹下生成USART.axf调试文件和USART.hex烧录文件。硬件连接- STM32开发板的BOOT0跳线帽置于0Normal模式- 使用USB转TTL串口模块如CH340连接开发板的USART1PA9/TX, PA10/RX和电脑注意TX-RX交叉连接- 将RS485收发器的A/B线通过双绞线连接到一个真实的Modbus从机如一个支持Modbus的温湿度传感器或连接到另一块运行本工程的开发板作为从机- 确保所有设备共地GND线必须连通。烧录程序- 方法一推荐使用ST-Link连接ST-Link调试器点击Flash → Download几秒内完成。- 方法二串口ISP将BOOT0置1BOOT1置0用串口下载工具如Flash Loader Demonstrator选择USART.hex文件烧录。完成后断电将BOOT0拨回0。上电观察- 板子上电瞬间LED1主控指示以2Hz慢闪表明已进入主机模式开始轮询地址0x01- 如果总线上有地址为0x01的从机且通信正常LED1会短暂变为8Hz快闪表示收到应答然后恢复2Hz慢闪- 按下K4键LED1变为1Hz呼吸灯效果LED2从机指示常亮表明已成功切换为地址0x02的从机- 此时用Modbus Poll软件Windows或QModMasterLinux/macOS作为主机向192.168.1.100:502假设你用USB转RS485模块虚拟的COM口发送读取0x02地址保持寄存器0x0000的请求你应该能看到LED3应答指示点亮且软件收到正确响应。实操心得第一次烧录后没反应别急着怀疑代码。先用万用表量一下PB12RS485 DE/RE引脚上电后的电平——应该是高电平接收模式。如果不是检查rs485.c里的RS485_Init()是否被正确调用以及RS485_SetRxMode()是否在main()开头执行。这是90%的“没反应”问题的根源。4.3 调试技巧与仿真脚本的妙用除了硬件调试工程还提供了强大的软件调试辅助keilkilll.bat脚本双击运行它会自动删除OBJ和List文件夹下所有中间文件.o,.d,.crf,.axf,.hex等让你每次都是“干净编译”避免旧目标文件导致的诡异链接错误。这比在Keil里手动Clean更快捷。run_stm32_sim.py仿真脚本这是一个基于Python的轻量级Modbus仿真器。它不需要真实硬件能模拟一个地址为0x01的从机响应读写请求。运行方法bash python run_stm32_sim.py --port COM3 --baud 9600 --slave-id 0x01其中COM3是你电脑上USB转RS485模块的串口号。运行后你的STM32主机板就会像连接了一个真实从机一样工作LED指示正常。这在你还没有采购从机硬件或者想快速验证主机逻辑时简直是救命稻草。Keil调试技巧在modbus_parse_request_frame()函数开头打个断点然后用Modbus Poll发一个请求程序会停在这里。查看rx_buffer数组内容就能直观看到接收到的原始字节流对照Modbus帧格式立刻知道是哪里出了问题是地址错功能码错还是CRC错。在modbus_state_machine()的case MODBUS_STATE_SENDING_RESP:分支打个断点可以观察到应答帧是如何一步步构建并发送出去的tx_buffer的内容就是你要发送的完整帧。5. 常见问题排查与独家避坑指南那些只有踩过才知道的坑5.1 通信完全无反应从电源到引脚的逐级排查这是最让人抓狂的问题。请按以下顺序用万用表和逻辑分析仪或示波器逐级排查排查层级检查点正常现象异常处理电源层STM32的VDD和VSS之间电压3.3V ± 5%电压过低检查LDO或USB供电电压不稳加10μF电解电容时钟层PA8MCO引脚可输出系统时钟72MHz方波如果RCC_ClockFreq配置正确无波形检查system_stm32f10x.c里SetSysClockTo72()是否执行RCC-CFGR寄存器值是否为0x00000000USART层PA9TX引脚上电后电平高电平空闲态一直是低电平检查USART_Init()是否调用USART_Cmd(USART1, ENABLE)是否执行RS485层PB12DE/RE引脚上电后电平高电平接收模式一直是低电平检查RS485_Init()和RS485_SetRxMode()调用顺序逻辑分析仪抓波形看发送时PB12是否在PA9发第一个字节之前拉高总线层A和B线之间的直流电压0V ~ 0.2V空闲态差分电压接近0A-B 0.2V检查终端电阻是否只在总线两端接入中间节点不能接独家技巧如果以上都正常但还是没反应试试把MODBUS_BAUDRATE临时改为1200。极低波特率对线路要求最低如果1200能通说明是电缆质量或终端电阻问题如果1200也不通那一定是前面某一层出了问题。5.2 能发不能收或能收不能发RS485方向控制的终极诊断“主机发了查询帧但从机应答不来”是RS485项目的头号杀手。根本原因几乎全是DE/RE引脚控制失误。终极诊断法用逻辑分析仪抓三根线PA9TX、PA10RX、PB12DE/RE。观察发送过程当主机发帧时PB12必须在PA9发出第一个起始位下降沿之前就变为高电平并在整个帧发送期间包括停止位保持高电平。观察接收过程PB12必须在PA9发送完成TC标志置位后等待≥1.5字符时间才变为低电平。此时PA10才能开始接收从机的应答帧首字节。关键时间点用逻辑分析仪测量PB12从高变低的时间点与PA9最后一个停止位结束的时间差。这个差值必须≥1.5字符时间。例如9600bps下1字符1042μs1.5字符1563μs。如果差值只有500μs那肯定收不到。避坑指南不要相信“发送完成中断”TC就是发送结束。TC标志在最后一个数据位的停止位结束时置位但此时USART硬件的发送移位寄存器可能还有残余电平。最稳妥的做法是在TC中断里启动一个TIM2定时器设定为1.5字符时间定时器溢出中断里才执行RS485_SetRxMode()。本工程正是这么做的所以极其可靠。5.3 数据错乱、CRC校验失败字节序与缓冲区的隐秘陷阱现象主机收到的帧地址、功能码都对但数据部分全是乱码CRC校验失败。原因往往很隐蔽缓冲区溢出rx_buffer[MODBUS_MAX_FRAME_SIZE]大小为256字节但如果从机发来一个超长帧比如功能码16写多个寄存器数据域很大rx_buffer会溢出覆盖相邻变量如rx_len计数器导致modbus_parse_request_frame()解析时读取错误内存。解决方案在USART1_IRQHandler()里每次接收前先检查rx_len MODBUS_MAX_FRAME_SIZE - 1超限则rx_len 0丢弃整帧。字节序混淆Modbus规定寄存器地址和数量都是高位在前Big-Endian。例如读取地址0x0000发送的字节必须是00 00而不是00 00一样但读取地址0x1234必须发送12 34。很多初学者用uint16_t addr 0x1234; usart_send(addr, 2);结果发送的是34 12小端从机必然解析错误。正确做法是c uint8_t addr_bytes[2]; addr_bytes[0] (addr 8) 0xFF; // 高字节 addr_bytes[1] addr 0xFF; // 低字节 usart_send(addr_bytes, 2);中断与主循环竞争rx_buffer和rx_len被USART1_IRQHandler()和modbus_state_machine()在主循环中共同访问。如果modbus_state_machine()正在解析一帧而USART1_IRQHandler()又往rx_buffer里写新字节就会导致数据错乱。解决方案在modbus_state_machine()访问rx_buffer前用__disable_irq()关总中断解析完再__enable_irq()开中断。本工程在modbus_parse_request_frame()开头就做了这个保护。5.4 LED指示异常状态机与定时器的协同故障LED不闪、常亮、乱闪往往是状态机和定时器协作出了问题LED完全不亮首先检查LED_Init()是否在main()开头被调用其次检查SysTick_Config()是否成功返回值为1如果失败led_update()永远不会被调用最后检查LED_SetPattern()里是否错误地设置了LED_PATTERN_OFF且未重置。LED常亮不闪说明led_update()没有被周期性调用。检查SysTick_Config(SystemCoreClock / 1000)是否执行1000Hz以及SysTick_Handler()中断服务程序里是否调用了led_update()。用调试器在SysTick_Handler()打个断点看是否能命中。LED闪烁频率错误比如该2Hz却成了1Hz。检查led_pattern_t查表数组里对应模式的period_ms值是否正确2Hz对应500ms。更可能是SysTick中断频率不对用示波器量PA8如果配置为SysTick输出或逻辑分析仪看SysTick_Handler()的调用间隔。最后一个压箱底技巧如果所有硬件、软件都检查无误但通信还是时好时坏把MODBUS_TIMEOUT_MS从1000ms提高到3000ms再把RS485的1.5字符间隔手动增加到2.0字符。这能极大容忍线路噪声和从机响应延迟是工业现场的“鲁棒性保险丝”。等系统稳定运行一周后再逐步调回标准值。稳定永远比理论最优更重要。这套STM32F103 RS485双模Modbus例程不是一份躺在硬盘里的代码而是一套经过产线淬炼的通信方法论。它教会你的不仅是如何让两个设备说话更是如何让它们在嘈杂的工业环境中清晰、准确、可靠地说出每一句话。从PB12引脚上那个精确到微秒的电平跳变到LED1上那个2Hz的稳定脉动再到modbus_state_machine()里那个永不迷失的状态指针——每一个细节都是对“可靠”二字的无声承诺。我把它放在GitHub上开源不是为了展示技术而是希望下一个在凌晨三点对着示波器抓狂的工程师能少走几公里弯路。毕竟在工业控制的世界里最珍贵的从来不是炫目的创新而是那一份让设备日复一日、年复一年沉默而坚定运行的底气。本文还有配套的精品资源点击获取简介基于STM32F103芯片通过硬件USART配合RS485收发器实现标准Modbus-RTU协议通信支持主机与从机两种模式自由切换。上电默认为主机自动轮询地址0x01的从设备读取保持寄存器按四个独立按键可快速切换目标从机地址0x01/0x02/0x03或将本机切换为地址0x02的从机响应功能码03读保持寄存器和06写单个寄存器。RS485半双工控制由专用IO引脚配合定时器精准时序管理CRC16校验全程软件实现保障数据传输可靠性。LED状态指示直观清晰不同闪烁节奏分别对应主机寻址中、收到有效应答、进入从机模式、接收帧错误等关键状态。工程已完整适配Keil MDK环境包含启动文件startup_stm32f10x_hd.s、系统初始化system_stm32f10x.c、外设驱动usart.c、key.c、led.c、timer.c、rs485.c、Modbus协议核心modbus.c、中断处理stm32f10x_it.c及CRC计算模块编译输出可直接烧录的USART.hex文件。配套提供Makefile依赖文件.d、一键清理脚本keilkilll.bat和仿真运行脚本run_stm32_sim.py方便调试与二次开发。本文还有配套的精品资源点击获取