企业官网建设流程全解析

简介：《USB Host 驱动CDC设备超详细资料-原创》面向嵌入式开发者与USB协议学习者，聚焦MCU通过USB Host直接识别并驱动CDC类设备、替代传统RS232接口的实践难题。资源为1个PDF文件，压缩包约4.12MB，内容围绕USB协议分析与CH32V307实验平台展开，适合具备一定单片机基础、希望打通USB主机通信链路的中高级读者。文档从插入检测、总线复位、NRZI编码与同步域讲起，逐层拆解SOP/EOP、PID、帧号及SETUP/IN/OUT事务，并结合0地址获取设备描述符、设置地址、读取配置与接口端点描述符等过程，说明CDC设备枚举与双向通信的建立方式。文中还涉及Bus Hound、DSView逻辑分析仪、USB Packet viewer等软硬件工具的配合使用，便于读者对照波形和数据包排查问题。目前已有2667人学习，可作为USB Host驱动CDC设备的协议速查与实验参考。

1. 需求不是"接个 USB 转串口"，而是让 MCU 自己当主机

实验室里有台老仪器，DB9 接口换成了 USB 口，插到电脑上装个驱动就能用，插到自己画的板子上却一动不动——这是做 USB Host 驱动 CDC 设备时最典型的开局。电脑之所以"插上就行"，是因为它内部跑着一整套主机控制器驱动和 CDC 类驱动；而多数 MCU 工程只做了 USB Device 侧，一旦要它反过来当主机去识别 CH340、FT232 这类串口转 USB 芯片，枚举、描述符解析、类请求、端点搬运哪一环都不能少。这套资料围绕 CH32V307 双路 USB（FS + HS，HS 内置 PHY 支持 OTG）搭了一套完整的 USB 协议分析与主机实现路径，从 D+ 电平变化一路讲到 bulk 端点收发，适合要做 USB Host 课设、毕设，或者手里有台 USB 接口仪器想甩掉 PC 的开发者。

2. 枚举流程拆解：从 D+ 上拉到 SET_CONFIGURATION 的六个状态

USB 主机识别设备不是"插上就读数据"，而是一套主机全程主导、设备被动应答的握手流程。把所有包都抓下来会发现，真正决定成败的是前几十毫秒：电平判定对不对、复位时序够不够、第一次取描述符只取 8 字节这件事有没有做对。这一章按时间顺序把枚举拆成可实现的六个状态。

2.1 插入检测与总线复位：主机眼里的"设备来了"

USB 线缆里 D+/D- 两根差分线在空闲时都靠下拉电阻保持在低电平。设备插入后，设备侧的上拉电阻把其中一根线拉高：D+ 被拉高，主机判定为全速或高速设备；D- 被拉高，判定为低速设备。用逻辑分析仪抓这段波形，插入前 D+、D- 双双为低，插入瞬间 D+ 直接抬起，这个沿就是主机开始干活的信号。

判定完速度，主机要做的第一件事是复位。协议规定 D+ 和 D- 同时拉低 10ms 以上代表 USB 总线复位。注意这里虽然跑的是差分信号，但复位阶段可以按单端方式控制两条线，实现上就是把两个引脚都配成推挽输出拉低，延时够 10ms，再放回 USB 外设接管。我一般会把这段延时写成可调宏，因为有些设备对上电时序比较敏感，10ms 刚好卡在临界点上会偶发识别不到。

复位之后设备回到默认状态：地址为 0，只能用端点 0 通信，且最大包长固定为 8 字节（低速设备）或 8/16/32/64 字节中的某一个（全速设备）。这一点直接决定了后面第一次取描述符为什么只能取 8 个字节。

还有一处容易忽略：复位并不是只做一次。主机在拿到设备描述符的前 8 个字节、确认了 bMaxPacketSize0 之后，通常会再复位一次，让设备重新回到干净的默认状态，然后才开始分配地址。Windows 主机就是这么干的，抓包时能看到两次明显的复位时序。

2.2 两次 GET_DESCRIPTOR：为什么第一次只取 8 个字节

第一次取设备描述符，主机发的 SETUP 包是这 8 个字节：

80 06 00 01 00 00 40 00

