做智能车调车、搞无人机调试、或者蹲在实验室里盯嵌入式数据的同学大概率都遇到过这样的场景车已经上赛道跑了你还想在电脑上实时看到编码器数值、电压曲线和姿态角度这时候有线串口就是一根甩不掉的尾巴人得跟着车跑。逐飞科技的无线透传模块就是为了解决这个痛点出现的它本质上就是把串口线剪断换成无线收发链路让调试数据可以从单片机一路透传到串口助手或上位机里。但很多同学用起来会发现一个非常现实的问题真正要把 int、float 这些不同类型的数据稳定、可读、按需格式化地发出来并不是调一个库函数那么简单。这篇文章就围绕逐飞科技无线串口这条链路从最基础的数据类型传输讲起再到类 printf 格式化输出的完整实现最后补上一层简单可靠的帧协议。每一步都有可以直接抄作业的代码、选型理由和实际踩坑记录。无论是准备智能车竞赛、电子设计竞赛还是日常做嵌入式调试的同学这篇文章都能帮你少走几个晚上调串口的弯路。1. 无线串口到底在传什么int、float背后的字节真相1.1 从逐飞无线串口说起一条透明通道坏的只是使用姿势逐飞的无线透传模块在智能车竞赛里几乎是标配外设。很多人第一次拿到手觉得它就应该像有线串口一样“发什么收什么”这个认知方向是对的但它带来的实际体验往往很差有人发一个 int上位机收到一堆看不懂的符号有人发一个 float打印出来小数位全乱还有人一帧数据里既有数字又有单位串口助手显示得歪歪扭扭。这些问题的根源其实不在无线模块本身而在于我们没有搞明白一件事无线串口是一条透明字节通道它对内容没有解释能力。单片机通过 UART 外设发出去的是什么字节接收端收到的就是什么字节。它根本不知道你发的是整数、浮点数、字符串还是结构体。真正控制数据含义的是发送端的编码方式和接收端的解析方式。所以“无线串口传数据”这个需求严格来说不是“把数据发出去”就完了而是要同时解决“发送端如何把不同类型数据编码成字节流”和“接收端如何从字节流中还原出原始数据”这两个问题。逐飞模块在硬件上已经把无线收发、天线匹配、空中协议这些东西封装好了它给你的就是一个类似“虚拟串口”的接口你调用的还是 uart_write_byte、uart_write_string 这一组底层接口。也正因为如此不同的使用姿势会得到天差地别的结果。理解了这条通道只是搬运工你才会去关心接下来这些类型层面的细节。1.2 一个int四个字节一个float也是四个字节先说整数。在 STM32、TC264、MK66 这些智能车常用平台上int 通常是 32 位也就是 4 个字节。你在 C 代码里写int speed 1200;这个数在内存里不是存储成字符 1、2、0、0而是按照二进制补码形式占据连续 4 个字节。如果在小端模式下低字节在前那么 12000x04B0这 4 个字节依次是 0xB0、0x04、0x00、0x00。浮点数更微妙一些。一个 float 也是 4 字节但它按 IEEE 754 标准存储分为 1 位符号位、8 位指数位、23 位尾数位。比如 123.456f 这个数它在内存里是一段肉眼完全看不出规律的二进制序列。如果你把这 4 个字节直接通过无线串口发出去接收端如果按“文本”去解码看到的大概率是不可打印字符。这就是很多人“发 int 正常、发 float 就乱码”的根本原因你用了适合文本传输的方式去传输一个二进制编码。我建议在写任何发送代码之前先在单片机上做一个小实验定义几个 int、float 变量用uart_write_byte把它们的内存字节一个个发出来然后在串口助手里切到 HEX 显示亲眼看一看“数据在内存里的本来面目”。做过这个实验之后你会对后续的发送方案有非常直观的理解。1.3 为什么float要加f以及int类型长度为什么是个问题先回答 float 为什么加 f。C/C 里写3.14这个字面量默认类型是 double占 8 字节只有写成3.14f才明确是 float占 4 字节。在嵌入式开发里这不是抠门是实打实的性能问题。很多飞控和车模主控是 Cortex-M0 或者不带 FPU 的 M3/M4 核心double 的软浮点运算比 float 慢很多代码体积也会变大。更关键的是printf 族函数属于变参函数调用时 float 会被隐式提升为 double 传入如果你的运行库里浮点格式化支持不完整打印结果就可能完全不对。所以我在代码里写浮点字面量时一律加 f能避免一批非常隐蔽的坑。然后是“求 int 类型数字长度”。别小看这个操作在格式化输出的时候它非常有用。比如你想让三路编码器数据在串口助手里右对齐、纵向对齐就需要知道打印数字占几位。%03d可以定死宽度但如果数据从 8 位变成 4 位固定宽度又不合适了。动态宽度的写法是printf(%*d, width, value)而这个 width 就需要动态计算。算长度可以循环除以 10也可以先判断范围我用得最多的还是这个int int_len(int32_t val) { int n 0; char tmp[12]; sprintf(tmp, %d, val); n strlen(tmp); return n; }虽然是用了 sprintf但在调试阶段完全够用。更底层的道理是你只有知道了一个数字要占多少个字符才能设计出好看的调试界面也才能合理分配发送缓冲区。2. 基础发送实战int和float的三套发送方案2.1 方案一逐字节发送原始内存数据第一种方案是直接把变量的内存字节拷贝出来一个一个发。这种做法最贴近底层带宽占用最小适合数据量大的场景。void uart_send_int32(int32_t val) { uint8_t buf[4]; memcpy(buf, val, 4); for (uint8_t i 0; i 4; i) { uart_write_byte(UART_DEBUG, buf[i]); } } void uart_send_float(float val) { uint8_t buf[4]; memcpy(buf, val, 4); for (uint8_t i 0; i 4; i) { uart_write_byte(UART_DEBUG, buf[i]); } }这套代码的本质是把“数据”和“表现形式”完全剥离开。接收端如果要还原必须知道两件事第一这一组字节对应什么类型第二发送端是什么字节序。如果是两个同架构单片机之间通信比如 MCU 发给 MCU接收端直接 memcpy 回来就行。如果数据要发给 PC 上位机比如用 Qt 写调试工具那就得在协议里约定字节序或者在上位机里做大小端转换。这类发送方式最大的问题是不直观。你在串口助手里用文本模式看全是乱码切到 HEX 模式能看到类似B0 04 00 00这样的字节但还是没法一眼看出“这是 1200”。所以它更适合做批量数据的高速回传不适合给人看的调试打印。2.2 方案二转成ASCII字符串再发如果你希望数据发出去了直接能在串口助手里阅读那就得把数值转成字符串再发。这是大多数调试场景的首选因为“给人看”的需求通常是第一位。int 转字符串最省事的是sprintfchar buf[16]; sprintf(buf, %d, speed); uart_write_string(UART_DEBUG, buf);但要注意很多嵌入式标准库里的 sprintf 是重量级函数RAM 和 Flash 占用都不小。如果只是转一个整数我更推荐手写一个轻量转换void uart_send_int(int32_t val) { char buf[12]; char *p buf 11; uint8_t neg 0; if (val 0) { neg 1; val -val; } *p \0; if (val 0) { *(--p) 0; } else { while (val 0) { *(--p) 0 (val % 10); val / 10; } } if (neg) { *(--p) -; } uart_write_string(UART_DEBUG, p); }从后往前填充字符最后直接拿到字符串首指针不需要做反转。注意 val 的负值处理在 32 位平台上 -2147483648 取反会溢出所以实际产品代码里要改成 uint32_t 处理这也是我后来踩过的坑。float 发字符串要复杂一些。最直接的办法是用snprintf(buf, sizeof(buf), %.2f, val)一次性解决转字符串和小数点位控制。但如果你的运行库不支持%f那就得手工处理。核心思路是拆成整数部分和小数部分void uart_send_float(float val, uint8_t decimal) { char buf[24]; int32_t int_part (int32_t)val; int32_t frac_part; float frac val - (float)int_part; if (frac 0) frac -frac; frac_part (int32_t)(frac * 100.0f 0.5f); snprintf(buf, sizeof(buf), %d.%02d, int_part, frac_part); uart_write_string(UART_DEBUG, buf); }这里我固定取了两位小数如果你的数据需要动态小数位可以把 100.0f 换成pow(10, decimal)。加 0.5f 是做四舍五入否则浮点乘法取整经常出现1.199999被截成.19的尴尬。这条经验是血泪教训很多人 float 打出来最后一位总是差 1就是因为少了这个舍入。2.3 方案三自己写一个专用的浮点格式化打印函数方案二里的snprintf虽然方便但在部分压缩版运行库里%f支持可能被裁剪或者浮点格式化逻辑占用的 Flash 超过了你的预期。这时候你可以自己写一个“够用就好”的浮点格式化函数。我这个函数的设计目标很明确只支持十进制和固定指定位小数不支持科学计数法不需要填充对齐占用空间越小越好。int32_t my_pow10(uint8_t n) { int32_t r 1; while (n--) r * 10; return r; } void uart_printf_float(float val, uint8_t decimal) { char buf[24]; int32_t scale my_pow10(decimal); int32_t scaled (int32_t)(val * scale 0.5f); int32_t int_part scaled / scale; int32_t frac_part scaled % scale; if (frac_part 0) frac_part -frac_part; // 先发整数部分 uart_send_int(int_part); uart_write_byte(UART_DEBUG, .); // 再发小数部分前面补零 char tmp[12]; int i decimal - 1; while (i 0) { tmp[i--] 0 (frac_part % 10); frac_part / 10; } tmp[decimal] \0; uart_write_string(UART_DEBUG, tmp); }这套实现只用了整数运算完全绕开了浮点格式化支持在任何编译环境下都能跑。而且打包成一个函数之后调用起来和 printf 很接近。它的缺点是不能当场指定格式但作为基础工具函数完全够用。在嵌入式调试里“绕过坑”往往比“硬刚坑”更高效。3. 核心硬核在单片机上实现类printf3.1 为什么不能直接把printf塞进无线串口聊完了基础类型现在来到标题里最核心的部分类 printf。我们真的想在单片机上实现类似于printf(speed%d, temp%.2f\n, speed, temp)这样的能力把所有类型一网打尽。但这里我先泼一盆冷水很多人以为只要把fputc重定向到无线串口就能直接调 printf。这个方案在简单场景下确实能跑但它有几个隐患。第一printf 的完整实现非常占用资源在部分 M0 内核的小容量芯片上链接完 printf 后 Flash 直接告急。第二printf 是阻塞式的如果无线模块发送速度跟不上主循环会被卡住。第三在多任务或中断上下文里调用标准 printf它的内部状态可能会被打断出现数据错乱。所以我更愿意把“类 printf”理解成一个分层设计底层是实际的字节发送中间层是带长度限制的格式化解析上层是给业务代码用的一个变参接口。这样每一层都可以替换出问题也好排查。3.2 路径A重定向fputc到无线串口先看最简单的一条路。在 C 标准库中printf 最终会调用fputc来逐字符输出。只要你重写了fputcprintf 就会自动把字符送到无线串口。在大部分 Keil 工程里是这样的int fputc(int ch, FILE *f) { uart_write_byte(UART_DEBUG, (uint8_t)ch); return ch; }然后把所有调试信息都通过 printf 输出。这个方案我用过很长一段时间它确实省事但也有几个前提条件。Keil 环境里通常要勾选微库MicroLIB否则标准库的底层会和你自己的 printf 重定向打架。GCC 环境里用 newlib-nano 时如果printf不支持浮点你还得手动链接_printf_float这个符号这是新人最容易卡住的地方。老 CCS 环境里同样有这个问题比如经典的 CCS 3.3默认配置下 printf 对%f的支持很弱需要在工程选项里开启浮点运行时支持。正因为这些和环境绑定很深的问题我不太建议一上来就选重定向fputc作为主力方案它适合“快速验证串口链路通不通”这个阶段。3.3 路径Bvsnprintf加缓冲发送工程上的首选我更推荐的做法是把“格式化”和“真正发出去”拆开。借用vsnprintf先在一个局部缓冲区里把字符串拼好然后再用底层发送函数逐字节送出去。这样做的好处非常明显你能控制缓冲区长度、能计算格式化后的总长度、能在发送前做临界区保护还能避免直接把 printf 和无线模块绑死。下面这个函数是我工程里一直在用的基础版void uart_printf(const char *fmt, ...) { static char buf[128]; va_list args; uint16_t i; va_start(args, fmt); vsnprintf(buf, sizeof(buf), fmt, args); va_end(args); for (i 0; i sizeof(buf) buf[i]; i) { uart_write_byte(UART_DEBUG, buf[i]); } }参数里加了sizeof(buf)这是保命设计。没有长度限制的 sprintf 遇到格式串写太长直接踩内存轻则跑飞重则把中断向量表搞坏。实际调试串口数据时128 字节的缓冲在大部分场景下够用了如果一帧数据确实超过 128可以拆分逻辑也可以把缓冲区加长但要注意 SRAM 小的芯片别开太大。调用起来就像标准 printf 一样直接float temp 26.56f; int32_t speed 1280; uart_printf(temp%.2f, speed%d\n, temp, speed);输出效果就是一行整洁的文本在串口助手和上位机里都能直接阅读。和路径 A 相比路径 B 的唯一代价是多了一段缓冲区和一次vsnprintf调用但它换来的是极高的可控性这个交易在工程上非常划算。3.4 路径C无标准库的轻量级printf如果项目对代码体积特别敏感比如你用的是 16KB Flash 的芯片连标准库都不想链接那就得上轻量级 printf。这方面的代表作是 mpaland/printf 这个开源库也有人叫它“迷你 printf”。它的核心思路是只实现格式化输出中常用的一小部分能力避开标准库庞大的 IO 和 locale 依赖。使用起来也不复杂把printf.c和printf.h拷进工程然后直接调printf_或者你自己封装的接口void uart_printf(const char *fmt, ...) { static char buf[64]; va_list args; va_start(args, fmt); vsnprintf_(buf, sizeof(buf), fmt, args); va_end(args); for (uint16_t i 0; buf[i] i sizeof(buf); i) { uart_write_byte(UART_DEBUG, buf[i]); } }轻量级库在配置宏里可以开关浮点支持。开浮点体积大一些不开浮点体积能压得非常小。如果你只是发 int、float 和字符串它完全够用而且不依赖编译器自带的 stdio 实现跨平台移植性更好。需要注意一点有些精简库对*宽度修饰符和%g这类冷门格式支持不完整所以别把它当标准 C 库用按它的功能清单来写格式串才是正道。3.5 三类方案的对比与我的选型建议为了让你有一个直观的判断我把三套方案的适用场景整理成一个表格。对比维度重定向fputcvsnprintf缓冲发送轻量级printf依赖标准库完整依赖依赖vsnprintf不依赖Flash占用高中高低浮点支持看编译器开关看库实现可控开关多任务安全性差容易重入可加锁保护可加锁保护实现复杂度最低低中推荐场景快速验证链路日常调试主力资源紧张项目我的选型逻辑很简单日常调试和比赛项目优先用路径 B 的vsnprintf缓冲发送它平衡了开发效率和可控性到了项目末期如果资源紧张再切换到路径 C把浮点开关调整好路径 A 只作为“这个串口通不通”的烟囱测试。4. 从“能打印”到“不出错”给无线串口加一层协议4.1 裸打容易遇到的问题粘包、断帧、解析困难有了类 printf 之后你的数据在串口助手里的呈现已经非常漂亮了。但如果你想把数据送进上位机做曲线显示、数据记录又会遇到新的问题。直接发送uart_printf(temp26.5,speed1280\n)这种字符串接收端要解析出“”“,”这些分隔符代码写起来繁琐。更麻烦的是无线链路偶尔会丢字节一旦丢了一个逗号或者换行符一帧数据就可能解析错了。多帧数据衔接时还会出现粘包接收端很难判断这一帧的边界在哪里。你自己写代码调试还好万一上位机还要发给别人用没有统一的帧结构对方根本没法维护。所以我强烈建议从裸的文本打印升级到“帧协议 文本负载”的发送方式。协议负责切帧和校验文本负载负责可读性。4.2 一套很省内存的帧格式我的帧格式设计原则是简单、省内存、够用。完整的一帧结构如下字段字节数说明帧头110xAA帧头210x55类型1上层用途标识长度1payload 字节数payloadN实际数据校验和1帧头后所有字节累加和帧头0xAA 0x55的作用是让接收端快速找到帧边界。为什么用两个字节因为单个帧头在高噪声无线环境下容易被干扰两个字节能显著降低误同步概率。校验和用最简单的累加和因为无线模块本身有 CRC 校验这一层校验防的主要是“链路错误导致的一两个字节被破坏”。4.3 发送端封装和接收端状态机解析发送端我们基于前面的uart_printf再包一层。先做一个底层的帧发送函数void send_packet(uint8_t type, const uint8_t *payload, uint8_t len) { uint8_t sum type len; uart_write_byte(UART_DEBUG, 0xAA); uart_write_byte(UART_DEBUG, 0x55); uart_write_byte(UART_DEBUG, type); uart_write_byte(UART_DEBUG, len); for (uint8_t i 0; i len; i) { uart_write_byte(UART_DEBUG, payload[i]); sum payload[i]; } uart_write_byte(UART_DEBUG, sum); }然后做成变参接口这样业务代码里一行就能调用void packet_printf(uint8_t type, const char *fmt, ...) { static char buf[64]; va_list args; va_start(args, fmt); vsnprintf(buf, sizeof(buf), fmt, args); va_end(args); send_packet(type, (const uint8_t *)buf, strlen(buf)); }接收端解析用状态机。不建议一开始就上队列和操作系统先用一个简单的switch-case就能满足大多数调试验证需求typedef enum { ST_WAIT_AA, ST_WAIT_55, ST_GET_TYPE, ST_GET_LEN, ST_GET_DATA, ST_CHECK } rx_state_t; void uart_rx_byte(uint8_t byte) { static rx_state_t state ST_WAIT_AA; static uint8_t type; static uint8_t len; static uint8_t cnt; static uint8_t sum; static uint8_t buf[128]; switch (state) { case ST_WAIT_AA: if (byte 0xAA) state ST_WAIT_55; break; case ST_WAIT_55: state (byte 0x55) ? ST_GET_TYPE : ST_WAIT_AA; break; case ST_GET_TYPE: type byte; sum type; state ST_GET_LEN; break; case ST_GET_LEN: len byte; sum len; cnt 0; state (len 0) ? ST_GET_DATA : ST_CHECK; break; case ST_GET_DATA: buf[cnt] byte; sum byte; if (cnt len) state ST_CHECK; break; case ST_CHECK: if (sum byte) { // 校验通过在这里做帧处理 process_packet(type, buf, len); } state ST_WAIT_AA; break; default: state ST_WAIT_AA; break; } }这段代码的好处是不依赖阻塞等待一字节一字节地喂给状态机就行非常适合放在 UART 接收中断里调用。就算中间丢了几个字节回到ST_WAIT_AA再重新找帧头也能自动恢复同步。4.4 实测效果多路int/float数据同时跑用这套协议跑车模调试数据效果非常明显。我可以一行代码把三个不同量程的数据一起发出去packet_printf(FRAME_TYPE_DEBUG, ENC%d,VOLT%.2f,ANGLE%.2f, encoder_cnt, battery_volt, pitch_angle);接收端 PC 上位机只需要按帧头切包再按分隔符解析文本即可。我在自己的 Qt 上位机里就是用自定义的串口接收类把数据按process_packet的流程拆帧然后把文本负载交给解析函数。像“int 转 QString”“IP 地址转换 int”这类小工具在 Qt 里直接用QString::number处理数据接收或者用QHostAddress::toIPv4Address做配置项转换都是顺手的事。关键是底层协议保证了我上层解析时拿到的永远是完整的一帧不会因为无线丢包而出错。5. 排错手册无线串口调试高频问题实录5.1 中文乱码和乱码多半不是无线模块的问题遇到乱码第一反应不要怀疑是无线模块坏了。绝大多数“乱码”现象的根源发送端和接收端字符编码不一致。比如你的源码里写了中文字符串Keil 默认可能按 GBK 保存编译后发出来的是 GBK 字节流而串口助手如果按 UTF-8 解码自然就是一串乱码。反过来也一样UTF-8 源码发到 GBK 串口助手同样乱。我的处理习惯是无线调试链路上尽量不用中文全部用 ASCII 英文和数字。像temperature就写temp电压就写volt这样可以彻底绕开编码问题。如果非要在上位机端显示中文那就把编码方案在源码和上位机之间统一比如两边都用 UTF-8并在 IDE 里设置好源码编码。另一个“像乱码但不是乱码”的问题是波特率不一致。逐飞无线模块本身有波特率配置模块和单片机 UART 要保持一致PC 端串口助手也要设置一致。曾经有一次调试串口助手里全是乱码查了半天发现问题出在无线模块的收端波特率被配置成了 9600而发送端还是 115200两端对不上数据自然全乱。后来我习惯先跑一个简单的回环测试用uart_printf(test\n)发固定字符确认链路无误再接具体业务代码。5.2 浮点打印失效和double/float精度误区现象很典型printf(%d, speed)正常但printf(%.2f, temp)打出来是 0 或者干脆不打印。这通常不是你的浮点变量有问题而是运行库的浮点格式化没有链接进去。Keil 工程里要勾选使用微库GCC 工程里需要加-u _printf_float链接参数CCS 3.3 这类老环境还得到工程选项里找浮点支持开关。每次遇到这个问题我都先确认编译器是否真正支持%f再检查自己的代码。另外就是前面多次提到的精度问题。用 float 做运算显示的时候一定要限制有效位。比如float temp 26.6f直接%.10f打印会看到 26.6000003815 这种尾巴。所以我在大多数调试输出里只用%.2f既保留两位小数精度又避免把浮点误差暴露出来。double 和 float 的差别在 32 位嵌入式平台上很容易酿成大坑。double 占 8 字节软件模拟 double 运算极慢。如果某个函数参数是 double你传一个 float 进来编译器可能悄悄把它提升成 double性能下降不说代码体积也明显增大。这也是我在嵌入式代码里给所有浮点字面量加f后缀的原因明确告诉编译器这就是单精度不要做无谓的提升。5.3 数据长度对不上、校验不对、粘包断帧排查如果你发现接收端解析出来的数值和发送端完全对不上优先检查这几个点。第一是字节序不同架构之间通信一定要约定小端还是大端否则 int 的高低位互换数值必然错得离谱。第二是类型宽度int 在 ARM 平台 32 位但在 8051 内核是 16 位如果两端平台不同就必须显式使用int16_t、int32_t这类固定宽度类型。第三是帧边界很多人在接收端用strlen或者strstr去找 payload 末尾遇到二进制数据或特殊字符极易出错还是老老实实按帧长度字段解析更稳。校验不过的问题多发生在帧里某个字段被误修改或者发送端长度和实际填充长度不一致。我的排错手法是先打印收到的每一字节和计算得到的 checksum手动比对第一帧通常几秒钟就能发现问题。粘包和断帧的问题核心是接收端要依赖状态机解析而不是依赖“收到一段数据就去解析”。如果你用HAL_UART_RxCpltCallback这类中断回调把每一字节喂给状态机就不会因为数据快慢不均而解析出错。5.4 几个越早明白越省事的习惯写到最后分享几个让我少走弯路的习惯。第一个把所有调试输出都收敛到一个统一接口上。不管底层的发送方案怎么改业务代码只调packet_printf这样以后想换协议、换传输方式业务代码一行都不用动。第二个在关键数据里带上时间戳或者帧序号。这样一旦出现丢帧你能立刻知道丢了多少、丢在哪里排查效率远高于纯靠猜。第三个合理利用编译期开关控制调试输出等级在正式发布版本里只保留必要的帧避免无用的调试数据占满无线带宽。如果你觉得“单向输出调试信息”已经满足不了你了可以把串口输入通道也利用起来引入letter shell这类交互式命令行组件。它能让你在串口助手里直接敲命令、调参数、看变量比反复重新烧录固件高效得多。这个方向属于进阶玩法核心思路和本文讲的“格式化输出 帧协议”一脉相承需要你先把底层的发送链路掌握扎实。我在实际工程里体会到最重要的一点是把这些方案沉淀成自己的一套调试工具链而不仅仅是记住某一个库函数。逐飞的无线串口模块也好、类 printf 格式化输出也好本质上都是在帮你建立一条从单片机到上位机的“可靠信息通道”。调通了这条通道你才算真正开始拥有远程调试的能力。
