做嵌入式这么多年我发现一个规律凡是刚接触物联网开发不久的朋友十个里有八个会在通信协议选型上卡壳。串口、I2C、SPI、RS-485、CAN、Modbus、WiFi、BLE、LoRa……光是名字就能把人绕晕更别说每个还带一串速率、距离、拓扑、抗干扰的参数。前阵子帮一个做环境监测的团队做技术评审他们想在同一个项目里同时上 Modbus、WiFi 和 LoRa结果光聊“哪段该用哪个”就花了两个小时。最后选型定了、协议栈通了但我发现真正缺的并不是某个协议的用法而是一套能把协议放对位置的判断框架。所以这篇我打算换个写法不按教科书顺序背概念而是把从板级通信到物联网广域网这十来种最常见的协议按我自己的实际使用经验逐一拆开优缺点、传输距离、典型速率、应用场景全部摊开对比。文章最后会给你一套可以直接照搬的选型思路再加上我这些年踩过的一些坑。如果你是刚开始做物联网项目、或者在单片机和云平台之间来回折腾的开发者这篇应该对你有用。1. 先想清楚通信协议到底在解决什么问题很多人一上来就纠结“用 WiFi 还是用串口”“用 CAN 还是用 RS-485”但在纠结之前我建议先把通信这件事分层看明白。否则你拿物理层的标准和应用层的标准放在一起比永远比不出结果。1.1 选协议前必须弄懂的分层思维通信协议这个词特别容易让人混淆因为不同人嘴里的“协议”可能根本不在一个层级。拿寄快递打比方物理层协议相当于公路和卡车决定货物能跑多远、拉多重链路层协议相当于快递站点之间的分拣规则决定包裹怎么装车、怎么防止丢件应用层协议则相当于快递单上的填写规范决定收件人信息长什么样、怎么读取。在物联网开发里UART、SPI、I2C、RS-485、CAN、Ethernet、WiFi、BLE、LoRa 这些都属于物理层和链路层的范畴它们决定了信号怎么编码、怎么传输、能传多远。而 Modbus、MQTT、HTTP、CoAP 这些属于应用层它们跑在物理链路之上决定数据以什么格式组织、怎么被解析。我们平时说的“串口通信”往严了讲其实是 UART 物理层 自定义应用层帧格式的组合。Modbus 则既可以跑在串口上Modbus RTU也可以跑在以太网上Modbus TCP。理解这层关系之后你在做选型时就会少很多纠结先确定物理链路再确定应用层协议两条线不能混着选。1.2 一张对照看懂不同协议的层级归属为了直观我按自己在实际项目中的习惯把常见协议分成了四个梯队板级通信UART、I2C、SPI解决的是同一块电路板或者同一个设备内不同芯片之间的数据交换。现场总线RS-485、CAN解决的是几十米到上千米范围内多个设备之间的数据交换是工业现场的支柱。局域网/互联网接入Ethernet、WiFi解决的是设备接入本地网络或云端的问题带宽大、生态成熟。低功耗广域网LoRa、NB-IoT、ZigBeeMesh 短距组网解决的是海量终端在几公里范围内低功耗、远距离通信的问题。这四层不是替代关系而是互补关系。一个典型的物联网项目里传感器和主控之间可能走 I2C 或 SPI主控和采集网关之间走 RS-485 或 CAN网关再通过 WiFi、以太网或 LoRa 上云。每一层选合适的协议整体系统才稳定。2. 板级通信三剑客UART、I2C、SPI这三个协议是嵌入式开发的入门必修课也是几乎所有 MCU 出厂自带的标配。它们主要解决短距离、板级芯片间通信距离通常不超过一米但使用频率极高。我把它们放一起讲因为对比着看会更容易理解各自的定位。2.1 UART串口物联网开发者的第一根脐带UART 全称是 Universal Asynchronous Receiver/Transmitter通用异步收发器。它是最简单、最通用的通信方式只需要两根数据线TX 发送、RX 接收加一根共地线就能完成点对点双向通信。所谓“异步”就是收发双方不需要共享时钟信号而是约定好波特率各自按照这个速率在线上采样。串口的优点非常明显实现简单、几乎不需要额外硬件逻辑、排障直观。你拿一个 USB 转 TTL 模块插上电脑打开串口调试助手就能把单片机里的数据打出来看。因为简单几乎所有 MCU 厂商都把它作为调试打印的第一接口很多传感器模块、GPS 模块、蓝牙模块、4G 模组也默认通过串口和主控交互。串口的缺点也摆在那里点对点通信不原生支持一主多从TTL 电平的抗干扰能力差线稍微长一点就容易丢包通信速率受限于线缆质量和波特率常规应用多用 9600、115200bps。如果你只是把两个设备面对面接起来串口是最省事的但一旦需要拉到几十米外或者挂多个节点就得往 RS-485 方向考虑了。实操中有一个细节值得注意串口接线要交叉连接也就是设备 A 的 TX 接设备 B 的 RX设备 B 的 TX 接设备 A 的 RX地线必须连通。我见过太多新手把 TX 对 TX 接上数据出不来还以为是代码问题。另外波特率两端必须一致差一点都会出乱码115200 和 115200 看似一样实际如果两块板子晶振偏差大长时间通信也会积累误差这种情况在批量生产时要特别留意。2.2 I2C一主多从的极简两线制I2C 是 Philips 发明的两线制串行总线两根线分别是 SDA数据线和 SCL时钟线所有设备都挂在这两根线上靠设备地址区分彼此。它支持一主多从、多主多从通信速率有标准模式 100kbps、快速模式 400kbps、高速模式 3.4Mbps 等档位。I2C 最大的价值是省引脚。一片 MCU 只有两根空闲引脚就能挂几十个 I2C 设备温度传感器、EEPROM、RTC 时钟、加速度计、显示屏驱动几乎都能通过 I2C 接进来。硬件结构上只需要在 SDA 和 SCL 上各接一个上拉电阻典型值 4.7kΩ 对应 5V 系统2.2kΩ 对应 3.3V 系统总线上所有设备通过开漏输出共同驱动。但 I2C 的限制也很明确。它的速率和传输距离在板级通信里都排不上号标准 I2C 通信距离基本就在同一块 PCB 或者很短的一小段排线内超过几十厘米就容易波形畸变。另外 I2C 没有硬件流控和应答机制之外的错误恢复能力如果从设备跑飞拉低 SDA 线整条总线会被卡死只能重启设备或复位总线上的从机。我的做法是板内芯片通信能用 I2C 就尽量用 I2C因为省引脚但如果两个板子之间用排线连接或者速率要求比较高那就改用 SPI 或 UARTI2C 拉线超过 20 厘米就值得警惕了。2.3 SPI为速度而生的四线全双工SPI 全称是 Serial Peripheral Interface四线制接口MOSI主出从入、MISO主入从出、SCLK时钟、CS片选。它和 I2C 最大的区别在于——全双工、速度快、且靠片选线而不是地址来选设备。SPI 的速率上限很高从几 Mbps 到几十 Mbps 都很常见具体取决于主控和从机的能力以及走线质量因此非常适合对吞吐量有要求的场景显示屏刷新、音频数据流、SD 卡读写、Flash 存储、ADC 采样数据回传。只要主控还剩一个空闲 SPI 外设我通常会把这类高速设备挂在 SPI 上。SPI 的缺点一是引脚占用多一主一从就要 4 根线挂多个从机时每个从机还要一条独立 CS引脚开销比 I2C 大不少二是不太适合远距离传输SPI 时钟频率高线一长信号完整性就崩通常建议也只在板内使用。三是从机数量受限于 CS 引脚数量当然也可以用 GPIO 扩展器或者菊花链方式拓展但复杂度就上去了。还有个小坑SPI 有四种模式CPOL、CPHA 组合不同芯片默认模式可能不一样配置错了数据解析就对不上。排障的时候如果发现 SPI 数据全是乱的第一件事不是看代码逻辑而是确认主从两端的 SPI Mode 对不对齐。2.4 三个板级协议怎么选我给个快速判断法点对点、低速、要简单选 UART多设备、省引脚、低速选 I2C高速、大数据量、同一块板子上选 SPI。但这里必须提醒一点这三个协议都是短距离通信的“内部工具”设计产品时不要指望它们解决跨设备、跨房间乃至跨城市的通信问题。很多新手在原型阶段用串口把两个开发板连起来就觉得万事大吉结果一到现场部署就傻眼因为距离或者节点数根本扛不住。这时就该往工业总线方向看了。3. 工业总线双雄与工控标准RS-485、CAN、Modbus从这一层开始通信就脱离了“板级调试”的舒适区进入真正的工业现场。设备之间隔着几十米甚至上千米环境里还有电机、变频器、开关电源带来的电磁干扰如果还用 TTL 串口基本属于送人头。工业场景选总线主要在 RS-485 和 CAN 之间做选择题再往上是 Modbus 这类应用层协议来解决数据组织问题。3.1 RS-485长距离多点传输的干线之王RS-485 本质上是串口的一种电气标准扩展它不是替代 UART而是把 UART 输出的 TTL 信号转换成差分信号在双绞线上传输。所谓差分信号就是用两根线 A、B 上的电压差来表示逻辑 0 和 1抗共模干扰能力强得多同时允许在一条总线上挂多个节点标准情况下最多 32 个使用高输入阻抗芯片可扩展到 128 甚至更多。RS-485 的传输距离和速率成反比。我做过的项目里9600bps 下跑到 1200 米问题不大115200bps 下建议控制在几百米以内更高速率就需要仔细考虑线缆质量和终端匹配。因为它是半双工通信四线制也可以全双工但用得少同一时刻只能有一个节点发送所以需要软件或者硬件方向控制来切换收发状态。RS-485 组网几乎是所有工控项目的起点典型的拓扑是一主多从比如一个 PLC 或者采集器通过 485 总线轮询下面几十个仪表、传感器、变频器。接线必须用双绞线首尾两端各接一个 120Ω 终端电阻A、B 极性不能反屏蔽层要单端接地。这些细节看着琐碎但任何一个出错都可能导致整个总线通信不稳定后面我会在排错部分专门展开。3.2 CAN带仲裁的差分总线天生适合实时控制CAN 总线是博世为汽车电子发明的后来又大规模进入工业控制、医疗设备和机器人领域。它同样使用差分两线CANH、CANL但和 RS-485 有本质区别CAN 是多主总线任何节点都能主动发起发送同时报文带优先级仲裁机制两个节点同时发数据时优先级低的会自动退避绝不让数据在总线上“撞车”。这个特性让 CAN 在实时控制场景里无可替代。还是拿汽车举例发动机 ECU、ABS、安全气囊、仪表盘之间有大量高优先级控制报文如果像 RS-485 那样靠主机轮询反应速度根本跟不上。CAN 的速率和距离关系也很有讲究1Mbps 下可靠通信距离约 40 米500kbps 约 100 米125kbps 可以到 500 米50kbps 甚至能到 1 公里左右。经典 CAN 单个数据帧有效负载只有 8 字节CAN FD 扩展到了 64 字节适合传输小但实时性要求极高的控制数据。CAN 组网需要特别注意终端电阻标准要求总线两端各接一个 120Ω 电阻否则波形反射会直接导致通信失败。此外CAN 节点需要 CAN 收发器芯片如 TJA1050、SN65HVD230把控制器输出的逻辑电平转换到总线差分电平硬件链路比 RS-485 多一层但也因此更皮实。在实际项目里CAN 总线在强电磁干扰环境下表现明显优于 RS-485代价是硬件成本略高、软件协议相对复杂。3.3 Modbus把寄存器搬上线的应用层老将Modbus 不是物理层协议而是一个运行在 RS-485 或以太网之上的应用层协议由 Modicon 公司在 1979 年提出是目前工控领域事实上的数据交换标准。它最经典的形态是 Modbus RTU一条 RS-485 总线上有一个主机通常为 PLC 或上位机和最多 247 个从机主机发请求帧从机回响应帧数据以 CRC16 校验保证完整性。Modbus 的数据模型把设备内部数据抽象成四类对象线圈、离散输入、输入寄存器、保持寄存器。读开关量用功能码 01、02读写模拟量用功能码 03、04、06、16。指令格式非常规整一个读保持寄存器的请求也就八个字节左右非常适合低速串口链路。这也是为什么几十年过去Modbus 依然是电表、水表、温控器、变频器、智能仪表最通用的接口。我在实际项目中用 Modbus RTU 的频率相当高因为它几乎成了传感器厂商的默认选项。很多工业传感器买回来引脚上直接标 A、B接到 485 转 USB 模块上打开串口助手发一条 01 03 00 00 00 02 C4 0B就能把测量值读出来。Modbus 的缺点也很明显轮询机制决定它不适合设备数量多且上报频繁的场景协议没有安全机制裸跑在公网容易出问题它的实时性一般工业运动控制会用 EtherCAT 这种实时以太网协议而不是 Modbus。3.4 工业场景的选型组合我在现场部署时几乎不会只用一种协议。比较成熟的做法是传感器和采集器之间根据距离和节点数选 RS-485 或 CAN采集器内部主控和通信模组之间用 UART采集器与上位机或云平台之间再用 Modbus TCP 或 MQTT 做接入。每一层选当前场景下最合适的协议而不是试图用一个协议包打天下这样系统出了问题也容易隔离开排查。另外补充一个关于 Modbus 地址的细节多台从机挂在同一条 485 总线上时每台从机的站地址必须唯一而且从机地址和功能码、寄存器地址在报文中都以十六进制传输。写上位机程序时如果没把字节序、数据格式搞清楚读回来的数据经常是“高位和低位颠倒”这个问题几乎每个做 Modbus 的人都会遇到至少一次。4. 网络化与无线物联以太网、WiFi、BLE、LoRa从这一层开始设备不再是孤立的信息孤岛而是要连局域网、上云或者进入低功耗广域网络。这一层的选择维度也从“速率、距离、节点数”扩展到了“功耗、成本、云端生态、部署便利性”。我把以太网、WiFi、蓝牙 BLE、LoRa 这四个并在一起讲因为它们代表了物联网接入层最主流的四条路径。4.1 以太网稳定可靠的有限骨干以太网在物联网里的存在感经常被低估但它其实是最省心的接入方式。一台设备只要插上网线配置好 IP数据的稳定性、速率、安全性都有保障。100Mbps 乃至 1Gbps 的带宽下传输视频流、大文件、远程登录都毫无压力而且以太网天然支持 TCP/IP 协议栈能和云端、数据库、上位机无缝对接。以太网的传输距离在双绞线标准下是 100 米超过就需要加交换机或光纤。它的优点是抗干扰能力强、不占频谱资源、没有无线信道竞争的问题缺点是布线施工成本高设备位置一旦确定就不方便移动。所以我的经验是凡是固定位置、有网线可布的设备优先考虑以太网需要移动或者布不了线的设备再考虑无线方案。在物联网网关设计中以太网通常是“最后 100 米”的出口。一个典型的工业网关内部通过 RS-485 把现场仪表数据收上来通过以太网或 WiFi 传出去有些高端网关预留双网口一路接内网设备一路接外网服务器。调试时优先用网线验证基础链路是否通所有传感器数据都调通了再切到无线模式这个顺序能帮你省掉大量没必要的变量。4.2 WiFi物联网上云的主流入口WiFi 几乎是智能家居和消费类物联网设备接入云端最常用的方式因为它直接复用家里或办公室的现成路由器不需要额外搭网关开发者也最熟悉。ESP8266、ESP32 这两颗芯片把 WiFi 模组的成本打到十几块钱更是让 WiFi 几乎成为入门物联网开发的第一站。WiFi 的传输距离在室内大概 30 到 50 米室外空旷环境可以到 100 到 300 米具体穿墙后衰减非常严重这点和 2.4GHz 频段的物理特性有关。速率方面802.11n 之后几十 Mbps 到上百 Mbps 都很容易达到传输常规传感器数据绰绰有余传视频流也基本够用。但 WiFi 有两个绕不开的短板一是功耗高电池供电的设备如果一直开着 WiFi续航会非常难看二是连接稳定性受环境干扰影响大2.4GHz 频段里蓝牙、ZigBee、微波炉都在抢频段。实操中我用 WiFi 模组的时候最注意两个问题。第一网络异常重连机制必须自己做好因为路由器重启、信号波动、DHCP 租约到期都会让设备掉线MCU 侧要在定时器里检测连接状态并自动重拨。第二尽量让设备走 MQTT 协议上云而不要直接用 HTTP 轮询HTTP 的请求响应开销大而且服务器推送能力弱在弱网环境下体验明显不如长连接的 MQTT。4.3 蓝牙BLE低功耗下的近场互联蓝牙 BLEBluetooth Low Energy是物联网近场无线通信里功耗控制做得最好的方案之一。一颗纽扣电池可以让 BLE 设备工作数年这个特性让它在穿戴设备、健康监测、Beacon 定位、智能门锁、医疗贴片等领域几乎是默认选择。BLE 的工作频率也是 2.4GHz使用 40 个信道其中 3 个广播信道用于设备发现与连接37 个数据信道用于数据传输。BLE 4.2 的理论速率约 1MbpsBLE 5.0 将速率提升到 2Mbps同时还引入了 Coded PHY 来牺牲速率换取更远的传输距离最远可以跑到几百米级别但在常规穿戴场景下10 到 100 米的覆盖范围已经完全够用。BLE 的数据模型基于 GATT通用属性协议设备通过 Service 和 Characteristic 来组织数据。手机和 MCU 之间的通信流程大致是BLE 设备广播、手机扫描并连接、手机发现服务、读写特征值、订阅通知。这套机制灵活但也让初学者容易迷惑尤其是“广播数据格式”“UUID 定义”“MTU 大小限制”这几个点网上能搜到一堆半懂不懂的帖子建议直接看官方文档或者开源库的源码。我在做低功耗设备时的原则是能广播解决的就不连接连接后能断就断尽量减少空中的活动时间。BLE 的功耗大头在于射频收发每次收发都是一次能量消耗所以合理设计上报周期对整机续航影响极大。4.4 LoRa远距离低功耗物联网的黑马LoRa 属于低功耗广域网LPWAN的代表性技术工作在 Sub-GHz 频段国内常用 470MHz 到 510MHz欧洲常用 868MHz北美常用 915MHz。它最大的特点是在极低功耗下仍然能覆盖数公里的通信距离这是因为 LoRa 使用了 Chirp 扩频调制技术接收灵敏度可以低到 -137dBm 左右比 WiFi 和蓝牙优秀得多。LoRa 的传输速率只有 0.3kbps 到 50kbps 左右显然不适合传图片、音频但非常适合传“浓度、温度、状态、计数”这类小数据包。在实际项目中一个温湿度采集终端每隔 15 分钟上报一次2 节 AA 电池供电往往能用一年以上。配合 LoRaWAN 协议栈终端通过网关接入网络一个基站可以接成千上万个终端非常适合智慧农业、智能表计、园区安防、消防水位监测这类覆盖范围大、节点数量多、对功耗敏感的场景。LoRa 的缺点也很明确速率低不能频繁传输大数据需要自建网关增加了部署成本Sub-GHz 频段在国内需要遵守相关无线电管理规定功率、占空比都有约束。在做方案选型时如果你的项目要在城市里覆盖几公里且没有布线的条件LoRa 比 WiFi 和蓝牙都靠谱得多但如果只是在一个房间里做设备联动用 LoRa 就是大炮打蚊子成本还高。除了 LoRaLPWAN 另一个常被提起的是 NB-IoT。它运行在运营商授权的蜂窝频段上覆盖范围更广且不需要自建网关插一张 SIM 卡就能上云非常适合分布在各处的智能水表、烟感、地磁车位检测器。NB-IoT 的劣势是模块成本和流量费用比 LoRa 略高且必须依赖运营商网络覆盖。两份方案我做过对比如果节点密集且集中在园区内LoRa 更划算如果节点分散在城区各处NB-IoT 更省事。5. 一张总表10大协议距离、速率、场景全对比铺垫了这么多下面把最核心的一张大表放出来。这张表里的数据是基于典型工业级配置和一般工程经验整理出来的不同芯片、不同线缆、不同环境会有偏差但用于初步选型已经足够。建议收藏做项目前对着过一遍能省下不少查资料的功夫。协议层级拓扑典型速率传输距离功耗抗干扰典型场景UART物理层点对点9600~115200bps最高数Mbps板级TTL几米RS-232约15米低低MCU调试打印、GPS/蓝牙/4G模组对接I2C物理层一主多从/多主100k~3.4Mbps板级通常小于0.5米极低低传感器、EEPROM、RTC、显示屏驱动SPI物理层一主多从片选几M~几十Mbps板级通常小于1米低低Flash、SD卡、显示屏、高速ADCRS-485物理层一主多从总线9600bps~10Mbps1200米9600bps百米115200bps低强工业仪表采集、门禁、楼宇自控CAN物理层多主总线125k~1MbpsCAN FD更高40米1Mbps1公里50kbps低强汽车电子、工业控制、机器人Modbus应用层主从跟随底层链路跟随底层链路视情况视情况PLC、电表、水表、变频器数据采集以太网物理链路层星型100M~1Gbps100米双绞线高需供电强网关、服务器、固定设备接入WiFi物理链路层星型几十~几百Mbps室内30~50米室外100~300米高中智能家居、摄像头、设备上云BLE物理链路层星型/广播1~2Mbps10~100米BLE5可达几百米极低中穿戴设备、Beacon、医疗贴片LoRa物理链路层网关星型0.3~50kbps城市1~5公里郊区15公里以上极低强智慧农业、表计、园区安防补充说明一点上表中“距离”和“速率”不是独立参数它们往往是同一个物理通道上的两个极端尤其在 RS-485、CAN、LoRa 这类协议里体现得尤其明显。速率越高传输距离越短距离越远速率就必须降下来。做选型时别只看单一方面一定要把速率、距离、节点数、功耗绑在一起考虑。另外ZigBee 和 NB-IoT 虽然没有进前 10 主表但它们也是物联网领域绕不开的常客。ZigBee 走 2.4GHzMesh 自组网单跳距离 10 到 100 米逐渐被 BLE Mesh 抢占市场NB-IoT 走运营商蜂窝网络覆盖广、单节点成本高一点适合海量终端分散部署。你可以把 NB-IoT 理解为“插卡即用的免自建网关 LoRa”把 ZigBee 理解为“被 BLE 和 WiFi Mesh 挤压生存空间的短距组网老将”。6. 实战选型从需求到协议的推导过程有了一张总表还不够因为选型从来不是查表就能完成的。我的习惯是倒着推先明确最终要达成什么效果再反推每一段链路用什么协议。下面这套四步决策法是我在不同项目里反复验证过的照着走基本不会出大偏差。6.1 四步决策法照着做就能圈定方案第一步先框定距离。设备在哪里数据要到哪去是同一块板子、同一个机柜、同一栋楼、同一个园区还是跨城区这个物理距离直接淘汰一大半选项。同一块板子在 UART、I2C、SPI 里选同一个机柜或车间在 RS-485、CAN、以太网里选同一栋楼但没有布线条件看 WiFi园区级且要低功耗看 LoRa城市级分散部署看 NB-IoT。第二步再定速率与数据量。把每帧报文大小、上报频率、接几个节点全部算出来得到链路需要的最小吞吐量。打个比方一个采集器带 20 个温度传感器每 5 秒轮询一次每次数据 8 字节链路吞吐量需求大概就是每秒 32 字节这种量级哪怕用 9600bps 的 RS-485 都绰绰有余。反过来如果要传高清摄像头画面LoRa 和串口想都别想直接上 WiFi 或以太网。第三步看节点数与拓扑。确认总线上要挂多少设备是主从轮询模式还是多主自主上报模式这决定你在 RS-485 和 CAN 之间怎么选。节点多、数据要主动上报、实时性要求高CAN 更合适节点适中、上位机轮询、实时性要求一般RS-485 加 Modbus 性价比更高。第四步死磕功耗与成本。电池供电、几年不换电池的设备基本上只能在 BLE、LoRa、NB-IoT 这三个方向里选WiFi 直接排除。功耗之外还有硬件成本和维护成本两相衡量之后再把方案细化到具体的芯片和模组。6.2 两个典型物联网项目选型实例举两个我最近评审过的实际项目方便你把这套方法套用到自己的场景里。第一个是智慧农业大棚监测需要在 200 亩的园区内部署 50 个土壤温湿度采集终端终端由太阳能电池供电数据每隔 15 分钟上传一次到云端平台。按四步法走距离是园区级、数公里范围功耗高不了速率要求极低所以最终选 LoRa 终端加 LoRa 网关网关通过以太网上云。50 个节点用一台网关就够了终端休眠功耗做到微安级别太阳能板加锂电池就能长期运转。第二个是工厂产线设备数据采集现场有 30 台 PLC分布在车间不同位置距离最近几米、最远几百米要求数据实时刷新到工位看板。底层用 RS-485 加 Modbus RTU 轮询把一个机柜里的数据集中到边缘采集器再通过以太网或者 WiFi 推送到看板服务器。选 RS-485 而不是 CAN是因为市面上的 PLC 仪表几乎都有 Modbus RTU 接口兼容性最省心实时刷新周期在 1 秒级别轮询完全够用没必要上 CAN。7. 高频踩坑与排错实录写文章的这部分我最愿意分享因为很多问题光看手册是学不来的。我干脆把高频出现的通信排查场景集中整理一下每一条都是实战里真实遇到过的希望能帮你少走点弯路。7.1 串口收不到或乱码不只是波特率的问题很多人在遇到串口乱码时第一反应是波特率不对。但波特率调对了还是乱码的情况同样常见。我排过的问题里出现过这几种原因一是两端电平不一致比如单片机是 3.3V TTL外接的串口模块却工作在 5V 电平信号识别出错二是共地问题两个设备电源不共地导致信号参考电位漂移三是线材质量差或者杜邦线太长尤其是 115200 以上波特率时劣质线会带来明显的寄生电容和反射。排查思路是先用最短的杜邦线、最低波特率9600做回环测试确认 MCU 自身收发正常再逐步把线加长、把波特率调高看哪一个环节开始出问题。串口调试助手是排查时最趁手的工具既能实时看数据流又能按 HEX 格式逐字节分析强烈建议所有做嵌入式的人把 HEX 显示和发送这个功能用起来一堆“看着正常其实是乱码”的字符问题切到 HEX 一眼就能看穿。7.2 CH340、CH341、FTDI驱动USB转串口的隐形地雷USB 转串口模块几乎人手一个但驱动问题永远是新手噩梦。CH340 和 CH341 是国产方案价格便宜驱动装不上常见于 Windows 系统更新后的驱动签名问题FTDI 芯片稳定性更好但市面上盗版芯片很多装上官方驱动后反而会被识别成 fake chip 导致功能锁定。这些事遇到后不用慌第一步是到芯片厂商官网下载对应版本驱动手动安装别用第三方驱动管家第二步是检查设备管理器里 COM 口号部分设备会因为 COM 口号被占用出现“端口无法打开”的提示第三步是确认波特率、数据位、停止位和校验位是否和单片机程序一致。有个冷知识CH340 芯片在部分 Linux 发行版里已经自带驱动插上即识别。但如果你用国产 ARM 开发板当主机去读 USB 串口某些内核版本需要手动加载模块编译内核时不要把 USB Serial 支持选项漏掉。7.3 串口DMA接收与空闲中断判断接收完成的正解单片机串口接收数据如果一帧数据不定长最怕的就是不知道什么时候算“收完一帧”。轮询加延时判断每个字节都停下等待效率太低逐字节中断处理又容易丢数据。我推荐的做法是串口 DMA 接收加空闲中断IDLE来判断一帧结束DMA 负责把数据搬进内存缓冲区空闲中断在总线空闲时触发此时检查 DMA 当前接收计数就能取出这一帧完整的数据。具体实现上以 STM32 为例开启 UART 的 IDLE 中断和 DMA 接收在中断回调里读取 DMA 剩余传输数据量用缓冲区总长度减去剩余量就是这一帧的实际字节数然后立刻清标志位、重开 DMA。这套方案在大流量、不定长协议的场景下非常稳定比传统的接收超时判断靠谱得多。踩过的一个坑是某些库函数会在关闭 DMA 再重新使能时丢最后一个字节解决办法是先切到循环模式或者用双缓冲具体要看厂商库的实现细节。7.4 RS-485/CAN总线静默与断连硬件细节决定成败RS-485 和 CAN 都是差分总线排查套路类似。最常见的“总线上偶尔有节点掉线、数据时好时坏”先不要怀疑程序八成是硬件层面问题。RS-485 重点查A/B 线有没有接反总线首尾有没有接 120Ω 终端电阻屏蔽层是否单端接地每个节点的收发切换方向控制是不是留出了足够的建立时间尤其是用 GPIO 控制收发方向时切换太慢会导致第一个字节被吞。CAN 总线重点查CANH 和 CANL 是否接反终端电阻是否匹配万用表量总线两端正常应该是 60Ω 左右如果量到 120Ω 说明某个终端电阻没接上波特率和采样点设置是否一致只要有一个节点采样点偏了总线在温升或者干扰下就会间歇性故障。还有一个容易忽略的点CAN 收发器和 MCU 之间的光耦隔离如果项目现场有强电设备建议做电气隔离否则一次浪涌就把一片节点打坏。8. 最后的实操体会做了这么多年通信相关的东西我最深的体会是没有最好的协议只有最合适的协议。UART 简单到被很多人瞧不上但它解决了 90% 的调试场景LoRa 慢得像蜗牛但它能在田间地头把数据传回几公里外的网关。选型时不迷信参数表把距离、速率、节点数、功耗、成本这五件事放在桌面上过一遍答案自己就浮出来了。最后再分享一个小技巧新手做项目时尽量把通信过程“可视化”。无论是串口调试助手、逻辑分析仪还是抓包工具一定要能实时看到数据在链路里的样子。很多隐蔽的时序问题、字节序问题、帧格式问题眼睛看到真实数据的那一刻往往比苦思冥想代码逻辑更有效。通信的本质就是一句话——让两端看到的字节完全一致搞定了字节就搞定了通信。