逐个字段读：80是 bmRequestType，最高位为 1 表示"设备到主机"，低 5 位为 0 表示接收者是设备；06是 bRequest，即 GET_DESCRIPTOR；00 01是 wValue，低字节 00 是描述符索引，高字节 01 是描述符类型（设备描述符）；00 00是 wIndex，设备描述符用不上，填 0；40 00是 wLength，小端序，实际值是 0x0040 也就是 64 字节。

请求是 64 字节，但设备只会先回 8 个字节。原因很实在：主机此刻还不知道这个设备的端点 0 最大包长是多少，回多了可能超出主机接收缓冲。这 8 个字节里，第 8 个字节正是 bMaxPacketSize0，拿到它之后主机才知道后续每次能收多少。

第一次收到的 8 字节是：

12 01 00 02 00 00 00 08

12是 bLength，说明完整设备描述符长度 18 字节；01是描述符类型；00 02是 bcdUSB，USB 2.0；后面三位是设备类、子类、协议，这里是 0，表示类信息不放在设备描述符里，而在接口描述符里定义——CDC 设备基本都是这个套路；08就是 bMaxPacketSize0，端点 0 最大包长 8 字节。

2.3 设置地址与完整描述符：地址只在 SET_CONFIGURATION 之后才真正生效

确认端点 0 包长后，主机会再复位一次，然后发 SET_ADDRESS。这一步用的是 OUT 事务，主机往设备写数据：

00 05 12 00 00 00 00 00

00表示主机到设备、接收者是设备；05是 SET_ADDRESS；12 00是 wValue，即新地址 0x12，也就是十进制 18；后面 wIndex 和 wLength 都是 0。设备收到后回一个长度为 0 的 IN 包表示应答，从这一刻起，后续所有包都得用 0x12 这个地址发，抓包里 ADDR 域会从 0 变成 18。

紧接着主机再发一次 GET_DESCRIPTOR，这次 wLength 是 0x12，把 18 字节完整描述符全取回来：

12 01 00 02 00 00 00 08 03 04 01 60 00 06 01 02 03 01

从里面能读到 VID = 0x0403、PID = 0x6001，这是典型的 USB 转串口芯片标识。真实的接口类信息还要往下取配置描述符，配置描述符里的 bNumInterfaces 告诉主机有几个接口，接口描述符的 bInterfaceClass 才是真正的类代码——CDC 的通信接口类是 0x02，这个值决定了主机该挂哪套类驱动。类的判定放在这里而不是设备描述符，是 CDC 复合设备的通用做法。

整个枚举的状态机骨架大概长这样，函数名各家 USB 主机栈不一样，逻辑是通用的：

/* USB Host 枚举状态机骨架，函数名按各自主机栈替换 */ typedef enum { HOST_IDLE = 0, /* 等待插入 */ HOST_RESET, /* 总线复位，拉低 D+/D- 10ms */ HOST_GET_DEV_8, /* 0 地址取 8 字节设备描述符 */ HOST_SET_ADDR, /* SET_ADDRESS，写入新地址 */ HOST_GET_DEV_FULL, /* 新地址取 18 字节完整描述符 */ HOST_GET_CONFIG, /* 先取 9 字节配置头，再取全量 */ HOST_SET_CONFIG, /* SET_CONFIGURATION 激活配置 */ HOST_READY /* 进入 CDC 类驱动收发 */ } host_state_t; void USBH_EnumProcess(void) { switch (host_state) { case HOST_RESET: USB_BusReset(10); /* 参数单位 ms，别低于 10 */ host_state = HOST_GET_DEV_8; break; case HOST_GET_DEV_8: /* wLength 给 0x40，但只解析前 8 字节 */ if (USBH_GetDescriptor(0, USB_DESC_DEVICE, 0, dev_buf, 0x40) == OK) { ep0_max_pkt = dev_buf[7]; /* 第 8 字节就是 bMaxPacketSize0 */ host_state = HOST_SET_ADDR; } break; case HOST_SET_ADDR: if (USBH_SetAddress(new_addr) == OK) { dev_addr = new_addr; /* 之后的包必须用新地址 */ host_state = HOST_GET_DEV_FULL; } break; case HOST_GET_CONFIG: /* 先取 9 字节配置头，拿到 wTotalLength 再取全量，避免缓冲不够 */ if (USBH_GetDescriptor(dev_addr, USB_DESC_CONFIG, 0, cfg_head, 9) == OK) { total_len = cfg_head[2] | (cfg_head[3] << 8); USBH_GetDescriptor(dev_addr, USB_DESC_CONFIG, 0, cfg_buf, total_len); ParseInterfaceAndEndpoint(cfg_buf); /* 解析接口类与端点 */ host_state = HOST_SET_CONFIG; } break; case HOST_SET_CONFIG: if (USBH_SetConfiguration(dev_addr, cfg_value) == OK) { host_state = HOST_READY; /* 配置生效后才能收发业务数据 */ } break; default: break; } }

