虚拟串口波特率模拟算法实战解析-开发者社区

软件如何“伪造”一个串口？深入拆解虚拟UART的波特率模拟黑科技

你有没有遇到过这样的窘境：
手里的MCU只有一个硬件串口，却要同时接GPS、蓝牙模块、调试输出和上位机通信？
或者想给旧设备写个Bootloader，但目标芯片压根没有UART外设？

别急着换主控或加转接芯片——真正的嵌入式老手，会直接用代码“造”出一个串口。

这背后的核心技术，就是虚拟串口（Virtual UART），也叫软件模拟串口。它不靠专用硬件，而是通过精准操控GPIO和定时器，在纯软件层面复现标准UART协议的行为。而其中最关键的一步，就是波特率的高精度模拟。

今天我们就来深挖这个看似简单、实则暗藏玄机的技术点：软件是怎么做到像模像样地“数时间”的？又是如何避免时钟误差导致通信崩溃的？

为什么需要虚拟串口？

在资源受限的微控制器中，硬件UART往往是稀缺资源。比如STM32F103C8T6这种经典“蓝色小板”，仅提供一个完整串口；许多RISC-V内核的极简MCU甚至完全不带UART模块。

这时候，如果项目又必须用到多个串行设备怎么办？

一种方案是外接USB转串芯片（如CH340、CP2102），但这会增加BOM成本、PCB面积和功耗。另一种更优雅的方式，就是用软件模拟。

✅一句话定义：虚拟串口 = GPIO + 定时机制 + 状态机 = 可编程的异步串行通信接口

它可以实现：
- 多路串口扩展（只要引脚够）
- 动态配置波特率（连76800都能跑）
- 成本敏感型产品的通信替代方案
- 固件升级中的临时通信通道（Bootloader专用）

听起来很美好，但问题来了：软件怎么保证每一位数据的时间长度刚刚好？

这就引出了我们今天的主角——波特率模拟算法。

波特率的本质：不是速度，是节奏

很多人把“波特率”理解成传输速率，其实更准确的说法是符号率，即每秒传输多少个“位”。例如9600bps，意味着每个bit持续约104.17μs。

真实UART硬件内部有独立的波特率发生器，通常基于分数分频器，能非常接近目标值。而软件模拟只能依赖系统主频和中断机制，天然存在两个挑战：

时钟无法整除：72MHz主频 ÷ 115200 ≈ 625.0… 不是整数 → 必然有余数误差
执行延迟不可控：中断响应、指令周期、编译优化都会引入抖动

如果不做处理，这些微小偏差会在连续传一帧数据时累积，最终导致接收端采样错位，出现帧错误甚至数据全乱。

所以，虚拟串口成败的关键，就在于能否精确控制“每一比特的生命周期”。

常见定时策略对比：从轮询到相位累加

方案一：最原始的“死等”法（别用！）

