通信协议解析的痛点：从轮询到中断，再到状态机

大家好，我是你们这堂课的主讲。今天咱们聊点实在的——通信协议解析。

做嵌入式这么多年，我见过太多人在协议解析上栽跟头。说白了，就是数据来了，你怎么把它“接住”并“读懂”。这看似简单，但里面的坑，一个比一个深。

传统轮询方式的“三宗罪”

我刚入行那会儿，用的最多的就是轮询。在主循环里不停地查：

while(1) {
    if (UART_DataReady()) {
        byte = UART_ReadByte();
        // 处理这个字节...
    }
    // 其他任务...
}

看着挺简单，对吧？但实际跑起来，问题就来了。

轮询的弊端，我总结为三点：

• CPU空转浪费：没有数据时，CPU也在那里傻等，功耗高，效率低。
• 实时性差：如果主循环里有耗时操作（比如刷屏、写Flash），数据来了你根本来不及处理，直接丢包。
• 粘包/半包问题突出：轮询是一次读一个字节，你很难判断一帧数据什么时候结束。读快了是半包，读慢了就粘在一起。

你想想看，一个每秒发1000帧数据的传感器，你用轮询去接，能接住多少？我实测过，在STM32F103上，如果主循环里加个延时，丢包率能到30%以上。这谁受得了？

中断驱动模型：让CPU“该干嘛干嘛”

所以，我们引入了中断。数据来了，硬件自动通知CPU，CPU暂停当前工作，去处理数据。处理完再回来。

这就像你正在写代码，快递员打电话让你下楼取件。你放下键盘，取完快递，回来继续写。而不是每隔几秒就跑到门口看一眼。

但中断也不是万能的。我见过不少新手，在中断服务函数里做大量处理，比如解析协议、校验CRC、甚至写日志。结果呢？中断嵌套，系统崩溃。

这样，中断的响应速度极快，不会阻塞其他中断。数据也不会丢。

粘包与半包：协议解析的“头号杀手”

好了，现在数据通过中断收进来了，放在一个环形缓冲区里。但问题来了——你怎么知道一帧数据从哪里开始，到哪里结束？

这就是粘包和半包问题。

• 半包：一帧数据还没收完，你就开始解析，结果读到一半发现数据不够，报错。
• 粘包：两帧数据连在一起收进来了，你解析时把两帧当成一帧，校验失败。

我举个例子。假设协议是：AA 55 长度 数据 CRC。你收到一串：AA 55 03 01 02 03 CRC1 AA 55 02 04 05 CRC2。如果你按字节流去读，根本分不清哪里是边界。

传统的做法是什么？加超时。收到一个字节后，如果超过一定时间没收到下一个，就认为一帧结束。但这个方法很不可靠——网络延迟、CPU负载波动，都会导致误判。

状态机：优雅地解决粘包与半包

那怎么办？我个人最推崇的方案就是——状态机。

状态机本质上是一个“有限状态自动机”。它根据当前状态和输入事件，决定下一步做什么。用在协议解析上，就是：

• 定义几个状态：IDLE（空闲）、HEADER（收到帧头）、LENGTH（收到长度）、DATA（收数据）、CRC（校验）。
• 每收到一个字节，状态机根据当前状态和这个字节的值，决定是继续收、还是报错、还是完成一帧。

这样，半包问题自然解决——状态机在DATA状态时，如果数据没收够，它就一直等，不会乱动。粘包问题也解决了——一帧收完，状态机回到IDLE，开始收下一帧，不会混淆。

下面这张图，是我常用的一个协议解析状态机框架。你看一眼就明白了：

你看，状态机把整个解析过程拆成了5个状态。每个状态只关心一件事：

状态	做什么	输入事件	下一状态
IDLE	等待帧头	收到0xAA	HEADER
HEADER	确认第二个帧头	收到0x55	LENGTH
LENGTH	读取数据长度	收到长度值	DATA
DATA	收指定字节数	收满长度	CRC
CRC	校验完整性	校验通过	完成

这样做的好处是什么？

• 半包不慌：状态机在DATA状态时，如果没收够数据，它就一直等。不会因为“数据不够”就报错。
• 粘包不怕：一帧处理完，状态机回到IDLE。下一帧的数据来了，重新开始。不会把两帧混在一起。
• 调试方便：每个状态都是独立的，出问题了，打印一下当前状态和输入，一眼就能看出哪里卡住了。