从一个“看不见”的串口说起：如何让STM32自己变出COM口？
你有没有遇到过这种情况——
板子已经焊好，引脚紧张到连RX/TX都挤不出来，结果调试时想看个printf日志，却发现根本没有串口可接？
只能拆了重画PCB？还是硬着头皮外挂CH340？
其实，你的STM32早就自带了一个“隐形串口”，不用额外芯片、不占UART引脚，插上USB线就能在电脑设备管理器里蹦出一个真正的COM端口。它就是：虚拟串口（Virtual COM Port, VCP）。
今天我们就来手把手揭开它的面纱，带你从零开始，在STM32上亲手搭起一条通往PC的“空中通道”。
为什么我们需要“假”串口？
传统的串口通信依赖物理UART模块和对应的TX/RX引脚，再通过USB转串芯片（比如CH340、CP2102）桥接到PC。这套方案虽然成熟，但有几个痛点：
- 多一块芯片 → 多一分成本
- 占两个GPIO → 资源浪费
- 驱动可能不兼容 → 插上去蓝屏或识别失败
- 板子小了放不下 → 尴尬
而如果你用的是像STM32F103C8T6（那个蓝色小板子）、STM32F4系列或G0/G4等新型号，它们内部集成了全速USB外设。这意味着：只要写对固件，这块MCU就可以假装成一个U盘、鼠标……或者，一个标准的串口设备。
这就是所谓的“虚拟串口”——没有物理UART参与，却能让Windows认出一个COM口，还能用PuTTY、串口助手正常收发数据。
听起来像魔法？其实背后有一套清晰的技术逻辑。
它是怎么“骗过”电脑的？
关键就在于USB CDC/ACM 协议。
USB不是天生支持串口的
USB本身是一种高速总线协议，和传统串口完全是两码事。但为了让嵌入式设备能模拟老式串行设备（比如调制解调器），USB-IF组织定义了一套规范：Communication Device Class (CDC)，其中最常用的是Abstract Control Model (ACM)子类。
简单说：只要你告诉电脑“我是一个符合CDC-ACM标准的虚拟串口设备”，系统就会自动加载原生驱动（Windows叫usbser.sys，Linux是cdc_acm.ko），并分配一个COMx端口。
整个过程就像一场精心编排的“身份伪装”。
枚举阶段：我是谁？
当你把STM32插进电脑USB口，主机首先发起枚举（Enumeration）流程。这时MCU要主动上报一系列描述符：
| 描述符类型 | 内容示例 |
|---|---|
| 设备描述符 | 厂商ID、产品ID、设备类别 |
| 配置描述符 | 支持几种工作模式 |
| 接口描述符 | 分为控制接口 + 数据接口 |
| CDC类特定描述符 | 声明这是个通信设备，支持SetLineCoding等命令 |
尤其是这个CDC类描述符，它是让系统识别为“串口”的核心凭证。一旦匹配成功，操作系统立刻激活内置串口驱动。
📌 小知识：大多数现代系统（Win7+/macOS/Linux）都原生支持CDC-ACM，无需安装任何第三方驱动！
双接口设计：管理和数据分开走
虚拟串口采用经典的双接口架构：
- Interface 0：控制接口
- 处理AT指令类请求，如设置波特率（SetLineCoding）、控制DTR/RTS信号（SetControlLineState）
实际开发中我们通常忽略这些信号，但必须响应SETUP包，否则枚举失败
Interface 1：数据接口
- 真正的数据通道
- 包含两个端点：
- OUT EP（主机→MCU）：接收数据
- IN EP（MCU→主机）：发送数据
- 使用批量传输（Bulk Transfer），保证可靠性和顺序性
数据以64字节为单位打包传输，理论速率可达约1.2Mbps，远超传统串口上限。
性能对比：真串口 vs 虚拟串口
| 维度 | 传统串口 + CH340 | STM32虚拟串口（CDC） |
|---|---|---|
| 是否需要额外芯片 | 是 | 否 |
| 占用IO资源 | TX/RX两根 | 仅需DP(PA12)/DM(PA11) |
| 驱动支持 | 需安装专用驱动 | Windows免驱，Linux/macOS原生支持 |
| 最大波特率 | 一般≤3Mbps（受限于晶振） | 批量传输下有效带宽更高 |
| 功能扩展性 | 仅作串口 | 可与其他USB功能复合（如HID+DFU） |
结论很明确：只要有USB外设，虚拟串口就是更优选择。
实战搭建：CubeMX + HAL库快速上手
下面我们以最常见的STM32F103C8T6为例，使用STM32CubeMX生成基础工程，实现虚拟串口通信。
第一步：CubeMX配置要点
- 打开STM32CubeMX，选择对应型号
- 在Pinout图中启用
USB外设 → Mode选为Device (Peripheral) - 进入Middleware栏目 → 添加
USB_DEVICE - Class选择：
Communication Device Class (CDC) - 生成代码（建议使用MDK-ARM或SW4STM32）
生成后你会看到新增几个关键文件：
usbd_cdc.c/usbd_cdc.h—— ST官方CDC类处理层usbd_cdc_if.c/.h—— 用户可修改的接口层（重点！）
第二步：接收数据 —— 捕捉来自PC的消息
打开usbd_cdc_if.c，找到这个函数：
static int8_t CDC_Receive_FS(uint8_t* Buf, uint32_t *Len) { // 处理收到的数据 ProcessReceivedData(Buf, *Len); // ⚠️ 必须重新启动接收！ USBD_CDC_SetRxBuffer(&hUsbDeviceFS, UserRxBufferFS); USBD_CDC_ReceivePacket(&hUsbDeviceFS); return USBD_OK; }⚠️ 注意事项：
- 此回调仅触发一次！每次接收完成后必须手动调用
USBD_CDC_ReceivePacket()重新开启监听 UserRxBufferFS是全局缓冲区，大小由APP_RX_DATA_SIZE定义（默认8字节，建议改大些）
可以在ProcessReceivedData()中做命令解析，例如：
void ProcessReceivedData(uint8_t *data, uint32_t len) { if (len == 4 && memcmp(data, "LED+", 4) == 0) { HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_SET); } else if (len == 4 && memcmp(data, "LED-", 4) == 0) { HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_RESET); } }第三步：发送数据到PC —— 主动输出信息
发送更简单， anywhere in your code:
extern USBD_HandleTypeDef hUsbDeviceFS; void SendToHost(uint8_t *data, uint16_t len) { if (hUsbDeviceFS.dev_state == USBD_STATE_CONFIGURED) { USBD_CDC_TransmitPacket(&hUsbDeviceFS, data, len); } }📌 关键判断：只有当设备状态为USBD_STATE_CONFIGURED时才能发送。否则会卡死或返回错误。
你可以在主循环中定期上报传感器数据：
while (1) { float temp = ReadTemperature(); char buf[64]; sprintf(buf, "TEMP: %.2f°C\r\n", temp); SendToHost((uint8_t*)buf, strlen(buf)); HAL_Delay(1000); }第四步：别忘了启动首次接收！
很多初学者踩坑：只能收到第一次数据，之后就没反应了。
原因很简单：没有启动初始接收！
在main()函数初始化完成之后，务必加上这一句：
/* Start reception */ USBD_CDC_SetRxBuffer(&hUsbDeviceFS, UserRxBufferFS); USBD_CDC_ReceivePacket(&hUsbDeviceFS);这样才能进入持续监听状态。
让 printf 直接打到电脑屏幕上
最爽的应用之一：重定向printf到虚拟串口。
只需添加下面这个函数：
int __io_putchar(int ch) { uint8_t temp = ch; while (USBD_CDC_TransmitPacket(&hUsbDeviceFS, &temp, 1) != USBD_OK) { // 等待发送完成（底层缓冲区空闲） } return ch; }从此以后，你可以像在PC上一样自由地打印日志：
printf("System started at %lu ms\r\n", HAL_GetTick()); printf("Version: v1.0.0\r\n");再也不用手动拼接字符串发送了！
💡 提示：若担心阻塞问题，可结合环形缓冲区+后台DMA发送优化性能。
解决实际工程中的三大难题
痛点一：多个设备插上去分不清是谁？
现象：好几个一样的开发板，插上后都是“USB Serial COMxx”，根本不知道哪个是哪个。
解决方案：自定义产品描述字符串
修改usbd_desc.c中的USBD_StringProd[]：
__ALIGN_BEGIN static uint8_t USBD_StringProd[] __ALIGN_END = { 0x16, // 长度 USB_DESC_TYPE_STRING, 'M',0,'y',0,'P',0,'r',0,'o',0,'j',0,'e',0,'c',0,'t',0 };这样设备就会显示为 “MyProject” 而非默认名称，方便识别。
痛点二：波特率乱设怎么办？
虽然你在串口助手中设置了115200，但USB本身没有波特率概念。这只是主机通过SetLineCoding请求传下来的一个参数。
你可以选择：
- 完全无视：只当作参考值记录日志等级
- 动态响应：根据设定调整采样频率或日志密度
典型做法是在CDC_Control_FS()中捕获该请求：
case CDC_REQ_SET_LINE_CODING: // 可保存到全局变量备用 LineCoding.bitrate = *(uint32_t*)(req->buf); break;不过多数情况下，直接忽略即可。
痛点三：拔掉再插就不工作了？
常见于未正确处理USB断开事件。
建议在主循环中加入状态监控：
if (hUsbDeviceFS.dev_state != USBD_STATE_CONFIGURED) { // 未连接或未配置，停止发送 } else { // 正常通信 }同时确保中断服务程序正常运行（NVIC使能、优先级合理）。
工程最佳实践清单
| 项目 | 建议 |
|---|---|
| ✅ 时钟精度 | USB需48MHz±0.25%，推荐使用外部晶振或精确PLL分频 |
| ✅ 电源保护 | VBUS接入时加PTC保险丝或限流电路 |
| ✅ ESD防护 | DP/DM线上加TVS二极管（如SMF05C） |
| ✅ 缓冲机制 | 接收使用环形缓冲区，避免数据丢失 |
| ✅ 异常恢复 | 监听RESET/SUSPEND事件，防止死锁 |
| ✅ 字符串定制 | 修改iManufacturer/iProduct提升辨识度 |
| ✅ 复合设备 | 可叠加HID键盘、DFU升级等功能 |
此外，启用Remote Wakeup功能可在低功耗模式下被主机唤醒，适合电池供电场景。
更进一步：不只是调试工具
你以为虚拟串口只是用来打日志？它的潜力远不止于此。
场景1：远程固件升级（Bootloader）
流程如下：
- 上位机发送
"BOOT"命令 - MCU进入引导程序模式
- 后续数据流写入Flash指定区域
- 校验无误后跳转至新固件运行
实现真正意义上的“免拆升级”。
场景2：多合一复合设备
利用USB复合设备（Composite Device）特性，让你的STM32同时具备：
- 一个虚拟串口（用于调试）
- 一个HID键盘（模拟按键输入）
- 一个MSC设备（作为U盘存配置文件）
只需要在CubeMX中勾选多个Class，并合并接口即可。
场景3：工业现场的统一接口
在PLC、传感器节点中，统一使用USB虚拟串口作为配置入口：
- 参数读写
- 故障日志导出
- 校准操作交互
无需额外接口，一线搞定所有维护需求。
写在最后：这不是终点，而是起点
当你第一次看到自己的STM32在设备管理器里弹出“COM5”时，那种成就感是难以言喻的。
但这不仅仅是为了省一颗CH340芯片。
它代表的是：你已经开始掌握嵌入式系统的主动权。
你不再依赖外部工具链来观察系统行为，而是构建了自己的通信生态。
你能实时输出结构化日志、接收远程指令、甚至实现OTA升级。
更重要的是，你迈出了理解USB协议栈的第一步。接下来，无论是做人机交互的HID设备，还是做高速传输的自定义类设备，路径已然铺平。
所以，别再把USB当成单纯的下载口了。
那两根小小的DP/DM线，藏着通往更高阶嵌入式世界的密钥。
现在，就去试试吧。
插上线，打开串口助手，敲下第一行printf("Hello, Virtual COM!\r\n");——
欢迎来到真正的嵌入式世界。
如果你在实现过程中遇到了枚举失败、无法发送、接收不触发等问题，欢迎留言交流，我们一起排查坑点。
