STM32串口奇偶校验配置详解

关注

原创最新推荐文章于 2026-09-08 16:57:55 发布 1.3k 阅读 AI 写同款· GEO 优化 ›

STM32F103单片机串口2带奇偶校验技术解析

在工业现场或远程监控系统中，你是否遇到过这样的问题：传感器数据偶尔“跳变”，明明CRC校验也没出错，但设备却执行了异常动作？深入排查后发现，其实是UART通信过程中某个比特被电磁干扰翻转，而无校验的8N1帧格式对此毫无察觉。这类隐患在电机启停频繁、布线较长的环境中尤为常见。

这时候，一个看似简单却极为有效的机制就能派上用场—— 硬件奇偶校验 。它不需要复杂的协议栈改动，也不显著增加传输开销，却能在物理层第一时间捕获单比特错误，为上层通信筑起第一道防线。本文以STM32F103的USART2为例，带你深入理解如何正确启用并利用这一功能，避免因配置误区导致“形同虚设”。

STM32F103系列基于Cortex-M3内核，其USART模块不仅支持标准异步通信，还集成了包括奇偶校验在内的多种差错检测机制。其中，USART2通常映射到PA2（TX）和PA3（RX），是除调试串口外最常用的通信通道之一。当我们将它配置为带奇偶校验模式时，本质上是在每一帧数据中插入一位冗余信息，用于验证数据位中“1”的个数是否符合预设规则。

具体来说，偶校验要求整个字节（含校验位）中“1”的总数为偶数；奇校验则反之。例如发送 0x5A （二进制 0101_1010 ），其中有4个“1”，本身就是偶数，因此偶校验位为0；若传输过程中某一位发生翻转（如变为 0101_1011 ），接收端计算得到5个“1”，与预期不符，便会触发 PE（Parity Error）标志 。

这个过程完全由硬件自动完成。发送时，你只需向 USART_DR 寄存器写入8位数据，MCU会根据当前设置自动生成并附加校验位；接收时，芯片同样会对接收到的数据位进行奇偶运算，并与实际接收到的第9位比较。一旦不匹配， SR 寄存器中的 PE 位立即置起。

值得注意的是，虽然每帧实际传输的是9位（8数据 + 1校验），但在编程接口上我们依然使用 uint8_t 类型操作DR寄存器。也就是说， 无需将 WordLength 设为9位 ——只要启用了非None的校验模式（如 USART_Parity_Even ），硬件就会自动切换至9位帧结构。这是很多开发者容易误解的地方：误以为必须显式配置 USART_WordLength_9b 才能启用校验，结果反而导致通信失败。

波特率精度也直接影响校验的有效性。STM32F103的USART2挂载在APB1总线上，默认时钟为36MHz。通过分频器生成目标波特率（如9600bps），其误差应控制在±2%以内，否则采样点偏移可能导致误判为校验错误。建议使用外部晶振（HSE）作为系统时钟源，而非依赖内部RC振荡器，以提升时基稳定性。

来看一段典型的初始化代码，实现9600-8E1（即波特率9600、8位数据、偶校验、1位停止位）配置：

#include "stm32f10x.h"

void USART2_Config(void) {
    GPIO_InitTypeDef GPIO_InitStructure;
    USART_InitTypeDef USART_InitStructure;

    // 1. 开启相关外设时钟
    RCC_APB1PeriphClockCmd(RCC_APB1Periph_USART2, ENABLE);
    RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA, ENABLE);

    // 2. 配置PA2(TX)为复用推挽输出，PA3(RX)为浮空输入
    GPIO_InitStructure.GPIO_Pin = GPIO_Pin_2;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP;        // 复用推挽输出
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_Init(GPIOA, &GPIO_InitStructure);

    GPIO_InitStructure.GPIO_Pin = GPIO_Pin_3;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN_FLOATING;  // 浮空输入
    GPIO_Init(GPIOA, &GPIO_InitStructure);

    // 3. 配置USART2参数
    USART_InitStructure.USART_BaudRate = 9600;
    USART_InitStructure.USART_WordLength = USART_WordLength_8b;    // 注意仍是8b
    USART_InitStructure.USART_StopBits = USART_StopBits_1;
    USART_InitStructure.USART_Parity = USART_Parity_Even;          // 启用偶校验
    USART_InitStructure.USART_Mode = USART_Mode_Rx | USART_Mode_Tx;
    USART_InitStructure.USART_HardwareFlowControl = USART_HardwareFlowControl_None;

    USART_Init(USART2, &USART_InitStructure);
    USART_Cmd(USART2, ENABLE);

    // 可选：开启奇偶校验中断
    USART_ITConfig(USART2, USART_IT_PE, ENABLE);
}