状态机里有两处参数最值得盯：USB_BusReset(10)的 10 是本项目验证过的最小可靠值，改小会出现偶发不识别；ep0_max_pkt必须从描述符里动态读，写死成 64 会在遇到 8 字节包长的设备时立刻挂掉，因为主机发的 IN 令牌包长度超过设备端点 0 的承受能力，设备直接不应答。

3. 协议层验证：用抓包把 NRZI、PID 和标准请求对到字节

光把流程跑通不够，出问题时需要知道坏在哪一层。这一层的能力来自两样工具：逻辑分析仪看电气时序，Bus Hound 或 USB Packet Viewer 看包内容。两者配合，能把一个"没反应"的现象定位到具体是电平没抬、PID 校验错、还是握手包丢了。

3.1 NRZI 编码与位填充：时钟藏在 SYNC 域里

USB 没有独立的时钟线，时钟从数据里恢复。编码用的是 NRZI：遇 1 不翻转，遇 0 翻转。这样连续的高电平或低电平不会太长，接收方能靠边沿维持同步。但连续 1 会导致长时间不翻转，所以协议规定连续出现 6 个 1 就强制插入一个 0，接收端按同样规则剔除。位填充写错是逻辑分析仪解码失败的头号原因，自己写软件解码时尤其容易漏。

更麻烦的是第一拍从哪开始。答案在同步域 SYNC：低速和全速设备的 SYNC 固定为0000 0001，高速设备是 31 个 0 后跟一个 1。按"遇 0 翻转"的规则，全速设备的 SYNC 会呈现出一串高低交替的方波，主机就靠这段方波把自己的采样频率对齐到设备发出来的速率上。抓波形时如果开头看不到这段规整方波，基本可以断定设备根本没开始发，问题在上游的供电或复位。

3.2 包结构与 PID：SOP、EOP 和四类包的配合

包的开头叫 SOP，总线空闲时 D+ 为高、D- 为低，驱动到相反状态就是 SOP。包尾叫 EOP，D+ 和 D- 同时拉低并保持两个位时间。抓包软件把这两个特征点之间的一段解成一帧。

SOP 之后紧跟 PID，一个字节里高 4 位是类型、低 4 位是类型字段的补码，接收方把两半异或一下就能校验，全 1 才算对。PID 分四类：令牌类有 SETUP、IN、OUT、SOF，数据类有 DATA0、DATA1 用来做数据翻转校验，握手类有 ACK、NACK、STALL，特殊类里有 ERR。CDC 设备通信里最常看到的是 IN/OUT 令牌配 DATA0/DATA1，NACK 表示设备暂时忙、不是出错，STALL 才是端点真出问题了。

包里的地址域是 7 位，理论上能挂 128 个地址，实际主机分配时通常从 1 开始往上加，0 留给默认状态。端点域 4 位，所以每个方向最多 16 个端点。这两段拼在令牌包里，抓包时看 ADDR 和 ENDP 就能确认主机到底在跟谁说话——枚举失败时经常发现地址没切过来，主机还在用 0 地址反复问，设备当然不理。

3.3 八个字节的标准请求：写个脚本把包拆开看

所有标准请求都是固定的 8 字节结构，字段含义按偏移量排：第 0 字节 bmRequestType，第 1 字节 bRequest，第 2～3 字节 wValue，第 4～5 字节 wIndex，第 6～7 字节 wLength。把这套规则写成脚本，抓到的 SETUP 包可以直接贴进去还原：

