1. 从一次“乱码”说起为什么我们需要偶校验几年前我帮一个学弟调试他的51单片机课程设计一个基于串口的温湿度数据采集系统。硬件连好了代码也烧进去了但上位机软件上显示的温度值时不时就跳出一个“-127℃”或者一个完全离谱的数字。学弟挠着头说“师兄我这线也没接错啊程序就是按照例程抄的怎么数据老出错呢”我让他把串口调试助手的数据显示模式切换到“十六进制”一看就发现了问题。正常的数据帧应该是规整的但偶尔会冒出来一个字节其中某一位bit从0变成了1或者从1变成了0。这就是典型的传输误码。单片机与电脑之间那根细细的串口线周围可能有电机在转可能有继电器在吸合这些电磁干扰都可能在数据传输的瞬间“偷袭”一下把某个高电平1打成低电平0或者反过来。对于单片机来说它可不知道这个数据是对是错它只会忠实地把接收到的二进制数当成有效数据。这时候就需要一种简单有效的机制来给数据“上个保险”让接收方有能力判断“嘿刚才传过来的这个字节路上是不是被人动了手脚”奇偶校验Parity Check就是其中最经典、最基础的一种“保险”。而偶校验Even Parity又是奇偶校验中的一种具体策略。它的核心思想非常简单在发送一个字节8位数据之前我们先数一数这个字节里二进制“1”的个数是奇数还是偶数。如果采用偶校验我们就人为地添加一个第九位校验位使得数据位加上校验位总的“1”的个数为偶数。举个例子假设我们要发送的数据是1101 0010二进制。数一下它有4个“1”偶数个。按照偶校验规则为了让总“1”个数保持偶数我们添加的校验位就应该是0。这样发送出去的就是9位数据位(1101 0010) 校验位(0)其中“1”的总数依然是4偶数。如果接收方收到这9位后自己再数一遍“1”的个数发现是奇数比如5个它就能立刻断定“这个数据在传输过程中出错了” 虽然它不知道具体是哪一位错了但它知道这个数据不可信可以选择丢弃或者请求重发。对于51单片机尤其是我们最常用的STC系列它的串口模块和程序状态寄存器PSW已经为我们内置了实现偶校验的“硬件外挂”用起来非常方便。接下来我们就深入芯片内部看看这套机制到底是怎么运转的。2. 核心“裁判”PSW寄存器与奇偶标志位P要玩转51单片机的偶校验你必须认识一个关键的寄存器PSWProgram Status Word程序状态字。这是一个8位的特殊功能寄存器你可以把它理解为CPU的“实时状态显示屏”。里面有几个非常重要的标志位比如进位标志CY、辅助进位标志AC以及我们这里的主角——奇偶标志位PParity Flag。这个P位非常智能也特别“勤快”。每执行完一条指令只要这条指令的执行结果影响了累加器AACC的值单片机硬件就会自动计算当前累加器A中“1”的个数是奇数还是偶数。如果是奇数P位就被硬件自动置为1如果是偶数P位就被清零为0。这个过程是硬件完成的不需要任何软件干预速度极快。我们来做个实验。假设累加器A的初始值是0x55二进制0101 0101。数一下“1”的个数是4个偶数所以此时PSW中的P标志位应该是0。然后我们执行一条指令ADD A, #0x01结果是0x56二进制0101 0110。“1”的个数变成了4个不对0x56是0101 0110其中“1”的个数是3个奇数。所以在这条加法指令执行完毕后硬件会立刻更新P标志位将其设置为1。这个自动更新的P值就是我们实现偶校验的“金钥匙”。在串口发送时我们可以把P位的值直接赋给校验位TB8在接收时将收到的校验位RB8与根据接收数据计算出的P位进行比较。这就相当于让发送端和接收端用同一把尺子计算“1”的奇偶性量了数据然后比对结果。2.1 串口模式的选择为何是模式2或模式351单片机的串口有几种工作模式由SCON寄存器控制。要实现带校验位的9位数据传输我们必须选择模式2或模式3。模式1是8位数据位没有固定的校验位而模式2和模式3的数据帧格式是1位起始位 8位数据位 1位可编程位第9位 1位停止位。这个“可编程的第9位”就是我们的校验位TB8/RB8的位置。在初始化串口时我们通过设置SCON寄存器来进入模式3通常波特率可调更常用。例如SCON 0xC0;这条语句就是将串口1设置为模式3SM01, SM11并做好接收准备REN1。在这个模式下我们就能自由地操控TB8发送第9位和检查RB8接收第9位了。3. 手把手代码实战发送与接收端的偶校验实现理解了原理我们来看具体代码。我会把发送和接收两个部分的代码拆开揉碎了讲并附上我调试时踩过的坑。3.1 发送端如何“打包”带偶校验的数据发送端的任务很明确在把数据扔进SBUF发送缓冲区之前先根据数据的奇偶性设置好校验位TB8。// 定义一个全局变量var0并初始化为0 unsigned char var0 0; void UartSend_WithEvenParity(uint8_t data_to_send) { // 关键步骤1将待发送数据赋值给累加器A的“替身” // 我们通过一个加法操作来“激活”P标志位的计算 // 因为var0是0所以 (data_to_send 0) 的结果就是data_to_send本身 // 但这条加法指令会让硬件去计算data_to_send中‘1’的奇偶并更新P位 ACC data_to_send; // 方法一直接赋值给ACC这是最清晰的 // 或者用加法: data_to_send var0; 然后后面用P // 关键步骤2将奇偶标志位P的值赋给发送校验位TB8 // 如果P1说明数据中‘1’的个数为奇数那么TB8就置1使得总‘1’数为偶数奇数1偶数 // 如果P0说明数据中‘1’的个数为偶数那么TB8就置0使得总‘1’数保持偶数偶数0偶数 TB8 P; // 关键步骤3将8位数据写入SBUF启动发送 // 此时串口硬件会自动将我们刚才设置的TB8作为第9位连同这8位数据一起发送出去 SBUF data_to_send; // 等待发送完成TI标志位由硬件置1 while(!TI); TI 0; // 软件清除发送完成中断标志 }这里有个非常重要的细节也是我当年迷惑的地方很多示例代码包括原始文章里用的是data_to_send var0;然后TB8 P;。这行得通因为加法运算会更新P位。但更直接、更容易理解的做法是直接操作累加器ACC。因为P标志位只追踪ACC的奇偶性。所以ACC data_to_send;这条语句执行后P位就已经根据data_to_send的值被正确设置了。我个人更推荐这种写法意图更明确。3.2 接收端如何“验货”与判断数据可信度接收端在中断服务程序里工作。当收到一帧完整数据后硬件会置位RI并将收到的第9位放入RB8寄存器将收到的前8位数据放入SBUF。// 接收中断服务函数 void Uart_ISR(void) interrupt 4 { uint8_t received_data; if (RI) { // 如果是接收中断 RI 0; // 清除接收中断标志 // 步骤1从SBUF读取接收到的8位数据 received_data SBUF; // 步骤2将接收到的数据“喂”给累加器A以计算其本身的奇偶性P位 ACC received_data; // 此时硬件自动计算了received_data中‘1’的奇偶结果在P标志位中。 // 步骤3进行偶校验判断 // 我们采用偶校验所以发送端保证了 “数据位TB8” 的总‘1’数为偶数。 // 对于接收端 // - 我们根据收到的数据计算的P位表示‘received_data’本身‘1’的奇偶性。 // - 我们收到的RB8是发送端发过来的校验位。 // 校验逻辑如果 (P RB8)则校验通过。 // 为什么因为 // * 如果数据本身‘1’为偶数(P0)且校验位RB80则总数为偶数(00)正确。 // * 如果数据本身‘1’为奇数(P1)那么为了总数为偶数校验位RB8必须是1(112,偶数)。 // 所以当且仅当 P 和 RB8 相等时总‘1’数才为偶数校验通过。 // 反之如果 P ! RB8则总‘1’数为奇数说明传输过程中发生了单数位错误1位、3位...校验失败。 if (P RB8) { // 偶校验通过可以放心使用received_data // 这里可以将数据存入缓冲区或者设置一个数据就绪标志 g_uart_rx_buffer received_data; g_data_ready_flag 1; } else { // 偶校验失败数据不可信 // 处理错误可以丢弃数据记录错误次数或者触发重发机制 g_uart_error_count; // 对于关键应用可以在这里请求发送方重传上一个数据包 } } if (TI) { // 处理发送中断如果需要的话 TI 0; } }接收逻辑是核心中的核心务必理解透彻。判断条件if (P RB8)就是整个偶校验机制的判决点。这里再强调一次推导过程我们的目标是总“1”数为偶数。设数据位“1”的个数奇偶性为P_dataP标志位即代表此意1为奇0为偶校验位值为P_check即RB8。那么总数奇偶性 (P_data P_check) % 2。要保证结果为0偶数则必须满足(P_data P_check) % 2 0这在二进制下等价于P_data P_check。所以比较P和RB8是否相等就是检验总“1”数是否为偶数的直接方法。4. 偶校验的能效与局限它真是“万金油”吗在实际项目中用了很多次偶校验后我对它的优点和缺点有了更深的体会。它绝对是一个轻量级、低成本的可靠性增强工具但绝不是“银弹”。它的优势非常突出硬件支持效率极高51单片机原生支持几乎不占用额外的CPU时间特别适合在中断服务程序这种对时间敏感的场景中使用。实现简单代码量小如上所示发送和接收各增加一两行代码即可对程序结构影响极小。能检测所有奇数位错误这是它最主要的能力。只要数据在传输过程中发生了1位、3位、5位…等奇数个比特的翻转从0变1或1变0校验必然失败。在干扰随机的环境下单比特错误是最常见的所以它能解决大部分问题。然而它的局限性也必须清醒认识无法检测偶数位错误如果数据中有2位、4位…同时发生翻转错误的比特数恰好是偶数那么数据位“1”的个数奇偶性可能不变加上校验位后总“1”数的奇偶性也可能不变从而导致校验通过。这是奇偶校验最根本的缺陷。只能检错不能纠错它只能告诉你“数据可能错了”但完全不知道是哪一位错了所以无法自动修复。处理方式通常是丢弃错误数据或请求重发。无法判断校验位本身的错误如果校验位RB8在传输中出错了而数据位完全正确校验也会失败导致一个本来正确的数据被误判为错误。这是一种“虚警”。对突发错误的检测能力有限虽然能检奇数位错误但如果干扰是连续一片突发错误情况会更复杂。所以在我的经验里偶校验非常适合对可靠性有一定要求但数据量不大、速率不高、且错误重传机制容易实现的场景。比如单片机与电脑调试终端之间的命令传输。主从机之间传输一些关键的状态标志或设定参数。在RS-485等长距离、易受干扰的总线通信中作为第一道数据过滤网。但对于传输大量连续数据如图像、音频、或者要求绝对可靠的控制指令如无人机飞控单纯的偶校验就显得力不从心了。这时就需要更强大的校验和Checksum、循环冗余校验CRC甚至是带有纠错能力的编码方案。你可以把偶校验看作是你家大门上那把简单的弹子锁能防顺手牵羊但防不了技术开锁。更重要的财物还得放进保险箱更强的校验机制。5. 调试技巧与常见问题排查如果你按照上面的代码实现了但校验好像不起作用或者数据还是不对别急我们可以一步步排查。问题一校验似乎永远失败或永远成功。检查串口初始化模式确认SCON寄存器被正确设置为模式2或模式3SCON 0xC0;或类似值。如果设成了模式18位数据那么第9位根本不会被发送或接收RB8的值是随机的校验必然混乱。检查TB8/RB8的访问时机在发送函数中一定要在写SBUF之前设置TB8。因为写SBUF这个动作会触发串口硬件开始发送过程此时TB8的值就被锁定了。如果先写SBUF再设TB8校验位可能是旧值或未定义值。接收端同理要在读取SBUF之后立刻进行P和RB8的比较因为退出中断或执行其他代码可能会影响ACC和P的值。验证P标志位的计算可以在发送和接收代码中在设置TB8或判断前通过软件模拟计算一下数据的奇偶性与P位对比。写一个简单的函数bit CalculateParity(uint8_t data) { ... }用循环移位和异或的方式计算奇偶看看结果是否与硬件P位一致。这能帮你确认是不是对P位的理解有误。问题二加了校验后通信偶尔会丢数据。中断处理时间加入了校验判断的接收中断服务程序执行时间比原来略长。如果波特率很高比如115200数据帧间隔很短要确保你的中断服务程序能在下一帧数据到来前执行完毕否则会导致数据覆盖或丢失。如果发现有问题尝试优化中断服务程序代码或者降低波特率。错误处理策略你的校验失败处理分支做了什么如果只是简单地丢弃那在干扰环境下就会表现为“丢包”。可以考虑建立一个简单的重传协议或者在应用层通过数据包序号、帧头帧尾来发现数据不连续。一个实用的调试方法利用串口调试助手。很多高级的串口调试助手如AccessPort、友善串口助手支持“自动添加/校验校验位”的功能。你可以先让单片机端不开启校验在调试助手上设置软件偶校验。让单片机发送一组固定数据看调试助手能否正确校验。然后再反过来让单片机开启硬件偶校验发送调试助手关闭软件校验以“无校验”模式接收查看收到的原始字节流包括第9位如果调试助手能显示的话。通过这种“交叉验证”可以非常精准地定位问题是出在发送方、接收方还是你对机制的理解上。最后我想说理解并掌握偶校验不仅仅是学会一种技术更是建立起一种“通信可靠性”的思维。在嵌入式开发中任何跨越物理空间的数据传输都是脆弱的。从简单的奇偶校验到复杂的CRC从软件重传到硬件冗余我们做的所有努力都是为了在不可靠的物理世界上构建起可靠的数据桥梁。当你下次再看到TB8 P;和if (P RB8)这样的代码时希望你能会心一笑知道这短短两行背后是一场发送端和接收端共同参与的、关于数据完整性的默契握手。