STM32实现HID+CDC复合设备

原创于 2025-11-04 14:19:20 发布 · 1k 阅读

11 ·

CC 4.0 BY-SA版权

文章标签：

#STM32 #USB #HID #CDC #复合设备 #虚拟串口 #报告描述符 #嵌入式

AI助手已提取文章相关产品：

STM32配置组合设备（HID + CDC）技术深度解析

在现代嵌入式开发中，一个常见的痛点是：如何在不增加物理接口的前提下，让调试、控制和数据交互同时高效运行？比如你正在调试一块工业控制器，既要通过串口看日志，又想模拟按钮操作来触发动作——如果能用一根USB线搞定这两件事，岂不是省事得多？

这正是 HID + CDC 复合设备 的价值所在。它将虚拟串口通信与免驱人机输入功能集成于同一USB设备中，无需额外驱动即可在PC上识别为“一个串口 + 一个HID设备”。而STM32凭借其成熟的USB OTG外设和HAL库支持，成为实现这一方案的理想平台。

要理解这种复合结构的工作原理，得先搞清楚USB枚举过程中主机是如何“拆解”一个设备的。当STM32连接到PC时，主机并不会一开始就知道它是键盘还是U盘，而是通过一系列标准请求获取描述符链，逐步解析出设备的功能组成。

在这个流程中，关键在于 配置描述符之后紧跟多个接口描述符 。每个接口声明自己的类类型（ bInterfaceClass ），例如：

接口0：CDC 控制接口（类码 0x02 ）
接口1：CDC 数据接口（类码 0x0A ）
接口2：HID 接口（类码 0x03 ）

虽然它们共享同一个设备地址和控制端点（EP0），但操作系统会根据各自的类码分别加载cdc_acm或hidusb驱动，最终呈现为两个独立的逻辑设备。这就是所谓的“复合设备”（Composite Device）——物理上一体，逻辑上分离。

相比“多功能设备”（Multi-function Device），复合设备更强调在同一配置下多接口共存，且不需要特殊的复合类定义，只需正确组织描述符顺序即可。

以CDC为例，它的作用是让STM32像传统串口一样被PC识别。我们常说的“虚拟COM口”就是基于CDC-ACM模型实现的。当你打开PuTTY或者SecureCRT时，看到的那个COM5，并非真实的RS232接口，而是由USB协议栈模拟出来的。

CDC必须包含两个接口：
- 控制接口 ：用于管理连接状态、波特率设置等控制命令；
- 数据接口 ：负责实际的数据收发，使用批量传输（Bulk Endpoint）。

在STM32 HAL库中，发送数据非常直观：

uint8_t user_data[] = "Hello from CDC!\r\n";
uint16_t len = sizeof(user_data) - 1;

if (CDC_Transmit_FS(user_data, len) == USBD_OK) {
    // 提交成功，等待底层完成传输
}

但要注意的是，这个函数是非阻塞的。调用后只是把数据交给USB堆栈排队，真正的发送是在后续的IN事务中完成的。因此，不能立即释放缓冲区或修改内容，否则可能导致乱码甚至枚举失败。

接收方面，则依赖中断回调机制。每当主机通过OUT端点发送数据，HAL库就会触发 CDC_Receive_FS() 回调，开发者可在其中处理命令解析、协议解包等任务。

值得一提的是，尽管CDC允许设置波特率、奇偶校验等参数，但实际上这些对USB传输速率没有影响——USB本身是高速总线，所谓“波特率”只是向后兼容的一种形式，真正决定吞吐能力的是端点最大包长和轮询间隔。

再来看HID部分。很多人以为HID只能做键盘鼠标，其实不然。由于Windows、Linux、macOS都内置了HID驱动，任何自定义的小数据量通信都可以借用这个“免驱通道”。

核心在于 报告描述符（Report Descriptor） ——它就像一份说明书，告诉主机：“我这个设备上报的数据是什么含义”。你可以定义输入报告（设备→PC）、输出报告（PC→设备）以及特征报告（可读写配置项）。

下面是一个典型的自定义HID描述符片段：

