MCU串口通信协议设计：用状态机实现可靠帧收发与校验

简介：这是一份围绕中微CMS8S6990单片机实现的串口收发并带有简单协议处理的完整工程源码包，适合刚入门单片机的开发者学习通信协议设计与底层驱动编写。资源包内共144个文件，涵盖C源文件、头文件、Keil工程配置文件、编译中间文件、hex烧录文件等，工程目录结构基本完整，压缩包整体仅2.05MB，适合直接导入到开发环境中查阅相关代码。目前已有1554人学习下载，内容以实际项目代码为主，重点展示如何为串口收发添加协议校验、消息解析和应答逻辑，初学者可借此掌握基本的通信协议设计思路。资源价值在于：既能看到system.c、uart.c、timer.c等模块化源码，也能参考工程配置文件、启动文件及编译生成文件，便于初学者对比源码和构建输出，快速理解单片机串口通信与简单协议收发的基本套路。对于需要动手验证单片机串口通信、想把协议机制落到代码层面的同学会有直接帮助。

1. 从一个实际场景说起：串口收发带上协议之后

刚调通串口回显时，感觉很简单，但真正把传感器数据发给上位机，对面收到的全是乱码和粘包，这就是很多人从点灯转向通信开发的第一道坎。这个项目要解决的正是这个痛点：在 CMS8S6990 增强型 8051 上，写一套极简但完整的串口收发协议，把裸机串口从「能收发字节」升级到「能可靠收发一帧完整命令」。整个工程不依赖操作系统，没有 DMA，只有串口中断、定时器和状态机，逻辑完全透明，非常适合初学者照着抄一遍，搞清楚协议帧到底怎么组、怎么拆、怎么校验。

2. 协议与硬件准备：帧格式设计和 CMS8S6990 的串口初始化

2.1 为什么裸串口必须加协议层

接触过几个入门项目的开发者应该都有体会：串口本质是一条字节流，芯片端没有任何「消息边界」的概念。你连续发 8 个字节，对端只能按顺序收到 8 个字节，但它不知道第几个字节算开始、第几个字节算结束。如果不加协议，上位机想发一条「查询设备版本」的命令，下位机只能约定「收到 0x01 就是查询版本」，这在一个命令、一个数据格式的场景下还能凑合；一旦有几十种命令、数据长度还不固定，立刻会失控。

更现实的问题是粘包与错位。假设下位机周期上报温度，每帧 6 个字节，如果其中某个字节丢失或电平受干扰翻转，后续所有字节都会错位，而且你根本不知道从哪一位开始重新同步。协议层解决的就是这三件事：帧同步（知道一帧从哪里开始）、长度约束（知道一帧到哪里结束）、校验（知道这一帧数据是否完好）。这个项目采用的方案是经典的一帧结构：固定帧头 + 命令字 + 数据长度 + 数据域 + 校验和。

2.2 一帧协议的字段定义

协议帧设计为总共最多 36 字节，数据域上限 32 字节，具体布局如下：

帧头选 0xAA 和 0x55 是很有讲究的。这两个字节的二进制分别是 10101010 和 01010101，波形上能看到清晰的电平交替，用逻辑分析仪抓串口波形时一眼就能认出帧起始位置；同时 0xAA 在普通数据中出现的概率不高，双帧头叠加更是把误同步的概率压到了可以忽略的程度。校验和的计算规则是：从 CMD 字节开始，把 CMD、LEN、DATA 所有字节累加，取累加结果的低 8 位当作 CHKSUM。帧头不参与校验，因为帧头只负责同步，如果连帧头都错了，直接丢弃重新同步即可。

也许有人会问为什么不用 CRC16。我的看法是：这个场景是 MCU 与 PC 或简单传感器通信，波特率 115200、数据量小、误码率低，8 位累加和已经能覆盖单字节跳变、丢包这类常见故障。CRC16 会引入一张查找表或移位算法，入门阶段先把协议主链路跑通，后面想升级校验可以平滑替换，这一点在第 6 章二次开发里专门讲。

2.3 CMS8S6990 的串口初始化

