4、通信参数校验：波特率、数据位、停止位、校验位一致性检查，超时与重试机制设置

通信参数校验，说白了就是让主站和从站「说同一种语言」。

我见过太多现场问题，最后查出来就是两边参数没对上。你想想看，一个说中文一个说英文，能聊到一块去吗？串口通信也是这个道理。

4.1 四大通信参数：一个都不能错

串口通信有四个核心参数，我习惯叫它们「四件套」：

• 波特率（Baud Rate）：每秒传输的符号数。常见的有9600、19200、115200。
• 数据位（Data Bits）：每个数据包实际承载的数据位数。通常是7位或8位。
• 停止位（Stop Bits）：数据包结束的标志位。一般是1位、1.5位或2位。
• 校验位（Parity Bit）：用于检错的附加位。可选无校验、奇校验、偶校验。

这四个参数，主站和从站必须完全一致。哪怕波特率差一点点，数据都会变成乱码。

4.2 参数不匹配的典型症状

我在项目中遇到过好几次这样的场景：设备能连上，但数据全是乱码。或者偶尔能收到正确数据，大部分时间都是错的。

为什么会这样？说白了就是参数没对上。我总结了几种常见情况：

参数不匹配	典型现象	我的排查经验
波特率不一致	完全收不到数据，或收到乱码	先看示波器波形，数一下位宽
数据位不一致	数据能收到，但字节错位	用串口助手对比收发数据
停止位不一致	偶尔丢包，通信不稳定	检查帧间隔，看停止位长度
校验位不一致	数据能收到，但校验错误频繁	查看错误计数器，看CRC或奇偶校验

4.3 超时机制：别让程序死等

通信不是每次都成功的。线路干扰、从站忙、主站发太快……各种原因都可能导致数据丢失。

如果没有超时机制，程序就会卡在「等待回复」这一步。我见过一个案例，现场工程师没设超时，结果从站掉线后，主站直接死机了。

超时设置有两个关键点：

• 接收超时：主站发完请求后，等多久算超时？我一般设50ms~200ms，具体看波特率和数据长度。
• 帧间隔超时：两个字节之间最大间隔。超过这个时间，就认为一帧结束了。Modbus协议里常用3.5个字符时间。

4.4 重试机制：一次不行就再来一次

超时之后怎么办？直接报错？还是再试一次？

我的建议是：先重试，再报错。很多通信失败是偶发性的，重试一次就能成功。

重试机制的几个要点：

1. 重试次数：一般设3次。太多会拖慢系统，太少又不够。
2. 重试间隔：每次重试之间等多久？我习惯用递增间隔：第一次等100ms，第二次等200ms，第三次等400ms。避免连续重试把网络打爆。
3. 重试策略：是重新发请求，还是先检查一下线路？我个人建议先检查从站状态，再决定是否重试。

4.5 实战配置示例

下面是一个典型的Modbus RTU通信参数配置。嗯，这里要注意，不同厂家的设备可能叫法不一样，但本质是一样的。

// 主站通信参数配置示例
typedef struct {
    uint32_t baudRate;      // 波特率：9600, 19200, 115200
    uint8_t  dataBits;      // 数据位：7或8
    uint8_t  stopBits;      // 停止位：1或2
    uint8_t  parity;        // 校验位：0=无, 1=奇校验, 2=偶校验
    uint16_t timeoutMs;     // 接收超时：毫秒
    uint8_t  retryCount;    // 最大重试次数
    uint16_t retryInterval; // 重试间隔：毫秒
} CommParams_t;

// 推荐配置
CommParams_t params = {
    .baudRate = 9600,
    .dataBits = 8,
    .stopBits = 1,
    .parity   = 0,          // 无校验
    .timeoutMs = 100,
    .retryCount = 3,
    .retryInterval = 200
};

4.6 知识体系总览

下面这张图是我自己画的，把通信参数校验的核心逻辑串起来了。你一看就明白。

这张图把整个流程串起来了。你从主站出发，先校验参数是否一致，然后设置超时保护，最后配置重试策略。每一步都不能少。