void send_bit_slow(uint8_t level) { GPIO_Write(TX_PIN, level); for(int i = 0; i < DELAY_COUNT; i++); // 空循环延时 }

这种方法依赖for循环消耗CPU周期，缺点非常明显：
-移植性差：换一款芯片或编译器，延时就变了
-精度低：受优化等级影响大
-阻塞主线程：发一个字节可能卡住几十毫秒

适合教学演示，实战中应坚决弃用。

方案二：SysTick打拍子 —— 中断驱动状态机

ARM Cortex-M系列自带一个叫SysTick的系统滴答定时器，常用于RTOS的时间片调度。我们也可以把它当成“节拍器”，每1μs触发一次中断，驱动状态机前进。

核心思路：16倍过采样 + 中点采样

真实UART接收器通常采用16倍过采样：将每位划分为16个时间片，在第8个采样以避开边沿毛刺。我们也照葫芦画瓢。

假设波特率为9600bps：
- 每位时间 ≈ 104μs
- 若SysTick中断频率为1MHz（每1μs一次），则每位对应约104个tick

于是我们可以这样设计状态机：

#define BAUD_RATE 9600 #define SYS_TICK_FREQ 1000000 #define TICKS_PER_BIT (SYS_TICK_FREQ / BAUD_RATE) // ~104 #define SAMPLE_OFFSET (TICKS_PER_BIT / 2) // 中点采样 static enum { IDLE, START_BIT, DATA_BITS } rx_state = IDLE; static uint8_t rx_bit_count; static uint16_t expected_tick; static uint8_t current_byte; void SysTick_Handler(void) { static uint16_t tick_counter = 0; tick_counter++; switch (rx_state) { case IDLE: if (GPIO_Read(RX_PIN) == 0) { // 起始位下降沿 expected_tick = tick_counter + SAMPLE_OFFSET; rx_state = START_BIT; } break; case START_BIT: if (tick_counter >= expected_tick) { if (GPIO_Read(RX_PIN) == 0) { // 确认为有效起始位 current_byte = 0; rx_bit_count = 0; expected_tick += TICKS_PER_BIT; rx_state = DATA_BITS; } else { rx_state = IDLE; // 干扰误判 } } break; case DATA_BITS: if (tick_counter >= expected_tick) { current_byte >>= 1; if (GPIO_Read(RX_PIN)) { current_byte |= 0x80; } rx_bit_count++; expected_tick += TICKS_PER_BIT; if (rx_bit_count == 8) { store_to_buffer(current_byte); rx_state = IDLE; } } break; } }

📌 关键技巧：使用一个全局计数器tick_counter来标记绝对时间点，避免每次重新计算。

这种方式比轮询先进得多，但仍有个隐患：TICKS_PER_BIT 是整数，无法表达小数部分。比如115200bps下，理想值是8.68μs/位，实际用了8或9个tick，误差高达±8%！

长期运行必然出错。

高阶玩法：相位累加器（Phase Accumulator）实现亚周期控制

要想突破整数tick的限制，就得引入定点小数运算的思想。这就是通信领域常用的相位累加器（Delta-Sigma风格）方法。

思路类比：音乐中的节拍器微调

想象你在打拍子，目标是每分钟96拍（=9600bps）。但你的手只能按整秒动作。怎么办？你可以大部分时间隔1秒敲一下，偶尔跳过一次或多敲一次，让长期平均节奏逼近目标。

相位累加器正是干这事的。

数学基础：把“每bit多少tick”变成小数

以72MHz主频生成115200bps为例：

理想ticks_per_bit = 72,000,000 / 115,200 ≈ 625.0

完美！刚好整除。但如果换成常见的8MHz晶振呢？

8,000,000 / 115,200 ≈ 69.444... → 存在0.444的余数

如果我们能让系统“平均每7个周期里，有4次用69个tick，3次用70个”，就能无限逼近真实值。

实现代码：24.8固定点数 + 相位累加

#define F_CPU 8000000UL #define TARGET_BAUD 115200UL #define FRAC_BITS 8 // 使用8位小数位 // 计算步长：相当于 (F_CPU / BAUD) << 8 uint32_t phase_step = ((uint64_t)F_CPU << FRAC_BITS) / TARGET_BAUD; uint32_t phase_acc = 0; void on_timer_tick_1us(void) { // 每1μs调用一次 phase_acc += phase_step; // 当累加值超过1.0（即256个单位）时，表示该进一位了 while (phase_acc >= (1UL << FRAC_BITS)) { phase_acc -= (1UL << FRAC_BITS); handle_next_bit(); // 发送或采样一位 } }

💡phase_step的值约为69.444 * 256 ≈ 17777，每次加上去后，大约每1.44次中断产生一次位操作，长期平均正好匹配目标波特率。

这种方法的优势在于：
-无累积误差：长期平均速率极其精准
-支持任意非标波特率
-无需查表或复杂逻辑

堪称软件波特率模拟的“天花板级”实现。

工程落地要点：不只是算法，更是系统设计

就算算法再精妙，实际应用中仍需注意以下几点才能稳定工作：

✅ 接收端建议多点采样（三取二判决）

单次中点采样虽好，但在强干扰环境下仍有风险。进阶做法是在每位的第7、8、9个时间片各采一次，取多数结果作为最终值：

int s1 = GPIO_Read(), s2 = GPIO_Read(), s3 = GPIO_Read(); current_bit = (s1 + s2 + s3) >= 2 ? 1 : 0;

可显著提升抗噪能力。

✅ 添加超时保护，防止状态机卡死

万一通信中断或噪声导致起始位误触发，状态机可能陷入等待下一个bit的无限循环。

解决办法：设置最大等待时间，超时自动回归IDLE状态。

if (tick_counter - last_action_tick > MAX_WAIT_TICKS) { rx_state = IDLE; }

✅ 使用环形缓冲区解耦中断与应用层

不要在中断里直接处理数据！正确的做法是：

// ISR中只做最轻量操作 ringbuf_put(&rx_buf, received_byte); // 主线程或任务中取出并解析 while (ringbuf_get(&rx_buf, &data)) { parse_at_command(data); }

避免中断抢占导致实时性问题。

✅ 实测验证：逻辑分析仪是最后的裁判

无论仿真多完美，都必须用逻辑分析仪抓波形确认：

起始位宽度是否一致？
数据位边沿是否整齐？
停止位是否完整？

特别是高波特率（如230400以上），任何微小偏差都会被放大。

这套思想还能用在哪？

掌握虚拟串口的设计精髓后，你会发现很多协议都有相似逻辑：

协议	相似点	可迁移技术
DS18B20单总线	严格时序控制	状态机 + 微秒级延时
红外遥控（NEC）	脉宽调制编码	边沿触发 + 时间测量
PWM信号解调	周期性事件捕获	定时器输入捕获 + 累加滤波
自定义无线协议	自同步帧结构	位同步 + 曼彻斯特编码