用I2C构建键盘级输入设备：从协议到STM32实战的完整路径
你有没有遇到过这样的场景？想给一台工控屏加几个快捷按键，但主控只留了一组I²C接口；或者在设计一款可穿戴设备时，苦于USB引脚太多、布线太复杂。传统USB HID虽然成熟稳定，但在资源受限的小型系统中却显得“大材小用”。
其实，有一个被很多人忽略的技术方案——I2C HID。它不是什么新奇实验，而是由USB-IF官方定义的标准协议，早已内置于Windows、Linux和Android系统之中。更重要的是，你完全可以用一个几块钱的MCU，通过仅仅两根线（SCL/SDA），就让主机把它识别成标准键盘或鼠标。
今天我们就来走一遍这条“轻量级HID”的实现路径：不讲空泛概念，不堆术语，直接从协议本质出发，手把手带你用STM32做出能被PC识别的自定义输入设备。
I2C也能做HID？先搞清它是怎么跑通的
很多人第一反应是：“I²C是主从结构，数据得等主机轮询才能发出去，怎么能当实时输入设备？”
这确实是关键点，但也正是I2C HID巧妙之处所在——它把USB HID那一套机制，“搬”到了I²C总线上。
你可以把它理解为一种“隧道通信”：
- 物理层走的是I²C（双线、低速、简单）
- 协议层模仿的是USB HID（描述符、报告、枚举）
只要你的设备按照《I²C HID Specification》规定的格式响应命令，主机驱动就会认为：“哦，这是个HID设备”，然后像对待USB设备一样去读取它的输入报告。
主机怎么发现你是“键盘”的？
整个过程就像一场精心编排的对话：
- 主机扫描I²C总线→ 发现地址
0x2C上有个设备 - 发送0x21命令→ “把你的HID描述符给我看看”
- 你返回一段二进制数据→ 告诉主机：“我支持两个按键 + 一个状态字节”
- 主机解析成功→ 加载内置i2c-hid驱动，开始每8ms轮询一次：“有新数据吗？”
一旦这套流程走通，操作系统就已经把你当成标准输入设备了。接下来只要你每次返回正确的数据结构，比如按下某个按钮就置位对应bit，系统就会触发一次“键盘敲击”。
✅ 实测效果：插入后无需安装驱动，Windows设备管理器直接显示“HID-compliant device”
关键组件拆解：哪些东西必须自己实现？
要在MCU端真正跑起来，你需要搞定四个核心模块：
| 模块 | 作用 | 是否必须 |
|---|---|---|
| I²C从机通信 | 接收主机命令并回传数据 | ✔️ 必须 |
| HID描述符 | 定义设备能力与数据格式 | ✔️ 必须 |
| 输入报告缓冲区 | 存储当前传感器状态 | ✔️ 必须 |
| 报告更新逻辑 | 外部事件触发数据刷新 | ✔️ 必须 |
我们一个个来看。
1. HID描述符：让主机看懂你是谁
这是最不能出错的一环。HID描述符是一段紧凑的二进制数据，用来告诉主机：“我能上报什么样的数据”。写错了，主机要么识别失败，要么误判成别的设备类型。
比如下面这段描述符，表示一个简单的按键设备：
const uint8_t hid_descriptor[] = { 0x05, 0x01, // Usage Page (Generic Desktop) 0x09, 0x06, // Usage (Keyboard) 0xA1, 0x01, // Collection (Application) 0x05, 0x07, // Usage Page (Key Codes) 0x19, 0xE0, // Usage Minimum (Left Control=224) 0x29, 0xE7, // Usage Maximum (Right GUI=231) 0x15, 0x00, // Logical Minimum (0) 0x25, 0x01, // Logical Maximum (1) 0x75, 0x01, // Report Size (1 bit) 0x95, 0x08, // Report Count (8 bits) 0x81, 0x02, // Input (Data, Variable, Absolute) —— 修饰键 0x95, 0x01, // Report Count (1) 0x75, 0x08, // Report Size (8 bits) 0x81, 0x03, // Input (Constant, Variable, Absolute) —— 填充字节 0x95, 0x06, // Report Count (6 keys) 0x75, 0x08, // Report Size (8 bits) 0x15, 0x00, 0x25, 0x65, 0x05, 0x07, 0x19, 0x00, 0x29, 0x65, 0x81, 0x00, // Input (Data, Array, Absolute) —— 主键区 0xC0 // End Collection };这段数据看似晦涩，但它其实就是在说：
- 我是一个桌面类设备（keyboard/mouse范畴）
- 支持8个修饰键（Ctrl/Shift等）
- 能上报最多6个普通按键码
- 每次上报共8字节
主机拿到这个描述符后，就知道该怎么处理后续的数据包了。
🔍 小贴士：可以用开源工具 hidrdd 反向解析
.desc文件，验证是否符合规范。
2. I²C从机模式：如何正确响应主机请求
STM32的硬件I²C模块支持从机模式，但使用方式和主机略有不同。重点在于：所有通信都由主机发起，你只能被动响应。
典型流程如下：
- 主机写一个命令字节（如
0x00表示读输入报告） - 紧接着切换为读操作，等待你发送数据
- 你在中断里捕获写入的命令，准备好数据，进入发送状态
HAL库提供了两个关键中断回调：
HAL_I2C_SlaveRxCpltCallback：接收到主机命令HAL_I2C_SlaveTxCpltCallback：完成数据发送，可重新准备接收
下面是精简后的初始化代码：
#define I2C_HID_ADDR 0x2C void I2C_HID_Init(void) { hi2c1.Instance = I2C1; hi2c1.Init.ClockSpeed = 400000; // Fast Mode hi2c1.Init.DutyCycle = I2C_DUTYCYCLE_2; hi2c1.Init.OwnAddress1 = I2C_HID_ADDR << 1; // 7-bit左移一位 hi2c1.Init.AddressingMode = I2C_ADDRESSINGMODE_7BIT; hi2c1.Init.DualAddressMode = I2C_DUALADDRESS_DISABLE; HAL_I2C_MspInit(&hi2c1); HAL_I2C_Slave_Receive_IT(&hi2c1, i2c_rx_buffer, 1); // 开始监听 }注意这里调用了Slave_Receive_IT，意味着我们始终等待主机发来第一个字节作为命令。
3. 输入报告结构：定义你要传的数据
假设我们要做一个双按键+状态指示的设备，可以这样定义结构体：
typedef struct { uint8_t report_id; // 通常为1，若单报告可省略 uint8_t buttons; // bit0: Btn1, bit1: Btn2 uint8_t status; // 自定义状态值 } __attribute__((packed)) InputReport; static InputReport input_report = { .report_id = 1 };当用户按下第一个按键时，就把buttons |= 0x01；松开则清零。
然后在接收到主机0x00命令时，把这个结构体原样发回去即可。
4. 中断服务逻辑：命令来了怎么办？
这才是真正的“大脑”部分。我们需要根据不同的命令，返回不同的内容。
void HAL_I2C_SlaveRxCpltCallback(I2C_HandleTypeDef *hi2c) { uint8_t cmd = i2c_rx_buffer[0]; switch(cmd) { case 0x00: // Get Input Report memcpy(i2c_tx_buffer, &input_report, sizeof(input_report)); HAL_I2C_Slave_Transmit_IT(hi2c, i2c_tx_buffer, sizeof(input_report)); break; case 0x21: // Get HID Descriptor HAL_I2C_Slave_Transmit_IT(hi2c, (uint8_t*)hid_descriptor, sizeof(hid_descriptor)); break; default: // 忽略未知命令，继续监听 HAL_I2C_Slave_Receive_IT(hi2c, i2c_rx_buffer, 1); break; } }这里有两个常见命令：
-0x00: 获取输入报告（Input Report）
-0x21: 获取HID描述符（HID Descriptor）
其他还有0x10（Set Output Report）、0x22（Get Report Map）等，按需扩展即可。
⚠️ 注意事项：发送完成后必须再次启动
Receive_IT，否则下次无法触发中断！
实战调试技巧：为什么我的设备没反应？
别急，这是正常现象。I2C HID初学者常踩的坑我都帮你列出来：
❌ 问题1：主机根本没发现设备
排查方向：
- 用逻辑分析仪抓I²C总线，确认主机是否在扫描0x2C
- 检查上拉电阻是否焊接（推荐4.7kΩ）
- MCU地址配置是否正确？注意HAL库要求7位地址左移1位填低位
❌ 问题2：设备发现了，但提示“无法加载驱动”
可能原因：
- HID描述符语法错误 → 用hidrd工具检查
- 描述符长度未对齐 → 某些系统要求固定偏移读取
- 返回数据长度与描述符声明不符
解决方案：
- 在Linux下查看dmesg | grep i2c_hid
- 或使用Wireshark + USB转I²C适配器模拟主机行为
❌ 问题3：能枚举，但按键无响应
典型症状：
- 设备出现在系统中
- 但按按键没有任何输入事件
原因分析：
- 主机轮询周期太长（默认8ms），而你只在事件发生时才准备好数据？
- 错误地只在有事件时才返回报告 → 正确做法是每次都返回最新状态
记住：主机是定期来“查岗”的，你不该“选择性应答”，而应该始终保持最新状态可用。
高阶玩法：不只是按键，还能做什么？
你以为这只是个“简化版键盘”？远不止如此。
🎛️ 场景1：旋钮编码器 → 虚拟音量滚轮
将旋转编码器接入MCU，上报HID Usage为Consumer Volume Increment/Decrement，即可实现免驱调节音量。
只需修改描述符中的Usage Page为0x0C（Consumer），Usage为0x80和0x81。
✍️ 场景2：电容触摸板 → 笔记本触控板替代
上报多点坐标数据，配合合适的描述符，完全可以模拟Synaptics触控板行为。
注意控制报告大小不超过64字节，并合理设置分辨率字段（Logical Maximum）。
💡 场景3：带反馈的智能面板
主机下发Output Report控制LED灯效或震动马达。例如游戏手柄上的RGB灯带同步灯光。
此时你需要监听0x10命令，并在回调中解析输出数据：
case 0x10: // Set Output Report // 解析i2c_rx_buffer[1]... 控制LED HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, i2c_rx_buffer[1]); HAL_I2C_Slave_Receive_IT(hi2c, i2c_rx_buffer, 1); break;最终建议：什么时候该用I2C HID？
| 适用场景 | 推荐程度 |
|---|---|
| 小体积设备需要添加输入功能 | ⭐⭐⭐⭐⭐ |
| 主控预留I²C但无USB PHY | ⭐⭐⭐⭐⭐ |
| 多个子模块统一挂载到同一总线 | ⭐⭐⭐⭐☆ |
| 对延迟敏感的应用（如高速游戏鼠标） | ⭐⭐☆☆☆（受轮询限制） |
| 需要主动推送大量数据 | ⭐☆☆☆☆（I²C为主控型总线） |
总结一句话：如果你要做的是低频、小数据量、高集成度的输入设备，I2C HID是最优解之一。
写在最后：别让接口限制了你的交互想象
我们习惯性地认为“输入设备=USB”，但这其实是历史包袱。随着嵌入式系统的高度集成化，越来越多的设备不再配备完整的USB接口。
而I2C HID提供了一种优雅的破局思路：用最少的资源，获得最大的兼容性。
下次当你面对一块只有I²C可用的主板时，不妨试试这条路。也许只需要几十行代码 + 几个GPIO，就能让你的设备拥有“即插即用”的交互能力。
如果你已经动手实现了类似项目，欢迎在评论区分享你的经验——尤其是你是怎么解决地址冲突或多设备管理的？让我们一起把这条路走得更宽一些。
