项目标题摆在眼前：串口不够用，想用STM32做USB主机，再接一堆CH340出来当虚拟串口用。这方向一听就很“嵌入式痛点”——我自己的调试台也是一样，三路串口打底，外设再挂几个，经常拔来拔去。后来我把STM32的OTG口改成Host模式，外接一个USB HUB，下面挂了四五个CH340转串口小板，主控一次性多出好几路“虚拟串口”，用起来就像在用普通UART一样。这套路踩了不少坑，这篇把选型、原理、驱动实现和排查方法一次讲透。
STM32做USB Host这件事，最容易被忽视的地方是：不是所有STM32都能当主机。很多朋友拿着F103最小板就想做，结果USB外设根本不支持Host模式，只能当Device。所以开篇先花点篇幅搞清楚硬件底子，后面才不至于白忙。
1. 方案选型与整体设计
1.1 为什么需要STM32自己当USB主机
常规思路里，CH340这种USB转串口芯片都是插电脑、插树莓派用的，让单片机去“反向”读取它，听起来有点绕。但实际项目里这个需求很真实：主控板串口外设数量有限，UART不够了，要么换大封装MCU，要么外扩多路UART芯片，要么就用一套“USB Host + CH340阵列”的通用方案。
后者的好处很明显：CH340模块便宜、随处能买、电平可调，而且一个USB口能通过HUB引出4路、7路甚至更多串口，硬件改动只是一根USB线加一个小HUB，比重新画板子优雅得多。STM32在这里的角色是“带键盘的小电脑”，负责枚举USB设备、管理传输端点、把CH340的数据变成几个独立的串口数据流，供业务代码直接读写。
适合参考这个方案的人，一般是手上已经有带OTG的STM32板子，又需要快速扩串口的开发者；或者正准备做一版“多串口采集/转发盒子”的朋友。核心不是让你死磕USB协议，而是把一套可复用的Host驱动框架跑起来，后续换USB键盘、U盘、网卡都能沿用。
1.2 硬件选型：不是所有STM32都能当Host
这点必须放在最前面说，因为我见过太多人拿F103C8T6一个劲猛搞，最后查手册才发现芯片上的USB只有一个Device模式，根本没法枚举外部设备。
做一个简单的硬件能力表：
| 芯片系列 | USB外设类型 | 是否可作Host | 备注 |
|---|---|---|---|
| STM32F103系列 | USB Device only | 不支持 | 只能模拟串口、HID这类设备 |
| STM32F105/107系列 | OTG_FS | 支持 | 需要外接ID/上拉电路，协议栈自己写 |
| STM32F405/407系列 | OTG_FS / OTG_HS | 支持 | 最推荐的起步选择，F407可Host可Device |
| STM32F7/H7系列 | OTG_FS / OTG_HS | 支持 | 性能更强，可跑高速USB Host |
| STM32F1 + CH376/MAX3421E | 外置Host控制器 | 支持 | 折中方案，但等于再加一颗芯片 |
我的建议是直接用带OTG_FS的芯片，比如F407，引脚不多，外部加一个最小系统就能搞定。注意OTG_FS的DP/DM引脚一般是PA11/PA12（F4系列），Host模式下需要把OTG_FS配置成“全速主机”，并且加上VBUS供电控制引脚（通常是PC5或PA9，不同板子不一样）。
如果用F407同时还想做“上位机虚拟串口”的功能，最好选带OTG_HS的型号（如F407ZG/F429），它有两个USB口：一个口做Host接CH340，另一个口做Device模拟成虚拟串口给电脑用，这样主机和设备的角色能同时存在。
1.3 软件方案：ST官方Host库与TinyUSB的抉择
软件选型是整个项目的分水岭。ST官方提供了一套USB Host库，CubeMX里勾选“USB_HOST”就能生成，支持HID、MSC、CDC等类设备。但坑就在这：官方Host库对“HUB扩展”支持很弱，很多版本根本没有现成的HUB类驱动。你要是想接一个4口USB HUB，再插4个CH340，用官方库会非常痛苦——枚举HUB这一关就够折腾。
相比之下，TinyUSB这个开源库在Host模式上做得更灵活。它本身支持Device/Host双模式，0.16版本之后加入了HUB class支持，而且Vendor类设备（CH340就是典型的Vendor类）可以自己写很简单的批量收发逻辑，不用套标准类协议。所以我最终选择的是“STM32裸机初始化 + FreeRTOS + TinyUSB Host模式”这套组合。
两者对比：
| 方案 | ST官方USB Host库 | TinyUSB Host模式 |
|---|---|---|
| HUB支持 | 很弱，多数版本没有 | 有实验性HUB class，可用 |
| 自定义Vendor设备驱动 | 需要自己扒库，接口繁琐 | 原生API清晰，直接操作端点 |
| 学习和调试成本 | 中等 | 较低 |
| 灵活性 | 受限于库内封装 | 高，适合折腾 |
| 社区资料 | 官方文档多但杂 | GitHub例子多，活跃度好 |
如果你只是接一个CH340，不用HUB，那ST官方库也能忍；但只要标题里带“多个”，HUB支持就是刚需，我强烈建议直接用TinyUSB。
2. USB Host开发的核心细节拆解
光有硬件和库还不够，得知道USB在底层到底干了什么，否则写代码就是猜。这里我用尽量通俗的方式把整个链路拆开。
2.1 USB设备是如何被识别的：枚举过程
USB主机的第一步是“枚举”。你可以把这个过程理解成：主机新认识一个陌生人，先问名字、再问职业、再问联系方式，然后按照该人的能力分配一个“工号”。
具体到USB协议，枚举大致分这么几步：
- 主机检测到设备接入，给USB总线复位信号。
- 设备响应一个“设备描述符”，里面包含VID、PID、类代码等信息。
- 主机给设备分配一个唯一的7位地址。
- 主机再次读取“配置描述符”、“接口描述符”、“端点描述符”。
- 主机发送“设置配置”请求，设备进入工作状态。
描述符这东西，可以理解成一张“能力说明书”。CH340的说明书上会写着：我是多少设备地址，我有几个接口，接口下有几个端点，端点是批量传输还是中断传输，数据方向是IN还是OUT。
在STM32 Host端，这些描述符会以二进制结构体传递，TinyUSB已经封装好了，你只需要在挂载回调里读取并解析即可。关键是知道：枚举成功后，所有真正的数据通信都是通过“端点”进行的，不是直接读写一串“串口数据”。
2.2 CH340在USB总线上到底是什么样子
CH340是南京沁恒的USB转串口芯片，市面上最常见的CH340G、CH340C模块，USB枚举信息一般如下：
- VID：0x1A86
- PID：0x7523（部分批次可能是0x5523或0x5502，以实际枚举为准）
- 接口类：Vendor类（0xFF），不是标准的CDC/ACM类
- 接口数：一般是1个接口，带2~3个端点
通信方式上，CH340的数据走的是批量端点（Bulk Transfer）。常见配置是：一个批量IN端点（设备给主机发数据，地址通常是0x82），一个批量OUT端点（主机给设备发数据，地址通常是0x02）。有些版本的CH340还会有个中断端点做状态通知，但业务数据主要在批量端点上。
这里有个很关键的坑：CH340的波特率设置、DTR/RTS控制，都是通过“厂商自定义控制请求”完成的，而不是USB标准类请求。也就是说，你在STM32上不能靠“标准CDC初始化”去配波特率，必须自己写控制传输，向CH340的控制端点发特定的Vendor指令。
不同批次的CH340，厂商指令的细节可能不一样。网上开源驱动（比如Linux内核里的ch341.c、ch34x.c，以及各种CH340逆向工程）基本把路趟平了，你直接参考它们，不需要自己抓USB包硬猜。核心逻辑无非是：向控制端点发一组字节，里面包含波特率分频系数、数据位、停止位等参数；再发一组字节设置DTR/RTS电平。
2.3 USB HUB扩展多路的原理
USB HUB的存在，让一个物理口能挂多个设备。插上HUB后，主机先枚举HUB本身，然后每个下游端口再接设备时，HUB会向主机报告“我某个端口有设备接入”，主机再对那个端口做一次复位和枚举。
理论上一共有两层设备：第一层是HUB，第二层是HUB下游的CH340们。主机的角色更像个管家：它要知道每个CH340挂在哪个端口、拥有哪个USB地址、用哪个端点收发数据。
这给我们带来的选择是：如果只是简单扩路数，选4口或7口USB HUB模块即可；但要注意HUB有“总线供电”和“自供电”两种。我们接4个CH340模块时，总线供电可能不够稳定，尤其CH340模块上如果还带电源指示灯、转接芯片，电流会大一些。我这边踩过的坑就是USB HUB用总线供电，四个CH340同时插满，枚举老是失败，后来换成带DC供电的自供电HUB就好了。
带宽也要提前算。USB全速（12Mbps）下，一个1ms的帧批量传输大约能传1200字节左右（这是理论值，实际受协议开销影响会更少）。每路串口115200bps，实际有效数据约11.5KB/s，四路同时全速也就是46KB/s左右，远小于1MB/s的理论上限，所以每路常用波特率下完全没问题。但如果每路都跑到921600bps以上，四路加起来接近甚至超过带宽上限，就会丢包。这个在方案阶段就要心里有数。
2.4 多路虚拟串口的资源管理
多个CH340接入后，不能每路都用一个独立的任务去“死等”数据，那样CPU会忙死。我的做法是：Host库在后台跑一个USB任务，负责轮询/中断处理批量端点；每个CH340的收数据回调里，把收到的字节塞进一个环形缓冲区；应用层任务只需要从环形缓冲区取数据。
本质上就是把每个CH340映射成一个“串口句柄”，底层是USB端点，上层是标准读写接口。代码里可以定义这样一个结构体：
typedef struct { uint8_t dev_addr; // USB设备地址 uint8_t ep_in; // 批量IN端点地址 uint8_t ep_out; // 批量OUT端点地址 uint16_t ep_in_size; // IN端点最大包长 uint16_t ep_out_size; // OUT端点最大包长 volatile uint8_t connected; // 是否已连接 ringbuf_t rx; // 接收环形缓冲区 uint32_t baud; // 当前波特率 } ch340_port_t;然后用一个数组ch340_ports[]存多路状态。每次有新CH340插入，就给它分配一个数组元素；拔出时释放。这个思路和操作系统管理文件描述符差不多，非常管用。
3. 从CubeMX到代码：完整实操流程
下面进入“照着做”的部分。我以STM32F407 + FreeRTOS + TinyUSB Host为例，给出可落地的全流程。
3.1 CubeMX配置USB_HOST与FreeRTOS
打开STM32CubeMX，选择芯片型号（我这里用F407VGT6）。按下面的步骤配置：
- 配置时钟：外部高速晶振HSE，系统时钟设为168MHz。USB OTG FS外设的时钟源通常是48MHz，CubeMX会自动派生，但要注意时钟树里USBCLK必须来自HSE或PLLQ，不能乱设。
- 配置USB_OTG_FS：
- Mode选择“Host_Only”。
- 使能VBUS sensing（有些板子没有VBUS检测脚，就要禁用VBUS sensing，否则卡枚举）。
- 配置FreeRTOS：找一个任务优先级分配方案。TinyUSB的tuh_task()最好放在默认任务或一个专用USB任务里，优先级不要太高，但也不能太低，否则USB事件处理不及时。
- 生成工程后手动添加TinyUSB代码，或者直接用TinyUSB的CMake/Makefile方式编译。
CubeMX不能直接生成TinyUSB的Host代码，所以CubeMX在这里只负责时钟、引脚、FreeRTOS配置，USB协议栈交给TinyUSB去做。这一步很多人会困惑，觉得CubeMX里选了USB_HOST就应该自动生成全套，实际上那生成的是ST官方库，不是我们要的TinyUSB。
3.2 TinyUSB工程集成与配置
TinyUSB源码克隆下来后，把src目录加入编译路径。关键的配置文件是tusb_config.h，里面有几个宏必须开：
#ifndef TUSB_CONFIG_H #define TUSB_CONFIG_H #define CFG_TUSB_ENABLED 1 #define CFG_TUSB_OS OPT_OS_FREERTOS #define CFG_TUSB_MCU OPT_MCU_STM32F4 // Host模式 #define CFG_TUH_ENABLED 1 #define CFG_TUH_MAX_DEVICE 8 #define CFG_TUH_HUB 1 // 启用HUB class #define CFG_TUH_MAX_HUB_PORT 4 #endif如果你不启用CFG_TUH_HUB，接一个CH340也能用；但要多路，HUB必须开。CFG_TUH_MAX_DEVICE要大于1，比如8，表示最多支持8个设备，其中有一个HUB和若干CH340，自己按实际路数调整。
TinyUSB的回调函数里，有三个最关键：
void tuh_mount_cb(uint8_t dev_addr) { // 设备枚举完成，可以读取设备描述符、配置描述符 } void tuh_umount_cb(uint8_t dev_addr) { // 设备拔出，释放资源 } void tuh_hub_port_connect_cb(uint8_t hub_addr, uint8_t port) { // 某HUB端口有新设备连接，等待枚举完成 }这些回调会在tuh_task()中被调用。所以主循环或RTOS任务里必须周期调用tuh_task()。
3.3 编写CH340的USB类驱动
这是整个项目最核心的部分。思路是：在tuh_mount_cb回调里，拿到设备地址后，读取配置描述符，找到Vendor接口下的批量IN/OUT端点地址，然后打开端点，启动接收。
我这里给出一个简化但能说明原理的框架：
#include "tusb.h" #define CH340_VID 0x1A86 #define CH340_PID 0x7523 extern ch340_port_t ch340_ports[8]; static void ch340_open_endpoints(uint8_t dev_addr) { // 1. 获取设备描述符，查看VID/PID，确认是CH340 tusb_desc_device_t desc_dev; tuh_descriptor_get_device(dev_addr, &desc_dev, sizeof(desc_dev), 0, NULL); if (desc_dev.idVendor != CH340_VID) { return; // 非CH340设备，忽略 } // 2. 获取配置描述符，遍历接口和端点 // TinyUSB的Host API里可以用 tuh_descriptor_get_configuration 获取完整配置块， // 然后手动解析bInterfaceClass、bNumEndpoints、bEndpointAddress。 uint8_t cfg_buf[512]; // 实际使用时要先请求配置描述符总长度，再根据长度读取完整数据 // 这里为了简洁，直接假设已经拿到 cfg_buf // 3. 找到第一个Vendor接口下的批量端点 uint8_t ep_in = 0, ep_out = 0; uint16_t ep_in_size = 0, ep_out_size = 0; // ... 遍历cfg_buf过程省略，遇到0xFF类接口，记录端点地址和wMaxPacketSize // 4. 打开两个批量端点 tusb_edpt_open(dev_addr, ep_in, TUSB_XFER_BULK, ep_in_size, NULL); tusb_edpt_open(dev_addr, ep_out, TUSB_XFER_BULK, ep_out_size, NULL); // 5. 初始化CH340的串口参数（发送厂商控制请求） ch340_set_baudrate(dev_addr, 115200); ch340_set_dtr_rts(dev_addr, true, true); // 6. 启动批量IN传输，准备接收串口数据 tuh_xfer_t xfer = { .daddr = dev_addr, .ep_addr = ep_in, .buflen = 128, .buffer = rx_buffer, .complete_cb = ch340_rx_complete_cb, }; tuh_xfer(&xfer); }这段代码的重点是：端点地址、端点大小要仔细解析，IN/OUT方向不能搞反。CH340的批量端点通常是0x82和0x02，但不同批次可能不同，写代码时一定要根据描述符解析出来再使用，不要硬编码。
波特率设置函数ch340_set_baudrate()不是标准USB类请求，而是厂商自定义控制请求。实现参照Linux下的ch341.c驱动，核心就两步：
static void ch340_set_baudrate(uint8_t dev_addr, uint32_t baud) { // 根据ch341.c驱动源码计算分频系数 // 向控制端点0发送Vendor请求，请求号为0xA1/0x9A等，具体值随芯片版本变化 // 发送前最好有USB抓包工具验证 uint16_t divisor = ch340_calc_divisor(baud); uint8_t buf[4] = {0}; tuh_control_xfer(dev_addr, 0x40, CH340_SET_BAUD, divisor, 0, buf, sizeof(buf), NULL); }注意这里我没有给出具体的请求号，因为CH340不同型号差异太大。网上一些文章直接贴死一个十六进制指令，照抄之后在某个型号上可能连枚举都过不去。更稳妥的做法是找一份你手头CH340型号对应的开源驱动源码，照着适配。
3.4 使用USB Hub管理多个CH340
TinyUSB开了CFG_TUH_HUB之后，HUB枚举和端口管理由库自动处理。我们要做的，是在端口连接回调里，等待设备地址分配完成。通常逻辑是：
void tuh_hub_port_connect_cb(uint8_t hub_addr, uint8_t port) { // HUB端口有设备接入，TinyUSB会继续后续枚举， // 真正的业务处理在tuh_mount_cb里做，这里只需要记录端口状态 }HUB接上后，tuh_mount_cb可能被调用两次：第一次是HUB设备本身枚举完成，第二次是每个下游CH340设备枚举完成。判断是HUB还是CH340，就靠VID/PID。如果是HUB的VID/PID，不去初始化成串口；如果是CH340，就走ch340_open_endpoints流程。
HUB还有一个老坑：有些HUB芯片的端口电源默认是关的，主机必须发送“设置端口特性(set port feature)”请求打开电源。TinyUSB的HUB class会处理这个动作，但使用某些“硬线配置”的HUB模块，可能不需要主机额外开电。面板上的“电源灯”不代表“可枚举”，真正的标准是看tuh_hub_port_connect_cb有没有被触发。
多路管理上，我维护一个“空闲槽位表”。每个CH340插入后，就在ch340_ports[]里找一个connected为0的槽位，写入dev_addr和端点信息；拔出后置0。业务代码只要遍历这个数组，就能发现串口增减。
3.5 把数据交给应用层：FreeRTOS任务调度
数据从CH340收上来后，最简单的交付方式是“回调进环形缓冲区 + 任务消费”。我在ch340_rx_complete_cb里做这几件事：
static void ch340_rx_complete_cb(tuh_xfer_t* xfer) { uint8_t dev_addr = xfer->daddr; uint8_t ep_addr = xfer->ep_addr; uint16_t len = xfer->xfered_bytes; // 把收到的len个字节写入对应串口槽位的环形缓冲区 ch340_port_t* p = find_port_by_dev_addr(dev_addr); if (p && len > 0) { ringbuf_write(&p->rx, xfer->buffer, len); // 通知应用层任务有数据到达 xSemaphoreGiveFromISR(p->rx_sem, NULL); } // 继续启动下一次接收，保证数据不断流 tuh_xfer_t next = *xfer; next.buflen = sizeof(rx_buffer); tuh_xfer(&next); }应用层某个任务想读某一路串口数据，就阻塞在对应的信号量上：
void uart_reader_task(void* arg) { ch340_port_t* p = &ch340_ports[0]; // 举例：第一路CH340 uint8_t buf[256]; while (1) { xSemaphoreTake(p->rx_sem, portMAX_DELAY); uint16_t n = ringbuf_read(&p->rx, buf, sizeof(buf)); // 把n个字节交给业务处理 } }这样四路CH340就是四个独立的“虚拟串口”，业务层只看到串口编号和字节流，完全不用关心底层USB细节。
4. 常见问题与排查技巧实录
这里整理的是我个人在这套方案上真正遇到过的问题，不是抄文档。每一项我都给过排查方法，直接照做能省不少时间。
4.1 设备反复枚举失败，USB头无法识别
现象：STM32的USB Host接上CH340后，tuh_mount_cb偶尔触发一次，然后就再也不动了；或者枚举到一半就超时。
排查步骤：
- 先检查USB线缆和CH340模块是不是好的：把CH340插到电脑上，装好驱动，看看能不能枚举出串口。如果电脑都识别不了，那就是模块本身的问题。
- 检查OTG_FS的VBUS检测：F4系列Host模式下，如果使能了VBUS sensing，但VDATA引脚没有接对，设备就检测不到插拔。很多最小系统板上VBUS sensing脚没有引出来，直接把CubeMX里的“VBUS sensing”关掉试试。
- 查DP/DM走线：USB的数据线要短，最好不要飞线超过10厘米。CH340模块上的USB座如果焊接不良，也会导致反复枚举失败。
4.2 CH340识别到但收不到数据
现象：tuh_mount_cb能触发，VID/PID也对，但往CH340发数据没反应，或者读不到外部串口发来的数据。
这个90%是初始化序列没做全。CH340不是一个“插上就能用”的USB设备，必须先完成：
- 发送厂商控制请求设置波特率。
- 发送厂商控制请求设置DTR/RTS等Modem信号。
- 有些CH340版本还要先读取一个版本号寄存器，才能进入数据模式。
调试方法：先把CH340插到电脑上，用USB抓包工具（比如免费的Wireshark+USBPcap，或逻辑分析仪）看电脑插入CH340时发了哪些控制请求，再模拟这些请求到STM32端。一套下来底层问题基本能定位。
4.3 多CH340同时工作互相干扰/丢包
现象：单独插一路CH340很稳定，插满四路后，某一路频繁丢字节，甚至所有路都卡死。
原因多半是USB带宽耗尽或者HUB供电不稳。先算带宽：如果每路波特率都超过921600，四路同时满速，全速USB基本扛不住。这时候有两个方向：
- 降低串口波特率到115200或460800，满足项目需求即可。
- 如果必须高波特率满速，换支持USB高速（480Mbps）的OTG_HS主机，并把HUB和CH340都换成高速设备。不过CH340本身是全速设备，所以实际总带宽还是受限于单设备全速，这个要意识到。
供电问题更好排查：换自供电HUB，或者给HUB外加5V电源，不带负载再看是否复现。
4.4 硬件12M带宽计算的经验
我习惯在项目初期把每路串口的极限吞吐折算成USB带宽。按CH340全速设备来算，批量传输在1ms内大约能传1200字节，1.2MByte/s。115200波特率串口，有效数据率约11.5KB/s，算上校验位停止位也不超过15KB/s，四路才60KB/s，带宽余量充足。但如果是921600波特率，一路就要92KB/s，四路接近368KB/s，再加协议开销，已经快到极限了。维护一张“波特率-每路带宽-最大路数”估算表，能避免后期改方案。
4.5 STM32既当Host又当Device的扩展问题
如果你想让这台设备既接多个CH340，又能被电脑当成虚拟串口，一个USB口做不到同时Host和Device。F407有两个USB口：OTG_FS和OTG_HS。可以配置一个作Host，一个作Device。注意OTG_HS如果不用外部PHY，只能以全速12Mbps工作，和OTG_FS性能相同；要跑480Mbps得外接USB PHY芯片（比如USB3300）。这个扩展方案我已在第二版板子上跑通了，代码上其实就是两套独立的TinyUSB实例或者一套ST库一套TinyUSB，互不干扰。
4.6 不要忽视电源与地回路
CH340模块如果分别供电，每个模块的地和STM32的GND必须连在一起。USB线上的GND不是万能的，模块和主机可能产生地电位差，导致数据错乱甚至烧芯片。我习惯在USB线中间加一个小共模电感，同时保证所有模块共用同一个5V电源和GND平面。自供电HUB的电源地和STM32板子的地也建议单点相连。
5. 写在最后：这套玩法还能往哪走
USB Host这条路走通之后，你会发现STM32不再只是一个“外设控制单片机”，它已经变成了一个能主动连接外部USB设备的“小主机”。CH340阵列只是第一步，后续可以挂USB键盘鼠标做输入设备，挂U盘做数据记录器，甚至挂4G上网卡做联网透传。核心的枚举、端点管理、HUB调度全是一套逻辑，学一遍受用很久。
我个人体会是：做这种多路串口扩展，最花时间的其实不是代码量，而是对USB协议的耐心。先理解枚举，再理解类设备和Vendor设备，最后再把HUB和带宽控制住，剩下的就是体力活。如果你拿到这个标题第一反应是“直接在单片机上加几个串口芯片”，也不是不行，但灵活性和成本都不会比USB Host方案好。建议先拿一块F407开发板，买一个4口USB HUB和四个CH340模块，按上面的步骤走一遍，把log打印出来看到四路数据同时刷新的时候，那种成就感相当值。
