网关串口奇偶校验与帧错误：在字节流之上保留UART证据

网关如果只报告“CRC失败”或“等待响应超时”，可能已经丢掉了解释故障的关键证据。在协议解析器看见字节之前，UART也许已经检测到奇偶校验错误、字符帧错误或接收溢出。应把这些观察保留为独立诊断信息，不要把所有故障压缩成一个Modbus错误。

本文以Linux 6.6串口和TTY接口为具体实现边界，并参照Modbus串行规范V1.02。USB适配器、厂商内核及微控制器暴露的信息可能不同。下面是建议诊断设计，没有报告任何硬件实测结果。

记录实际生效的字符格式

记录波特率、数据位、校验方式、停止位、流控、控制器或适配器型号、驱动和内核构建版本。能够回读设置时，应核对生效值。设置失败或另一个进程打开端口后，界面显示、保存文件和UART当前配置可能并不一致。

串行规范第2.5.1节描述RTU使用八个数据位，默认偶校验，无校验时增加一个停止位。某产品支持八数据位、无校验、一个停止位，并不代表这就是通用规范默认值。解释错误计数前，应先按两端文档统一实际格式。

奇偶校验指示意味着按接收端配置执行的校验未通过。字符帧错误通常涉及停止位采样不符合预期。接收溢出则表示某个接收阶段没能保留全部到达数据。具体标志的含义、FIFO关联方式及读取后是否清除，必须查对应控制器手册。

它们不同于Modbus消息长度错误或CRC不匹配。校验配置错误时，可见的八位数据可能仍然看似合理；溢出可能直接丢掉字节，未必留下一个可以标注的“坏字节”。反过来，没有UART错误指示也可能出现协议失败，尤其当适配器从未暴露这类证据时。

Linux 6.6底层串口API说明，set_termios会影响读取和忽略状态掩码。INPCK决定帧错误、奇偶错误事件能否进入TTY层，IGNPAR则影响错误字符是否被丢弃。因此，同一电气输入在不同输入策略下，可能形成不同的应用可见字节。

TTY缓冲接口支持随字符传递标志，但不代表每个底层驱动都提供准确的逐字节状态。应检查当前驱动的接收路径，尤其DMA或USB状态处理。不能提供的信息应标记为不可用，不能把始终为零的计数解释为链路没有错误。

普通读取调用得到的是字节，并不是可移植的UART状态对象数组。TTY可能依据termios配置丢弃、替换或标记异常字符。PARMRK会引入标记序列，也可能转义合法的0xFF字节，具体路径见Linux v6.6 N_TTY实现。

不能打开标记后，把得到的字节流原封不动交给Modbus解析器。要么先正确解码该表示并保留关联错误信息，要么使用驱动专用诊断通道，同时明确负载处理。BREAK、输入高位剥离和软件流控也要单独检查，仅写“使用原始模式”不足以说明应用保留了哪些证据。

若驱动支持，可在限定采集窗口前后读取错误计数。Linux v6.6的serial_icounter_struct包含奇偶、帧错误、接收溢出和缓冲溢出字段，但适配器是否实现有意义的计数必须验证。接收硬件溢出与后续软件缓冲丢失应分别保留。

每个窗口记录计数增量、单调时钟时间、接收字节量、有效协议帧、CRC失败、丢弃的半帧和事务超时。注明计数宽度、重置方式及采样边界。驱动可能聚合错误，一次读状态也可能覆盖多帧；没有更强接口保证时，应表述为“此区间观察到”，而不是指定某个字节就是根因。

先以匹配设置和批准的数据源建立基线，再只改变一个参数，例如接收端校验方式。保留原配置，预测哪一层应出现证据，采集后恢复，再重复基线。不能为了让计数增加，就向生产执行器注入畸形控制流量。

逐层检查硬件或适配器状态、驱动计数、TTY表示和应用报告。伪终端可以验证标记解码器与上报逻辑，却不能证明真实UART会检测奇偶错误或溢出。同样，故意让应用读取变慢也不保证触发硬件溢出，中间缓冲可能吸收这些数据。

报告先说明串口配置及证据是否可用，再分别列出接收错误、字节变换、协议失败和事务结果。如果CRC失败增加但没有UART证据，解析器与传输原因都应保留。如果错误随受控校验失配出现、恢复后消失，就描述这次限定观察，不要断言所有现场故障都有相同原因。

这些证据用于决定下一步排查方向，不能代替电气测量、RTU时序分析或具体驱动的能力验证。