CMS8S6990 是增强型 8051 内核，自带多个定时器和两组 UART，本工程使用 UART0，波特率 115200、8 位数据、无校验、1 位停止位。初始化代码我习惯单独放一个 uart.c，不跟业务逻辑混在一起：

/* uart.c — 基于 CMS8S6990 的 UART0 初始化 */ #include <8051.h> void UART0_Init(void) { SCON = 0x50; /* 模式1：8位可变波特率，REN=1使能接收 */ TMOD &= 0x0F; /* 清空T1相关位 */ TMOD |= 0x20; /* T1工作在方式2：8位自动重载 */ PCON |= 0x80; /* SMOD=1，波特率加倍 */ TH1 = 0xE8; /* 复位值按数据手册计算，不是固定值 */ TL1 = TH1; TR1 = 1; /* 启动定时器1 */ ES = 1; /* 使能串口中断 */ EA = 1; /* 开总中断 */ }

这里有个容易踩的坑：TH1 的重载值不能从网上随便抄。CMS8S6990 跑在 1T 增强模式，系统时钟分频系数和传统 12T 的 8051 不一样，同一个 115200 波特率对应的 TH1 值很可能不同。最稳妥的做法是翻芯片手册里的波特率表格，或者先按手册填一个值，用逻辑分析仪抓 TX 脚波形，数实际位宽再反推校准。第 4 章会再展开讲这个坑。

初始化里还有一个细节：SCON 的 0x50 同时完成了两件事，一是配置串口工作模式，二是把接收使能位 REN 置 1。如果不写 REN，串口就只会发不会收，初学者第一次跑通发送、卡在接收上时，第一个要查的就是这个寄存器值。

3. 核心代码拆解：发送打包与接收状态机的完整链路

3.1 发送端：如何把数据打包成一帧

发送端的设计分两层：底层负责一个字节一个字节地推给 SBUF，上层负责把命令和数据组装成协议帧。底层发送函数的实现很直接：

/* uart.c — 发送单个字节 */ void uart_send_byte(unsigned char dat) { SBUF = dat; /* 写入SBUF，硬件自动移位发送 */ while (!TI); /* TI=1表示当前字节已发送完成 */ TI = 0; /* 必须由软件清零 */ }

这里的逻辑是：把数据写进 SBUF 后，串口硬件会在移位时钟的驱动下把 8 个数据位逐个发出去，发完置位 TI。程序在 while 里等着，直到 TI 变 1 才继续。TI 清零必须放在等待之后，如果清零放在写 SBUF 之前，第二轮发送时 TI 还残留上一帧的结果，会直接跳过等待导致数据错乱。这也是初学者最容易写出「第一帧正常、第二帧全乱」的经典原因之一。

上层组帧函数放在 protocol.c 里，负责按照第 2 章定义的帧格式，把命令字和数据域打包并计算校验和：

/* protocol.c — 组帧并发送一帧协议数据 */ #define P_HDR1 0xAA #define P_HDR2 0x55 extern void uart_send_byte(unsigned char dat); void protocol_send(unsigned char cmd, unsigned char *buf, unsigned char len) { unsigned char i; unsigned char sum = 0; uart_send_byte(P_HDR1); uart_send_byte(P_HDR2); uart_send_byte(cmd); uart_send_byte(len); for (i = 0; i < len; i++) { uart_send_byte(buf[i]); sum += buf[i]; /* 数据域累加进校验 */ } sum += cmd + len; /* CMD与LEN也参与校验 */ uart_send_byte(sum); /* 发送低8位校验和 */ }

这段代码有两个设计点值得说。其一，校验和的累加顺序是 CMD、LEN、DATA，与帧头无关，这必须和接收端的状态机严格对齐，否则自测时就会发现「自己发的帧自己解不了」。其二，unsigned char溢出会自动回绕到低 8 位，所以累加过程中不需要额外& 0xFF，这正是 C 语言里无符号整型的一个讨巧用法。需要注意的是，buf指向的数据域不能超过 32 字节，如果调用方传了更大的 len，帧会突破协议上限，接收端会在长度检查那里直接整帧丢弃。

