从零实现USB主机识别：手把手入门实践教程

从零实现USB主机识别：手把手入门实践教程

当你的MCU开始“主动出击”——为什么我们需要USB主机功能？

在嵌入式开发中，我们早已习惯让STM32、ESP32这类微控制器作为USB设备接入电脑：比如虚拟串口、HID键盘、U盘模拟……这些场景下，我们的板子是“被管理”的一方。

但有没有想过，让你的MCU反过来扮演“电脑”的角色，主动去读一个U盘、接一个鼠标、甚至控制一台USB摄像头？这正是USB主机模式（Host Mode）的核心能力。

尤其是在工业控制、数据采集、边缘智能终端等应用中，这种“主控外设”的需求越来越普遍。例如：
- 工业PLC自动导出日志到U盘；
- 智能收银机扫描二维码枪输入；
- 嵌入式网关连接4G Dongle拨号上网；

然而，与设备模式相比，USB主机开发门槛更高——它不仅需要理解复杂的协议栈，还要处理动态接入、枚举流程、状态机跳转等一系列底层细节。

本文不讲空泛理论，而是带你一步步亲手实现最基础的USB主机识别流程，从检测设备插入，到完成枚举，再到解析设备信息。目标明确：让一块普通MCU真正“认出”插上去的USB设备。

USB主机控制器：你是总线上的“交通警察”

它到底是什么？

你可以把USB主机控制器想象成整条USB总线的“指挥官”。所有通信都由它发起，任何数据传输都不能“自发进行”。

常见的主机控制器类型包括：
-OHCI/EHCI/xHCI：PC级标准，支持高速（480Mbps），复杂度高；
-SL811HS兼容控制器：轻量级方案，适合资源受限MCU；
-OTG控制器（如STM32 OTG FS/HS）：双模设计，既能做主机也能做设备，是当前主流选择。

我们今天聚焦的就是这类集成在MCU内部的OTG模块。

主机是怎么“发现”新设备的？

这个过程就像交警发现一辆新车驶入高速公路：

第一步：看谁“亮灯了”

USB设备会通过上拉电阻将D+（全速设备）或 D-（低速设备）拉高。主机持续监测这两根线的电平变化。

⚠️ 注意：主机端不能主动上拉！否则会导致冲突。只有当设备插入时，它的上拉才会生效。

一旦检测到D+或D-被拉高，就知道有设备来了。

第二步：发个“复位令”

主机向总线发送一个持续约10ms 的SE0信号（D+和D-同时为低），强制设备进入默认状态。

此时设备使用地址0，所有配置回到出厂值，等待主机下一步指令。

第三步：问“你是谁？”

主机通过控制传输，向地址0发起GET_DESCRIPTOR请求，获取设备描述符。

拿到VID（厂商ID）、PID（产品ID）、设备类等关键信息后，系统就知道该怎么对待这个设备了。

第四步：分配“身份证”

主机调用SET_ADDRESS命令，给设备分配一个唯一的非零地址（1~127）。从此以后，所有通信都用这个新地址。

第五步：全面体检

再次读取完整的描述符链：
- 设备描述符 → 配置描述符 → 接口描述符 → 端点描述符 → 字符串描述符（可选）

根据bDeviceClass字段判断设备类型：
-0x08：大容量存储（MSC），比如U盘；
-0x03：人机接口设备（HID），比如键盘鼠标；
-0xFF：自定义类设备；

第六步：正式上岗

最后执行SET_CONFIGURATION，选择一个有效配置值（通常是1），设备进入“已配置状态”，可以开始正常工作。

关键特性一览表

枚举机制拆解：一次完整的“身份登记”流程

让我们把上面提到的枚举过程再细化一下，看看每一步究竟发生了什么。

1. 连接检测（Connection Detection）

// 示例：基于STM32 HAL库轮询DP/DM状态 if (__HAL_USB_GET_FLAG(&hpcd, USB_ISTR_CTR)) { // 处理控制事务 } else if (__HAL_USB_GET_FLAG(&hpcd, USB_ISTR_RESET)) { Handle_Device_Reset(); } else if (__HAL_USB_GET_FLAG(&hpcd, USB_ISTR_WKUP)) { Handle_Wakeup(); }

实际项目中建议结合外部中断或专用引脚触发，避免频繁轮询浪费CPU资源。

2. 总线复位（Bus Reset）

复位期间，主机必须保持SE0至少10ms，之后释放并等待设备稳定。

// 发送复位信号（以HAL库为例） HAL_PCD_ResetCallback(&hpcd); // 内部会清空中断、重置端点 Delay_us(10000); // 保持10ms

复位完成后，设备进入Default State，仅响应地址0的控制请求。

3. 获取设备描述符（Get Device Descriptor）

这是最关键的一步，决定了后续能否正确识别设备。

构造一个标准的控制请求包（Setup Packet）：

然后通过控制传输读回前18字节设备描述符：

