STM32 USB HID自定义设备开发：实现64字节数据包双向通信

1. 项目概述与核心需求

最近在做一个需要将老旧的串口设备升级为USB接口的项目，原来的通信协议是基于串口的，命令包最大长度是64字节。直接换USB转串口芯片当然简单，但我想利用STM32自带的USB设备控制器，实现一个更“原生”、更灵活的双向通信通道。HID（人机接口设备）类是个不错的选择，它免驱动（在主流操作系统上），协议栈成熟，但官方例程通常只演示了鼠标、键盘这类标准设备，传输的数据量很小，每次就几个字节。我的目标是把HID“改造”成一个能传输64字节自定义数据包的“透明通道”，模拟出类似串口那种按包收发的感觉。

这不仅仅是改几个参数那么简单，它涉及到对USB HID协议底层机制的理解，包括端点描述符、报告描述符的定制，以及上位机如何正确识别和操作这个非标设备。整个过程就像是在标准的HID框架内，开辟出一条符合自己业务逻辑的专用车道。下面，我就把从STM32下位机固件修改，到Windows上位机应用程序开发的完整过程，结合踩过的坑和总结的技巧，详细拆解一遍。

2. 方案选型：为什么是自定义HID？

面对设备与PC通信的需求，可选方案很多，比如虚拟串口（CDC）、大容量存储（MSC）或者自定义设备类。我最终选择自定义HID，主要基于以下几点考量：

2.1 免驱带来的巨大便利性这是最核心的优势。USB HID类是操作系统内置支持的设备类。在Windows、macOS、Linux等系统上，无需用户额外安装驱动程序，系统在识别设备后会自动加载内置的HID类驱动。这对于产品化部署和用户体验至关重要，即插即用，减少了用户安装驱动的麻烦和潜在的兼容性问题。

2.2 协议栈成熟且开销可控USB协议本身很复杂，但HID类为其定义了一套完整的子协议。STM32的USB官方库（如标准外设库或HAL库中的Custom_HID例程）已经实现了HID设备的基本框架，包括描述符处理、标准请求响应、中断传输管理等。我们只需要在这个框架上做“装修”，而不需要从零开始“盖楼”，开发起点高，稳定性好。同时，HID默认采用中断传输（Interrupt Transfer），这是一种保证延迟的传输方式，虽然速度不是最快的，但对于毫秒级响应的控制与数据采集场景，其带宽和实时性完全足够，且CPU占用率相对较低。

2.3 灵活性与自定义能力很多人误以为HID只能用于键盘鼠标。其实，HID规范允许定义“供应商自定义”（Vendor-Defined）的用法页（Usage Page）和用法（Usage）。这意味着我们可以定义自己的设备类型和数据报告格式。通过精心设计报告描述符（Report Descriptor），我们可以描述出任意结构和长度的输入（IN）、输出（OUT）和特征（Feature）报告，从而实现灵活的双向数据交换。这正是本项目实现64字节自定义数据包的理论基础。

2.4 对比其他方案

• 虚拟串口（CDC）：虽然也是免驱趋势（Windows 10后内置了USB CDC驱动），但在一些老系统或特定环境下可能仍需驱动。其优势是上位机编程极其简单，兼容所有串口软件。劣势是协议开销比原始HID中断传输稍大，且对USB枚举过程的控制不如自定义HID直接。
• 自定义设备类：最灵活，可以自定义一切，但代价是必须在PC端开发并安装专用的内核模式驱动（.inf + .sys），开发难度大、周期长、安全审核复杂，不适合快速原型开发或个人项目。
• WinUSB：微软推出的用于简化USB设备驱动开发的方案，需要安装特定的驱动（可通过驱动签名或使用Zadig等工具）。它比自定义内核驱动简单，但仍需处理驱动安装，不如HID免驱彻底。

综合来看，对于需要稳定、免驱、且数据量在中断传输承载范围内（低速/全速设备每个微帧最多1024字节，高速设备更多）的双向通信，自定义HID是一个在开发复杂度、部署便利性和功能灵活性之间取得绝佳平衡的方案。

3. 下位机（STM32）固件深度改造

官方STM32 USB库中的Custom_HID例程是一个很好的起点，但它默认只为鼠标键盘等小数据量设计。我们的目标是64字节的数据包，需要对其进行多处关键手术。

