空调开发中嵌入式通信协议贯穿从板级到云端的全部环节越是接近量产越能看出通信设计的好坏。一个空调控制器既要读取温湿度、压力、风速等传感器又要驱动变频压缩机、显示面板、步进电机还要接收红外遥控指令、接入 WiFi/BLE最后把运行状态经 MQTT 等协议上报到云端平台。这里的每一步都对应一类通信协议板级常用 I2C、SPI、UART设备间多用 CAN 和 RS485向云端走则普遍选择 MQTT。下面按这条链路把协议选型、连接方法、报文结构、验证手段和排错思路串起来适合正在做空调控制器、智能家居设备或物联网网关的嵌入式工程师参考。读完以后可以按层判断问题出在板级采集、设备间通信还是云端链路并能独立搭建一段最小可运行的验证示例。1. 空调通信链路的三层结构板级、设备级、云端各管什么1.1 三层通信的职责边界空调控制器里的通信任务并不是一个协议能覆盖的。它至少可以被拆成三层每层的物理环境、数据量和可靠性要求都不同。板级通信发生在同一块 PCB 或同一块控制器内部时间尺度是微秒到毫秒。主控 MCU 需要读取温度传感器、湿度和压力传感器可能需要读写 EEPROM 保存用户设置和历史参数也可能要驱动一块点阵液晶或段码屏。这一层的特点是距离很短、布线可控、时序要求严格接口通常直接挂在 MCU 的外设引脚上常用 I2C、SPI、单总线、UART甚至纯 GPIO 模拟时序。设备级通信发生在空调不同部件之间已经不局限于同一块板卡。室内机主控要把状态发给显示线控器要和室外机交换压缩机频率、故障码、环境温度大一点的商用空调还会接楼宇自控系统。这一层距离可能从几十厘米延伸到几十米甚至上百米需要更强的抗干扰能力和错误检测机制所以 CAN、RS485、Modbus RTU、红外协议会在这一层出现。云端通信是空调具备联网能力之后新增的一层。设备端通过 WiFi 模组、BLE、以太网或蜂窝网络接入物联网平台使用 MQTT、HTTP 或私有 TCP 长连接把温度、模式、风速、故障状态上报到服务端同时接收平台下发的开关机、目标温度、定时策略等指令。这个部分的网络环境最不稳定存在弱网、断网、丢包、平台重启等情况因此需要在设备端设计重连机制和报文确认机制。层级通信范围典型协议空调场景中的典型用途板级PCB 内部几厘米到十几厘米I2C、SPI、UART、单总线、GPIO读温湿度、读写 EEPROM、驱动显示、接调试串口设备级控制器与面板、内外机、楼宇设备之间CAN、RS485、Modbus、红外内外机通信、线控器交互、楼宇 BA 接入云端设备到物联网平台或服务器MQTT、HTTP/HTTPS、私有 TCP状态上报、命令下发、OTA、远程诊断1.2 各类通信协议怎么选关键看四个指标选型时不要凭习惯或别人用过就定要先看四个指标通信距离、传输速率、可靠性机制、开发成本。板级 I2C 适合连接寄存器型传感器和存储芯片线少但从设备地址是全局分配的速率一般到 400 kHz 或 1 MHz距离拉长以后上升沿变缓容易出问题。SPI 速率高适合视频缓存、大容量 Flash、LCD 等批量数据场景但至少需要 4 根线而且 SPI 主机必须知道从机的时钟极性和相位配置。UART 是设备之间最通用的接口速率以 9600 和 115200 最常见它只定义物理层字节传输一帧数据的边界、校验、重传都要自己实现。从板级跨到设备级CAN 和 RS485 通常比 UART 更可靠。CAN 使用差分信号带硬件仲裁和错误帧重发适合多节点实时控制RS485 也是差分信号半双工主从模式成本低是中长距离 Modbus 通信的物理层基础。无线通信则要单独评估信道占用、干扰、丢包和功耗。协议典型速率典型距离可靠性机制常见使用场景I2C100 kHz / 400 kHz部分器件支持 1 MHz板级通常小于 30 cm从机 ACK但缺少内置 CRC 或重传温湿度传感器、EEPROM、IO 扩展SPI几 MHz 到几十 MHz板级为主走线短全双工无帧级 ACK需软件上层保证Flash、LCD、触摸屏、高速 AD 采集UART通常 9600 bps 或 115200 bps板内或短距离线缆只有帧级起始停止位校验可加可省调试日志、WiFi/BLE 模组透传CAN常见 250 kbit/s 或 500 kbit/s最高 1 Mbit/s随速率下降通常几十米硬件仲裁、错误帧检测、自动重发多联机内外机通信、变频驱动控制RS485常见 9600 bps、19200 bps、115200 bps低波特率可达几百米至上千米物理层差分应用层需再加 CRC 重传商用空调接楼宇、多台设备轮询MQTT取决于网络不取决于协议本身局域网或公网QoS 0/1/2、遗嘱、会话保持空调状态上云、平台命令下发这一节的核心判断是空调项目里没有“最好的协议”只有“这一层最合适的协议”。板级追求低成本和总线简单设备级追求稳定和抗干扰云端追求弱网可用和持续连接。下面从底层开始逐层看实现方法。2. 板级通信最常接触的是这几类单总线、I2C、SPI 和 UART2.1 温度与湿度采集NTC、DHT11 和 I2C 传感器并存空调系统采温点是分散的。室内环温、蒸发器管温、室外环温、压缩机排气温度都可能使用 NTC 热敏电阻MCU 通过 ADC 测量分压电压后查表得到温度这种方式并不属于数字通信但它在空调主板上占比最高。随着智能化程度提高很多产品会再加入一块数字温湿度传感器来获得室内湿度常见的选择是 DHT11、AHT20、SHT30 这类小封装器件。DHT11 使用的是单总线协议只有一根数据线主机需要严格按时序发起读取。常见流程是主机把总线拉低 18 ms然后释放总线等待从机响应再从总线里读回 40 bit 数据。40 位数据里包含湿度整数、湿度小数、温度整数、温度小数和校验和。读取函数里最容易出错的是对高低电平宽度的判断因为单总线要求微秒级延时。/* 单总线读取 DHT11 一个字节时序依赖较强 */ static uint8_t dht11_read_byte(void) { uint8_t value 0; for (uint8_t i 0; i 8; i) { /* 等待数据线拉低再等待 30us 左右采样判断电平 */ while (dht11_in_read() 0); delay_us(30); if (dht11_in_read() 1) { value | (0x80 i); } /* 等待高电平结束进入下一位 */ while (dht11_in_read() 1); } return value; }使用 DHT11 前要确认你用的延时函数是阻塞延时还是任务调度延时。在 RTOS 环境里直接调用vTaskDelay做微秒级时序往往不准确需要关中断或使用硬件定时器否则数据位很容易错位。如果产品希望减少 MCU 资源占用更推荐换成 I2C 接口的 AHT20 或 SHT30它们把时序管理放在芯片内部主机只按寄存器命令读取就能得到结果。/* I2C 读取 AHT20 温湿度器件地址以实际数据手册为准 */ static int aht20_read_temp_humidity(float *temperature, float *humidity) { uint8_t cmd[] {0xAC, 0x33, 0x00}; uint8_t data[6] {0}; /* 触发测量 */ i2c_write_bytes(AHT20_ADDR, cmd, sizeof(cmd)); /* 等待测量完成不同传感器等待时间不同 */ delay_ms(80); /* 读取 6 字节状态和数据 */ i2c_read_bytes(AHT20_ADDR, data, sizeof(data)); *humidity ((uint32_t)(data[1] 12) | (data[2] 4) | (data[3] 4)) * 100.0f / (1 20); *temperature (((uint32_t)(data[3] 0x0F) 16) | (data[4] 8) | data[5]) * 200.0f / (1 20) - 50.0f; return 0; }这里要注意I2C 器件的 7 位地址和 8 位地址在不少 SDK 中存在混用。如果代码里写错高低位主机会收到 NACK或者一直读到 0xFF。AC 命令、测量时间和唤醒操作都应以最终选型的芯片手册为准。2.2 SPI 在空调主板里一般负责什么SPI 在空调主板上的存在感没有 I2C 那么强但只要出现往往是为了传输批量数据。典型场景包括使用大容量 SPI NOR Flash 保存故障记录和升级包使用 SPI 接口的 LCD 显示中文菜单或者用 SPI 扩展多路 IO 去驱动继电器和阀体。SPI 是全双工同步串行接口至少使用时钟线 SCLK、主机输出从机输入 MOSI、主机输入从机输出 MISO、片选 CS 四根线。每个从设备都需要一根独立片选线主机把 CS 拉低后从机才能和主机通信。SPI 没有 ACK bit任何一端的时钟极性或相位配置不统一从机都会返回毫无意义的数据。在驱动 SPI Flash 时寄存器读、扇区擦除、页编程是三条基本操作。/* 伪代码向 SPI Flash 写入一页数据 */ uint8_t page_program_cmd[] { 0x02, /* Page Program 命令不同 Flash 可能不同 */ addr 16, /* 地址高字节 */ addr 8, /* 地址中间字节 */ addr 0xFF, /* 地址低字节 */ data[0], data[1], data[2] }; spi_select(FLASH_CS); spi_transmit(page_program_cmd, sizeof(page_program_cmd)); spi_deselect(FLASH_CS);使用 SPI 最大的坑是 CPOL 和 CPHA 不匹配。主机用模式 0从机用模式 1数据在错误的时钟沿被采样轻则数据错位重则完全无响应。联调前先确认两边的数据手册最好用逻辑分析仪抓 CLK、MOSI、MISO 三根线确认空闲电平和采样沿是否符合预期。2.3 UART 是主控的“日志口”和“帧读写口”UART 是空调嵌入式开发必须熟练掌握的一类接口。硬件上它只有 TX、RX 两根线全双工通信工作频率一般用波特率表示。空调项目里至少要保留一个 UART 做调试日志输出把协议栈状态、传感器值、错误码打印出来如果产品是 WiFi 模组或 BLE 模组主控还会用另一个 UART 和模组交换 AT 指令或透传数据。UART 本身在物理层只保证字节时序它不知道一帧命令从哪里开始、到哪里结束。所以工程上必须自定义帧协议。常见做法是规定帧头、数据长度、命令字、数据和校验和。[帧头] [帧头] [数据长度] [命令字] [数据...] [校验和] AA 55 0x02 0x01 0x00 0x??下面用状态机方式解析串口数据可以避免按中断一次处理完整帧既支持随机时间到达的字节也防止数组越界。typedef enum { WAIT_FRAME_HEADER_1, WAIT_FRAME_HEADER_2, WAIT_FRAME_LENGTH, WAIT_FRAME_DATA, WAIT_FRAME_CHECK } uart_rx_state_t; void uart_rx_state_machine(uint8_t byte, uint8_t *payload, uint8_t *len) { static uart_rx_state_t state WAIT_FRAME_HEADER_1; static uint8_t frame_len 0; static uint8_t frame_index 0; switch (state) { case WAIT_FRAME_HEADER_1: if (byte 0xAA) state WAIT_FRAME_HEADER_2; break; case WAIT_FRAME_HEADER_2: if (byte 0x55) { state WAIT_FRAME_LENGTH; } else { state WAIT_FRAME_HEADER_1; } break; case WAIT_FRAME_LENGTH: frame_len byte; frame_index 0; state WAIT_FRAME_DATA; break; case WAIT_FRAME_DATA: payload[frame_index] byte; if (frame_index frame_len) {