以下是对您提供的博文内容进行深度润色与重构后的技术文章。整体风格更贴近一位资深嵌入式工程师在技术社区中自然、扎实、有温度的分享——去AI感、强实操性、逻辑层层递进、语言精炼有力，同时完全保留所有关键技术细节、代码示例和工程洞见，并显著增强可读性、教学性与传播力。
用I²C“假装”是个USB键盘：一个嵌入式工程师的轻量级HID实践手记
“我们不是在做USB，而是在让主机相信——它连上的就是个标准USB设备。”
这是我在给一款医疗手持终端加按键交互功能时的真实顿悟。当时主控是颗资源极紧的STM32G030F6（32KB Flash / 8KB RAM），团队已否决了USB方案：PHY成本高、布线难、驱动调试周期长，且Windows上偶发枚举失败——而客户只想要“插上就能用”的体验。
后来我翻出尘封已久的《I²C HID Specification v1.0》，试了三天，把一个8键矩阵键盘通过I²C“骗过”了Windows和Linux——没有驱动、没有libusb、不改内核，只靠63字节描述符 + 7个寄存器 + 一段不到200行的裸机I²C从机代码。
这篇文章，就是我把这段经历拆解成可复现、可裁剪、可debug的完整路径。不讲空泛概念，只说你真正会卡住的地方：寄存器怎么填？描述符为什么总被内核reject？轮询间隔改了却没生效？报告更新时为啥老读到旧值？
它为什么能“冒充”USB设备？
先破除一个迷思：I²C HID不是USB over I²C，也不是协议转换桥。它压根不碰USB协议栈，也不需要D+ D−信号线。
它的本质，是一种语义映射协议——操作系统看到的，依然是标准的HID设备；但背后的数据通道，换成了最朴素的I²C读写。
Windows/Linux/macOS的HID子系统早已内置支持：
- Linux：drivers/hid/i2c-hid/（自4.15起默认启用）
- Windows：i2c_hid.sys（Win10 1809+）
- macOS：AppleI2CHID（macOS 12 Monterey起）
它们的工作方式高度统一：
✅ 扫描I²C总线，发现新从机
✅ 读寄存器0x00–0x01→ 得到描述符内存地址
✅ 读寄存器0x02→ 得到描述符长度
✅ 按地址+长度，批量读取二进制描述符
✅ 解析后，自动绑定hid-generic或hid-input驱动
✅ 后续所有输入数据，都从寄存器0x03开始读
整个过程，MCU只需要响应I²C地址匹配、寄存器地址接收、数据发送——不需要中断嵌套、不需要状态机、甚至不需要理解“HID”这个词。
这才是它能在M0+/RISC-V小核上跑起来的根本原因：
🔹 ROM开销 < 3.2 KB（含I²C外设驱动 + 描述符 + 报告组装）
🔹 RAM占用 < 1.8 KB（双缓冲+描述符缓存）
🔹 最高仅依赖标准I²C从机模式（无DMA也OK）
寄存器不是摆设：7个地址，决定你能不能被识别
I²C HID规范定义了8个强制寄存器（0x00 ~ 0x07），但实际能让你设备“活下来”的，核心就这5个：
| 寄存器 | 地址 | 作用 | 关键细节 |
|---|---|---|---|
)