3.1 工程基础与硬件确认我使用的硬件是STM32F103ZET6（俗称的“大容量”型号），它内置了全速USB设备控制器。软件基础是STM32 USB标准外设库V3.2.0中的“Custom_HID”工程。首先确保你的工程能正常编译，并通过USB线连接电脑后，能在设备管理器的“人体学输入设备”下看到你的设备（可能显示为“HID-compliant device”或你自定义的名称）。这是后续所有修改的基石。

3.2 修改端点描述符（Endpoint Descriptor）端点是USB通信的逻辑管道。在usb_desc.c文件中，找到CustomHID_ConfigDescriptor数组。这个数组定义了设备的整个配置信息。我们需要修改的是其中关于端点（Endpoint）的部分。

默认的端点描述符可能如下所示（具体值可能因库版本略有差异）：

/* 端点描述符 */ 0x07, /* 描述符长度 */ USB_ENDPOINT_DESCRIPTOR_TYPE, /* 描述符类型：端点 */ 0x81, /* 端点地址： EP1 IN */ USB_ENDPOINT_TYPE_INTERRUPT, /* 属性：中断传输 */ 0x40, 0x00, /* 最大包大小： 64字节 */ 0x0A, /* 轮询间隔 (ms) */

这里0x40, 0x00表示最大包大小为64字节（小端格式，0x0040）。这已经是64了，为什么还要改？注意，这个64是USB协议层一次中断传输所能携带的最大数据量。但对于HID设备，实际传输的数据还包括一个字节的报告ID（Report ID）。所以，如果你希望应用层数据是64字节，那么USB包大小至少需要设置为65（64数据 + 1报告ID）。我们将它改为0x41, 0x00（即65）。

同样，找到OUT端点（例如0x01， EP1 OUT）的描述符，进行同样的修改。修改后，USB主机（电脑）就知道这个端点每次传输最多能接收/发送65个字节的数据。

注意：对于全速USB设备，中断传输的最大包大小理论上是64字节。但实际测试和规范表明，可以设置为65甚至更大（如8、16、32、64、...、1024）。设置为65是为了容纳“64字节数据+1字节报告ID”。如果你的芯片支持高速USB（如STM32F4/F7/H7），这个值可以设得更大。

3.3 修改端点缓冲区大小描述符是告诉主机“我能吃多少”，而端点缓冲区是设备内部“我的碗有多大”。在usb_prop.c或usb_endp.c的CustomHID_Reset函数中，会调用SetEPTxCount和SetEPRxCount来设置端点Tx（发送）和Rx（接收）缓冲区的计数。

找到类似下面的代码：

SetEPTxCount(ENDP1, 64); // 设置端点1发送缓冲区大小为64 SetEPRxCount(ENDP1, 64); // 设置端点1接收缓冲区大小为64

同样，为了容纳65字节的包（64数据+1报告ID），需要将它们改为65。

SetEPTxCount(ENDP1, 65); SetEPRxCount(ENDP1, 65);

这个函数在每次USB复位时被调用，确保硬件缓冲区配置与描述符一致。

3.4 设计并修改报告描述符（Report Descriptor）这是自定义HID的灵魂。报告描述符用一种特殊的“语言”告诉主机：我这个设备有哪些报告（数据包），每个报告是输入（设备到主机）还是输出（主机到设备），里面包含什么数据，数据是什么类型（数组、变量）、什么单位。

官方例程的报告描述符通常定义了多个报告，且数据量很小。我们需要简化它，只定义两个报告：一个65字节的输入报告（IN Report），一个65字节的输出报告（OUT Report）。报告ID分别为1和2。

手动编写报告描述符非常晦涩，强烈推荐使用USB-IF官方工具“HID Descriptor Tool”。你可以通过图形化界面勾选添加项目，它会自动生成描述符代码。基本思路如下：

1. 定义一个用法页（Usage Page）为0xFF00（Vendor Defined）。
2. 定义一个用法（Usage）为0x01。
3. 创建两个报告（Collection）。
4. 在输入报告（Input）中，定义一个报告ID为1，然后定义一个长度为64字节（512位）的数组（Report Count=64,Report Size=8）。
5. 在输出报告（Output）中，定义一个报告ID为2，同样定义一个64字节的数组。

生成的代码片段会类似这样（仅供参考，需根据工具实际输出调整）：