3.2 接收端：用状态机解析一帧

接收端是全工程的核心，也可以说是初学者从「会串口收发」进阶到「会写协议解析」的关键一步。思路是把接收过程拆成若干状态，串口中断每收到一个字节，就喂给状态机走一步；状态机根据当前处于什么阶段，决定这个字节应该当帧头、命令、长度、数据还是校验来处理。

先定义状态枚举和全局缓冲：

/* protocol.c — 接收状态与缓冲区 */ enum { ST_HDR1 = 0, /* 等待第一个帧头 */ ST_HDR2, /* 等待第二个帧头 */ ST_CMD, /* 接收命令字 */ ST_LEN, /* 接收长度 */ ST_DATA, /* 接收数据域 */ ST_CHK /* 接收校验和 */ }; volatile unsigned char rx_cmd = 0; volatile unsigned char rx_len = 0; volatile unsigned char rx_done = 0; static unsigned char rx_buf[32]; static unsigned char state = ST_HDR1; static unsigned char expect_len = 0; static unsigned char rx_idx = 0; static unsigned char rx_sum = 0;

rx_done 是一个「帧到达标志」，由中断置 1，主循环看到后取数据并清零。注意这里用了 volatile，因为它在中断和主循环两个上下文之间共享，不加 volatile 有可能被编译器优化成寄存器副本，导致主循环永远看不到更新。

串口中断函数如下：

/* uart.c — UART0接收中断，中断号4是8051串口的固定位置 */ void UART0_ISR(void) interrupt 4 { unsigned char dat; if (!RI) return; /* RI=1时才是接收中断 */ dat = SBUF; /* 读数据，硬件自动清RI */ RI = 0; switch (state) { case ST_HDR1: if (dat == 0xAA) state = ST_HDR2; break; case ST_HDR2: if (dat == 0x55) { state = ST_CMD; } else { state = ST_HDR1; /* 没等到0x55，重新同步 */ } break; case ST_CMD: rx_cmd = dat; rx_sum = dat; /* 校验从CMD开始累加 */ state = ST_LEN; break; case ST_LEN: expect_len = dat; rx_sum += dat; rx_idx = 0; if (expect_len == 0) { state = ST_CHK; /* 无数据域，直达校验 */ } else if (expect_len > 32) { state = ST_HDR1; /* 长度非法，整帧作废 */ } else { state = ST_DATA; } break; case ST_DATA: rx_buf[rx_idx++] = dat; rx_sum += dat; if (rx_idx >= expect_len) { state = ST_CHK; } break; case ST_CHK: if (dat == rx_sum) { rx_len = expect_len; rx_done = 1; /* 校验通过，通知主循环 */ } state = ST_HDR1; /* 无论对错都重新开始 */ break; default: state = ST_HDR1; break; } }

这段代码的巧妙之处在于，帧头匹配只在 ST_HDR1 和 ST_HDR2 两个状态进行；一旦进入 ST_DATA，数据里的 0xAA 0x55 就不会再干扰同步。这比很多人一开始写的「在主循环里找帧头」的方案要健壮得多，因为数据域里的字节不会被误认为是新帧的起点。

再细看几个边界。第一个是 LEN 为 0 的情况，此时帧里没有数据域，收到 LEN 后直接跳到 CHK 状态。第二个是 LEN 超过 32 的情况，说明这一帧不是我们的协议帧，或者数据被干扰成了异常值，直接丢弃比强行接收更安全。第三个是校验失败，此时 rx_done 不会被置位，主循环不会处理这帧数据，等于静默丢弃。

3.3 主循环里的帧分发

接收状态机把一帧完整数据装进了 rx_buf，置 rx_done=1。主循环要做的是轮询这个标志，然后按命令字分发处理：

/* main.c — 主循环帧分发 */ void main(void) { System_Clock_Init(); UART0_Init(); EA = 1; while (1) { if (rx_done) { process_frame(); } /* 其他周期任务放这里 */ } } /* protocol.c — 命令分发 */ void process_frame(void) { switch (rx_cmd) { case 0x01: /* 查询设备信息 */ handle_get_version(); break; case 0x02: /* 控制LED */ handle_set_led(rx_buf[0]); break; default: break; } rx_done = 0; /* 处理完必须清标志，否则会重复处理 */ }