# 拆解 USB 标准请求的 8 字节 SETUP 包 def parse_setup(hexstr): b = bytes.fromhex(hexstr.replace(" ", "")) assert len(b) == 8, "SETUP 包必须是 8 字节" bmRequestType = b[0] direction = "设备到主机" if bmRequestType & 0x80 else "主机到设备" req_type = (bmRequestType >> 5) & 0x03 # 0 标准 1 类 2 厂商 recipient = bmRequestType & 0x1F # 0 设备 1 接口 2 端点 req_names = {0x05: "SET_ADDRESS", 0x06: "GET_DESCRIPTOR", 0x08: "GET_CONFIGURATION", 0x09: "SET_CONFIGURATION"} return { "方向": direction, "请求类型": ["标准", "类", "厂商"][req_type], "接收者": ["设备", "接口", "端点"][recipient], "请求": req_names.get(b[1], hex(b[1])), "wValue": b[2] | (b[3] << 8), "wIndex": b[4] | (b[5] << 8), "wLength": b[6] | (b[7] << 8), # 小端序，低字节在前 } print(parse_setup("80 06 00 01 00 00 40 00")) # 结果：设备到主机 / 标准 / 设备 / GET_DESCRIPTOR / wValue=0x0100 / wLength=64

脚本里最需要注意的是小端序。00 01拼出来是 0x0100，低字节 00 是描述符索引，高字节 01 是描述符类型。很多人第一次调试时把 wValue 当成 0x0001 去查，怎么看都对不上。同样，40 00是 0x0040 = 64，不是 0x4000。

标准请求里常用的就三个：0x05 设置地址、0x06 取描述符、0x09 设置配置。CDC 类还会用到类请求（bmRequestType 的第 6～5 位是 01），比如设置串口波特率，这部分放到第 4 章讲。

3.4 事务三阶段与 SOF：时间基准从哪来

一个完整事务分三段：令牌包、数据包、握手包。主机写数据到设备时是 SETUP/OUT 令牌 → DATA 阶段 → 状态阶段，状态阶段用一个长度为 0 的空包表示应答；主机从设备读数据时是 IN 令牌 → DATA 阶段 → 状态阶段，同样用空包收尾。CDC 的 bulk 传输会省掉中间的状态阶段，靠 ACK 直接确认。

总线上的时间基准来自 SOF 包。全速设备每 1ms 一个帧，高速设备每 125us 一个微帧，主机以广播形式发 SOF，里面带 11 位帧号，从 0 涨到 0x7FF 之后回卷。帧号只在 SOF 里有，其他包不带。这条信息在做超时判定时很有用：与其用软件计时器死等，不如数 SOF，超时阈值直接按帧算，不受主频和中断延迟影响，比纯软件延时靠谱得多。

4. CDC 类驱动落地：接口、端点与 CH32V307 上的收发通路

协议层通了，接下来要让两个串口助手对发数据。这一段的核心是描述符解析要准、端点配置要对、FIFO 分配要够。CH32V307 的好处是自带两路 USB，FS 和 HS 都有，HS 内置 PHY 支持 OTG，做主机实验时不用外挂 PHY，直接对接设备就行。

4.1 CDC 描述符结构：通信接口与数据接口的分工

CDC 设备在配置描述符里通常有两个接口：通信接口（bInterfaceClass = 0x02，子类 0x02 表示 ACM 抽象控制模型，协议 0x01 表示用 AT 命令集）和数据接口（bInterfaceClass = 0x0A）。通信接口挂一个中断端点，用来传串口状态通知和线路编码设置；数据接口挂一对 bulk 端点，一进一出，才是真正搬业务数据的地方。

配置描述符里还能读到 bMaxPower 字段，按 2mA 为单位换算，比如读到 0x16 就是 44mA，说明这设备总线供电就能带起来。这个值在做主机供电设计时要看，超了得外部供电。