0x06, 0x00, 0xFF, // Usage Page (Vendor Defined 0xFF00) 0x09, 0x01, // Usage (0x01) 0xA1, 0x01, // Collection (Application) 0x85, 0x01, // Report ID (1) 0x09, 0x01, // Usage (0x01) 0x15, 0x00, // Logical Minimum (0) 0x26, 0xFF, 0x00, // Logical Maximum (255) 0x75, 0x08, // Report Size (8 bits) 0x95, 0x40, // Report Count (64 items) -> 64 bytes 0x81, 0x02, // Input (Data, Var, Abs) -> IN Report 0x85, 0x02, // Report ID (2) 0x09, 0x02, // Usage (0x02) 0x15, 0x00, // Logical Minimum (0) 0x26, 0xFF, 0x00, // Logical Maximum (255) 0x75, 0x08, // Report Size (8 bits) 0x95, 0x40, // Report Count (64 items) -> 64 bytes 0x91, 0x02, // Output (Data, Var, Abs) -> OUT Report 0xC0 // End Collection

将生成的这段数组替换掉usb_desc.c中原来的CustomHID_ReportDescriptor数组。务必确保数组长度与定义一致。

3.5 改造数据发送（IN）函数官方例程的数据发送可能分散在多个地方，并且是针对小数据包的。我们需要一个统一的、能发送65字节包的函数。首先定义一个发送缓冲区：

__IO uint8_t Send_Buffer[65]; // 索引0存放报告ID，索引1-64存放用户数据

然后编写发送函数：