handle_get_version 和 handle_set_led 内部会调用 protocol_send 组帧回执。比如收到查询版本命令后，回复一帧固件版本号，上位机就能在串口助手里看到完整的 AA 55 开头的报文。这里有一个工程习惯值得从一开始就养成：process_frame 里只做命令分发，不写具体业务逻辑，具体动作都放到独立的处理函数里。后续每增加一个命令，程序结构就多一个 case 和一个处理函数，不会把 main.c 变成一团乱麻。

4. 常见问题排查：三处让串口协议翻车的细节

4.1 现象：波特率配置看起来没问题，但收发的数据全是乱码

这是串口开发里出现频率最高的一个问题，现象是上位机收到字符完全不可读，或者偶尔第一个字节正确、后面的字节全部错位。原因有两层：第一，CMS8S6990 这类增强型 8051 的系统时钟源可能是内部 RC，也可能是外部晶振，如果固件里没有显式配置时钟源，实际跑起来的主频和代码里假设的主频不一致，波特率自然对不上；第二，1T 内核的波特率计算公式与传统 12T 的 8051 不同，直接套用网上 STC 或 AT89S52 的 TH1 计算结果，误差会被放大。

解决方法是先确认时钟源并显式初始化，再用逻辑分析仪抓 TX 脚波形，量一个字节的实际位宽。比如设了 115200，理论上一位是 8.68 微秒，实测如果明显偏大或偏小，按比例反推回到 TH1 的重载公式重新计算。这个流程熟练之后，基本上五分钟就能定位波特率类问题。

4.2 现象：连续发两帧数据时，接收端偶发一帧丢失或帧头错乱

帧头错乱的具体表现是：单帧发送一切正常，但连续发多帧时，第二帧有时收不到，有时状态机像是「卡住了」，需要重启才能恢复。原因通常是两帧之间没有留间隔，接收端刚处理完第一帧的校验字节，第二帧的帧头就紧跟着到了，此时状态机虽然已经回到 ST_HDR1，但主循环还没把 rx_buf 里的数据处理完，新帧又覆盖了缓冲。

解决方法是两件事：一是发送端在两帧之间插入至少 2~5 毫秒延时，给接收端留出处理时间；二是在接收状态机的 ST_HDR2 分支里，当第二个字节不是 0x55 时，不要直接丢弃当前字节，而应先判断它本身是否是 0xAA，如果是，就保持在 ST_HDR2 继续等下一个字节。这个小改动能让状态机在半截帧的情况下更快恢复同步，属于典型的「状态机边界条件」优化。

4.3 现象：一旦在中断里做复杂处理，串口偶发丢字节

有人为了省事，把命令处理逻辑直接写进串口中断函数，比如在中断里调用 protocol_send 发回执。现象是数据量小的时候没问题，一帧里数据多了，比如收到 32 字节数据域，就偶尔丢一个字节。原因在于 8051 的串口硬件只有一个 SBUF 寄存器，接收缓冲区深度只有 1 字节。如果上一个字节还没被取走，下一个字节到达就会直接覆盖，造成丢数据。中断函数里代码越长，关中断时间越久，丢字节概率越高。

解决方法是严格遵守「中断只做接收和状态转移」的原则，把业务处理全部放到主循环的 process_frame 里。以这个工程的中断函数为例，从进入中断到返回，只执行了一些比较和赋值操作，指令周期在微秒级，远远小于一个字节的接收时间，自然不会丢。记住一个判断标准：中断函数里如果出现了函数调用、循环等待或复杂计算，就说明设计出了问题。

5. 工程搭建到跑通：从新建工程到实机验证的完整步骤

5.1 工程目录与代码文件怎么摆

很多初学者习惯把所有代码塞进一个 main.c，协议程序几百行之后，改一个宏定义都得翻半天。这里推荐按功能拆文件，一个芯片工程拆成四个模块：