解析描述符时不能按固定偏移硬啃。配置描述符后面跟的是一串变长描述符，每个都以 bLength 开头、bDescriptorType 标识类型，正确做法是一个循环走完 wTotalLength 指定的总长度，遇到 0x04（接口）就记接口号、类、子类，遇到 0x05（端点）就记端点地址、属性、最大包长。端点地址最高位表示方向，0x81是端点 1 的 IN，0x02是端点 2 的 OUT。

4.2 端点规划与 FIFO 分配

以抓到的这台设备为例，通信接口的中断端点 IN 方向，数据接口 IN 是 0x81、OUT 是 0x02，两个 bulk 端点最大包长都是 64 字节。CH32V307 的 USB 外设有一块共享 FIFO 内存，主机模式下要给每个通道单独分配深度，分配原则是至少能装下两包最大包长的数据，否则高速收发时容易因为来不及搬运而丢包。

FIFO 总量是固定的，深度给大了会挤占其他通道，给 128 字节（两包）是平衡点。如果设备是高速 512 字节包长，深度要跟着翻，不然大文件传输必然丢。

4.3 收发通路：中断端点通知 + bulk 数据搬运

配置生效（SET_CONFIGURATION 成功返回）之后才能碰业务端点。收发本身不复杂，麻烦的是状态管理——bulk OUT 发完要等 ACK，收到 NAK 要重试，收到 STALL 要清端点。

/* CDC 数据收发核心逻辑，基于 USB 主机通道接口，函数名按各自库替换 */ #define CDC_OUT_EP 0x02 #define CDC_IN_EP 0x81 #define CDC_EP_SIZE 64 #define RETRY_MAX 100 /* 发送：把 len 字节通过 bulk OUT 端点发出去 */ int CDC_SendData(const uint8_t *buf, uint16_t len) { uint16_t offset = 0; uint16_t retry = 0; while (offset < len) { uint16_t chunk = (len - offset) > CDC_EP_SIZE ? CDC_EP_SIZE : (len - offset); /* 每个包的长度不能超过端点最大包长 */ if (USBH_BulkSend(CDC_OUT_EP, (uint8_t *)buf + offset, chunk) == OK) { offset += chunk; retry = 0; } else { /* 收到 NAK 说明设备忙，不代表出错，重试即可 */ if (++retry > RETRY_MAX) { USBH_ClrEndpoint(CDC_OUT_EP); /* 超限则清端点复位通路 */ return -1; } DelayUs(100); } } /* 长度正好是最大包长整数倍时，补一个零长度包表示结束 */ if (len % CDC_EP_SIZE == 0 && len > 0) { USBH_BulkSend(CDC_OUT_EP, NULL, 0); } return 0; } /* 接收：中断端点里有数据说明串口状态变化，必须先读走 */ void CDC_Poll(void) { uint8_t notify[16]; uint8_t data[CDC_EP_SIZE]; if (USBH_IntInReady(0x81)) { USBH_BulkReceive(0x81, notify, sizeof(notify)); /* 不清会阻塞后续中断 */ } int n = USBH_BulkReceive(CDC_IN_EP, data, sizeof(data)); if (n > 0) { RingBuffer_Push(data, n); /* 先进环形缓冲，业务层慢慢取 */ } }

两处注释是踩过坑才加的。len % CDC_EP_SIZE == 0时补零长度包，是因为接收方靠短包判断传输结束，正好整数倍时如果不补，对方会一直等下一包，表现为"数据发完了但对面少一截"。中断端点不读走也是同理，很多 CDC 设备在串口参数变化时会往中断端点塞通知，主机不取，端点一直 NAK，看起来像是设备挂了。

4.4 类请求：把波特率真正设进去

CDC ACM 设备默认波特率是设备决定的，要改就得发类请求 SET_LINE_CODING，bmRequestType = 0x21（主机到设备、类请求、接口接收者），bRequest = 0x20，后面跟 7 字节线路编码：4 字节波特率、1 字节停止位、1 字节校验、1 字节数据位，全部小端序。发送顺序是先 SET_LINE_CODING 再 SET_CONTROL_LINE_STATE（bRequest = 0x22）把 DTR 拉起来，两包都成功，对端串口助手才会开始正常收发。

这一步很容易漏，尤其是对接那些"不设参数也能收"的芯片，一旦换成严格的设备就完全没数据，现象和端点没配对一模一样，排查时要先怀疑它。

