Nicholas Qin1. 先从一次跑飞的通信开始
做嵌入式或者数据通信的朋友，大概率都遇到过这种场景：树莓派通过串口给STM32发一帧传感器指令，程序逻辑看起来一点问题没有，波特率也对，电平也匹配，但接收端时不时就收到一两个错字节——轻则控制量抖一下，重则整个系统状态机直接跑飞。你对着逻辑分析仪翻过来覆过去查了半天，硬件上该查的都查了，最后才发现问题根本不在硬件，而在数据传输过程中缺了“差错控制”这一层。
差错控制这个词听起来像教科书里的理论概念，但它本质上就是个非常朴素的问题：数据在传输或者存储的过程中，怎么确认它没被改坏？怎么在改坏之后把它恢复回来？无论是树莓派和STM32之间的串口帧，还是硬盘里存的一张照片，还是你在网上下载的一个固件包，底层都离不开这套机制。这篇文章不打算给你堆公式，而是用实际能落地的思路，把差错控制的核心技术、实现方法、常见坑位一次说清楚。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 差错控制到底在解决什么问题
2.1 数据在传输和存储中为什么会出错
数据在信道里跑，本质上是电信号、光信号或者电磁波在物理介质上传播。只要信号穿过铜线、PCB走线、光纤、空气，就会受到各种干扰。干扰的来源五花八门：电机启停带来的电磁脉冲、电源纹波耦合、长线缆上的串扰、阻抗不匹配导致的反射、甚至太阳耀斑引起的宇宙射线翻转。这些干扰作用到信号上，轻则让接收端采样到的电平发生偏移，重则直接把一个bit从0翻成1。
存储系统也一样。固态硬盘的NAND闪存靠浮栅电荷来保存数据，电荷会随着时间泄漏；机械硬盘的磁记录层也会因为磁场扰动发生翻转；内存颗粒里的电容会漏电，需要定时刷新。哪怕你什么都不做，数据放在那儿也会慢慢“变质”。更别说写入过程中控制器本身的异常、掉电瞬间的读写操作，都可能在存储介质上留下错误的数据。
这个问题在数字世界里被归结为一个模型：发送端发出去一个码字，经过信道/存储介质，接收端拿到的可能是另一个码字。差错控制要做的，就是让接收端有能力判断“拿到的东西是不是发出来的东西”，以及更进一步——“如果不是，能不能自己把它改回来”。
2.2 差错控制的三条路线
差错控制的实现思路基本可以分成三类，理解这三类，后续看任何协议里的具体实现都会非常通透。
第一类是检错重传，英文缩写ARQ。接收端只负责检查收到的数据有没有错，发现错了就丢弃并让发送端重发。它的前提是信道得有一条反向通路，而且延时不能太大。TCP协议里的校验和加上ACK重传机制，就是典型的ARQ。
第二类是前向纠错，英文缩写FEC。发送端在原始数据上附加足够多的冗余信息，接收端收到后即使出现一定数量的错误，也能直接解算出原始数据，不需要重传。深空通信、卫星广播、光盘存储都用这种方案，因为在这些场景里反向通路要么没有，要么往返延时太长，重传根本不现实。
第三类是混合纠错，英文缩写HARQ。先做前向纠错，纠不过来的时候再请求重传。4G/5G通信里的物理层重传机制就是HARQ。中继节点会把没解出来的数据缓存下来，收到重传版本后和旧数据合并解码，而不是简单地丢弃重来。
这三条路没有绝对的优劣，关键看应用场景。实时性要求高、反向通道代价大的场景，优先考虑FEC；信道质量好但偶尔突发错误、重传代价低的场景，ARQ更简单高效。做树莓派和STM32这种短距离板级通信，串口或者SPI上最常见的做法就是CRC检错加重传，因为我没法在你面前画一个协议站的框图，但是思路就是ARQ。你要是觉得这还不够，回头往下看实操部分，我会把整个流程讲透。
3. 那些常用的差错控制技术
3.1 从最简单的奇偶校验说起
奇偶校验是计算机体系结构里最古老也最基础的检错手段。它的做法很简单：在数据后面附一个bit，让整个码字里“1”的个数保持为奇数（奇校验）或偶数（偶校验）。接收端数一下1的个数，和校验位比对一下就知道有没有错。
但它有个天然的缺陷——只能检测奇数个bit的错误，偶数个bit同时翻转就会漏检。比如数据里有两位同时被干扰翻转，校验位算出来还是一样的，错误就被完美掩盖了。实际工程里，噪声脉冲经常打翻连续的好几个bit，奇偶校验在这种场景下的漏检率相当可观。所以它现在主要用在内存条的ECC计算里作为辅助手段，或者一些极低速、对成本极其敏感的场合，一般不建议作为数据通信的主力检错方案。
3.2 校验和：协议栈里的常见脸孔
校验和的思路是把数据按一定的字长（比如16位）切分成多个段，然后逐段累加，最后的累加结果取反作为校验值。IP协议头里的Header Checksum、UDP的Checksum、ICMP的校验和，用的都是这个思路。
实现起来极其简单，资源占用也少，但它和奇偶校验一样有个问题：如果数据里多个字节同时发生变化而累加结果恰好不变（比如两个字节交换位置），校验和就检测不出来。所以校验和通常用在协议头或者对可靠性要求不苛刻的场合，作为第一层快速过滤。真正传大量业务数据的时候，协议栈底层还是会用更强的CRC来兜底。
3.3 CRC循环冗余校验：工程界的绝对主力
CRC是数据通信和存储系统里应用最广的检错算法，名字叫“循环冗余校验”，核心思想是把数据看作一个大整数，用约定的生成多项式做模2除法，得到的余数就是CRC校验值。接收端用同样的多项式去除，余数不为零就说明数据被改动了。
CRC的检错能力是有理论保证的，懂行的人都知道选对多项式有多重要。它能检出所有奇数个错误bit、所有长度不超过生成多项式阶数的突发错误、以及绝大多数更长的突发错误。比如CRC-32可以100%检出长度不超过32bit的突发错误，而对于更长的突发错误，漏检率只有2的负32次方级别。这在工程上是完全可以接受的。
我平时做嵌入式通信，最常用的是CRC-8和CRC-16，传输的数据量不大，选16位多项式就够了。如果是PC端或者上位机传大文件，直接上CRC-32，比如ZIP文件、以太网帧尾的FCS用的就是CRC-32。需要注意的是，同样叫CRC-16，不同协议用的多项式、初始值、输入输出反转规则可能都不一样，代码之间不能随便替换，否则校验结果对不上。这块最容易踩坑，后面我会详细说。
3.4 汉明码和ECC内存：数据存储的守护神
汉明码是一种能够纠错的编码，它通过在数据位之间插入多个校验位，让每个校验位覆盖不同的数据位组合，接收端根据校验结果可以定位出错bit的位置并直接翻转纠正。对于数据存储这类读写时错误稀少的场景，单bit纠错能力已经非常实用。
内存条的ECC功能就是基于这个原理。普通非ECC内存里存的数据如果发生bit翻转，系统完全不感知，直到程序读到一个怪值才可能崩溃。而ECC内存在每个存储块后面附带额外的纠错码，当读取时发现某一位翻转了，控制器可以直接修正，系统照常运行。对于服务器、数据库、长时间运行的边缘计算设备来说，这个能力非常关键。你可能觉得内存出错是小概率事件，但在大型数据中心里，内存错误的发生频率远比你想象的高，多少不明原因的宕机最后查下来都是内存bit翻转导致的。
3.5 更高级的纠错编码：卷积码、RS码和LDPC
如果你的数据要穿过一个噪声很大的信道，或者要存到一块寿命接近极限的闪存里，简单的CRC加汉明码就不够用了。这时候需要更强的前向纠错编码。
卷积码适合随机错误比较多的信道，Viterbi译码算法在工程里非常成熟。RS码（里德-所罗门码）擅长应对突发错误，光盘上的划痕、QR码上的污渍，都是靠RS码的纠错能力兜住的。LDPC码是近十几年的明星，性能逼近香农极限，固态硬盘的控制器和5G通信的物理层都在用。不过这些编码的编码译码复杂度都不低，用软件实现会很吃力，一般都在硬件模块里跑。
对我们做树莓派和STM32通信来说，这些编码通常用不上，因为无线串口模块本身的调制解调就做了大量信道编码。但如果你做的是远距离无线传输、或者需要把数据发给卫星（当然大多数人不做这个），这些编码就需要认真考虑了。知道它们的存在和适用场景，看协议文档的时候就不会一脸懵。
4. 实操：树莓派和STM32数据通信的差错控制实现
4.1 通信场景与硬件选型
我做这个项目的时候用的是树莓派4B作为上位机，STM32F103作为下位机，两者之间采用UART串口通信，同时也测试过SPI总线。之所以选UART，是因为大部分工控场景下串口是最稳妥的点对点方式，线缆也长，而且干扰最明显，非常适合用来演示差错控制的作用。
硬件连接我踩过不少坑，有几个细节必须提醒一下。树莓派的GPIO是3.3V电平，STM32F103的IO口基本兼容3.3V，但如果你用5V供电的STM32系列，必须做电平转换，否则大概率烧IO口。串口通信的地线必须共地，如果两个板子分别供电而地不连在一起，会出现电平基准不一致导致的乱码，而且这种乱码你用示波器看波形还看不出明显异常。树莓派的UART默认终端可能被系统占用，要在/boot/config.txt里做配置，或者通过引脚复用切到其他UART口，否则你发出去的数据可能有系统日志混进来。
4.2 协议帧设计：加CRC校验
串口通信最容易出的问题就是帧同步错乱。如果只是简单地在数据之间加个分隔符，一旦某个字节传错，整个帧就废了。我的做法是设计一个带帧头、长度、数据和CRC的协议帧。帧头用两个固定字节比如0xAA 0x55，用来做起始同步；长度字段告诉接收端这一帧数据区有多少字节；数据区放实际业务数据；最后两位放对整帧（从帧头到数据区结束）计算出的CRC16校验值。接收端先找帧头，再按长度字段收完整个帧，最后校验CRC，校验不通过就丢弃并请求重发。
这样设计有几个好处。首先，帧头能够快速恢复同步，即使前一帧丢了一部分，下一帧只要帧头还能被识别，接收机就能重新对齐。其次，CRC校验覆盖整帧，即使帧头的同步字节被干扰改成了别的值，也能通过不匹配被丢弃，不会把噪声当成有效数据。最后，长度字段让接收端知道该等多少字节，避免把后面所有数据都当成垃圾。
CRC16多项式我选了常用的0x8005（即X16+X15+X2+1）标准CRC-16，计算代码用查表法实现，在STM32上跑没有问题。查表法的原理是预先把256种输入组合对应的CRC值算好存成数组，计算的时候每个字节直接查表，再把结果和当前CRC寄存器做异或和移位操作。这样比逐bit硬算快一个数量级，代码也很好写。为了更好地区分各种协议，还可以在配置里定义初始值、结果异或值以及输入输出是否反转，初学的时候建议先不要动这些配置，等理解透了再按需要调整。
4.3 重传机制：超时重发还是立即重发
CRC能检错，但检出错之后怎么办，这是协议设计里必须想清楚的问题。我的实现比较简单，采用停止等待ARQ：发送端发完一帧后不立刻发下一帧，等接收端返回ACK表示收到且CRC校验通过；如果校验失败就返回NACK；如果发送端在指定时间内没有收到任何回复，就超时重发。ACK和NACK本身也要套同样的帧格式和CRC保护，否则应答帧一旦被干扰，发送端会以为接收端没收到，造成重复发送。
重传参数需要根据波特率和帧长度来估算。假设波特率115200，每秒大约能传11520字节。如果一帧总长是30字节，那么发送一帧大约需要2.6毫秒，加上接收端处理时间和空中的传输延迟，我设置了10毫秒的超时窗口，连续重传次数上限设为3次。为什么是3次不是无限次？因为如果链路质量差到连续三次都传错，重传再多也只是增加无效流量，这时候应该上报链路异常，让上层决定是降低波特率还是切换通信介质。实测下来，在正常的室内环境下这个策略很稳定，偶尔一次干扰都能在重传一次后恢复。
当然，停止等待ARQ的效率偏低，如果通信双方要连续传大量数据，可以考虑滑动窗口ARQ：发送端一次性发出多帧，接收端只回复最后收到的连续帧序号，发送端只需要重发出错的帧之后的所有帧。这个机制在TCP协议里比比皆是，做嵌入式通信时你可以先想清楚自己确实需要多高的吞吐量，再决定是否引入窗口机制，不要一上来就搞复杂协议。
4.4 实测效果对比：不加校验和加校验的对比
我在程序里特意做了一个开关，可以临时关闭CRC校验，再把同样的数据反复发1000帧，统计接收端的错误帧数。不加校验的情况下，在电机启动瞬间或继电器吸合时，1000帧里能统计到几帧到几十帧的错误，而且错误经常是连续好几位被干扰。开了CRC加重传逻辑之后，同样条件下整体通信的差错率基本为0，偶尔出现的错误帧也被重传机制自动消化掉了。
这个对比其实说明了一个很重要的道理：差错控制不是为了“理论上好看”，而是真正能让系统从“偶尔跑飞”变成“稳定运行”的关键。在工业现场，电磁环境远比实验室复杂，一个控制器如果连自己收到的数据是否正确都不知道，那你对它发出去的每一帧控制指令都应该打个问号。这也是为什么所有工业总线协议，像Modbus、CANopen、Profibus，都把CRC或类似机制当作标配的原因。
4.5 SPI总线上的差错控制补充
树莓派和STM32之间还可以用SPI通信，速率比UART高很多，很多人觉得SPI是同步协议，主机和从机共享时钟，所以不会出错。这个想法是个误区。SPI虽然有自己的时钟线，但长走线、电源干扰、时序偏移同样会引入采样错误，而且SPI协议本身没有内建校验机制，连帧格式都得自己定义。如果你用SPI传一屏大尺寸LCD的图像数据，偶尔花屏，大概率就是SPI链路上没有差错控制导致的。
我的建议是，SPI通信的场景里至少加一个简单的校验字，或者干脆对每个帧用CRC-16做保护。不要因为速率高就忽略可靠性，速率越高，单位时间内出错的影响范围越大。当然了，SPI的重传机制和UART类似，主机可以通过片选和状态标志来触发重发，只是从机需要多暴露一个“收到坏帧”的状态位，方便主机知道该重发。
5. 存储系统里的差错控制怎么落地
5.1 从文件复制到RAID阵列
存储系统和通信链路在差错控制上的逻辑高度一致，只是把“传输信道”换成了“存储介质”。你在电脑上复制一个文件，操作系统会做校验吗？如果你只是靠复制完成后“看上去大小一样”来判断文件没问题，那你就默认相信了硬盘控制器不会静默写错数据。大多数消费级硬盘没有端到端的校验能力，所以复制完大文件之后，偶尔做一次hash校验其实是值得的，尤其是固件、数据库备份、照片原片这些重要的东西。
RAID技术是存储系统里差错控制思想最集中的体现。RAID 1把同一份数据同时写两块盘，相当于一种空间上的“重传”——一块盘坏了直接用另一块。RAID 5在多个盘之间分布数据和奇偶校验块数据，任意坏一块盘都能靠剩余数据和校验信息把数据重新算出来。从差错控制的角度看，RAID就是联合了FEC和冗余存储的一套完整方案，它的核心是用空间换可靠性。
5.2 ECC内存值不值得上
做服务器或者长时间跑数据的边缘计算设备时，我的建议是优先考虑ECC内存。虽然ECC内存比普通内存略贵，而且需要匹配的主板和CPU支持，但对于要连续运行几十天甚至几个月的系统来说，一次未被发现的内存bit翻转就可能引起进程崩溃、数据写坏、甚至内核panic。这种发生在底层的错误，排查起来极其困难，往往最后只能用“重启大法”解决，过几天又复发。
我自己用过带ECC的服务器在高压测试环境下跑数据采集，连续两周内存错误记录里出现过几次单bit错误修正事件。这意味着如果没有ECC，那几次事件可能已经悄无声息地污染了采集数据。很多做数据分析的人认为处理结果错了是算法的问题，其实源头可能在内存这一层。ECC的本质就是汉明码在存储领域的工程实现，它把单bit错误从“不可见”变成“可见且可控”，这个价值在实际生产里是无法估量的。
5.3 文件系统和校验工具的使用
除了硬件层面的ECC和RAID，软件层面的校验工具也应该成为日常习惯。每次给板子烧完固件，养成先比对文件哈希的习惯，确认固件文件在网络传输或者拷贝过程中没有被改坏。用树莓派给STM32传输固件升级包的时候，我习惯在升级包末尾附上CRC32或者SHA256的摘要，STM32收到后先算摘要，校验通过才允许进入bootloader擦写流程。如果摘要不匹配，直接拒绝升级，这个做法能避免大量“刷砖”问题。
有一些文件系统本身就支持校验和，比如ZFS和Btrfs，它们会为每个数据块存储校验和，读取时校验不通过就从冗余副本恢复。你在自己设计嵌入式存储方案时也可以借鉴这个思路：关键配置数据在Flash里保存两份，一份为主数据，一份为备份，每次读出来都做CRC校验，如果主数据错就用备份恢复，同时记录一条错误日志。这比单纯相信Flash不会坏要靠谱得多。
6. 排查技巧：当差错控制“失灵”的时候
6.1 CRC计算不一致问题
很多人自己实现了CRC校验，发现通信两端算出来的值对不上，第一反应是数据传错了，但排查了半天发现经常是代码实现的问题。最典型的坑是多项式、初始值或结果异或值设置不一致。同样是CRC-16，Modbus用的多项式是0x8005、初始值0xFFFF、结果还要做异或；而某些自定义协议可能用0x1021、初始值0x0000、不做异或。两端只要有一项配置不同，即使原始数据完全相同，算出来的结果也完全不同。
我建议在调试时先在发送端和接收端分别写一个自测函数，用同一组已知测试数据（比如字符串“123456789”）计算CRC值，和公开的CRC校验工具网站对比结果。如果两边计算的结果都一致，再连到通信链路上测。这样可以快速排除CRC实现层面的问题。另外切记，CRC的初始值不是0就是0xFFFF，查表法和逐bit法只是实现不同，结果必须一致，不要因为结果不同就怀疑表算错了，通常还是初始值、反转、多项式这几个参数的锅。
6.2 噪声导致大量重传怎么办
如果通信环境很差，CRC检错确实能发现问题，但如果频繁重传，系统的实时性会受到很大影响。这时候单纯调大重传次数上限是没有意义的，必须从源头排查。先看硬件接线：地线是否共地、信号线是否远离强电和电机线缆、线缆是否用带屏蔽层的类型且屏蔽层是否单端接地。再看软件参数：波特率能否降下来，降低波特率在低速现场往往是立竿见影的，因为低速时每个bit的占空比更宽、抗干扰能力更强。最后看数据帧设计：能否减小帧长度，长帧在受到脉冲干扰时更容易出错，拆成短帧传输虽然会增加协议开销，但重传代价也小得多。
我之前遇到过一种情况：继电器每次吸合，通信立刻出现一批错误帧。查下来发现继电器的线圈和通信线缆在同一个线槽里走了十几米，线圈断电瞬间产生的反向电动势通过线缆耦合进来。解决措施是给继电器线圈并联续流二极管，同时把通信线缆移出线槽，重新测试后错误帧数量明显下降。差错控制不是万能的，硬件设计上的基础防护永远不能省。
6.3 如何判断是发送端还是接收端出错
如果CRC校验频繁失败，排查的时候必须分清楚是发送端本身就算错了，还是接收端算错了，还是链路把数据弄坏了。一个高效的办法是在发送端回环测试：把发送端发出的数据直接接回自己的接收引脚，看能不能通过校验。如果回环也失败，说明问题大概率在发送端代码或硬件；如果回环成功，再断开通路、接上接收端，做完整的链路测试。利用STM32和树莓派的串口工具可以很方便地完成这种回环测试。
还有个经验是，在调试过程中把原始接收数据包和CRC校验值一起打印出来，这样即使校验失败也能直接看到数据哪里被改动了。比如原本应该收到0x01的位置变成了0x81，那就可以推断是最高位的电平被干扰拉高了。有了现场数据再做分析，比拍脑袋猜要高效得多。
6.4 工具推荐
调试串口通信差错的工具里，逻辑分析仪是我目前最推荐的，它比示波器便宜，用来抓UART、SPI时序非常直观。抓下来的波形可以按协议解析出字节内容，能看到数据在哪一个bit上发生了畸变。如果你用的是树莓派，还可以直接用Python的pyserial库做脚本化的通信测试，自动发大量帧、统计出错率、打印错误详情，比手动发包高效得多。我之前就把这些统计脚本集成到一个简单的控制台工具里，跑一晚上就能拿到一份完整的链路质量报告。
7. 写给后来人的几点实在建议
做了几个项目之后，我对差错控制最大的感受是：它不只是一个算法，更是一种设计思维——永远假设数据可能会坏，然后在每一层都留一手。做通信协议时先想清楚有没有CRC，做存储方案时先想清楚有没有冗余和校验，做系统架构时先想清楚如果某条链路出错了，系统会怎么表现。把这些假设想在前面，能省掉后面大量“救火式”的排查。
如果你刚接触这块，我建议从一个自己能动手的场景开始：用两块开发板，自己定义一个帧格式，加上CRC和重传，跑起来观察效果，然后再做一次不加校验的对比测试。数据会告诉你这个技术到底有多重要。踩过几次坑之后，你会在潜意识里把差错控制当成通信方案的默认选项，而不是可选的加分项。这种习惯，可能比记住任何算法都更值钱。