USBH_StatusTypeDef GetDeviceDescriptor(USBH_HandleTypeDef *phost) { uint8_t setup_req[8] = { 0x80, // bmRequestType: IN, Standard, Device USB_REQ_GET_DESCRIPTOR, // bRequest: GET_DESCRIPTOR 0x01, 0x00, // wValue: Device Descriptor (0x0100) 0x00, 0x00, // wIndex: 0 LOBYTE(USB_DESC_LEN_DEVICE), HIBYTE(USB_DESC_LEN_DEVICE) // wLength: 18 }; return USBH_CtlReq(phost, setup_req, (uint8_t*)&(phost->device.DevDesc), USB_DESC_LEN_DEVICE); }

成功返回后，就可以从中提取关键字段：

printf("Vendor ID: 0x%04X\n", phost->device.DevDesc.idVendor); printf("Product ID: 0x%04X\n", phost->device.DevDesc.idProduct); printf("Device Class: 0x%02X\n", phost->device.DevDesc.bDeviceClass);

4. 设置设备地址（Set Address）

注意：此请求没有数据阶段！

uint8_t SetAddress_Request[8] = { 0x00, // OUT, Standard, Device USB_REQ_SET_ADDRESS, // SET_ADDRESS new_addr, 0x00, // wValue = 地址 0x00, 0x00, // wIndex 0x00, 0x00 // wLength = 0 }; USBH_CtlReq(phost, SetAddress_Request, NULL, 0);

发送完后需延时至少2ms，确保设备切换成功，之后所有通信改用新地址。

5. 再次读取完整描述符链

这次要读完整的设备描述符（通常18字节）、配置描述符（可能上百字节），以及可选的字符串描述符（厂商名、产品名等）。

// 读取配置描述符（前9字节） USBH_GetCfgDesc(phost, 9); // 读取完整配置描述符（wTotalLength来自前9字节） uint16_t total_len = phost->device.CfgDesc.wTotalLength; USBH_GetCfgDesc(phost, total_len);

配置描述符开头包含如下重要信息：

接着遍历每个接口描述符，查看其bInterfaceClass来决定加载哪个类驱动。

6. 配置设备（Set Configuration）

最后一步，告诉设备“你现在启用这个配置”。

uint8_t Configure_Request[8] = { 0x00, USB_REQ_SET_CONFIGURATION, config_value, 0x00, 0x00, 0x00, 0x00, 0x00 }; USBH_CtlReq(phost, Configure_Request, NULL, 0);

至此，设备进入Configured State，可以开始正常的批量传输、中断传输等操作。

控制传输详解：三次握手的艺术

为什么叫“控制传输”？因为它像一场严谨的对话，分为三个阶段：

Stage 1: Setup（设置阶段）

主机发送一个8字节的Setup包，格式如下：

struct usb_setup_packet { uint8_t bmRequestType; // [Direction][Type][Recipient] uint8_t bRequest; uint16_t wValue; uint16_t wIndex; uint16_t wLength; };

这是整个请求的“命令头”。

Stage 2: Data（数据阶段，可选）

根据bmRequestType和wLength，执行IN或OUT传输。

• 若为IN：主机从设备读数据；
• 若为OUT：主机向设备写数据；
• 若wLength == 0：跳过此阶段；

Stage 3: Status（状态阶段）

方向反转，确认传输结果。

• 如果是IN请求，则最后用OUT握手包表示“我收到了”；
• 如果是OUT请求，则用IN握手包回应“我处理好了”；

✅ 成功标志：收到ACK包
❌ 失败情况：NAK（忙）、STALL（错误）、TIMEOUT（无响应）

这种三阶段机制极大提高了命令传输的可靠性。

实战案例：如何让STM32读取一个U盘？

假设你正在做一个工控面板，需要定期导出运行日志到U盘。

系统架构简图

[STM32F4] └── [OTG_FS Host Controller] ├── [PHY] → D+/D- └── [Host Stack] ├── 枚举模块 ├── MSC类驱动（SCSI命令集） └── FATFS文件系统 └── 用户应用（读写log.txt）

开发要点清单

✅硬件设计
- 使用15kΩ下拉电阻于D+/D-（防止误触发）；
- VBUS引脚接稳压电路，支持5V输入，并具备过流保护；
- D+/D-走90Ω差分阻抗线，长度匹配误差<5mm；

✅软件设计
- 使用状态机管理枚举流程：

typedef enum { HOST_IDLE, HOST_DEV_CONNECTED, HOST_RESET, HOST_GET_DEV_DESC, HOST_SET_ADDR, HOST_GET_CFG_DESC, HOST_SET_CONFIG, HOST_CLASS_INIT, HOST_READY } host_state_t;

• 加入超时机制防止卡死：

if (tick_ms - last_step > 1000) { handle_timeout(); }

• 对复合设备做特殊处理：有些U盘同时上报HID+MSC，需忽略多余接口。

✅调试技巧
- 使用Beagle USB 12或Wireshark + USBPcap抓包分析各阶段Packet是否合规；
- 在关键节点打印日志，如：

LOG("VID:%04X PID:%04X Class:%02X", vid, pid, dev_class);

• 初始阶段先用标准U盘测试，再逐步兼容杂牌设备。

常见坑点与避坑指南

写在最后：掌握底层，才能驾驭未来

USB主机识别看似复杂，其实本质就是四个字：按序发令，逐级确认。

只要你掌握了：
- 如何检测设备接入，
- 如何执行总线复位，
- 如何发起控制传输，
- 如何解析描述符，

你就已经跨过了最难的那道门槛。

随着国产RISC-V芯片（如GD32VF103、CH32V307）陆续支持USB OTG，低成本实现主机功能已成为现实。未来无论是对接Type-C、PD快充，还是构建自主可控的嵌入式主控系统，这套底层能力都会成为你的核心竞争力。

如果你正在尝试自己实现USB主机功能，欢迎留言交流你在枚举过程中遇到的具体问题。也可以分享你的硬件平台和使用的库（HAL/LL/LibUSB等），我们一起排查解决。

技术这条路，从来都不是一个人的独行。