关键点在于 .USART_Parity = USART_Parity_Even 这一行。一旦启用，后续所有发送和接收都将包含校验位。如果你希望及时响应错误事件，可以开启 USART_IT_PE 中断。但在编写中断服务程序时有一个 极易忽略的关键细节 ：清除PE标志需要“先读状态寄存器SR，再读数据寄存器DR”。否则，即使进入中断也无法清除该标志，导致中断反复触发。

正确的中断处理方式如下：

void USART2_IRQHandler(void) {
    uint8_t data;

    if (USART_GetITStatus(USART2, USART_IT_PE) != RESET) {
        // 必须顺序读取SR和DR才能清零PE
        data = USART_ReceiveData(USART2);  // 清除错误标志
        // 此处可记录日志、触发重传或报警
    }

    if (USART_GetITStatus(USART2, USART_IT_RXNE) != RESET) {
        data = USART_ReceiveData(USART2);
        // 正常数据处理逻辑
    }
}

如果只处理 RXNE 而忽视 PE ，那么一旦出现一次误码，后续所有接收都会携带未清除的PE标志，最终导致整个通信链路瘫痪。这正是许多项目在现场运行一段时间后突然“失联”的潜在原因之一。

在实际系统中，这种机制的价值尤为突出。比如在一个基于Modbus RTU协议的多节点传感器网络中，主控STM32通过USART2连接MAX485收发器，轮询多个从站。尽管Modbus本身有CRC-16校验，能检测多数数据错误，但它只能在完整帧接收完成后才进行验证。而奇偶校验则在 每个字节到达时就已完成检查 ，可以在第一个错误字节出现时立即丢弃整帧，避免浪费时间接收后续无效数据，同时也防止错误帧进入解析流程引发误动作。

设想这样一个场景：一条指令本应读取地址为0x01的设备，但由于干扰导致地址字节中的某一位翻转，变成了0x03。如果没有底层校验，这条错误命令会被正常发送出去，可能误触其他设备；而有了奇偶校验，该字节会在接收瞬间就被识别为错误，主机可选择忽略或重发，从而杜绝此类风险。

当然，奇偶校验也有局限性：它只能检测单比特错误，对双比特及以上翻转无能为力（概率较低但仍存在）。因此，在高可靠性系统中，建议将其作为 第一级防护 ，配合上层协议的CRC校验形成双重保障。此外，软硬件协同设计也很重要：

时钟设计 ：优先采用8MHz或更高精度的外部晶振；
PCB布局 ：TX/RX走线尽量短且远离电源、时钟等高频信号；
电平转换 ：长距离通信务必使用RS-485并加入光耦隔离；
软件健壮性 ：始终检查 PE 标志，不可假设“环境干净”就关闭错误中断；
调试手段 ：初期可用XCOM等串口助手模拟带校验通信，验证两端一致性。

值得一提的是，现代开发趋势已逐渐转向STM32Cube生态。使用STM32CubeMX图形化工具，你可以直观地勾选“Parity: Even/Odd”选项，生成HAL库代码，大大降低配置门槛。但即便如此，理解底层行为仍然至关重要——当你面对一台“莫名其妙不停进中断”的设备时，真正能帮你定位问题的，不是自动生成的代码，而是对寄存器工作机制的清晰认知。

回到最初的问题：为什么有些项目启用了奇偶校验却仍无法改善通信质量？答案往往藏在细节之中——可能是收发双方校验方式不一致，可能是中断未正确清除标志，也可能根本就没意识到硬件已自动处理9位帧。这些看似微小的疏忽，恰恰是嵌入式系统稳定性的最大敌人。

通过合理配置USART2的奇偶校验功能，开发者能够在几乎不增加成本的前提下，显著提升串行通信的鲁棒性。对于工业自动化、智能仪表、远程终端单元（RTU）等应用场景而言，这种“轻量级增强”带来的长期收益远超投入。毕竟，在关键时刻少一次误动作，可能就意味着避免了一次停产事故。