2.3 串口乱码与中断丢失排错实录

2.3 串口乱码与中断丢失排错实录

本节摘要：前两节分别建立了中断模型与定时器工具，这一节把它们放进一次真实排错：一台现场数据采集器同时出现串口乱码与数据缺笔，两个症状一个根源。完整走一遍从现象到根因的五步排查，途中沉淀出乱码四线排查法与中断丢失检查单——本节的目标不是给出答案，而是给出可迁移的排查路径。

这一节是第 2 章的收官：2.1 的中断丢失机理、2.2 的时钟与波特率关系，都会在这份实录里各就各位。选"乱码加丢数据"这对组合症状做案例，是因为它们在真实项目里几乎总是结伴出现——而分开看又都像"偶发玄学"，最适合演示系统化排查的威力。

两起故障，一个现场

背景：冷库温度监测节点，主控 ESP32，通过串口外挂一个 RS485 温度变送器（经收发器芯片接入），每 5 秒轮询一次温度并打印日志。现场反馈两类问题：日志串口偶尔打印乱码；温度读数每天缺笔若干次，缺笔时刻与乱码时刻大致重合。实验室复现不了，冷库零下十几度一进去就出现。

操作第一步：分类症状。乱码与缺笔谁因谁果？先假设互不相干，各查各的；若查到最后发现同源，再合并解释。乱码按四条线排：时钟线（双方波特率是否真的一致）、电平线（TTL 与 RS485 电平是否匹配）、地线（共地是否可靠）、干扰线（线缆是否引入毛刺）。

操作第二步：查时钟线。ESP32 默认主时钟源在低温下漂移极小，先量发送端波形：把日志串口 TX 接逻辑分析仪测一位宽度。115200 波特下一位应为 8.68 微秒，实测 8.70 微秒，误差 0.2%，远低于容限——发送端无嫌疑。再测接收：变送器回帧的位宽 8.9 微秒，误差 2.5%，已接近累积错位边缘，但还没有越线，记为"高度可疑，暂不定罪"。

操作第三步：查中断线（缺笔方向）。翻代码发现轮询函数是阻塞式读：发指令后循环等待回帧，超时 100 毫秒。而主循环里还有 OLED 刷新（I2C）与 SD 卡写入，一次写卡可达几十毫秒。怀疑链条成形：读温帧到达时若 CPU 正陷在 SD 写入里，串口接收缓冲区（硬件只有一两字节）溢出，字节被静默丢弃——这就是缺笔；而部分丢弃恰好发生在帧中间，残缺帧校验失败被重试，日志层面只表现为"这次读数慢了一点"，偶发的缓冲错位重同步则把中间残值打进日志——这就是乱码。

图：字节错位的采样漂移机理

操作第四步：合并验证。给接收端装上"帧完整性统计"：每次读到残帧计数加一，同时用定时器在主循环埋点，记录 SD 写入与 OLED 刷新的阻塞时长。跑一晚：乱码与残帧计数同步增长，且都集中在 SD 写入后的第一个轮询周期——因果链闭合。

操作第五步：改三层。第一层，轮询改为中断接收：串口每收一字节进缓冲，主循环按帧协议取完整帧，彻底消灭"正在忙导致丢字节"；第二层，SD 写入挪出轮询路径，改为攒批低速写；第三层，给变送器换用外部高精度时钟方案并在协议层加帧校验重传。

结果：连续运行两周，乱码零次、缺笔零次，日志延迟上限从"不确定"变为 200 毫秒。

解读：回头看两个症状的关系——接收时钟 2.5% 的误差是"体质弱点"，决定了它在边界上晃；SD 写入的阻塞是"压垮稻草"，决定了它什么时候真的出错。单看哪一条都够不成故障，两条叠加才发作。这是现场故障最常见的形态：测出来的每个单项都在合格边缘，组合起来就是事故。排查的价值不在于找出"那一个元凶"，而在于把整条链路上所有"边缘项"都拉回安全区。

变式：若你的设备乱码呈现"规律性"——比如固定在开机电平切换瞬间——方向就完全不同：多半是总线上设备上电的瞬态毛刺，解法在硬件（加瞬态抑制、延迟使能收发器）而非软件。症状的形状本身就是线索：随机乱码查时钟与阻塞，规律乱码查事件相关性。

// 中断接收 + 帧缓冲：消灭"主循环忙导致丢字节"的标准结构
#define BUF_SIZE 256
volatile char    rxBuf[BUF_SIZE];
volatile uint16_t rxHead = 0, rxTail = 0;

void setup() {
  Serial1.begin(9600);                     // 与变送器一致的波特率
  Serial1.onReceive(onRxByte, false);      // 收到数据即回调
  Serial.begin(115200);
}

// 回调里只搬字节进环形缓冲，不做任何耗时处理
void onRxByte() {
  while (Serial1.available()) {
    uint16_t next = (rxHead + 1) % BUF_SIZE;
    if (next == rxTail) return;            // 缓冲满：丢弃并等待上层消化
    rxBuf[rxHead] = Serial1.read();
    rxHead = next;
  }
}

// 主循环按帧协议取完整帧：帧尾为换行符
bool readFrame(char *out, uint16_t maxLen) {
  uint16_t n = 0;
  noInterrupts();
  while (rxTail != rxHead && n < maxLen - 1) {
    char c = rxBuf[rxTail];
    rxTail = (rxTail + 1) % BUF_SIZE;
    interrupts();
    if (c == '\n') { out[n] = '\0'; return true; }
    out[n++] = c;
    noInterrupts();
  }
  interrupts();
  return false;
}
​

代码的核心是环形缓冲：中断侧只做入队，主循环侧按帧出队，两侧用头尾指针解耦。这正是 2.1 节"服务例程只记录不加工"纪律的完整落地——实测同一段代码在 SD 写入风暴下零丢字节。

乱码四线排查法与丢失检查单

把这次实录沉淀成两张可复用的清单。乱码四线：时钟线（量位宽算误差，目标 2% 以内）、电平线（RS232 的正负电平、RS485 的差分、TTL 的 0 与 VCC，三者互不兼容）、地线（共地是串口的隐形前提，隔离收发器要跨隔离边界连参考地）、干扰线（长线、变频器旁、电机旁，先加屏蔽与终端电阻再说软件）。中断丢失检查单：接收是否走了中断缓冲？主循环最长阻塞段多长、量过吗？硬件 FIFO 多深、按数据率够撑几个主循环周期？帧协议有没有校验与重同步机制？

⚠️ 常见坑：别用"提高波特率"解决丢数据。波特率越高容错越差，阻塞丢字节的问题会从"偶尔丢"恶化成"频繁丢"。丢字节的病根是缓冲与调度，不是速度。

💡 关键直觉：串口调试不是打印日志，而是设计一条"坏消息也能完整送达"的数据通道。通道设计好了，日志本身就是诊断报告。

本节要点回顾

• 组合症状先分类再合并：乱码与缺笔分头排查，查到同源再合流解释；
• 乱码四线：时钟、电平、地线、干扰，按顺序过堂，量位宽是时钟线的量化手段；
• 缺笔的病根常在主循环阻塞：硬件接收缓冲极浅，忙过就丢，中断缓冲是标准解；
• 单项合格边缘的叠加就是事故：排查要把全链路拉回安全区，而非找一个元凶；
• 症状形状是线索：随机乱码查时钟与阻塞，规律乱码查事件相关性。