__ALIGN_BEGIN static uint8_t My_HID_ReportDesc_FS[50] __ALIGN_END =
{
    0x06, 0x00, 0xFF,        // USAGE_PAGE (Vendor Defined)
    0x09, 0x01,              // USAGE (Vendor Usage 1)
    0xA1, 0x01,              // COLLECTION (Application)

    // Input Report (8 bytes)
    0x15, 0x00,              //   LOGICAL_MINIMUM (0)
    0x26, 0xFF, 0x00,        //   LOGICAL_MAXIMUM (255)
    0x75, 0x08,              //   REPORT_SIZE (8)
    0x95, 0x08,              //   REPORT_COUNT (8)
    0x09, 0x01,              //   USAGE (Vendor Usage 1)
    0x81, 0x02,              //   INPUT (Data,Var,Abs)

    // Output Report (8 bytes)
    0x95, 0x08,
    0x09, 0x01,
    0x91, 0x02,              //   OUTPUT (Data,Var,Abs)

    0xC0                     // END_COLLECTION
};

这段描述符定义了一个厂商设备，支持8字节输入和8字节输出报告。PC端可以通过标准HID API（如 HidD_GetInputReport 或 WriteFile ）与其通信，完全无需安装驱动。

在STM32侧，发送HID数据也很简单：

uint8_t hid_report[8] = {0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08};
USBD_HID_SendReport(&hUsbDeviceFS, hid_report, 8);

但这里有个陷阱： 每次发送完成后必须等待 USBD_HID_DataIn() 回调触发，才能进行下一次发送 。否则连续调用会导致状态机冲突，甚至设备断开。

至于接收，需要主动开启监听：

int8_t USBD_HID_ReceiveCallback(USBD_HandleTypeDef *pdev, uint8_t *pBuf, uint32_t Len)
{
    OnHidDataReceived(pBuf, Len);
    USBD_HID_ReceivePacket(pdev); // 重新启用接收
    return 0;
}

注意最后一行——如果不重新调用 USBD_HID_ReceivePacket() ，那么下一次主机发来的输出报告将无法被捕获。这是一个新手常犯的错误。

在一个典型的应用场景中，比如基于STM32F407的测试仪器前端，整个系统架构可以这样设计：

使用PA11/PA12作为D+/D-引脚，连接USB mini-B插座；
共享EP0用于控制传输；
IN端点1 → CDC数据发送（批量传输）；
OUT端点1 ← CDC数据接收；
IN端点2 → HID输入报告（中断传输，每1ms~10ms轮询一次）；
OUT端点2 ← 可选的HID输出报告接收；

初始化流程如下：

系统上电，配置时钟、GPIO和USB模块；
初始化 USBD_Device 句柄，注册 USBD_CDC 和 USBD_HID 类驱动；
设置复合设备的配置描述符，确保 wTotalLength 准确反映所有接口总长度；
调用 USBD_Start() 并使能内部上拉电阻（DP Pull-up），宣告设备已就绪；

一旦连接PC，主机开始枚举，依次读取设备描述符、配置描述符、字符串描述符，然后逐个解析接口。若一切正常，设备管理器中将出现一个新的COM端口和一个HID设备（可能显示为“符合HID规范的供应商定义设备”）。

运行期间，两条通路并行工作：
- CDC通道用于上传日志、接收命令；
- HID通道用于实时上报传感器采样值，或接收来自PC的快速控制指令（如启动/停止信号）；

然而，在实际开发中总会遇到一些“意料之外”的问题。

比如，为什么有时候PC只识别出CDC却看不到HID？
最常见的原因是 报告描述符语法错误 。即使只是一个字节错位，主机也可能直接跳过该接口。建议使用 HID Descriptor Tool 验证描述符合法性。另外，也要检查配置描述符中的 bNumInterfaces 是否正确设置为2（或更多），否则主机根本不会尝试读取第三个接口。

另一个问题是：HID能收到数据，但偶尔丢包？
这是中断传输机制的固有特性。全速模式下，HID默认每10ms轮询一次，若STM32未能及时响应IN令牌，该帧就会丢失。解决办法包括：
- 缩短轮询间隔（通过 bInterval 字段设为1~2ms）；
- 在中断服务程序中尽快提交新报告；
- 避免在主循环中长时间阻塞；

还有人反馈CDC出现粘包或数据错乱。这通常是因为 未实现流控机制 。批量传输虽可靠，但接收缓冲区有限。如果PC端来不及读取，新的数据就会覆盖旧数据。推荐做法是在应用层加入帧定界符（如 \n 或特殊头尾标记），并在接收端做缓存重组。

从工程实践角度看，有几个关键设计点值得特别注意：