当前位置：首页 > news >正文

别再傻傻分不清！用UART、SPI、CAN这些协议实例，5分钟搞懂同步/异步与单/双工

news 2026/6/17 22:42:03

嵌入式通信协议实战指南：从UART到CAN的同步/异步与单/双工解析

引言

在嵌入式系统开发中，通信协议的选择直接影响着系统性能和可靠性。面对数据手册中"全双工同步"、"半双工异步"等专业术语，不少开发者容易陷入概念混淆的困境。本文将通过UART、SPI、I2C、CAN四种典型协议的实际应用场景，带您快速掌握这些核心概念的本质差异。

想象一下这样的场景：当您需要为智能家居设备选择通信方案时，是采用简单的UART还是更复杂的SPI？汽车电子系统中为何普遍使用CAN总线而非其他协议？这些选择背后都涉及到对通信方式特性的深刻理解。我们将从硬件连线、时序波形到代码配置，全方位解析这些协议的工作机制。

1. 同步与异步：时钟信号的奥秘

1.1 同步通信的典型代表：SPI协议

SPI(Serial Peripheral Interface)是典型的同步串行通信协议，其核心特征是通过专用时钟线(SCLK)保持收发双方的严格同步。在STM32的SPI配置中，时钟极性(CPOL)和时钟相位(CPHA)这两个参数决定了数据采样的精确时机：

// STM32 SPI初始化示例 SPI_HandleTypeDef hspi1; hspi1.Instance = SPI1; hspi1.Init.Mode = SPI_MODE_MASTER; hspi1.Init.Direction = SPI_DIRECTION_2LINES; hspi1.Init.CLKPhase = SPI_PHASE_1EDGE; // CPHA=0 hspi1.Init.CLKPolarity = SPI_POLARITY_LOW; // CPOL=0 hspi1.Init.DataSize = SPI_DATASIZE_8BIT; HAL_SPI_Init(&hspi1);

同步通信的优势在于其高效率的数据传输。以SPI为例，其传输速率可达数十MHz，远高于常见的异步协议。这是因为：

无需起始/停止位等开销
时钟信号确保精确采样
支持全双工同时收发

提示：在高速SPI通信中，布线长度应控制在时钟周期的1/10波长以内，避免信号完整性问题。

1.2 异步通信的实践案例：UART协议

UART(Universal Asynchronous Receiver/Transmitter)采用典型的异步通信方式，最显著的特点是通信双方各自使用独立的时钟源。这种设计带来了布线简单的优势（只需TX/RX两根线），但也引入了波特率匹配的要求：

参数	典型值	重要性
波特率	9600,115200等	双方必须严格一致
数据位	5-9位	决定单次传输数据量
停止位	1,1.5,2位	帧间隔标识
校验位	奇/偶/无校验	简单错误检测机制

在Linux系统中配置UART参数的示例命令：

stty -F /dev/ttyS0 115200 cs8 -cstopb -parenb

异步通信的灵活性使其在以下场景中表现优异：

远距离通信（RS-485可传输千米级）
不同时钟域的设备互联
对实时性要求不高的应用

2. 单工、半双工与全双工的实际应用对比

2.1 全双工的极致表现：SPI通信

SPI协议通过独立的MOSI和MISO线路实现真正的全双工通信。在读取传感器数据时，主设备可以同时发送下一个命令字，这种"乒乓操作"极大提高了吞吐量。以读取加速度计数据为例：

uint8_t txBuf[2] = {0x80 | REG_X_H, 0x00}; // 读命令+空字节 uint8_t rxBuf[2]; HAL_SPI_TransmitReceive(&hspi1, txBuf, rxBuf, 2, 100); // rxBuf[1]包含X轴数据

全双工通信的硬件代价是需要更多信号线（标准SPI需要4线），这在引脚资源紧张的MCU上可能成为制约因素。

2.2 半双工的经典实现：I2C协议

I2C协议仅用两根线（SDA和SCL）就实现了多设备组网能力，这得益于其精妙的半双工设计：

时钟由主设备控制
每个设备有唯一地址
严格的仲裁机制避免冲突

典型的I2C读取EEPROM的流程：

开始条件 → 发送设备地址(写) → 发送内存地址 → 重复开始条件 → 发送设备地址(读) → 读取数据 → 停止条件

注意：I2C总线的上拉电阻取值很关键，通常为1.8KΩ-10KΩ，需根据总线电容计算。

2.3 单工通信的特殊应用：CAN总线

虽然CAN协议本质上是半双工的，但其广播特性在某些场景下呈现单工特征。例如在汽车电子中，发动机控制单元定期发送转速数据，各接收节点只监听不回复：

CAN_TxHeaderTypeDef txHeader; txHeader.StdId = 0x201; // 发动机转速报文ID txHeader.RTR = CAN_RTR_DATA; txHeader.IDE = CAN_ID_STD; txHeader.DLC = 2; // 数据长度 uint8_t data[2] = {rpm >> 8, rpm & 0xFF}; HAL_CAN_AddTxMessage(&hcan, &txHeader, data, &txMailbox);

这种设计确保了关键信息的可靠传播，即使某些节点出现故障也不影响整个系统。

3. 协议选择的实战指南

3.1 速率与距离的权衡

协议	典型速率	有效距离	适用场景
SPI	1-50Mbps	<0.5m	板级高速通信
I2C	100-400Kbps	<1m	低速外设管理
UART	300-3Mbps	<15m(RS232)	调试接口/简单互联
CAN	125K-1Mbps	<1000m	汽车/工业抗干扰通信

3.2 硬件资源考量

在STM32F103系列MCU上实现不同协议的资源占用对比：

SPI
- 专用硬件外设
- 最少4个GPIO
- DMA支持提升效率
I2C
- 专用硬件外设
- 2个GPIO
- 需处理总线冲突
UART
- 专用硬件外设
- 2个GPIO
- 简单流控可选
CAN
- 专用控制器
- 需要收发器芯片
- 复杂错误处理机制

3.3 错误处理能力比较

SPI：无内置错误检测，依赖应用层校验
I2C：简单的ACK/NACK机制
UART：可选奇偶校验
CAN：完善的CRC校验+重传机制

4. 混合应用案例：智能家居网关设计

4.1 系统架构设计

一个典型的智能家居网关可能组合使用多种通信协议：

[WiFi模块] ←UART→ [主MCU] ←SPI→ [显示模块] ↑ I2C ↓ [传感器集线器] ←CAN→ [安防子系统]

4.2 协议桥接实现

在不同协议间转换时需特别注意：

速率匹配：设置适当的缓冲区和流控
数据格式转换：处理端序和单位差异
超时处理：适应不同协议的响应时间

示例：将CAN报文转换为UART数据帧

void CAN_to_UART(CAN_RxHeaderTypeDef *header, uint8_t *data) { uint8_t uartBuf[13]; uartBuf[0] = '$'; // 帧头 memcpy(&uartBuf[1], &header->StdId, 2); uartBuf[3] = header->DLC; memcpy(&uartBuf[4], data, 8); uartBuf[12] = checksum(uartBuf, 12); HAL_UART_Transmit(&huart1, uartBuf, 13, 100); }