void USB_Send_Report(uint8_t *user_data, uint16_t len) { // 参数检查：用户数据长度不能超过64 if (len > 64) len = 64; // 填充报告ID Send_Buffer[0] = 0x01; // 对应报告描述符中定义的Input Report ID // 拷贝用户数据 memcpy(&Send_Buffer[1], user_data, len); // 如果数据不足64字节，可以填充0或保持原样（取决于协议要求） // for(uint16_t i = len+1; i < 65; i++) Send_Buffer[i] = 0x00; // 等待上一个IN传输完成（确保端点Tx缓冲区空闲） while (GetEPTxStatus(ENDP1) != EP_TX_NAK); // 将数据写入USB发送端点缓冲区 USB_SIL_Write(EP1_IN, Send_Buffer, 65); // 使能端点发送 SetEPTxValid(ENDP1); }

这个函数的关键在于：

1. 报告ID先行：Send_Buffer[0]必须放置报告ID（此处为1），主机靠它来识别是哪个报告。
2. 等待就绪：在写入新的数据之前，必须检查端点状态，确保上一次传输已经完成（状态为EP_TX_NAK），否则会覆盖未送出的数据。
3. 正确调用API：USB_SIL_Write将数据从应用缓冲区拷贝到USB内核的端点缓冲区，SetEPTxValid则通知USB内核可以发起传输了。

3.6 改造数据接收（OUT）处理数据接收是由USB中断驱动的。当主机发送数据到OUT端点时，会触发相应的中断。我们需要在中断服务程序或主循环的轮询中处理接收到的数据。

首先，在USB中断服务程序（USB_LP_CAN1_RX0_IRQHandler）或相关处理函数中，确保对OUT端点中断的处理。通常，在CustomHID_Data_Setup或专门的OUT端点回调函数中，我们需要读取数据。

我们可以创建一个接收缓冲区和标志位：

uint8_t Receive_Buffer[65]; volatile uint8_t USB_Data_Received = 0;

在OUT端点中断处理部分（例如在EP1_OUT_Callback函数中）：

void EP1_OUT_Callback(void) { uint16_t data_len; // 从USB端点缓冲区读取数据到Receive_Buffer data_len = USB_SIL_Read(EP1_OUT, Receive_Buffer); if(data_len == 65) { // 确保收到完整包 // 检查报告ID，例如我们定义输出报告ID为2 if(Receive_Buffer[0] == 0x02) { // 数据有效，置位标志位，供主循环处理 USB_Data_Received = 1; } } // 重新使能OUT端点接收，准备下一次传输 SetEPRxValid(ENDP1); }

在主循环中，可以检查USB_Data_Received标志，然后处理&Receive_Buffer[1]开始的64字节用户数据。

3.7 清理与优化删除或注释掉原工程中与ADC、按钮、LED控制相关的代码，这些是官方例程的演示部分，与我们的自定义数据通信无关。确保你的主循环专注于应用逻辑，并在合适的时间调用USB_Send_Report发送数据，以及处理USB_Data_Received接收到的数据。

编译并下载程序到STM32，使用USBLyzer或Bus Hound这类USB协议分析工具，可以看到设备枚举的详细过程，以及当你尝试发送数据时，是否正确生成了包含报告ID的65字节IN请求。这是验证下位机修改是否成功的关键一步。

4. 上位机（Windows）应用程序开发详解

下位机准备好后，我们需要一个PC程序来与之通信。Windows提供了hid.dll和setupapi.dll中的一系列函数来访问HID设备。

4.1 开发环境与项目配置我使用的是Visual Studio 2005，但原理适用于更高版本。关键是要配置好DDK/WDK的头文件和库路径，因为HID相关的函数需要这些。

1. 包含头文件：在源文件中包含必要的头文件。

   extern "C" { #include <windows.h> #include <setupapi.h> // 用于设备枚举 #include <hidsdi.h> // HID专用函数 #include <dbt.h> // 设备消息通知（可选） }

2. 链接库文件：在项目属性中链接hid.lib和setupapi.lib，或者使用编译指令。

   #pragma comment(lib, "hid.lib") #pragma comment(lib, "setupapi.lib")

4.2 发现与打开特定HID设备PC上可能连接了多个HID设备（键盘、鼠标等）。我们需要通过设备的供应商ID（VID）和产品ID（PID）来找到我们的目标设备。这两个ID在STM32的USB描述符（usb_desc.c中的CustomHID_DeviceDescriptor）中定义。

GUID hidGuid; HidD_GetHidGuid(&hidGuid); // 获取系统HID类的GUID HDEVINFO hDevInfo = SetupDiGetClassDevs(&hidGuid, NULL, NULL, DIGCF_PRESENT | DIGCF_DEVICEINTERFACE); if (hDevInfo == INVALID_HANDLE_VALUE) return -1; SP_DEVICE_INTERFACE_DATA interfaceData; interfaceData.cbSize = sizeof(SP_DEVICE_INTERFACE_DATA); DWORD memberIndex = 0; HANDLE hDevice = INVALID_HANDLE_VALUE; WCHAR devicePath[MAX_PATH]; // 遍历所有HID设备 while (SetupDiEnumDeviceInterfaces(hDevInfo, NULL, &hidGuid, memberIndex, &interfaceData)) { DWORD requiredSize = 0; // 第一次调用获取所需缓冲区大小 SetupDiGetDeviceInterfaceDetail(hDevInfo, &interfaceData, NULL, 0, &requiredSize, NULL); PSP_DEVICE_INTERFACE_DETAIL_DATA detailData = (PSP_DEVICE_INTERFACE_DETAIL_DATA)malloc(requiredSize); detailData->cbSize = sizeof(SP_DEVICE_INTERFACE_DETAIL_DATA); if (SetupDiGetDeviceInterfaceDetail(hDevInfo, &interfaceData, detailData, requiredSize, NULL, NULL)) { // 尝试打开这个设备路径 hDevice = CreateFile(detailData->DevicePath, GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, FILE_FLAG_OVERLAPPED, // 或0，用于同步I/O NULL); if (hDevice != INVALID_HANDLE_VALUE) { // 获取设备的VID/PID HIDD_ATTRIBUTES attrib; attrib.Size = sizeof(HIDD_ATTRIBUTES); if (HidD_GetAttributes(hDevice, &attrib)) { if (attrib.VendorID == 0x0483 && attrib.ProductID == 0x5750) { // 替换为你的VID/PID wcscpy_s(devicePath, MAX_PATH, detailData->DevicePath); break; // 找到目标设备 } } CloseHandle(hDevice); // 不是目标设备，关闭句柄 hDevice = INVALID_HANDLE_VALUE; } } free(detailData); memberIndex++; } SetupDiDestroyDeviceInfoList(hDevInfo); if (hDevice == INVALID_HANDLE_VALUE) { printf("未找到目标HID设备。\n"); return -1; }

这段代码的核心是遍历所有HID设备接口，打开它们，并通过HidD_GetAttributes查询VID/PID来筛选出我们的设备。成功打开后，hDevice就是与设备通信的句柄。

4.3 获取设备能力（关键步骤）打开设备后，必须获取其能力信息，特别是报告的长度。这是很多新手容易出错的地方。

PHIDP_PREPARSED_DATA preparsedData = NULL; HIDP_CAPS capabilities; // 获取预解析数据 if (!HidD_GetPreparsedData(hDevice, &preparsedData)) { CloseHandle(hDevice); printf("获取预解析数据失败。\n"); return -1; } // 获取设备能力 if (HidP_GetCaps(preparsedData, &capabilities) != HIDP_STATUS_SUCCESS) { HidD_FreePreparsedData(preparsedData); CloseHandle(hDevice); printf("获取设备能力失败。\n"); return -1; } // 打印关键信息 printf("Input Report Byte Length: %d\n", capabilities.InputReportByteLength); printf("Output Report Byte Length: %d\n", capabilities.OutputReportByteLength); printf("Feature Report Byte Length: %d\n", capabilities.FeatureReportByteLength); printf("Usage Page: 0x%04X\n", capabilities.UsagePage); printf("Usage: 0x%04X\n", capabilities.Usage); // 使用完后释放预解析数据 HidD_FreePreparsedData(preparsedData);

capabilities.InputReportByteLength和capabilities.OutputReportByteLength这两个值至关重要！它们直接来自设备报告描述符，并且包含了报告ID所占的1个字节。所以，如果你在STM32端定义了一个65字节的报告（1字节ID+64字节数据），这里获取到的InputReportByteLength就应该是65。后续调用ReadFile和WriteFile时，缓冲区大小必须等于这个值。

4.4 数据读写操作有了设备句柄和报告长度，就可以进行读写了。读写操作是围绕报告（Report）进行的，缓冲区第一个字节必须是报告ID。

• 写数据（OUT Report）到设备：

BOOL WriteToDevice(HANDLE hDevice, BYTE* data, DWORD dataLen, BYTE reportID) { DWORD bytesWritten = 0; // 分配缓冲区，大小为输出报告长度 DWORD outReportLen = capabilities.OutputReportByteLength; // 假设已从capabilities获取 BYTE* outBuffer = new BYTE[outReportLen]; ZeroMemory(outBuffer, outReportLen); // 缓冲区清零是个好习惯 // 第一个字节是报告ID outBuffer[0] = reportID; // 对应STM32端报告描述符中Output Report的ID，例如2 // 拷贝用户数据 memcpy_s(&outBuffer[1], outReportLen - 1, data, min(dataLen, outReportLen - 1)); BOOL result = WriteFile(hDevice, outBuffer, outReportLen, &bytesWritten, NULL); // 或者使用异步I/O，这里用同步简单示例 delete[] outBuffer; if (!result || bytesWritten != outReportLen) { printf("写入失败或写入字节数不正确。错误码: %d\n", GetLastError()); return FALSE; } return TRUE; }

• 从设备读数据（IN Report）：

BOOL ReadFromDevice(HANDLE hDevice, BYTE* buffer, DWORD bufferLen, DWORD* bytesRead) { // 分配缓冲区，大小为输入报告长度 DWORD inReportLen = capabilities.InputReportByteLength; // 假设已从capabilities获取 BYTE* inBuffer = new BYTE[inReportLen]; BOOL result = ReadFile(hDevice, inBuffer, inReportLen, bytesRead, NULL); if (result && *bytesRead == inReportLen) { // 第一个字节是报告ID，可以校验 BYTE reportID = inBuffer[0]; if (reportID == 0x01) { // 对应STM32端Input Report的ID // 有效数据从 inBuffer[1] 开始，长度是 inReportLen - 1 memcpy_s(buffer, bufferLen, &inBuffer[1], min(*bytesRead - 1, bufferLen)); } else { printf("收到未知报告ID: 0x%02X\n", reportID); result = FALSE; } } else { printf("读取失败或读取字节数不正确。错误码: %d\n", GetLastError()); result = FALSE; } delete[] inBuffer; return result; }

关键点：ReadFile和WriteFile的nNumberOfBytesToRead/Write参数必须严格等于从HidP_GetCaps获取的报告长度。缓冲区第一个字节留给报告ID，用户数据从第二个字节开始。

4.5 异步I/O与重叠操作上面的示例使用的是同步I/O，ReadFile会阻塞直到数据到达。对于需要实时响应的应用，建议使用异步I/O（重叠I/O）。在CreateFile时指定FILE_FLAG_OVERLAPPED标志，并使用OVERLAPPED结构体和WaitForSingleObject或GetOverlappedResult来管理读写操作，这样可以避免主线程被阻塞。

5. 调试技巧与常见问题排查

在整个开发过程中，调试是耗时最多的环节。以下是我总结的一些实用技巧和常见问题的解决方法。

5.1 下位机调试

1. LED/串口辅助调试：在关键代码位置（如USB复位成功、收到数据、发送数据前）添加LED闪烁或通过串口打印调试信息。这是最直接判断程序运行到哪一步的方法。
2. USB协议分析工具：USBLyzer、Bus Hound、Wireshark（配合USBPcap）是神器。它们能捕获USB总线上的所有数据包。
   • 检查枚举过程：连接设备后，看是否能正确完成枚举过程（SETUP阶段，获取描述符）。如果枚举失败，设备管理器里会出现黄色感叹号。重点检查设备描述符、配置描述符、端点描述符的内容是否正确。
   • 检查报告描述符：工具会解析并显示报告描述符。对照你设计的描述符，看是否被正确发送和理解。
   • 检查数据流：当你尝试读写时，可以看到具体的IN/OUT令牌包和数据包。确认数据包长度是否为65字节，第一个字节是否是预期的报告ID。
3. STM32 USB库状态：仔细阅读库文件中的错误码和状态寄存器。例如，GetEPTxStatus可以返回端点状态（NAK,VALID,STALL等），帮助判断传输是否卡住。

5.2 上位机调试

1. 设备管理器：首先确认设备是否被正确识别为“HID-compliant device”，并且没有感叹号。如果有，查看设备属性中的“事件”日志，通常会有错误代码，如“设备描述符请求失败”等。
2. 权限问题：在Windows Vista及以后版本，对HID设备的读写可能需要管理员权限。特别是WriteFile操作。尝试以管理员身份运行你的上位机程序。
3. 缓冲区大小错误：这是最常见的读写失败原因。务必使用HidP_GetCaps获取的InputReportByteLength和OutputReportByteLength作为ReadFile/WriteFile的缓冲区大小。这个长度是包含报告ID的！
4. 报告ID不匹配：上位机发送的OUT报告ID必须与下位机报告描述符中定义的Output Report ID一致。同样，下位机发送的IN报告ID也必须与Input Report ID一致。不匹配会导致主机忽略该报告。
5. 访问冲突：确保没有其他程序（包括系统进程）正在独占访问该HID设备。使用CreateFile时，共享模式（FILE_SHARE_READ | FILE_SHARE_WRITE）要设置正确。

5.3 常见问题速查表

6. 性能优化与扩展思考

实现基本通信后，可以考虑以下方面进行优化和扩展：

6.1 双缓冲与零拷贝在STM32端，对于IN传输（设备到主机），可以使用USB库提供的双缓冲机制（如果硬件支持），或者自己在应用层实现双缓冲区。当USB内核正在发送一个缓冲区中的数据时，应用程序可以准备下一包数据到另一个缓冲区，从而提高吞吐量，避免等待。

6.2 报告描述符的进阶用法我们目前只用了最简单的“数组”项。报告描述符功能非常强大：

• 多个报告：可以定义多个Input/Output报告，用不同的报告ID区分，用于传输不同类型或优先级的数据。
• 特征报告（Feature Report）：用于主机和设备双向传输配置、控制信息，不受中断传输的轮询间隔限制，主机可随时读写。
• 用途选择器（Usage Selector）：可以定义更复杂的数据结构，比如包含多个字段（如命令字、长度、校验和、数据载荷）的结构化报告。

6.3 上位机异步通信框架对于复杂的GUI应用，建议将HID通信模块封装成一个独立的线程或使用事件驱动的异步模式。利用WaitForMultipleObjects同时等待设备句柄的可读事件和其他UI事件，使通信不影响界面响应。

6.4 跨平台考虑HID的免驱特性在Linux和macOS上同样有效。Linux下可以通过libusb或直接操作/dev/hidraw设备文件进行读写。macOS则使用IOKit框架。报告描述符是跨平台的，因此下位机代码通常无需改动，只需重写上位机部分即可实现多平台支持。

经过以上步骤，一个基于自定义HID、支持64字节灵活数据包、稳定双向通信的STM32-PC通道就搭建完成了。整个过程虽然涉及细节较多，但脉络清晰：下位机定制描述符和端点，上位机按规范发现和读写。掌握了这套方法，你就可以让STM32的USB接口摆脱“仅用于编程”的刻板印象，变身成为各种项目中高效、可靠的数据桥梁。