1. 从蓝牙自拍杆说起：理解BLE HID的敲门砖
那天我拿着一个蓝牙自拍杆在景点拍照，手指轻轻一按，远处的手机就“咔嚓”一声完成了拍摄。这个看似简单的动作，背后其实是蓝牙低功耗（BLE）和人机接口设备（HID）协议在默默工作。很多朋友可能都好奇，这么一个几十块钱的小玩意儿，是怎么让手机听话的？其实，它本质上就是一个超简单的BLE HID设备，只不过它模拟的不是键盘字母，而是手机的音量键。
在手机相机应用里，音量键通常被映射为快门键。蓝牙自拍杆做的，就是通过BLE告诉手机：“嗨，音量加键被按下了！”手机一收到这个信号，就触发拍照。所以，它的核心就是一个能发送特定HID报告的蓝牙设备。我拆解过好几个自拍杆，也用过像nRF Connect这样的蓝牙调试工具去抓包，发现它们广播包里都包含一个特殊的服务UUID：0x1812，这就是HID服务的“身份证”。同时，广播数据里还会有一个“设备外观”字段，对于自拍杆这类设备，通常填的是0x03C1，代表它是一个键盘类设备。这听起来有点怪，自拍杆怎么是键盘？其实在HID的世界里，很多消费类控制设备（比如多媒体按键、音量控制）都被归类在“键盘”或“消费者控制”页面下，共用一套底层机制。
真正决定这个设备能干什么的，是一个叫做HID Report Descriptor（报告描述符）的东西。你可以把它理解为一份“产品说明书”，用一套特定的代码写成，详细告诉手机或电脑：我这个设备能发送哪些数据，每个数据位代表按下哪个键。自拍杆的报告描述符通常很简单，主要定义的就是“音量加”、“音量减”这样的消费者控制功能。当杆上的按钮被按下，设备就会通过BLE发送一个对应的报告，比如0x08 0x00表示“音量加按下”，紧接着再发一个0x00 0x00表示“按键释放”，这样就完成了一次完整的按键操作模拟。
2. HID报告描述符：读懂设备的“基因编码”
如果你只想用现成的库实现功能，可能不需要深究报告描述符。但如果你想自定义设备，比如做个带特殊快捷键的键盘，或者把游戏手柄和鼠标合二为一，那这份“基因编码”就是你必须要掌握的核心技能。我第一次看报告描述符那一串十六进制数字时，也是一头雾水，感觉像在看天书。但后来我发现，它其实是一套非常严谨的微型语言，用来描述一个数据结构。
这套语言的基本单词是“用法页”、“用法”、“逻辑最小值/最大值”、“报告大小”、“报告数量”等等。我来打个比方：假设你要设计一个表格来登记一次考试的成绩。你需要先定义这个表格的用途（Usage Page），比如“学生成绩登记表”。然后定义具体登记项（Usage），比如“语文成绩”、“数学成绩”。接着，你要规定每个成绩的填写范围（Logical Minimum/Maximum），比如0到100分。最后，你要规定这个表格有多少列，每列占多宽（Report Count/Size）。HID报告描述符干的就是这个事儿，只不过它描述的是设备上报的数据包格式。
举个例子，一个最简单的自拍杆描述符，可能只描述一个比特位（bit），用来表示“快门键”是否按下。这个比特位的“用法”会被定义为消费者控制页面下的“快门”功能。当这个比特位是1，就表示按下；是0，就表示释放。设备每次发送报告，其实就是把这个比特位的当前值发给主机。主机根据描述符的“基因编码”翻译出：“哦，这是快门指令”，于是触发拍照。
网上有很多工具可以帮你生成和解析这份描述符，比如HID Descriptor Tool。但工具用多了容易知其然不知其所以然。我建议你有空翻一翻USB-IF官方发布的《Device Class Definition for HID》文档，虽然它主要是为USB写的，但核心原理和BLE HID完全相通。理解了描述符的生成和解析机制，你就能从“能用”进化到“能创造”。
3. 实战第一步：打造一个专属的蓝牙键盘
理解了报告描述符，我们就可以动手创造自己的设备了。让我们从一个最实用的设备开始：蓝牙键盘。不是那种全尺寸键盘，而是一个可以自定义的、只有几个关键按键的小键盘，比如专门用于视频剪辑的快捷键键盘，或者一键打开某个应用的神器。
首先，我们需要准备硬件。一块支持BLE的开发板是必须的，像Nordic的nRF52系列、TI的CC2640，或者国内厂商如瑞昱的RTL8762C，都是不错的选择。这些芯片通常都有完善的SDK，里面自带HID设备的例子，能帮我们省掉很多底层搭建的功夫。我手头用的是瑞昱8762C的开发板，它的SDK里就有现成的HID键盘和鼠标例程，我们可以在上面修改。
关键就在于修改那个“基因编码”——报告描述符。一个标准全键盘的描述符比较复杂，它要描述8个修饰键（Ctrl、Shift等）和最多6个普通键同时按下的情况。但对于我们的自定义键盘，可以大幅简化。比如，我只想要三个键：Ctrl、C和V，实现一键复制粘贴。那么我的报告描述符就可以这样设计：定义一个包含3个比特位的报告。第一个比特位对应“左Ctrl键”的用法，第二个对应“键盘C键”，第三个对应“键盘V键”。这样，当我上报数据0x03（二进制011）时，就表示同时按下了Ctrl和C；上报0x05（二进制101）时，就表示按下了Ctrl和V。
在代码里，发送报告的流程通常是：先连接上手机或电脑，然后在需要模拟按键时，调用SDK提供的发送函数。比如，在8762C的SDK里，可能是hids_send_report这样的函数。你需要传入服务句柄、报告索引和你的数据。这里有个细节要注意：按键消息通常需要“按下”和“释放”两个动作。所以代码往往是先发送带按键值的报告，延时一小会儿（比如50-200毫秒，模拟人按下的时间），再发送一个全零的报告表示释放。如果不发送释放，主机可能会认为这个键一直被按着。
// 示例：发送 Ctrl+C 组合键 uint8_t report_data[1] = {0x03}; // 二进制 011，表示Ctrl和C按下 bool success = hids_send_report(conn_handle, hid_service_id, report_index, report_data, 1); os_delay(150); // 等待150毫秒，模拟按键持续时间 report_data[0] = 0x00; // 释放所有按键 success = hids_send_report(conn_handle, hid_service_id, report_index, report_data, 1);做完这些，编译代码烧录到开发板，用手机蓝牙搜索连接，你会发现它被识别成了一个键盘。打开记事本，触发你的按键，就能看到文字被复制或粘贴了！这种自己创造工具的感觉非常棒。
4. 再进一步：实现一个蓝牙鼠标
搞定了键盘，鼠标就是下一个顺理成章的目标。鼠标的报告描述符和键盘有所不同，它主要描述的是“指针”设备。核心数据通常包括：按键状态（左键、右键、中键）、X轴位移、Y轴位移和滚轮位移。
一个典型的鼠标报告是4个字节。第一个字节的低3位分别表示左、右、中键是否按下（1为按下，0为释放）。第二个字节是一个有符号数，表示X方向移动的相对距离，正数向右，负数向左。第三个字节同理，表示Y方向移动。第四个字节表示滚轮滚动。这里“相对距离”是关键，它告诉主机指针应该从当前位置移动多少，而不是移动到某个绝对坐标。
在报告描述符里，你会看到对X、Y、滚轮的“逻辑最小值”和“逻辑最大值”的定义，比如0x15, 0x81（-127）和0x25, 0x7F（127）。这定义了位移数据的取值范围。当你让鼠标“移动”时，实际上就是计算一个位移值，填充到报告里发送出去。
// 示例：让鼠标向右下方移动 uint8_t mouse_report[4] = {0}; mouse_report[0] = 0x00; // 没有按键按下 mouse_report[1] = 50; // X方向向右移动50个单位 mouse_report[2] = 30; // Y方向向下移动30个单位（注意：屏幕坐标系通常向下为正） mouse_report[3] = 0; // 滚轮不滚动 hids_send_report(conn_handle, hid_service_id, mouse_report_index, mouse_report, 4);这里有一个非常容易踩坑的地方：修改报告描述符后，必须重新配对设备！因为主机（手机或电脑）会在第一次配对时解析并缓存你的报告描述符。如果你只改了代码，没有在主机端删除旧设备并重新搜索配对，主机还会按照旧的理解方式来解析你的新数据，导致行为异常或者根本没反应。我早期调试时就经常被这个问题卡住，明明代码改了，怎么动都没反应，折腾半天才发现是缓存问题。
另外，别忘了修改广播包中的“设备外观”字段。键盘是0x03C1，鼠标是0x03C2。改对了，你在手机蓝牙列表里看到的设备图标就会从键盘变成鼠标，非常直观。
5. 终极形态：构建键盘鼠标复合设备
单独的设备已经满足不了我们了？那就把它们合体吧！一个BLE设备同时具备键盘和鼠标的功能，这就是HID复合设备。想象一下，一个无线遥控器，既能当PPT翻页笔（模拟键盘方向键），又能当激光笔（模拟鼠标移动），还能一键调出备注（模拟键盘快捷键），是不是很方便？
从技术上看，复合设备就是把键盘和鼠标的报告描述符拼接在一起，但要用不同的Report ID来区分。Report ID就像是数据包的信封，告诉主机：“这包数据是键盘的”还是“鼠标的”。在报告描述符中，每个“集合”的开头，通过0x85这个操作码来指定本集合报告的ID。
例如，我们可以定义Report ID 1为键盘报告，Report ID 2为鼠标报告。那么，当我们发送数据时，就需要在有效数据前加上这个ID。比如，发送0x01 0x04，主机看到开头的0x01，就知道后面0x04这个数据要按照键盘报告描述符去解析（假设0x04代表‘a’键）。发送0x02 0x01 0x20 0x10 0x00，主机看到0x02，就知道后面四个字节要按鼠标报告去解析（左键按下，同时向右移动32，向下移动16）。
// 复合设备上报示例 uint8_t composite_report[5]; // 模拟按下‘a’键 composite_report[0] = KEYBOARD_REPORT_ID; // 假设是1 composite_report[1] = 0x04; // ‘a’键的键值 send_report(composite_report, 2); // 模拟鼠标移动 composite_report[0] = MOUSE_REPORT_ID; // 假设是2 composite_report[1] = 0x00; // 无按键 composite_report[2] = 50; // X位移 composite_report[3] = 0; // Y位移 composite_report[4] = 0; // 滚轮 send_report(composite_report, 5);在实现时，广播包的设备外观最好设置为0x03C0，这代表“通用HID”，这样主机能更准确地识别它。不过根据我的实测，就算不改成这个，功能一般也不受影响。
这里有个平台差异的坑需要特别注意。理论上，复合设备的所有数据都通过同一个“报告”特征值来收发，靠前置的Report ID区分类型。但我在用瑞昱8762C平台时发现，直接按上述理论做不生效。查阅SDK和实验后发现，这个平台的实现方式有点特殊：它需要为每一个Report ID在HID服务下单独创建一个报告特征值。也就是说，键盘报告和鼠标报告走的是两个不同的蓝牙特征值通道。在这种情况下，发送数据时反而不需要在数据前加Report ID了，因为通道本身已经区分了报告类型。如果你也遇到类似问题，不妨检查一下SDK的示例，看看它是否为复合设备创建了多个报告特征值。
6. 自定义控制器：释放你的创意
掌握了复合设备，我们就不再局限于键盘和鼠标了。HID协议定义了大量丰富的“用法”，从游戏手柄（摇杆、扳机键）、医疗设备，到健身器材、VR控制器，都可以描述。这就是设计自定义控制器的舞台。
比如，我想做一个简单的游戏手柄，有两个按钮（A、B）和一个二维摇杆。摇杆需要上报X和Y两个轴的绝对位置（比如0-255的范围）。那么，我的报告描述符就需要混合“按钮”页面和“游戏控制”页面。我可以定义一个报告，包含1个字节的按钮状态（每个bit一个按钮），和2个字节的模拟量（分别代表X轴和Y轴）。
更复杂一点的，比如做一个带手势感应的空中鼠标，或者一个用于智能家居控制的多功能旋钮。旋钮可以模拟鼠标滚轮，按下可以模拟中键，旋转的同时按下不同的辅助键又可以触发不同的宏命令。这些功能都需要你在报告描述符里精心设计数据的组织方式。
设计的关键在于平衡灵活性和效率。报告长度越短，传输越快越省电，但能表达的信息也越少。你需要根据实际控制器的输入维度（有多少个按钮、几个轴）来设计最紧凑的报告格式。同时，要充分利用HID协议中“数组”和“变量”这两种输入类型的区别。“数组”适合描述一堆互斥的选项（比如一堆按钮里同时只能按下一个），“变量”则适合描述可以同时存在的多个状态（比如多个修饰键可以同时按下）。
在调试自定义控制器时，我强烈建议在开发初期增加一个“调试服务”。这个服务与HID服务并行，通过它你可以用手机APP或者串口工具，直接发送你想要模拟的报告数据到设备，设备再原样转发给HID服务上报。这能让你快速验证报告描述符和上报逻辑是否正确，而不用每次都去编译和触发真实的物理输入（比如焊接按钮、读取ADC），极大提升了调试效率。
7. 数据上报的优化与避坑指南
设备做出来了，但要稳定好用，还得在数据上报策略上下功夫。BLE是低功耗设计，频繁、大量地发送数据会快速消耗电池。对于HID设备，尤其是鼠标这种需要连续上报位移的设备，优化至关重要。
第一，合理设置上报间隔。在HID服务中，有一个叫做“报告间隔”的描述符，你可以设置主机查询设备状态的最高频率。对于鼠标，这个值不能太慢，否则光标移动会卡顿；对于键盘，由于按键是离散事件，可以设置得相对慢一些。你需要根据设备类型和用户体验来权衡。
第二，使用通知（Notify）而非读请求。BLE HID设备通常采用“通知”方式主动上报数据，这比等待主机来“读”要实时得多。确保你的报告特征值已经正确配置了通知属性，并且在连接后及时通知主机。
第三，状态改变才上报。这是省电的核心原则。对于键盘，只有在按键状态发生变化（按下或释放）时才发送报告。对于鼠标，如果采用了相对坐标模式，在静止时就不应该发送任何数据。很多新手会犯的错误是让鼠标以固定频率（比如10Hz）持续上报(0,0)的位移，这纯粹是浪费电量。
第四，处理连接参数。BLE连接参数（连接间隔、从机延迟）直接影响响应速度和功耗。你可以尝试在代码中请求更优的连接参数。例如，游戏外设需要低延迟，可以请求较短的连接间隔（如15-30ms）；而一个不常用的自定义键盘，则可以使用较长的间隔来省电。
第五，注意平台和OS的兼容性。不同手机品牌、不同电脑操作系统对BLE HID的支持细节可能有微小差异。比如，有的系统对报告描述符的解析更严格，有的则对连接绑定有特殊要求。在完成主要功能后，最好用你手头能找到的不同品牌手机和电脑都测试一下，确保兼容性。我遇到过在A品牌手机上工作正常，在B品牌上却无法识别的情况，最后发现是广播数据中某个标志位设置的问题。
最后，别忘了安全性和用户体验。如果你的设备需要配对码，考虑一下用户是否方便输入。对于无屏幕的设备，像蓝牙自拍杆，通常使用“Just Works”配对方式，无需输入密码，虽然安全性低一些，但体验最流畅。这些细节，往往决定了你的作品是一个“极客玩具”还是一个“好用产品”。
中的边缘计算应用)
