先说一个我自己的经历。去年给一个养殖场做环境监测棚里湿度大、空间跨度长前期试过WiFi信号穿两堵墙就没了一半换蓝牙更是撑不到一百米最后老老实实改成RS485总线。一根双绞线把十几个传感器节点串起来跑了好几个月没出过大毛病。从那以后我对RS485的好感一直在线工业现场能传1200米、一条总线挂几十个节点、抗干扰能力还强芯片几块钱一片属实是性价比之王。这篇实战笔记的主角是MAX13487一颗支持自动方向控制的RS485收发器配合MicroPython在ESP32上实现主从通信。如果你也想用MicroPython做多节点采集、设备控制或者远程通信这篇文章从原理到硬件再到代码基本可以一路抄作业。选择MAX13487不是因为它是新出来的芯片而是因为它在MicroPython场景下把RS485半双工通信最大的痛点给抹平了。以往用MAX485这类收发器必须额外用GPIO去切换收发方向方向切换的时序稍有闪失就丢数据。MAX13487内部自己搞定这件事对软件来说跟用普通UART没区别。所以这篇内容虽然标题写了“驱动芯片”但代码部分你几乎感觉不到芯片的存在这种“无感”恰恰是RS485入门最舒服的路径。1. RS485不是“串口”它是串口信号的“物理层变身”1.1 UART负责格式RS485负责电平很多人刚开始接触RS485时会有一个误区觉得RS485就是一种串口协议。其实严谨一点说UART定义的是数据帧格式——起始位、数据位、停止位、波特率这些RS485定义的是电气标准——信号用什么电平、怎么传输。两者分工不同UART管“怎么说”RS485管“用什么姿势说”。单片机上的UART外设输出的是TTL电平高电平3.3V代表逻辑1低电平0V代表逻辑0。这种电平只能在板子内部短距离传输拉出去超过一米信号就开始衰减变形。RS485收发器要做的事就是把单片机UART引脚的TTL信号转换成A、B两根总线之间的差分电压送到几十米甚至上千米之外再由另一端的RS485收发器还原成TTL信号给那边的单片机。所以物理链路端到端的完整链条是MCU的UART TX引脚发出一个字节MAX13487这类收发器把它变成A、B两根线上的差分信号经过双绞线传输到达从机的收发器再还原成TTL信号送给从机UART的RX引脚。整个过程里协议帧怎么组织、CRC怎么校验UART和RS485都不关心这是上层自己的事。1.2 差分信号为什么能抗干扰RS485用两根线A和B之间电压差来判断逻辑状态而不是像TTL那样拿一根线对地的绝对电压说事。判断规则很简单A相对B的电压差为正且超过大约200mV接收端认为收到逻辑1A相对B的电压差为负且低于-200mV认为是逻辑0。电压差落在中间区域属于无效区普通芯片在这个区间输出随机电平这也是许多RS485干扰问题的根源之一。差分信号最大的优势是抗共模干扰。外界电磁干扰比如电机启动、变频器工作作用在A、B两根线上时几乎会同时产生相同的电压扰动这个扰动被称为“共模干扰”。既然A和B被干扰的程度一样两者相减之后干扰就被抵消掉了。可以打个比方两个人面对面说话外界噪音同时灌进两只耳朵但双方听到的语音音量差基本不变照样能分辨语义。RS485抗干扰能力强本质就是这个逻辑。当然差分并不等于完全免疫干扰。如果线缆屏蔽层接地处理不好或者共模电压超过了芯片的容忍范围MAX13487的A/B对GND共模输入范围大约是-7V到12V照样会出问题。我这个项目里后期加隔离方案就是处理这类共模问题后面会单独讲。1.3 半双工、距离、速率与节点数RS485有四组关键参数做方案前必须心里有数第一半双工。A、B两根线同一时刻只能有一个方向的数据在传输要么发送要么接收不能同时进行。主从通信模式就是顺着这个特性来的——主机逐个点名从机被点到才开口。第二传输距离。理论极限是1200米但这是低波特率下的说法。实际工程中9600bps下跑几百米很常见115200bps下能跑100米左右就算不错。距离和速率是跷跷板关系总线长度越长可靠传输的波特率就越低。第三节点数。标准RS485收发器按“单位负载”折算一般一颗芯片算1个单位负载标准总线最多挂32个节点。MAX13487属于1/4单位负载芯片理论上一条总线可以挂到128个节点。但理论归理论线缆长度、连接器接触、电源质量都会压缩这个数字工程上建议一条总线控制在32个节点以内轮询周期和故障排查都会轻松很多。第四速率。RS485短距离下可以传10Mbps以上但速率一高线缆和连接器的寄生参数就凸显出来。对MicroPython场景来说我用得最多的是9600和115200。115200适合节点少、实时性要求高的情况9600更稳适合长线和多节点。MAX13487E本身是限摆率版本最高约500kbps跑115200绰绰有余。2. 选MAX13487的真正理由自动方向控制把半双工用成了“全双工”2.1 从MAX485说起手动切换方向的痛点RS485半双工通信收发器必须有个方向控制机制。经典芯片MAX485的做法是引出两个引脚DE控制发送使能RE控制接收使能。要发送时把DE拉高、RE也拉高接收关闭发送完再把DE拉低、RE拉低回到接收状态。听起来简单实际操作起来全是细节。发送前的切换还算好办难的是发送完成之后什么时候把方向切回接收。拉早了不行UART最后一个停止位可能还没发完总线上的尾巴会被截断拉晚了也不行从机的响应报文已经到了而你的收发器还在发送模式收到的数据全是零。MicroPython这种解释型语言代码执行时机本身就有不确定性uart.write()返回之后驱动里可能还有数据在移位寄存器里没送完如果你立刻拉低DE就会把帧尾砍掉。很多人在这一步被折磨得死去活来最后不得不在发送后硬sleep几十毫秒再切方向靠牺牲实时性换可靠性。下图是传统MAX485的典型伪代码DE.value(1) # 发之前拉高发送使能 uart.write(data) time.sleep_ms(5) # 靠猜等待发送完成 DE.value(0) # 再切回接收这个“靠猜”就是痛点。波特率不同、帧长不同发送时间都不同固定sleep要么浪费周期要么丢帧。我曾经做过一个项目轮询11个节点每个节点光方向切换等待就耗掉5ms一轮下来白白浪费几十毫秒。2.2 MAX13487自动方向控制DE和RE直接接地MAX13487改变游戏规则的方式很粗暴芯片内部自己检测数据起始位发现DI引脚上有数据过来自动使能驱动器开始发送发送完停止位之后自动切回接收模式。整个过程不需要软件参与DE和RE两个引脚直接接到GND就行了。它的工作原理是基于UART帧的结构特点总线空闲时是高电平要发送数据时DI引脚先来一个下降沿起始位。芯片检测到这个下降沿就知道“要开始发数据了”于是打开发送驱动器发送完最后一个停止位总线回到高电平芯片再关掉驱动器回到接收状态。这一切都由硬件完成对上层软件完全透明。所以硬件的接法非常省事MAX13487的RE引脚和DE引脚短接后直接接地RO接收输出接MCU的RXDI发送输入接MCU的TXVCC和GND接好完事。软件里根本不需要GPIO去切方向把收发器当普通UART用就行。这正是MicroPython场景最喜欢的少一个GPIO、少一段时序代码、少一堆时序bug。2.3 失效保护、ESD与单位负载数据手册里真正值钱的部分除开自动方向控制MAX13487还有几个特性对实战很有价值。失效保护Fail-Safe尤其重要。传统MAX485在总线开路、短路或者空闲时A、B之间电压差处于无效区RO引脚会随机输出高或低单片机就会收到一堆毫无意义的0xFF或0x00垃圾数据。MAX13487内部做了偏置处理让这些异常状态下RO稳定输出逻辑1也就是说总线空着的时候你读到的是空闲电平而不是乱码。我调试时经常遇到“没有数据在发但串口助手疯狂刷0xFF”的情况用的普通芯片就极其痛苦换成MAX13487这类带失效保护的芯片问题直接从根上消失。ESD保护方面MAX13487支持大约±16kV人体模型的静电放电保护。实验室里你摸一下A/B线可能没事工业现场就不一样了雷击感应、静电放电、操作人员误触都有可能芯片自带高等级ESD保护能大大降低挂掉的概率。不过我要提醒一句ESD保护只是第一道防线真正的雷击浪涌还是得靠TVS管和隔离方案。单位负载方面MAX13487是1/4单位负载理论挂载能力比MAX485强不少。另外它3.3V供电和现在主流MCU的电平一致不像MAX485典型5V供电和3.3V单片机对接时还得琢磨电平匹配。为了直观这里把MAX13487和经典MAX485做一个快速对比对比项MAX485MAX13487方向控制需要GPIO控制DE/RE自动方向控制DE/RE接地即可供电电压典型5V3.3V失效保护无空闲时RO可能乱跳内置开路/短路/空闲输出逻辑1单位负载1个单位负载约32节点1/4单位负载理论128节点数据速率不限制摆率最高2.5Mbps限摆率最高约500kbpsESD视型号±16kV HBM级别3. 硬件接线详解从ESP32引脚到A/B总线的全链路3.1 引脚对照ESP32 UART2 MAX13487这次演示用ESP32开发板做主机和从机其实换成STM32、RP2040或者其他支持MicroPython的板子也完全一样UART外设的用法是一致的。MAX13487采用SO-8封装引脚功能很经典和MAX485是兼容排列。1脚RO接收数据输出2脚RE接收使能低有效3脚DE发送使能高有效4脚DI发送数据输入5脚GND6脚A7脚B8脚VCC。我用的接线方式如下MAX13487第1脚RO接ESP32的GPIO16UART2 RXMAX13487第4脚DI接ESP32的GPIO17UART2 TXMAX13487第2脚RE和第3脚DE直接短接再一起接到GNDMAX13487第8脚VCC接3.3VMAX13487第5脚GND接开发板GNDMAX13487第6脚A和第7脚B引出到双绞线注意一点A和B的接法是对应连接A接A、B接B不是像RS232那样交叉。总线两端如果有多个节点所有节点的A都并到同一条线上所有B都并到另一条线上。GPIO脚位选型上ESP32的UART0默认用于REPL调试TX/RX是GPIO1和GPIO3不建议占用来接RS485否则开机时固件的启动信息会直接灌到总线上从机收到一堆ASCII乱码。我习惯用UART2GPIO16和GPIO17是常用默认脚位如果和你的板载外设冲突也可以换到GPIO4、GPIO5等空闲引脚在代码里指定就行。3.2 终端电阻与偏置电阻放哪、接几个、阻值怎么定RS485总线的信号完整性很大程度上取决于终端电阻的处理。双绞线的特征阻抗大约是120Ω当线缆长度接近信号波长时如果不匹配阻抗信号会在末端反射导致波形振铃、误码率飙升。终端电阻的使用原则总线两端各接一个120Ω电阻跨接在A和B之间。只有两个节点且距离很近几米内时不加终端电阻也能工作但一旦线缆长度超过十几米或者总线挂了三个以上节点就必须在物理最远的两个端点各接一个120Ω。中间节点不要加终端电阻不然多个电阻并联把差分阻抗拉到几十欧收发器的驱动能力会被严重消耗信号幅度变得很弱。除了终端电阻偏置电阻也值得一提。总线空闲时A、B之间的电压应该稳定在逻辑1的范围。虽然MAX13487有失效保护空闲时能输出确定的高电平但如果总线上同时存在多个非失效保护芯片的老设备建议在主机端加一组偏置A通过10kΩ上拉到VCCB通过10kΩ下拉到GND。这样总线一旦空闲A-B自然有一个稳定的正向电压差。阻值选4.7kΩ到10kΩ之间都比较常用太小会加重收发器负载太大偏置效果不明显。终端电阻和偏置电阻的正确接法总结一下总线最远端节点A-B之间跨接120Ω终端电阻总线最远端节点可以同时加10kΩ上拉到VCC、10kΩ下拉到GND中间节点不加任何电阻接线原则所有节点的A并联B并联不要接成星型3.3 供电、共地与防护通电前的最后检查RS485通信有一个非常隐蔽的坑就是共地问题。RS485虽然用差分信号传输数据但收发器本身需要参考地如果两端设备的GND电位不一致共模电压就可能超过芯片容忍范围。轻则通信偶发错误重则直接烧毁收发器。在实验阶段两块开发板用同一路USB电源供电GND天然连在一起通常没问题。但到了真实项目比如一个节点用太阳能供电、另一个节点用市电供电适配器两边的GND很可能存在几十伏的电位差。这种情况下必须做两件事之一要么在总线设备之间拉一根结实的公共地线要么使用隔离型RS485方案。另一个容易忽略的是A/B线上的防护器件。工业现场的总线经常会受到静电放电、雷击感应等瞬态干扰建议在A、B对地各加一个双向TVS管比如SMBJ6.0CA再在两线上串联PTC自恢复保险丝做限流。如果预算允许直接选用隔离型RS485模块把MCU地和总线地物理隔离保护效果最彻底。我那个养殖场项目后期就是给每个节点加了电源隔离和数字隔离器从那以后雷雨天里再也没出现过节点丢通信的情况。4. 主从通信协议设计帧格式、地址分配与超时重传策略4.1 帧格式设计帧头、地址、功能码与CRC16UART和RS485只负责把字节从一端搬到另一端它们不关心字节和字节之间怎么组合成有意义的消息。要在总线上可靠地通信必须自己定义一套帧格式让收发双方都知道一帧从哪里开始、到哪里结束、内容是什么、数据有没有被污染。我在这套系统里用的帧格式如下帧头(2字节) 地址(1字节) 功能码(1字节) 数据长度(1字节) 数据(N字节) CRC16(2字节) 0xAA 0x55 0x01 0x01 0x02 0x00 0x64 ...帧头固定为0xAA 0x55。0xAA的二进制是101010100x55是01010101这种交替模式在示波器上特征非常明显而且它们在正常数据里出现的概率相对均匀不容易和普通内容混淆。接收方在字节流里找这两个字节连续出现的位置就认为是一帧的开始。地址字段标记目标从机功能码告诉从机要执行什么操作数据长度字段说明后面跟着多少字节的数据。帧尾是CRC16校验值我采用Modbus CRC16算法校验范围涵盖地址、功能码、数据长度和数据部分在MicroPython里用纯Python实现每帧计算耗时在微秒级完全够用。为什么要CRC而不是简单的累加和校验总线环境里一条帧被干扰可能同时翻掉好几个字节甚至整段数据。累加和很容易出现“错了几位但校验恰好通过”的情况CRC16冲突概率则低得多。对于这种几十字节的小帧CRC16已经足够可靠没必要上更重的校验算法。4.2 地址分配与广播约定越清晰后面越省心主从通信模式下总线上有一条不成文的规矩同一时刻只允许一个节点说话。主机负责发起所有通信从机没有请求绝不主动上报。这就要求每个从机必须有唯一地址主机才能精确寻址。地址分配我建议这样约定0x00保留不用作从机地址很多协议里习惯把0x00预留给主机地址或者当作无效地址从机地址从0x01开始到0xFE为止共可支持254个从机0xFF作为广播地址所有从机都必须接收处理但按约定不回包。广播帧适合用来做校时、下发公共配置这类一次性动作因为你显然不希望总线上所有从机同时回包那样必然撞车。从机程序里对地址的判断顺序也很重要。先找帧头再解析地址字段如果地址既不是自己的地址也不是0xFF整帧直接丢弃连CRC都不用算。这样可以避免总线上无关的请求浪费从机的计算资源。我习惯在每条命令执行前再检查一次地址防止缓冲区里拼出了脏数据导致误执行。4.3 超时重传与轮询周期合理参数不是拍脑袋定的主从通信中主机最怕的就是发完请求后石沉大海。从机掉电、线缆断裂、A/B接反都可能导致没有任何回应。所以主机必须设置超时时间超时后重传重传还是没响应才判定这个节点故障。超时时间定多少合适可以做个简单计算。假设帧长约11字节波特率115200一字节传输时间约87微秒一帧传输时间不到1毫秒。从机收到帧后要做CRC校验、命令解析再sleep 2毫秒等总线切换然后回一帧整体耗时大约5到10毫秒。把余量留足我一般把超时设为50毫秒。如果设为500毫秒虽然更稳但节点多时轮询周期被拉长体验会差如果设为10毫秒很可能从机还在处理主机就已经等不及重发了白白增加总线负载。重传次数我习惯设为3次。超过3次还收不到应答就不再死磕这个节点把它标记为离线继续轮询下一个节点一轮结束后再对离线节点单独补一次深度探测。轮询周期的计算方式也很简单单节点的“请求发送时间从机处理时间响应时间少量余量”再乘以节点数量大约就是一轮轮询的总耗时。10个节点每个约20毫秒一轮下来约200毫秒也就是每秒大概能完整扫5轮这个频率对多数传感器采集场景完全够用。5. MicroPython代码实现主机轮询与从机响应的完整流程5.1 CRC16的MicroPython实现与性能评估MicroPython和桌面Python最大的差异是性能。好在CRC16的纯Python实现即使在ESP32这种主频240MHz的芯片上计算一个几十字节的小帧也只耗时几百微秒完全不会成为瓶颈。我用的是标准的Modbus CRC16算法def crc16_modbus(data): crc 0xFFFF for b in data: crc ^ b for _ in range(8): if crc 1: crc (crc 1) ^ 0xA001 else: crc 1 return crc这个函数的逻辑不难理解先初始化CRC寄存器为0xFFFF每个字节先和CRC低8位异或然后按位移位遇最低位为1就异或多项式0xA001。最终得到的CRC值和主机的CRC计算结果比对两边一致说明帧数据大概率没被污染。有人可能会问为什么不预先算好256个字节的CRC查找表用查表法加速因为MicroPython跑查找表方案内存开销更大而且对每帧代码也没必要性能瓶颈根本不在CRC计算上。保持代码简单、可读性强才是MicroPython这种开发方式的价值所在。5.2 主机轮询代码发送、等待与解析主机逻辑很清晰构造请求帧写到UART然后等待从机在超时时间内返回有效应答帧。如果没等到就清空缓冲区重试。下面是完整的主机核心代码from machine import UART import time uart UART(2, baudrate115200, tx17, rx16, timeout5) # 如果固件版本较老导致构造函数报错改成 # uart UART(2) # uart.init(baudrate115200, bits8, parityNone, stop1, tx17, rx16) def crc16_modbus(data): crc 0xFFFF for b in data: crc ^ b for _ in range(8): if crc 1: crc (crc 1) ^ 0xA001 else: crc 1 return crc def make_frame(addr, func, payloadb): body bytes([addr, func, len(payload)]) payload crc crc16_modbus(body) return b\xAA\x55 body crc.to_bytes(2, little) def frame_ok(buf): if len(buf) 7 or buf[0] ! 0xAA or buf[1] ! 0x55: return False body_len buf[4] if len(buf) ! 2 3 body_len 2: return False body buf[2:-2] crc int.from_bytes(buf[-2:], little) return crc16_modbus(body) crc def read_sensor(addr, timeout_ms50, retries3): req make_frame(addr, 0x01) for _ in range(retries): uart.write(req) # 给自动方向控制留一点点切换时间 time.sleep_ms(2) buf b deadline time.ticks_ms() timeout_ms while time.ticks_diff(deadline, time.ticks_ms()) 0: if uart.any(): buf uart.read(uart.any()) if frame_ok(buf): return buf # 超时后清空残留数据避免脏数据影响下一次请求 while uart.any(): uart.read() return None # 依次轮询1到5号从机 for addr in range(1, 6): resp read_sensor(addr) if resp: print(node, addr, ok, data:, resp[5:-2].hex()) else: print(node, addr, timeout) time.sleep_ms(20)这段代码里几个关键点值得展开。uart.read(uart.any())是MicroPython里读取接收缓冲区的常用写法先查有多少字节可读再一次性读出来。之所以不在while循环里直接uart.read(1)逐字节读是因为在某些固件上没有数据时uart.read(1)会阻塞直到超时这会导致超时逻辑完全失效。frame_ok()函数里面我计算了完整帧的长度来判断一帧是否收齐同时校验CRC。如果缓冲区里的字节还不够一帧长度就继续等待如果长度够了但CRC不对说明这一帧被干扰了直接丢弃并继续等。这里有个细节一帧数据如果被噪声插入了额外字节会导致长度对不上frame_ok返回False后主机并不会重新对齐帧头所以我在每次发送请求前都会清空接收缓冲区。这是最简单也最有效的脏数据预防策略。time.sleep_ms(2)虽然看上去很小却是稳定通信的功臣。MAX13487自动方向控制切换的时间在微秒级但MicroPython的调度和UART驱动的处理存在不确定性留出2毫秒的余量让发送操作彻底落定再进入接收等待阶段能有效避免丢失从机响应帧的前几个字节。5.3 从机响应代码地址匹配、命令分发与回包从机的任务是从UART字节流里提取完整帧校验判断是不是发给自己的然后执行命令并回包。核心代码如下from machine import UART import time SLAVE_ADDR 1 uart UART(2, baudrate115200, tx17, rx16, timeout5) def crc16_modbus(data): crc 0xFFFF for b in data: crc ^ b for _ in range(8): if crc 1: crc (crc 1) ^ 0xA001 else: crc 1 return crc def frame_ok(buf): if len(buf) 7 or buf[0] ! 0xAA or buf[1] ! 0x55: return False body_len buf[4] if len(buf) ! 2 3 body_len 2: return False body buf[2:-2] crc int.from_bytes(buf[-2:], little) return crc16_modbus(body) crc def make_response(addr, func, payload): body bytes([addr, func, len(payload)]) payload crc crc16_modbus(body) return b\xAA\x55 body crc.to_bytes(2, little) buffer b while True: if uart.any(): chunk uart.read(uart.any()) if not chunk: continue buffer chunk if len(buffer) 64: buffer buffer[-64:] while True: # 找帧头0xAA 0x55 idx -1 for i in range(len(buffer) - 1): if buffer[i] 0xAA and buffer[i 1] 0x55: idx i break if idx -1: buffer b break # 丢弃帧头之前的数据 buffer buffer[idx:] if len(buffer) 7: break body_len buffer[4] frame_len 2 3 body_len 2 if len(buffer) frame_len: break frame buffer[:frame_len] buffer buffer[frame_len:] if not frame_ok(frame): continue addr_field frame[2] func frame[3] if func 0x01: # 模拟读传感器返回温度25.6度编码为0x0100湿度60.1%编码为0x6400 payload bytes([0x01, 0x00, 0x64, 0x00]) if addr_field 0xFF: # 广播帧执行但不回包 continue resp make_response(SLAVE_ADDR, 0x01, payload) time.sleep_ms(2) # 等总线上一次发送彻底结束 uart.write(resp)从机代码的while True循环里我一直用uart.any()检查接收缓冲区有数据才读读完后拼到buffer里。因为RS485是字节流传输这一帧和下一帧之间没有天然边界必须靠帧头去寻找帧起点。buffer里可能出现前置垃圾字节所以代码会在缓冲区里搜索0xAA 0x55找到之后才认为找到了有效帧头的可能性。frame_ok校验完成后还要做地址判断。如果地址是广播地址0xFF按协议约定继续执行命令但不回复如果地址是自身地址执行命令后回包。回包前强制sleep_ms(2)是为了确保半双工总线上主机的发送操作已经彻底释放MAX13487的方向控制也已经切回接收模式这时候从机再开口不会和主机尾部“撞车”。这里有一个MicroPython特有的优化点从机不要用uart.read(1)逐字节阻塞读。这样的循环一旦碰上UART底层超时某些固件可能等100毫秒以上从机响应时间会被严重拉长。先uart.any()再uart.read的模式可以保证UART有数据时立即处理没有数据时也不阻塞主循环可以一直保持灵敏。6. 调试实录示波器判读、万用表量测与高频坑位排查6.1 用万用表、示波器、逻辑分析仪快速定位问题RS485出问题第一步就是量A、B两根线之间的电压差。总线空闲时A相对B的电压差应该是正电压。什么范围算正常如果没有加偏置电阻空闲时差值接近0V甚至为正几百毫伏加了上拉和下拉偏置电阻后通常能看到零点几伏到一伏的正压差。当主机在发送数据时用万用表测A-B电压会出现快速跳变万用表读数是平均值不太直观但至少能看到一个非零读数。如果A-B电压始终在0V附近纹丝不动基本可以判断没有设备在驱动总线或者驱动器的方向控制有问题。万用表只能看静态要看波形还得上示波器。示波器探头A接A线B接B线用数学通道做A减B就能看到真正的差分波形。正常通信时差分信号应该是清晰的方法幅值大约±0.2V到±5V之间。如果波形边沿出现强烈的振铃、过冲或者幅值被压得很低大概率是终端电阻配置问题或者线缆质量不行。如果没有示波器逻辑分析仪也能帮上大忙。最省事的方法不是去测A/B差分而是直接把逻辑分析仪夹在MAX13487的RO引脚上。RO输出是接收解调后的TTL信号逻辑分析仪夹在这里看到的UART波形和MCU的RX引脚收到的一模一样足以判断“总线上的数据到底来没来、来的数据对不对”。我自己调试时经常一手示波器量A/B差分一手逻辑分析仪量RO两边一对比是芯片问题、线路问题还是协议问题基本一眼就能定位。6.2 三个高频坑位A/B反接、终端电阻堆叠、共地缺失A/B接反是RS485新手最常见的问题。接反之后接收端会把差分信号的极性完全翻转原来该是逻辑1的位置变成逻辑0原来的0变成1。表现为主机发请求完全没回应或者从机能收到但回包全是错的数据。排查方法很简单如果确信协议和波特率没问题直接把A/B两根线对调再试。注意如果是手搓的PCB板要检查一下是不是所有节点都一致地对调否则会出现一部分对调、一部分没对调总线彻底混乱。终端电阻堆叠这个坑我是在一次30米布线的测试里踩到的。三个模块放在桌上测试一切正常因为线缆短、反射影响小一拉到30米问题立刻来了丢包率飙升。用示波器一看A-B波形出现严重的振铃幅值也偏低。检查之后发现三个模块的板子上都预留了120Ω终端电阻焊盘全部被焊上了相当于三个电阻并联成40Ω驱动芯片的负载被压得喘不过气来。解决办法是只保留总线最远两端的120Ω中间模块的终端电阻全部摘掉波形肉眼可见地恢复正常。终端电阻的本质是吸收线缆末端的信号能量防止反射不是“每个节点都要匹配”而是“物理终点要匹配”。共地缺失这个坑最隐蔽。两个设备单独测试都好好的一接上线就偶发乱码甚至发烫。用万用表量两个设备GND之间的电压居然有2V多的压差这就是“地电位漂移”。RS485差分信号抗的是共模干扰但共模电压有上限MAX13487大概能容忍-7V到12V一旦超过就可能误判甚至损坏芯片。解决办法我在前面提过拉一根粗地线把两端的GND连起来或者上隔离方案。我在养殖场那个项目里两段设备之间的地线靠一根2.5平方的铜线连接后期又加装隔离模块后才真正踏实。6.3 MicroPython特有的坑REPL占用、读缓冲和固件差异MicroPython平台有一些和硬件平台强相关的问题也会影响RS485通信。第一REPL串口占用。ESP32上UART0默认是REPL调试口调试时Thonny或者串口终端都走它。如果你把MAX13487接到GPIO1和GPIO3上开机会看到从机收到一堆乱码因为这些引脚同时被REPL输出占用。所以RS485千万别接UART0用UART1或UART2最好在代码里显式指定tx、rx引脚。第二UART接收缓冲溢出。MicroPython的UART驱动底层有缓冲区不同固件默认大小不同有的只有128字节。如果从机处理速度太慢、一段时间不来读缓冲区满了之后新数据会被丢弃。好在我们的帧很小几字节的请求完全不会触发溢出。但如果你在从机里做传感器读取、屏幕刷新等耗时操作记得在忙之前把UART缓冲区里的数据先读清空或者提高读取频率。第三不同固件版本对UART构造函数的支持有差异。有的ESP32固件版本上UART(2, baudrate115200, tx17, rx16)能直接跑有的要写成uart UART(2); uart.init(baudrate115200, tx17, rx16)。遇到TypeError不要慌先确认固件版本和官方文档。我的建议是统一先uart UART(2)再调init兼容性会好一些。7. 多节点组网与工程化落地清单7.1 总线型拓扑菊花链与短分支RS485的物理拓扑是总线型也就是所有节点的A、B线并接到同一条主干上节点和主干之间的分支越短越好。理想情况下分支长度不要超过1米否则分支末端会形成短截线导致信号反射。我看到过一些项目图省事用一条网线把每个节点像星型一样拉回主机这在节点少、距离近时也许能跑一旦节点多、距离长反射和干扰会让人怀疑人生。正确做法是一路走到底从主机出发沿现场路径把每个节点的A/B并联上去最后一个节点在物理末端加终端电阻。如果现场确实只能星型汇聚那么分支线尽量用双绞线且长度要短有条件的话在分支点和主干之间加隔离中继器。7.2 隔离、TVS和地线处理的产品化建议如果你的RS485设备要装到户外、生产现场、配电柜这些环境有几个东西不能省。隔离电路是最有效的地环路和共模干扰防护手段。常见方案是数字隔离器加隔离电源比如隔离侧用一个独立的5V转5V隔离电源模块给MAX13487供电数字侧通过ADuM1201这类隔离器连接MCU的UART。这样MCU的地和总线侧的地完全断开共模电压再大也影响不到MCU。MAX13487本身的A/B共模范围是-7V到12V有了隔离之后等于把整个隔离侧的“地”都浮空了实际能容忍的共模范围大大增加。TVS管也是必需品。A、B线各对地加一个双向TVS典型型号SMBJ6.0CA可以吸收瞬态静电脉冲。再串两个PTC自恢复保险丝一旦总线被意外接错电源导致大电流PTC能限制电流保护芯片。这些器件成本不高却在雷雨季节和工业现场能救下你的设备。7.3 从原型到产品协议兼容、实时性与平台权衡MicroPython适合原型验证和中小规模数据采集系统但如果你要把这套通信方案产品化有两点要想清楚。第一协议是不是应该直接兼容Modbus RTU。我这次演示用的是自定义帧格式方便讲清楚帧头、地址、CRC这些概念。但工业现场大量传感器、电表、PLC、组态软件都支持Modbus RTU如果你的从机直接用Modbus RTU协议主机可以和商用上位机软件无缝对接省去大量私有协议的适配工作。Modbus RTU的帧格式本质上和我上面讲的是一个套路设备地址、功能码、数据、CRC16区别主要在帧结构细节和寄存器寻址方式。从初级项目过渡到产品时直接迁移到Modbus RTU是性价比最高的路线。第二MicroPython的实时性局限。解释型执行、垃圾回收、软中断调度都会引入毫秒级的不确定性。如果从机的响应时间要求苛刻比如必须10毫秒内回包MicroPython可能顶不住。但大多数传感器采集和控制场景几十毫秒的响应周期完全能接受。如果真要强实时可以写C扩展模块或者换到C/C裸机配合FreeRTOS开发再把RS485驱动做成中断收发。我的建议是前期用MicroPython快速验证整条链路后面性能不够了再针对瓶颈模块局部改写不要一上来就用复杂工具链跟自己较劲。从原型到产品还有个小经验想分享给你PCB设计时MAX13487尽量靠近连接器放置A/B走线保持平行且短把终端电阻和偏置电阻的焊盘预留出来用跳线控制是否焊接这样调试阶段可以快速尝试不同配置不需要改板。细节决定效率这些留到后面会感谢自己当时多画了几个焊盘。