1. 文本数据包到底解决了什么先想清楚再动手1.1 从收发裸字节到收发“有意义的数据”带CH32V307玩到串口这一章前面几章的路径大概都是这样点灯看GPIO输出读按键看GPIO输入到了串口很多人第一反应是“能打印点东西出来就行了”。串口助手收到一串字符板子也把数据发出去了似乎闭环已经完成。但只要你认真做几个实际项目就会发现“能打印”和“会通信”完全是两码事。举个例子上位机发字符“1”给板子你想让它开灯这“1”到底是什么是命令编号、是灯的亮度、还是某个模式选择如果发的是字符串“LED,1,255”板子又怎么知道逗号是用来分隔参数的更麻烦的是上位机发送速度稍快两次数据连在一起发过来比如“LED,1,255\r\nLED,0,0\r\n”一次性塞进串口程序怎么把这两条命令正确切分开单纯靠“收到一个字节就读一个字节”的思路根本处理不了这种场景。所以这一步的思维转变非常关键你要从“收发字节”升级到“收发数据包”。字节只是传输的载体数据包才是有意义的完整信息。这一章要做的就是围绕CH32V307的USART外设设计一整套能稳定识别、解析、校验、发送文本数据包的方案。方案落地以后你接上位机、接WiFi模块、接另一块板子都会顺手很多。1.2 文本协议与二进制协议怎么选串口通信的数据格式大体分文本和二进制两条路。文本协议就是把人能看懂的ASCII字符拼成一帧比如“$LED,1,255*4E\r\n”二进制协议则直接传结构体、字节流比如帧头0xAA、长度0x03、数据0x01 0x00 0xFF、校验0xXX。文本协议最大的优势是可读性好。串口助手里收到的每一帧都是人眼可读的字符串出问题能直接看出来上位机调试、写测试脚本、手动发命令都极其方便。二进制协议的优势是紧凑、解析快、效率高适合大数据量和高实时性场景但手动调试时非常痛苦一串十六进制看起来像天书。我对这两个方向的取舍是这样的如果项目里主要是“控制命令 状态回传”这类中小数据量交互比如灯控、电机调速、传感器轮询无脑选文本协议如果涉及固件升级、音频波形、图像数据、日志高速上传那就必须用二进制协议加长度字段加CRC了。这一章讲文本是因为它覆盖面最广、最适合学习数据包设计的思路。等你把文本状态机吃透回头再去看二进制协议会发现思路完全通用。1.3 这个方案适合哪些场景这套文本数据包收发方案适用的典型场景包括用上位机软件控制开发板上多个外设单片机通过串口连接WiFi模块、蓝牙模块做远程控制两块MCU之间进行简单的指令交互甚至把一个传感器节点的数据拼成文本帧定时上报。我在实际项目中最常用到的组合是“文本协议 串口调试助手”。调试的时候工具里直接手动输入“$LED,1,255*4E\r\n”点发送看板子动作对不对接上位机时上位机按照同一套帧格式自动生成字符串逻辑完全不冲突。这套方案对单帧数据量不大、频率不高的场景非常舒服代码量也不大。如果你手里已经有现成的串口通信代码但它是“定时读一下、攒够一定字节数再解析”的模式我建议看完这一章后把接收逻辑改造成状态机模式。原因后面会详细展开简单说就是状态机能天然应对半包、粘包和错帧这是定时器攒包方案想都不敢想的。2. 帧格式设计五字段协议一次说透2.1 一套可直接使用的文本帧格式写代码之前必须先把协议定死。协议就是双方都遵守的约定缺一个字符都不行。我在这章采用一个非常经典的文本帧格式长这样$CMD,ARG1,ARG2*XX\r\n一个具体例子是$LED,1,255*4E\r\n意思是命令字是LED参数1等于1参数2等于255*后面的4E是校验值\r\n是帧结束标记。把这个字符串通过串口发给CH32V307板子解析出“LED”“1”“255”之后就知道要把某个引脚拉高同时把PWM占空比设为255。各字段的约定我整理成了一个表方便你后面对照字段位置作用示例帧头$每帧第一个字符标记一帧数据开始$命令字CMD帧头后到第一个逗号区分命令类型LED、TEMP、MOTOR参数区逗号分隔的若干字段携带具体数据1,255校验分隔符*参数区结束后分隔数据和校验值*校验值XX*后两位十六进制字符校验数据完整性4E帧尾\r\n最后两个字符标记一帧数据结束\r\n这套帧格式看起来简单但它把“边界识别”“命令识别”“数据校验”“结束判定”四件事全涵盖进去了。新手最容易犯的错是帧格式里只有帧头没有帧尾或者只有长度没有边界标记。你用串口助手实操一次就会发现没有帧尾的协议调试起来特别别扭你不知道数据什么时候算完。2.2 异或校验的计算过程和手工推演校验是很多初学串口的人最容易忽略的部分。有些人觉得收个文本命令而已有必要校验吗实际项目里串口线缆一长、电磁环境一杂一个字节传错太常见了。比如上位机本来发的是“容量255”结果数据位某一位翻转变成“127”设备就执行了一个错误动作。没有校验这种问题极难定位。校验算法有很多种最简单实用的是异或校验。约定对“$”和“”之间的所有字符也就是对命令字和参数区的所有ASCII码逐字节做异或把结果作为校验值用两位大写十六进制表示。注意这个范围不包含“$”本身也不包含“”。我拿“$LED,1,255*4E\r\n”来手工推演一遍L 0x4C E 0x45 D 0x44 , 0x2C 1 0x31 , 0x2C 2 0x32 5 0x35 5 0x35从第一个字符开始逐个异或0x4C ^ 0x45 0x09 0x09 ^ 0x44 0x4D 0x4D ^ 0x2C 0x61 0x61 ^ 0x31 0x50 0x50 ^ 0x2C 0x7C 0x7C ^ 0x32 0x4E 0x4E ^ 0x35 0x7B 0x7B ^ 0x35 0x4E最终得到校验值0x4E对应字符串“4E”所以完整帧就是“$LED,1,255*4E\r\n”。上位机在发送前做一遍同样的异或单片机在接收过程中边收边算收完校验位后一比对就知道这帧数据中途有没有被改过。异或校验的选择不是随便拍的它的优势在于实现极简一个8位变量、一个异或指令就能算完不需要查表、不需要累加进位而且对文本协议里常见的单比特翻转错误非常敏感。当然它也有局限如果帧里同时有两个字节翻转变成了别的字符异或结果可能碰巧对得上但对于绝大多数串口控制场景这个概率已经低到可以接受。要求更严格的场景可以用CRC8替代原理是移位和多项式计算代码量会比异或大不少初学者先掌握异或完全够用。2.3 帧头、帧尾与特殊字符的约定帧头为什么选“$”因为“$”是ASCII里一个不太常用的符号正常的字母数字命令里不会出现它。选帧头的原则一是这个字符不能是命令里通常会用到的二是不能歧义比如字母“O”和大写字母“O”太像坚决不能当帧头。帧尾为什么用\r\n而不是单独一个\n这有两个原因。第一绝大多数串口工具和上位机控件在“发送新行”时默认补的就是\r\n我们按这个设计调试时最省事不用每次勾选奇怪的发送选项第二双字符帧尾比单字符更抗干扰单个0x0A字符在传输中可能因为噪声冒出来导致误判帧结束而0x0D0x0A连续出现才能触发结束误判概率低一个数量级。还有一类问题必须提前说清楚参数区里能不能出现“$”和“*”我建议从一开始就约定参数区只允许字母、数字和逗号不允许出现帧头、校验分隔符和帧尾字符。这种“白名单式”的协议设计可以避开一大堆转义处理。如果哪天你的数据里真需要包含这些特殊符号再去设计转义机制比如用“*”表示星号字面量那是另一个复杂度的故事不在本章范围内。3. 接收端核心代码状态机解析和缓冲管理3.1 串口初始化和接收中断配置协议定好了代码就好写了。先看初始化部分。CH32V307的外设库接口和标准库风格比较接近下面的代码基于官方EVT库的写法实现UASRT1默认使用PA9作为TX、PA10作为RX。相关时钟宏如果和你手里的头文件版本有出入以实际头文件为准。void USART1_Config(uint32_t baudrate) { GPIO_InitTypeDef GPIO_InitStructure; USART_InitTypeDef USART_InitStructure; NVIC_InitTypeDef NVIC_InitStructure; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_USART1, ENABLE); GPIO_InitStructure.GPIO_Pin GPIO_Pin_9; 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_10; GPIO_InitStructure.GPIO_Mode GPIO_Mode_IN_FLOATING; GPIO_Init(GPIOA, GPIO_InitStructure); USART_InitStructure.USART_BaudRate baudrate; USART_InitStructure.USART_WordLength USART_WordLength_8b; USART_InitStructure.USART_StopBits USART_StopBits_1; USART_InitStructure.USART_Parity USART_Parity_No; USART_InitStructure.USART_HardwareFlowControl USART_HardwareFlowControl_None; USART_InitStructure.USART_Mode USART_Mode_Rx | USART_Mode_Tx; USART_Init(USART1, USART_InitStructure); USART_ITConfig(USART1, USART_IT_RXNE, ENABLE); NVIC_InitStructure.NVIC_IRQChannel USART1_IRQn; NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority 1; NVIC_InitStructure.NVIC_IRQChannelSubPriority 0; NVIC_InitStructure.NVIC_IRQChannelCmd ENABLE; NVIC_Init(NVIC_InitStructure); USART_Cmd(USART1, ENABLE); }这里把串口接收中断使能放在NVIC配置之前中断使能后立刻就能响应。之所以把抢占优先级设为1、子优先级设为0是为了让串口中断的优先级高于主循环中可能用到的定时器事件不至于因为其他中断抢占过高而丢字符。如果你项目里还有更紧急的中断再单独调优先级但串口中断的建议优先级至少处于中上位置。波特率我一般用115200。这个速率在CH32V307上跑文本协议很稳串口助手和逻辑分析仪也默认支持省去很多调试麻烦。9600也行但体验会明显慢一截尤其是一次发好几条命令的时候。3.2 状态机解析的核心实现进入正题。接收中断里每收到一个字节就把它喂给解析函数。解析函数本身是一个有限状态机状态之间根据收到的字符做跳转。先看状态定义和全局变量。typedef enum { FRAME_STATE_IDLE 0, FRAME_STATE_BODY, FRAME_STATE_CHECK, FRAME_STATE_CR, FRAME_STATE_LF, } frame_state_t; #define FRAME_HEADER $ #define FRAME_CHECK * #define FRAME_TAIL_CR \r #define FRAME_TAIL_LF \n #define MAX_FRAME_LEN 64 static volatile uint8_t rx_buf[MAX_FRAME_LEN]; static volatile uint16_t rx_len 0; static volatile uint8_t check_sum 0; static volatile uint8_t check_recv 0; static volatile uint8_t check_byte_idx 0; static volatile frame_state_t frame_state FRAME_STATE_IDLE; static volatile uint8_t frame_done_flag 0;中断服务函数长这样void USART1_IRQHandler(void) { if (USART_GetITStatus(USART1, USART_IT_RXNE) ! RESET) { uint8_t ch (uint8_t)(USART_ReceiveData(USART1) 0xFF); text_frame_parse(ch); USART_ClearITPendingBit(USART1, USART_IT_RXNE); } }核心解析函数是text_frame_parse。它的逻辑就是五个状态的流转static void text_frame_parse(uint8_t ch) { switch (frame_state) { case FRAME_STATE_IDLE: if (ch FRAME_HEADER) { rx_len 0; check_sum 0; check_recv 0; check_byte_idx 0; rx_buf[rx_len] ch; frame_state FRAME_STATE_BODY; } break; case FRAME_STATE_BODY: if (ch FRAME_CHECK) { check_byte_idx 0; frame_state FRAME_STATE_CHECK; } else if (ch FRAME_HEADER) { rx_len 0; check_sum 0; rx_buf[rx_len] ch; } else { if (rx_len MAX_FRAME_LEN) { rx_buf[rx_len] ch; check_sum ^ ch; } else { frame_state FRAME_STATE_IDLE; } } break; case FRAME_STATE_CHECK: if (check_byte_idx 0) { if (hex_char_to_val(ch) ! 0xFF) { check_recv hex_char_to_val(ch) 4; check_byte_idx 1; } else { frame_state FRAME_STATE_IDLE; } } else { if (hex_char_to_val(ch) ! 0xFF) { check_recv | hex_char_to_val(ch); if (check_recv check_sum) { frame_state FRAME_STATE_CR; } else { frame_state FRAME_STATE_IDLE; } } else { frame_state FRAME_STATE_IDLE; } } break; case FRAME_STATE_CR: if (ch FRAME_TAIL_CR) { frame_state FRAME_STATE_LF; } else { frame_state FRAME_STATE_IDLE; } break; case FRAME_STATE_LF: if (ch FRAME_TAIL_LF) { frame_done_flag 1; } frame_state FRAME_STATE_IDLE; break; } }状态机的流转过程是IDLE状态只等“$”收到后清空所有累加变量进入BODYBODY状态把每个非“”字符存进缓冲同时累加异或校验如果遇到“”就转入CHECK等待两位十六进制校验字符校验字符收满两位后和计算值比对一致就进入CR状态等待回车收到回车后进入LF状态等待换行收到换行则整帧完成置位frame_done_flag。整个过程中任何一步发现字符不符合预期立刻回到IDLE重新等“$”。这里有两个值得特别说明的细节。第一个是BODY状态里如果又遇到了“$”说明当前这个包异常比如上一帧的数据还没结束新一帧就进来了此时直接重置缓冲、重开一帧而不是继续把“$”当正常字符存进去。这个逻辑能让程序面对杂乱数据时快速自愈不会因为一个坏帧卡死状态机。第二个细节是长度保护rx_len超过MAX_FRAME_LEN时直接回到IDLE防止异常数据把数组写穿。数组越界写入是嵌入式开发里最危险的隐患之一它不像编译错误会马上报出来而是可能悄悄破坏别的变量表现为“程序偶尔莫名其妙跑飞”排查难度极高。3.3 校验值转换与帧完成判定CHECK状态里收到的是两个十六进制字符需要转换成真正的数值再和check_sum比较。转换函数实现如下static uint8_t hex_char_to_val(uint8_t ch) { if (ch 0 ch 9) { return ch - 0; } if (ch A ch F) { return ch - A 10; } if (ch a ch f) { return ch - a 10; } return 0xFF; }这里有个细节要强调校验字符的各位权重。第一个字符是高四位第二个字符是低四位所以check_recv先被赋值为“第一个字符左移4位”然后与第二个字符直接相或。比如收到的校验字符是“4E”第一个字符“4”转成0x4左移四位得到0x40第二个字符“E”转成0xE相或得到0x4E正好等于校验值。同时代码兼容了大小写。上位机用“%02X”格式化输出时生成的是大写校验符有些工具或人写的上位机会生成小写兼容小写能省去一个“明明协议一样、程序就是不识别”的排查过程。这点我在项目里吃过亏后来统一在代码里兼容才消停。帧完成标志frame_done_flag被置位以后主循环就能感知到一帧完整数据已经到达。注意这里用的是volatile修饰保证主循环读它时能拿到最新值而不是被编译器优化成缓存副本。嵌入式开发里ISR和主循环共享的变量一定要加volatile这是一个新手老手都容易忽略的坑。3.4 主循环消费与命令分发中断只负责“认帧”真正处理命令的动作放在主循环里。主循环每轮检查frame_done_flag如果置位就说明有一个完整合法的帧已经躺在rx_buf里可以拿出来解析执行了。while (1) { if (frame_done_flag) { frame_done_flag 0; text_frame_handle(); } // 其他任务 } static void text_frame_handle(void) { char cmd[8] {0}; int arg1 0, arg2 0; char *body (char *)(rx_buf 1); if (sscanf(body, %7[^,],%d,%d, cmd, arg1, arg2) 3) { if (strcmp(cmd, LED) 0) { led_ctrl(arg1, arg2); text_frame_send(ACK,OK); } else { text_frame_send(ERR,1); } } else { text_frame_send(ERR,2); } }为什么不在中断里直接处理命令因为中断服务函数要求短小精悍里面做sscanf、strcmp、控制硬件一旦命令处理逻辑变复杂中断占用时间过长下一个串口字节可能就丢了。正确做法就是中断里只做轻量级的状态机和缓冲主循环慢悠悠地消费两边各司其职。实际项目里我更推荐自己写一个简单的字符串分割函数来替代sscanf避免C库里的scanf族函数在嵌入式环境下占据较大的代码空间、并存在格式解析异常的风险。分割逻辑无非是遍历数组找逗号、用strncpy截字段、再转数字几十行代码搞定。如果遇到半包半路的场景比如上位机发到一半突然停了状态机停在CR或CHECK状态此时不需要特殊处理因为后续数据到达时状态机会因为字符不匹配自动回IDLE。如果你担心长时间等不到后续数据导致状态机一直卡着可以加一个软件超时主循环用系统节拍记录“距上次收到有效帧字符的时间”超过比如200毫秒就强制把状态机复位到IDLE。这个扩展不复杂但能让协议对残缺帧的容错性更好。4. 发送封装与应答机制让上下位机对话闭环4.1 数据包发送的封装方法接收有了发送还没有。要形成一个完整的通信闭环CH32V307也得能按同样的帧格式往外吐数据。发送端的核心工作有两个计算校验值、拼装完整帧字符串。校验计算函数和接收端用的是同一套异或逻辑uint8_t text_frame_calc_check(const char *data, uint8_t len) { uint8_t chk 0; for (uint8_t i 0; i len; i) { chk ^ (uint8_t)data[i]; } return chk; }然后是单字符发送和字符串发送。USART的TXE标志表示发送数据寄存器为空可以写入下一个字节这是最稳妥的轮询发送方式。void USART1_SendString(const char *str) { while (*str) { while (USART_GetFlagStatus(USART1, USART_FLAG_TXE) RESET); USART_SendData(USART1, (uint8_t)(*str)); } } void text_frame_send(const char *body) { uint8_t chk text_frame_calc_check(body, (uint8_t)strlen(body)); char frame[64]; sprintf(frame, $%s*%02X\r\n, body, chk); USART1_SendString(frame); }调用起来非常直接你想回一条“温度正常”之类的状态信息只要写text_frame_send(ACK,OK); text_frame_send(TEMP,25,6);发送方自动把校验值算好、把帧头和帧尾加上外部完全不用关心细节。这里有一个值得提醒的点发送帧时要保证frame数组足够大。如果body很长比如上报传感器数据携带十几个字段64字节可能不够用多少开多少别傻乎乎地固定一个过小缓冲然后往里硬塞。4.2 应答机制与错误码约定有了发送能力就可以设计应答机制了。我推荐一个简单可靠的约定设备收到合法且能识别的命令后回一帧“ACK,OK”收到校验失败或者帧格式异常的包不回任何数据让上位机超时重发收到合法帧但命令字不认识、参数越界回“ERR,错误码”。错误码可以约定成错误码含义0校验失败1未知命令2参数个数不对3参数数值越界这个机制的好处是上位机根本不需要关心底层串口细节它只做两件事发命令等待ACK或者ERR。超时没收到就重发收到ERR就知道哪里不对。在实际项目中这套“命令-应答-超时重发”的模型能挡掉大量由于线缆松动、噪声干扰、上位机逻辑错误导致的问题。这里我多说一句校验失败的包我选择不回复。有人问为什么不回ERR,0因为整帧的校验值都错了ERR本身也可能被干扰传歪回复的意义不大。上位机走超时重发这条兜底路径反而更简单可靠。记住协议设计的目标是让复杂问题简单化而不是把所有异常路径都写成代码。4.3 多串口场景下的状态机复用CH32V307不止一个串口实际项目里经常是USART1接上位机、USART2接传感器模块这样分工。如果把本章的状态机代码直接复制一份给USART2代码冗余不说改了USART1的解析逻辑还得同步改USART2的维护性很差。更好的做法是把状态机相关变量封装成一个结构体每个串口维护自己的实例。示意如下typedef struct { frame_state_t state; uint8_t buf[MAX_FRAME_LEN]; uint16_t len; uint8_t check_sum; uint8_t check_recv; uint8_t check_byte_idx; uint8_t done_flag; } text_frame_ctx_t; static text_frame_ctx_t frame_ctx[2];这样USART1的中断处理函数调text_frame_parse(frame_ctx[0], ch)USART2的中断处理函数调text_frame_parse(frame_ctx[1], ch)。解析逻辑完全共用只有数据隔离。等你后面用到RS485、CAN转串口的板子时这套结构体的意识会帮你节省大量重构时间。5. 串口调试避坑实录乱码、半包、粘包一次说清5.1 上位机显示乱码先查波特率再查晶振串口调试最常见的现象就是收到乱码。大多数情况下乱码的根因是波特率不匹配。你串口助手设置9600板子跑115200收出来的字符基本就是一堆乱码。所以第一步永远是确认两边波特率完全一致包括小数位。116000和115200差一点也会偶尔出错。第二种情况是波特率数值没错但芯片实际跑出的串口时钟不准。CH32V307使用外部晶振时晶振如果选的8MHz但代码里倍频系数是按8M算的实际晶振如果有偏差串口波特率就会有系统性偏差。这种问题用逻辑分析仪抓一下TX引脚的波形量一下实际波特率很快能看出来。我建议项目初期就养成用逻辑分析仪的习惯比肉眼看串口助手判断可靠得多。还有一种乱码是收的中文变成乱码那是编码问题串口助手显示编码设置和发送端不一致导致的。本章协议全部用ASCII字符天然没有这个烦恼这也是文本协议的优势之一。5.2 半包、粘包的实际表现与对策半包就是一帧数据没有完整到达。串口是流式传输上位机分两次发送同一帧数据两次之间隔了几十毫秒这种情况叫半包。如果代码是“等收集到固定长度再解析”的模式半包直接导致程序一直等卡死在那。状态机方案天然免疫半包它不管数据什么时候到全来一个字节就认一个字节状态还没跳完就继续等不会有“收集未完成就超时”的问题。粘包就是两个帧连着到达中间没有间隔。上位机把“$LED,1,2554E\r\n$LED,0,0XX\r\n”一次性发出来状态机处理完第一帧的\r\n后回到IDLE紧接着就能识别第二帧的$。这就是为什么帧头帧尾必须准确而不能靠延时判断的原因时间间隔并不可靠字符边界才可靠。我在调试过程中碰到过一个真实案例上位机通过WiFi模块透传数据WiFi网络本身会有缓冲和重传数据到达时间完全不规律典型的高延迟和高抖动场景。用定时器攒包方式一条命令经常被截断或者合并后来改成状态机解析问题立刻消失配合超时复位机制整个链路的健壮性明显提升。5.3 中断里的安全细节串口接收中断里最能藏坑的是flags的清除操作。使用CH32V307标准库时读USART_ReceiveData本身就会清除RXNE标志有些时候再手动调用USART_ClearITPendingBit也不会出错。但在某些中断标志处理不当的场景下可能出现中断反复触发、程序卡死在ISR里的情况。建议先读数据、再清标志顺序不要反如果你的库版本里Clear函数存在保留调用也无妨。还有一个我提过但值得再强调的点中断服务函数里禁止做任何耗时操作。比如在解析到ACK后直接调用text_frame_send去发送回复如果TX正处于被占用的状态这个发送可能会阻塞很长时间。阻塞期间RXNE的数据就会积压单字节接收模式下必然丢。正确姿势永远是ISR里只放状态机解析回复发送放到主循环的帧处理函数里去做。缓冲区方面MAX_FRAME_LEN设为64对文本命令已经比较宽裕但你要确保上位机的单帧长度绝不会超过这个数。协议设计时最好明文规定“单帧最大64字节”上位机按这个限制组帧。万一真收到超长帧状态机会因为长度越界直接回IDLE宁可丢帧也不破坏内存这是底线。5.4 常见问题速查表我把实际操作里最常遇到的几个问题整理成速查表方便你对照排错。现象可能原因处理办法收到全乱码波特率不一致或晶振偏差太大统一波特率用逻辑分析仪测量实际波形频率一帧收不全帧尾缺少\r\n或帧尾设置不一致上位机发送时勾选“发送新行”或手动在命令末尾补\r\n解析总是失败校验值计算范围不一致确认收发双方的校验范围都是“$后到*前”不含两者校验值看起来对不上上位机发送的是小写校验符接收代码兼容a-f/A-F/0-9偶发丢字符串口中断优先级被更高优先级中断抢占提高串口中断抢占优先级缩短其他ISR耗时命令执行两次上位机同时勾了自动加\r\n和自己加帧尾检查串口工具设置避免重复帧尾程序偶尔跑飞接收缓冲越界写入加长度保护单帧长度必须强制设上限最后再分享一个根据个人经验得来的技巧在做串口协议联调的时候不要一上来就用上位机完整工程去跑先用串口助手手动发几帧确认协议通了再对接上位机代码。这样能快速把问题隔离在“协议层”还是“上位机逻辑层”。等文本协议这章跑顺了你再去接触DMA空闲中断接收、环形缓冲这些进阶方案会发现一切水到渠成。这章的收发改法往哪个方向扩展都稳。
