4、UART接口驱动开发：RS232/RS485硬件设计、波特率配置、数据帧解析
好，咱们今天聊聊UART。说实话，在嵌入式世界里，UART可能是最古老、但又最顽强的接口之一。我做了十几年RFID读写器开发，几乎每个项目都离不开它。你想想看，从最简单的串口调试，到工业现场的长距离通信，UART的身影无处不在。
这一章，我重点讲三个东西：RS232和RS485的硬件设计差异、波特率怎么配才稳、以及数据帧解析的那些坑。嗯，都是实战中反复踩过的雷。
4.1 RS232 vs RS485：硬件设计上的选择
很多新手会问：RS232和RS485，不都是串口吗？有什么区别？
区别大了去了。我简单给你捋一捋。
| 特性 | RS232 | RS485 |
|---|---|---|
| 传输方式 | 单端（不平衡） | 差分（平衡） |
| 最大距离 | 约15米 | 约1200米 |
| 节点数 | 1对1 | 最多256个节点 |
| 电压范围 | ±3V ~ ±15V | ±1.5V ~ ±6V |
| 常用芯片 | MAX232, SP3232 | MAX485, SP3485 |
我个人习惯，如果是板级调试、或者短距离连接PC，直接用RS232。但如果是工业现场、多台RFID读写器组网，那必须上RS485。
关键点：RS232是负逻辑，RS485是差分信号。千万别搞混了电平转换芯片的选型。
4.2 硬件设计中的几个细节
我记得有一次，一个同事画的RS485电路，收发控制脚直接接地了。结果呢？只能收不能发，查了半天。这种低级错误，其实很常见。
这里我列几个硬件设计的要点：
- RS232的电荷泵电容：MAX232这类芯片需要外接4个电容，通常是1μF。位置要尽量靠近芯片，不然电压泵不上去。
- RS485的终端电阻：长线传输时，在总线两端各加一个120Ω电阻。我见过有人加了4个，结果信号衰减得厉害。
- TVS管保护：工业环境里，静电和浪涌是常客。在A、B线上对地加TVS管，能省很多维修的麻烦。
- 收发控制脚：RS485是半双工，RE和DE脚要一起控制。我习惯用一个GPIO同时控制，省引脚。
我的小技巧：RS485的A线接上拉电阻（约4.7kΩ），B线接下拉电阻。这样在总线空闲时，能保证一个确定的高电平状态，避免误触发。
4.3 波特率配置：不是越快越好
波特率，说白了就是每秒传多少位。常见的值有9600、19200、115200等等。
但这里有个误区：很多人觉得波特率越高越好。其实不是。波特率越高，对时钟精度要求越高，抗干扰能力也越差。
我在一个RFID项目中，用了115200bps，结果在强电磁干扰环境下，数据经常出错。后来降到38400bps，问题就解决了。你想想看，稳定比速度重要得多。
配置波特率时，要注意以下几点：
- 时钟源精度：MCU的主频误差要在±1%以内，否则波特率会漂。
- 分频计算：以STM32为例，波特率 = 时钟频率 / (16 × USARTDIV)。USARTDIV要取整，否则会有误差。
- 自动波特率检测：有些RFID模块支持这个功能。但我建议，除非必要，还是手动固定波特率更可靠。
避坑指南：我曾经遇到过，两个设备波特率标称都是9600，但一个用8MHz晶振，一个用12MHz晶振，结果就是通信不上。后来用示波器一量，实际波特率差了3%。所以，同频晶振很重要。
4.4 数据帧解析：从字节到协议
UART的数据帧，通常包含：起始位（1位）、数据位（5~8位）、校验位（可选）、停止位（1~2位）。
但真正麻烦的，不是物理层，而是协议层的解析。RFID标签的数据，往往是一帧一帧的，有头有尾，中间是数据。
我常用的解析方法是状态机。举个例子：
// 简单的数据帧解析状态机
typedef enum {
WAIT_HEADER,
WAIT_LENGTH,
WAIT_DATA,
WAIT_CHECKSUM
} FrameState;
FrameState state = WAIT_HEADER;
uint8_t buffer[256];
uint8_t index = 0;
uint8_t expected_length = 0;
void UART_RxCallback(uint8_t byte) {
switch(state) {
case WAIT_HEADER:
if(byte == 0xAA) { // 帧头
state = WAIT_LENGTH;
index = 0;
}
break;
case WAIT_LENGTH:
expected_length = byte;
state = WAIT_DATA;
break;
case WAIT_DATA:
buffer[index++] = byte;
if(index >= expected_length) {
state = WAIT_CHECKSUM;
}
break;
case WAIT_CHECKSUM:
// 校验和验证
uint8_t checksum = 0;
for(int i = 0; i < expected_length; i++) {
checksum += buffer[i];
}
if(checksum == byte) {
// 数据帧有效，处理数据
ProcessFrame(buffer, expected_length);
}
state = WAIT_HEADER;
break;
}
}
这个状态机看起来简单，但实际项目中，要考虑超时、错误恢复、缓冲区溢出等问题。我建议你加上一个超时定时器，如果超过一定时间没收到完整帧，就重置状态机。
核心思路：数据帧解析，本质上是把字节流还原成有意义的协议单元。状态机是最清晰、最不容易出错的方式。
4.5 实战中的几个常见问题
最后，我总结几个我在项目中遇到过的典型问题：
- 丢字节：中断服务程序里处理时间太长，导致下一个字节丢失。解决办法：用DMA或者环形缓冲区。
- 波特率不匹配：两个设备波特率设置不一致，但偶尔能通。这种情况最坑，因为时好时坏。一定要用示波器确认。
- RS485的收发切换：发送完最后一个字节后，不能立刻切到接收模式。要等移位寄存器清空。我习惯加一个1ms的延时。
- 接地问题：RS232的GND一定要连，否则通信不稳定。RS485虽然差分，但共模电压过高也会出问题。
嗯，这一章的内容就这些。UART看似简单，但真正做好，需要硬件和软件一起配合。下一章，我们会讲SPI接口，那又是另一番天地了。
课后建议：拿一个RFID读写器模块，用示波器抓一下UART波形。看看起始位、数据位、停止位长什么样。相信我，看过波形之后，你对UART的理解会上一个台阶。