project/ ├── main.c /* 主循环与帧分发 */ ├── uart.c /* 串口初始化与中断 */ ├── uart.h ├── protocol.c /* 协议组帧、解析状态机 */ ├── protocol.h └── system_config.h /* 时钟配置、引脚定义 */

uart.h 只对外开放 UART0_Init 和 uart_send_byte 两个函数；protocol.h 对外开放 protocol_send、process_frame，以及 rx_done、rx_cmd、rx_buf 这组接收结果变量。头文件里不要暴露内部状态机的枚举和静态变量，这样下次想改协议结构，不影响外部调用方。main.c 里只需要 include 两个头文件，剩下的事情都交给协议模块，主循环保持干净。

5.2 编译烧录与串口通信联调

CMS8S6990 可以使用通用的 8051 编译工具链，新建工程后把上述文件加入编译，生成 hex 文件后烧录进芯片。接线方面，芯片的 TX 接 USB 转 TTL 小板的 RX，芯片的 RX 接小板的 TX，同时两块板子必须共地。很多初学者漏了共地，导致串口通信「时好时坏」，这是硬件层面最典型的玄学问题。

烧录完成后打开串口助手，选择对应串口号，波特率设置为 115200，勾选 HEX 发送，然后发送一帧测试命令：

AA 55 02 01 01 04

对照第 2 章的帧格式拆解：AA 55 是帧头，02 是 CMD（控制 LED），01 是 LEN，01 是数据域（点亮），04 是 CMD 加 LEN 加数据域的累加和。校验计算过程是 0x02 + 0x01 + 0x01 = 0x04。如果开发板的 LED 应声点亮，同时串口助手能收到一条如下格式的回执帧：

AA 55 02 00 02

说明发送、接收、解析、分发、回包整条链路已经打通。回执帧里 CMD 还是 0x02，LEN 为 0，校验和就是 0x02 + 0x00 = 0x02。这一步跑通了，整个协议工程的核心目标就达成了。

5.3 用逻辑分析仪验证波形时序

如果手边有逻辑分析仪，可以把它夹在芯片 TX 引脚和地之间，抓一帧发送波形。观察点有两个：一是起始位和 8 个数据位的时间宽度是否与 115200 波特率匹配，这能直接验证 TH1 重载值是否准确；二是两帧之间是否能清楚看到整段空闲高电平，能直观理解「帧间隔」对接收状态机的影响。这一步虽然不影响跑通，但能帮你建立串口时序的手感，以后再遇到波特率偏差时会有方向感。

6. 二次开发思路：让协议能扩展而不是推倒重写

6.1 协议层与应用层分离带来的扩展空间

工程里 process_frame 只做事分发的设计，本质上已经把协议层和应用层解耦了。接下来扩展一个多机通信需求时，只需要在帧结构里增加一个地址字段，把校验和从 CMD 开始改成从地址开始，收端状态机多一个 ST_ADDR 状态，应用层完全不需要改动。如果一帧数据超过 32 字节，把 LEN 字段从 1 字节扩展为 2 字节，同时保留第一个字节的高两位作为扩展标志，老设备仍然能按旧格式解析短帧，新设备通过标志识别长帧。这样协议演进不需要版本 2.0 重写。

6.2 给协议加上超时重传机制

另一个值得加的能力是应答与超时重发。目前协议是单向的，发送端发出后不确定对端是否收到。可以定义一条新的命令字 0x80 表示应答，接收端处理完一帧后原样回传 CMD；发送端记录发出的 CMD 和帧序号，开启一个 5 毫秒定时器，超时未收到应答就重发，最多重发 3 次。实现时只需要用到 CMS8S6990 的定时器 0，在中断里维护一个发送状态机和重发计数，这部分已经超出了入门范围，但有了前面的状态机基础，理解起来并不难。

从那以后我每次做串口通信，都会强制走一遍「定义帧格式 → 写状态机 → 回环测试 → 抓波形」这套流程，再没有出现过「串口坏了但是找不出原因」这种玄学问题。这套流程同样适合你手头的第一个串口协议工程，希望帮到你。

本文还有配套的精品资源，点击获取