STM32自定义串口协议设计：十六进制转十进制实现与状态机解析-平芜编程栈

1. 串口协议设计的整体思路与选型考量

1.1 为什么要在STM32上自定义串口协议

很多刚接触STM32的朋友，第一次点灯、第一次串口打印“Hello World”之后，紧接着就会遇到一个很现实的问题：上位机发来一串数据，怎么让单片机准确理解并执行？直接收一个字节判断一个字节，在简单场景下能用，但只要数据量一大、指令一多，代码就会变成一团乱麻。自定义串口协议就是来解决这个问题的。

我做过不少基于STM32的项目，从环境监测到电机控制，几乎每一个都绕不开串口通信。串口本身只负责把字节一个一个搬过去，它不关心这些字节是什么意思。协议就是双方约定好的“暗号”——帧头是什么、数据多长、怎么校验、收到之后干什么。没有协议，通信就是鸡同鸭讲；有了协议，哪怕波特率有微小偏差、偶尔丢一个字节，也能通过校验机制发现并处理。

以“十六进制转十进制”为例，这个需求看起来简单，但背后涉及的东西一点都不少。上位机可能发来“0x1A”这样的十六进制字符串，也可能直接发来一个字节0x1A，STM32需要识别这是哪种格式，然后把它转换成十进制数值，再通过串口返回结果。如果没有一套清晰的协议，你很难区分“这是要转换的数据”还是“这是要修改波特率的指令”。

1.2 协议帧格式的选型与设计

设计一个自定义串口协议，核心就是定义帧格式。我见过很多种做法，有纯文本的AT指令风格，也有纯二进制的紧凑帧。对于STM32这种资源有限的单片机，我一般推荐二进制帧，原因有三：解析效率高、占用带宽小、不容易产生歧义。

一个典型的二进制帧结构可以这样设计：

字段	长度	说明
帧头	2字节	固定为0xAA 0x55，用于帧同步
命令字	1字节	标识这条帧的功能，比如0x01表示十六进制转十进制
数据长度	1字节	后续数据区的字节数
数据区	N字节	实际载荷，N由数据长度字段决定
校验和	1字节	从帧头到数据区所有字节的累加和取低8位

这个结构的好处是：帧头固定，接收方可以通过状态机逐字节判断；数据长度明确，不会出现粘包问题；校验和能过滤掉大部分传输错误。你可能会问，为什么不用CRC？CRC当然更可靠，但对于短帧来说，累加和已经够用了，而且计算量小，在STM32上几乎不占时间。

注意：帧头选择0xAA 0x55不是随便定的。这两个字节在二进制里是10101010和01010101，交替的0和1有利于接收方做位同步，尤其是在波特率较高时能减少误判。

1.3 十六进制与十进制转换在协议中的位置

在这个项目里，“十六进制转十进制”是核心业务逻辑，但它不是孤立存在的。它需要被封装在协议的数据区里。比如上位机要转换“0x1A”，可以发送这样一帧：

AA 55 01 01 1A 1B

其中AA 55是帧头，01是命令字（表示十六进制转十进制），01是数据长度（1个字节），1A是数据（十六进制数0x1A），1B是校验和（AA+55+01+01+1A=0x11B，取低8位为0x1B）。

STM32收到这一帧后，解析出数据0x1A，把它转换成十进制26，然后组织返回帧：

AA 55 81 01 1A 1B

这里命令字变成0x81，表示这是对0x01命令的响应，数据区仍然是0x1A，但上位机知道这是结果。当然，你也可以返回十进制字符串“26”，但那样数据长度会变化，协议要能兼容。

这种设计把“转换”这个动作变成了协议的一个命令，后续要加新功能，比如十进制转十六进制、进制转换、数据校验，只需要增加命令字即可，框架不用动。这就是自定义协议的价值——可扩展。

2. 核心细节解析与实操要点

2.1 STM32串口外设的配置要点

在写协议解析代码之前，先把串口外设配置好。我用的是STM32F103C8T6，标准库和HAL库都试过，这里以HAL库为例，因为现在新项目基本都用HAL了。配置串口主要关注几个参数：波特率、数据位、停止位、校验位、中断优先级。

波特率我一般选115200，这个速率在STM32上很稳，大多数USB转串口芯片也都支持。数据位8位，停止位1位，无校验，这是最常用的组合。中断优先级要设置得合理，如果系统里还有定时器中断、DMA中断，串口接收中断的优先级不能太低，否则容易丢数据。

