HID数据传输速率限制：不是“慢”，而是被三重硬件枷锁牢牢锁死
你有没有遇到过这样的场景？
调试一款高速旋转编码器控制面板，明明传感器采样率跑到了2 kHz，MCU主频180 MHz，USB线缆换成了屏蔽双绞的优质货，报告描述符也反复用hid-parser检查过——可主机端hid_read()拿到的数据，还是隔三差五跳变、延迟抖动超过3 ms？Windows 设备管理器里显示“HID 兼容设备”一切正常，Wireshark 抓包一看：每帧（1 ms）只发一个64字节包，但里面真正有用的字段加起来不到20字节。
别急着怀疑驱动、怪罪操作系统，甚至想重写内核模块。问题不在软件栈上层，而在 USB 协议栈最底层的物理契约里——HID 不是“传输数据的管道”，它是一张严格按秒打卡的考勤表，而你的 MCU，正卡在三次打卡机会之间喘不过气。
这不是性能调优问题，这是对 HID 硬件语义的误读。我们今天就撕开协议文档的包装纸，把那三把锁——带宽分配锁、报告结构锁、中断响应锁——一把一把拧开，看看它们究竟卡在哪儿、怎么松动、以及为什么有些螺丝根本拧不动。
第一把锁：USB 中断传输——不是“带宽”，是“排班表”
很多人第一反应是：“HID 走的是 USB，USB 2.0 不是 480 Mbps 吗？怎么才跑出 64 kB/s？”
错。HID 几乎从不走 High-Speed 的路。
绝大多数 HID 设备（键盘、鼠标、MIDI 控制器、触控笔）在枚举时主动声明自己是Full-Speed（12 Mbps）设备。这不是偷懒，是设计使然：FS 模式 PHY 更便宜、功耗更低、布线更宽松，且完全满足人机交互的“事件驱动”本质——我们不需要持续吞吐，我们需要的是确定性、低抖动、准时送达。
而 USB 对这类需求的解决方案，叫Interrupt Transfer（中断传输）。注意：这里的“中断”和 MCU 的 IRQ 完全无关，它是一个调度模型：主机控制器像一位严苛的教务主任，给每个 HID 设备在每毫秒（1 ms）的帧（frame）里，固定分配一次“上台发言”的机会，时长极短，仅够你交一份最多 64 字节的“小纸条”。
- 这张排班表的刚性体现在
bInterval = 1—— 它不是“尽量每1ms来一次”，而是“必须且只能每1ms来一次”。错过这一班，就得等下一班，没有插队，没有加急。 - 那个“最多64字节”，由端点描述符里的
wMaxPacketSize决定。FS 下合法值只有 8/16/32/64。选 64 是理论最优，但前提是——你真能填满它。
所以，HID 的速率天花板，从来就不是“我能发多快”，而是“我每1ms被允许交一张多大的纸条”。
64 B ×
