工业现场那帧“总不对”的Modbus数据，可能就卡在校验位上
去年冬天调试一条老药厂的灌装线，PLC（S7-1200）死活读不出新换的压力传感器数值——串口助手一抓包，发现所有请求帧发出去都石沉大海；示波器上看TX波形规整，RX线上却几乎没响应。折腾两天，最后发现：传感器出厂固件默认配的是奇校验，而PLC项目里写死的是偶校验。改完那一行配置，通信瞬间恢复，压力值跳动得比车间暖气还稳。
这件事让我重新翻开尘封的UART手册第3章：原来那个被我们习惯性勾选、又常常忽略的“Parity”下拉菜单，不是界面装饰，而是工业串口链路上一道沉默但锋利的守门人。
它到底在守什么？——奇偶校验不是“纠错”，是“一票否决”
先说个反直觉的事实：奇偶校验从不修复错误，它只负责当场宣布“这帧数据作废”。
就像海关抽检集装箱，不打开箱子修货，只看封条是否完好——坏了，整箱退回；完好，才放行。
它的逻辑极简：
- 发送前，硬件把8个数据位全部异或（⊕），结果为0就填校验位=0（偶校验），为1就填校验位=1（保证总“1”的个数为偶数）；
- 接收时，硬件对收到的9位（8数据+1校验）再异或一次；
- 如果结果不是0（偶校验）或不是1（奇校验），立刻拉高PE（Parity Error）标志，且不把数据放进接收缓冲区——连中断都不触发。
这意味着：
✅ 单比特翻转 → 100%检出，帧被静默丢弃；
❌ 双比特翻转 → 异或结果碰巧恢复，漏检（概率≈50%）；
⚠️ 校验位自己翻转 → 同样被检出，和数据位翻转无区别。
所以别指望它“让通信更准”，它真正的价值是：让错误变得确定、可感知、可重试。当PLC主站超时没等到响应，它知道该重发，而不是把0xFF当真实压力值去控制阀门。
（springcloud微服务课day6）)