huart1.Instance = USART1; huart1.Init.BaudRate = 115200; huart1.Init.WordLength = UART_WORDLENGTH_8B; huart1.Init.StopBits = UART_STOPBITS_1; huart1.Init.Parity = UART_PARITY_NONE; huart1.Init.Mode = UART_MODE_TX_RX; huart1.Init.HwFlowCtl = UART_HWCONTROL_NONE; huart1.Init.OverSampling = UART_OVERSAMPLING_16; HAL_UART_Init(&huart1);

配置完之后，要开启接收中断。我习惯用HAL_UART_Receive_IT一次接收一个字节，然后在中断回调里把字节丢进环形缓冲区。为什么不一次接收多个？因为协议帧长度不固定，一次接收多个反而不好处理边界。

uint8_t rx_byte; HAL_UART_Receive_IT(&huart1, &rx_byte, 1);

然后在HAL_UART_RxCpltCallback里处理：

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart->Instance == USART1) { ring_buffer_put(&rx_ring, rx_byte); HAL_UART_Receive_IT(&huart1, &rx_byte, 1); } }

实操心得：环形缓冲区的大小要留够。我一般设256字节，对于115200波特率来说，足够缓冲一帧数据了。如果缓冲区太小，主循环处理不及时，新来的字节会覆盖旧数据，导致帧解析错乱。

2.2 状态机解析协议帧的实现

协议解析的核心是一个状态机。我见过有人用HAL_UART_Receive阻塞接收，然后在一个大循环里判断，那种写法在简单场景能用，但一旦数据量上来就会卡死。状态机的好处是每来一个字节只做一次判断，不阻塞，效率高。

状态机可以这样设计：

状态0：等待帧头第一个字节0xAA
状态1：等待帧头第二个字节0x55
状态2：接收命令字
状态3：接收数据长度
状态4：接收数据区，根据长度计数
状态5：接收校验和，校验通过则处理