5. 常见问题排查：五个最容易翻车的现场

5.1 插上设备，主机毫无反应

现象：逻辑分析仪抓 D+，插入前后都是低电平，主机侧状态机停在 IDLE 不动。

原因：设备上拉电阻需要供电才起作用，主机没有给 VBUS，或者 VBUS 控制引脚没使能。另一种情况是 GPIO 复用没配对，USB 外设根本没接管引脚，引脚还挂在普通输入上。

解决：先量设备侧 VBUS 有没有 5V，再确认 USB 引脚是否切到复用功能、时钟是否使能。这一步用万用表和示波器比看代码快得多。

5.2 枚举停在 SET_ADDRESS 之后

现象：地址设置成功，后面再发什么包设备都不回，抓包看到主机还在用 0 地址问。

原因：多数是主机内部没同步更新地址，或者 SET_ADDRESS 的状态阶段没处理完就开始下一包。USB 协议要求地址在状态阶段完成之后才生效，早一个包都不行。

解决：在设置地址成功的回调里显式更新主机侧的地址变量，并在状态阶段完成后再发起下一次传输；中间加一两帧 SOF 的间隔，别图快。

5.3 枚举成功但业务数据一个字节都收不到

现象：设备描述符、配置描述符都取到了，端点也配了，就是没数据。

原因：三种可能——没发 SET_CONFIGURATION，接口没被激活；选错了接口（CDC 有两个接口，数据在第二个）；类请求没发，设备的 DTR 没拉起来。

解决：按顺序确认配置已激活、端点地址取的是数据接口那一对、补发 SET_LINE_CODING 和 SET_CONTROL_LINE_STATE。这三步做成固定流程，别跳。

5.4 小数据能通，大数据必丢

现象：发几个字节正常，一发几百字节就少一段或者整段没了。

原因：FIFO 深度只够一包，搬运不及时就溢出；或者长度正好是最大包长整数倍时没补零长度包，对端一直在等结尾。

解决：FIFO 按两包最大包长分配；发送逻辑里补零长度包；接收改环形缓冲，别在中断里直接处理业务。

5.5 逻辑分析仪解出来的包全是乱的

现象：波形看着有高低变化，但软件解不出 PID，或者 CRC 报错。

原因：采样率不够，USB 全速是 12Mbps，采样率低于 48MHz 基本没戏；或者地线没接好，差分信号共模漂移；再或者是自己写解码时漏了位填充的剔除。

解决：采样率拉到 100MHz 以上，探头地线尽量短，解码脚本先拿已知的 SETUP 包做回归验证，通过了再去解业务数据。

6. 验收与答辩：怎么证明这条链路真的通了

验收这一步最怕"我觉得它通了"。可靠的做法是把结论拆成可以单独复现的观察点，每一条都有抓包或波形做证据，答辩时被问到哪一层都能立刻翻出材料。

答辩时最容易被追问的是"你怎么确定是 CDC 类而不是厂商自定义类"。答案在接口描述符的 bInterfaceClass，不是设备描述符——设备描述符里那一字节常常是 0，类信息放在接口层，这是 CDC 复合设备的通行做法。把配置描述符的原始字节和解析后的字段并排贴在 PPT 上，比讲十句原理都管用。

还有一个加分项：把第一次取 8 字节、第二次取 18 字节、第三次取全量配置描述符这三段抓包按时间轴排好，标出复位点和地址切换点。评审看一眼就知道你真的抓过包，而不是抄的流程图。

我从这个项目里留下一个习惯：任何 USB 相关的问题，先抓波形再改代码。以前遇到识别不稳定的情况，第一反应是翻代码找逻辑漏洞，改了半天没进展，最后拿逻辑分析仪一看，复位低电平只有 6ms，压根没到协议要求。从那以后我每次调 USB，都强制先跑一遍"插入—复位—取 8 字节"这三步的抓包，确认电气层没问题再往上查。这份资料里完整的协议分析、抓包记录和 CH32V307 上的实现路径，基本能覆盖从零到跑通的全过程，希望帮到你。

本文还有配套的精品资源，点击获取