内容摘要：去年帮一个朋友调试智能门锁，I2C总线上挂的指纹模块死活读不出数据。示波器一挂，SDA和SCL的时序乱成一团。换成SPI重新布线，十分钟跑通。嵌入式通信协议选型这件事，很多时候不是"哪个更好"的问题，

去年帮一个朋友调试智能门锁，嵌入I2C总线上挂的式通指纹模块死活读不出数据。示波器一挂，信协SDA和SCL的嵌入时序乱成一团。换成SPI重新布线，式通十分钟跑通。信协嵌入式通信协议选型这件事，嵌入很多时候不是式通"哪个更好"的问题，而是信协"哪个更合适"。

先聊最基础的嵌入UART。两根线，式通TX和RX，信协没有时钟线，嵌入靠约定的式通波特率同步。简单到几乎每颗MCU都标配。信协但正因为简单，它没有寻址机制，点对点通信，多设备就得多个串口或者加多路复用器。我见过有人用UART组网，搞了个轮询机制，结果实时性一塌糊涂。UART适合什么？调试串口、GPS模块、蓝牙透传——数据量不大、设备单一的场景。115200的波特率传个传感器数据绰绰有余。

I2C是另一回事。两根线挂一堆设备，靠7位地址区分。当年Philips搞这个协议是为了让电视内部的芯片少走线。现在你随便拆个开发板，EEPROM、陀螺仪、OLED屏大概率都挂在I2C上。但它有个硬伤：总线电容不能太大，线长了波形就塌。400kHz是常见速率，再往上走Fast Mode Plus能到1MHz，但驱动能力跟不上。而且I2C是半双工，主机不发时钟从机就不能说话。遇到需要高速连续采样的IMU，I2C基本撑不住。

SPI就暴力多了。四根线，MOSI、MISO、SCK、CS，全双工，时钟可以跑到几十MHz。没有地址机制，靠片选线拉低来选中设备。代价是每多一个从机就多一根CS线。PCB上走线多了确实烦，但速度摆在那。Flash存储、TFT屏幕、高速ADC，这些场景SPI是首选。我手上有个项目用SPI接ADXL345加速度计，8MHz时钟，三轴数据连续读，一点不卡。

CAN总线得单独说。差分信号，抗干扰强，多主架构，带仲裁机制。汽车上几乎全是CAN，发动机、变速箱、车窗、座椅，各种ECU挂在两条双绞线上。它没有时钟线，靠位同步，速率和总线长度成反比。1Mbps只能跑40米，125kbps能跑500米。工业控制里CANopen、J1939这些上层协议都跑在CAN上。有个做充电桩的朋友，BMS和充电模块之间就是CAN通信，环境电磁干扰大，换成别的协议早崩了。

RS485不是协议，是物理层标准。差分传输，半双工，通常配合Modbus协议使用。工厂里那些老设备，PLC、变频器、电表，Modbus RTU over RS485一抓一大把。布线简单，两根线手拉手，终端电阻一接，跑个1200米没问题。但它是主从轮询，主机不问，从机不能主动上报。做数据采集够用，做实时控制就差点意思。

无线这块，BLE、Zigbee、LoRa、WiFi各有各的地盘。BLE适合手机配对的低功耗设备，心率带、防丢器。Zigbee搞Mesh组网，智能家居里灯控、传感器用得多。LoRa跑远距离，几公里起步，但速率低得可怜，适合抄表、环境监测。WiFi带宽大，但功耗高，插电设备才扛得住。

选协议这事，我一般看三个维度：速率、距离、拓扑。点对点短距离高速，SPI。多点低速少线，I2C。多点抗干扰中距离，CAN。远距离低速率，RS485加Modbus。功耗敏感无线，BLE或LoRa。没有银弹，每个协议都是取舍的结果。那些说"用XX就对了"的，多半没踩过坑。