typedef enum { STATE_IDLE, STATE_HEADER1, STATE_HEADER2, STATE_CMD, STATE_LEN, STATE_DATA, STATE_CHECKSUM } parse_state_t; parse_state_t state = STATE_IDLE; uint8_t frame_buf[64]; uint8_t data_len = 0; uint8_t data_index = 0; uint8_t checksum = 0; void parse_byte(uint8_t byte) { switch (state) { case STATE_IDLE: if (byte == 0xAA) { state = STATE_HEADER1; checksum = byte; } break; case STATE_HEADER1: if (byte == 0x55) { state = STATE_HEADER2; checksum += byte; } else { state = STATE_IDLE; } break; case STATE_HEADER2: frame_buf[0] = byte; // 命令字 checksum += byte; state = STATE_CMD; break; case STATE_CMD: data_len = byte; frame_buf[1] = byte; checksum += byte; data_index = 0; if (data_len > 0) { state = STATE_DATA; } else { state = STATE_CHECKSUM; } break; case STATE_DATA: frame_buf[2 + data_index] = byte; checksum += byte; data_index++; if (data_index >= data_len) { state = STATE_CHECKSUM; } break; case STATE_CHECKSUM: if (byte == (checksum & 0xFF)) { handle_frame(frame_buf, data_len); } state = STATE_IDLE; break; } }

这个状态机逻辑清晰，每个状态只做一件事。handle_frame函数根据命令字分发处理，比如命令字0x01就调用十六进制转十进制的函数。

注意：状态机里不要做耗时操作。handle_frame里如果要做复杂计算，最好只做标记，让主循环去处理。中断里执行时间太长会影响其他中断响应。

2.3 十六进制转十进制的算法实现

十六进制转十进制，本质上是按权展开求和。比如0x1A = 1×16 + 10×1 = 26。在STM32上实现，有两种常见做法：一种是直接计算，一种是查表。

直接计算适用于任意长度的十六进制数：

uint32_t hex_to_dec(uint8_t *hex, uint8_t len) { uint32_t result = 0; for (uint8_t i = 0; i < len; i++) { result = result * 16 + hex[i]; } return result; }

这里hex数组里存的是每个十六进制位的数值，比如0x1A就存成{0x01, 0x0A}。如果上位机发来的是ASCII字符串“1A”，需要先转换成数值：

uint8_t ascii_to_hex(uint8_t c) { if (c >= '0' && c <= '9') return c - '0'; if (c >= 'A' && c <= 'F') return c - 'A' + 10; if (c >= 'a' && c <= 'f') return c - 'a' + 10; return 0; }

如果数据长度固定，比如只转换一个字节，那更简单：

uint32_t hex_byte_to_dec(uint8_t hex) { return (hex >> 4) * 10 + (hex & 0x0F); }

等等，这里要小心。(hex >> 4) * 10 + (hex & 0x0F)这个公式是错的。比如0x1A，高四位是1，低四位是10，1×10+10=20，不是26。正确的做法是(hex >> 4) * 16 + (hex & 0x0F)，或者直接用hex本身，因为0x1A在内存里就是26。

踩过的坑：有一次我写了个“十六进制转十进制”函数，结果发现输出不对，查了半天才发现是把乘16写成了乘10。十六进制转十进制，权值是16的幂，不是10的幂。这个错误很低级，但确实容易犯，尤其是在赶项目的时候。

如果是要把十进制数转成十六进制字符串返回，可以用sprintf：

char buf[16]; sprintf(buf, "%lu", dec_value);

但sprintf在STM32上比较占资源，如果只是返回数值，直接发二进制更高效。我一般根据上位机需求决定，如果上位机是Qt或Python写的，发二进制完全没问题。

3. 实操过程与核心环节实现

3.1 工程搭建与串口初始化

新建一个STM32工程，我用的是STM32CubeMX生成初始化代码，然后手动添加协议解析部分。步骤大致如下：

在CubeMX里选好芯片型号，配置时钟树，外部晶振8MHz，系统时钟72MHz。
使能USART1，模式设为异步，波特率115200，开启中断。
生成代码，打开工程。
在main.c里添加环形缓冲区、状态机、处理函数。

时钟配置很关键，如果时钟不对，波特率就会偏，通信会出错。我一般用外部晶振，因为内部RC振荡器精度不够，长时间通信容易累积误差。72MHz主频下，USART1挂在APB2总线上，时钟是72MHz，波特率115200的分频系数计算出来是39.0625，实际会有一点误差，但在允许范围内。

// 在main函数初始化部分 MX_USART1_UART_Init(); HAL_UART_Receive_IT(&huart1, &rx_byte, 1);

然后主循环里不断从环形缓冲区取字节，喂给状态机：

while (1) { uint8_t byte; while (ring_buffer_get(&rx_ring, &byte)) { parse_byte(byte); } // 其他任务 }

这种“中断收，主循环解析”的架构，既保证了接收的实时性，又避免了在中断里做复杂处理。

3.2 完整帧的收发测试

测试的时候，我用的是串口调试助手，手动发送十六进制帧。比如发送AA 55 01 01 1A 1B，预期STM32返回AA 55 81 01 1A 1B。

第一次测试的时候，什么都没收到。排查过程如下：

先检查硬件，TX/RX有没有接反。我用的是USB转TTL模块，TX接STM32的RX，RX接STM32的TX，这个没错。
再检查波特率，两边都是115200，没错。
然后用示波器看STM32的TX引脚，发现发送的时候有波形，说明STM32确实在发。
最后发现是串口调试助手的问题，它默认是ASCII模式，我发的十六进制被当成字符串了。切换到十六进制发送模式后，一切正常。

实操心得：串口调试助手一定要确认发送模式。很多新手在这里卡住，以为是代码问题，其实是工具设置问题。我一般会在代码里加一个“收到任何字节就原样返回”的测试逻辑，先确认链路通畅，再调试协议。

返回帧的组装也很简单：

void send_response(uint8_t cmd, uint8_t *data, uint8_t len) { uint8_t frame[64]; uint8_t idx = 0; uint8_t sum = 0; frame[idx++] = 0xAA; frame[idx++] = 0x55; frame[idx++] = cmd | 0x80; // 响应命令字 frame[idx++] = len; sum = 0xAA + 0x55 + (cmd | 0x80) + len; for (uint8_t i = 0; i < len; i++) { frame[idx++] = data[i]; sum += data[i]; } frame[idx++] = sum & 0xFF; HAL_UART_Transmit(&huart1, frame, idx, 100); }

这里cmd | 0x80是把命令字的最高位置1，表示这是响应。上位机收到后，用cmd & 0x7F就能还原原始命令字。

3.3 多字节十六进制数的处理

实际项目中，十六进制数往往不止一个字节。比如上位机要转换“0x1234”，这是两个字节。协议数据区可以这样组织：

AA 55 01 02 12 34 4A

数据长度是2，数据是0x12和0x34。STM32解析后，按大端模式组合成0x1234，再转成十进制4660。

uint32_t hex_array_to_dec(uint8_t *data, uint8_t len) { uint32_t result = 0; for (uint8_t i = 0; i < len; i++) { result = (result << 8) | data[i]; } return result; }

注意这里用的是移位，不是乘16。因为每个字节代表8位，两个字节组合就是高8位左移8位再或上低8位。这个逻辑和十六进制字符串转数值不一样，字符串是每4位一个字符，字节是每8位一个单位。

如果上位机发来的是ASCII字符串“1234”，那数据区就是0x31 0x32 0x33 0x34，需要先转成数值：

uint32_t ascii_hex_to_dec(uint8_t *str, uint8_t len) { uint32_t result = 0; for (uint8_t i = 0; i < len; i++) { result = result * 16 + ascii_to_hex(str[i]); } return result; }

两种方式各有适用场景。二进制方式效率高，适合数据量大的场合；ASCII方式可读性好，适合调试和人工输入。

3.4 返回结果的格式选择

返回十进制结果时，我一般提供两种格式，由命令字区分。命令字0x01返回二进制数值，命令字0x02返回ASCII字符串。这样上位机可以根据需要选择。

二进制返回：数据区就是十进制数的字节表示。比如4660是0x1234，数据区就是12 34。

ASCII返回：数据区是字符串“4660”，即34 36 36 30。

void handle_hex_to_dec(uint8_t *data, uint8_t len, uint8_t mode) { uint32_t dec = hex_array_to_dec(data, len); if (mode == 0x01) { uint8_t buf[4]; buf[0] = (dec >> 24) & 0xFF; buf[1] = (dec >> 16) & 0xFF; buf[2] = (dec >> 8) & 0xFF; buf[3] = dec & 0xFF; send_response(0x01, buf, 4); } else { char str[12]; uint8_t n = sprintf(str, "%lu", dec); send_response(0x02, (uint8_t *)str, n); } }

注意：sprintf返回的是写入的字符数，不包括结尾的\0。发送的时候不要发\0，否则上位机可能会多收到一个空字符。

4. 常见问题与排查技巧实录

4.1 串口接收丢数据怎么办

丢数据是串口通信最常见的问题。原因通常有三个：中断优先级太低、缓冲区太小、处理时间太长。

中断优先级方面，如果系统里有其他高优先级中断频繁触发，串口中断可能被延迟响应。STM32的USART中断优先级可以设得高一点，比如抢占优先级1，子优先级0。但也不要设成最高，否则会影响系统滴答定时器。

缓冲区方面，我建议至少256字节。如果波特率是115200，每秒最多传输11520字节，256字节的缓冲区能缓冲约22毫秒的数据。主循环一般几毫秒就能跑一圈，足够处理了。

处理时间方面，状态机解析一个字节只需要几十个时钟周期，非常快。但如果handle_frame里做了浮点运算或者大量字符串操作，就会拖慢主循环。我的做法是handle_frame只做数据拷贝和标记，实际处理放到主循环里。

4.2 校验和计算错误的排查

校验和错误通常是因为计算范围不一致。发送方和接收方必须约定好：校验和是从帧头开始算，还是从命令字开始算？包不包括校验和本身？

我的习惯是从帧头第一个字节开始，累加到数据区最后一个字节，不包括校验和本身。这个规则要在协议文档里写清楚，否则联调的时候会互相扯皮。

还有一种情况是数据长度字段算错了。比如数据区实际有3个字节，但长度字段写的是2，接收方就会少收一个字节，校验和自然对不上。排查的时候，可以先把校验和功能关掉，直接看数据内容对不对，确认数据没问题后再开校验。

4.3 十六进制转十进制结果不对的几种情况

结果不对，先看输入数据对不对。可以在handle_frame里把收到的数据原样返回，确认上位机发的是什么。我遇到过上位机发的是ASCII字符串，但我按二进制解析了，结果当然不对。

再看转换算法。如果是单字节，直接用hex值就是十进制。如果是多字节，注意字节序。大端是高位在前，小端是低位在前。STM32是小端模式，但协议里我一般约定大端传输，这样和网络字节序一致，上位机处理也方便。

还有一种情况是数据类型溢出。uint32_t最大能表示4294967295，如果十六进制数超过4个字节，就会溢出。这时候要用uint64_t，或者分段处理。

4.4 常见问题速查表

现象	可能原因	排查方法	解决方案
完全无返回	硬件连接错误	检查TX/RX是否交叉连接	交换TX和RX
返回乱码	波特率不匹配	确认双方波特率一致	统一设为115200
偶尔丢帧	缓冲区溢出	增大环形缓冲区	改为256字节以上
校验和错误	计算范围不一致	打印校验和计算过程	统一从帧头开始算
转换结果错误	字节序问题	检查数据组合方式	统一用大端模式
中断不触发	中断未使能	检查NVIC配置	使能USART中断