1. 什么是HID报告描述符它到底在解决什么问题HID报告描述符HID Report Descriptor不是一段可执行代码也不是某种加密协议而是一份用二进制字节流写成的“设备说明书”——它告诉操作系统“我这个USB设备长什么样、能发什么数据、每个字节代表什么意思”。你插上一个机械键盘Windows不用装驱动就能识别出它是键盘你接上一个游戏手柄系统自动映射摇杆和按键甚至你用AC6328A2芯片做的自拍杆一按就触发手机快门——背后全靠这份描述符在说话。它不处理数据传输也不控制硬件逻辑但它决定了操作系统能不能“看懂”你的设备。很多人卡在HID固件开发的第一步明明USB枚举成功了设备管理器里也显示“HID兼容设备”但上位机收不到任何有效数据或者收到的数据全是0xFF、乱码、长度不对——十有八九是报告描述符写错了。这不是编译错误没有报错提示这是语义错误像用英语语法写中文句子机器能读但完全理解不了。我做过二十多个基于STM32、Nordic nRF52、AC6328A2的HID项目最耗时的环节从来不是写中断服务程序而是反复修改、验证、抓包比对这份80–300字节的二进制描述符。它不像C语言有IDE语法高亮也不像Python有运行时异常它只有一条铁律一字之差全盘失效。所以这篇内容不讲抽象理论不堆RFC文档而是带你从Usage用途出发逐字逐句拆解Item项结构还原一个真实可用的键盘媒体键复合设备描述符设计全过程。无论你是用AC6328A2做蓝牙HID遥控器还是用STM32F072跑USB HID鼠标或是调试鸿蒙开发板上的HID over I²C接口只要涉及“让主机认出你的设备并正确解析数据”你就需要这套实战方法论。2. 整体设计思路为什么必须从Usage开始推导而不是反向拼凑2.1 Usage决定功能边界Item决定数据表达方式很多初学者习惯先画数据包结构比如“我要发8字节第0字节是修饰键第1字节是普通键第2–7字节是6个按键扫描码”。然后倒推着去填报告描述符——这恰恰是踩坑的起点。HID规范的核心逻辑是功能驱动Usage-driven而非结构驱动Structure-driven。也就是说你首先要明确“我的设备要实现哪些标准HID功能”——是KeyboardConsumer ControlGeneric Desktop还是自定义Usage Page每种Usage Page对应一套预定义的Usage ID如0x09 0x04代表“键盘左Ctrl”0x0C 0x01代表“消费者控制音量加”这些ID直接决定了主机端如何解释后续数据。如果你硬把“音量加”塞进Keyboard Report里Windows会把它当成一个不存在的按键根本不会触发音量调节。我曾帮一位做AC6328A2自拍杆的同事调试他把“快门”Usage0x09 0x01放在Consumer Page下但描述符里却用了Keyboard的Report Size和Count结果PC端始终识别为“未知键盘”连HID测试工具都读不出Usage Name。后来我们重走Usage路径查HID Usage Tables 1.12文档确认快门属于Consumer Page0x0C其Usage ID为0x01再确认该Page下支持的Report结构是“单比特开关型”于是改用Input (Data, Variable, Absolute) Logical Minimum/Maximum 0/1问题当场解决。所以第一步永远不是想“我怎么发数据”而是问“我要实现哪个标准功能它的Usage Page和Usage ID是什么”2.2 Item层级嵌套的本质构建一棵“功能树”HID报告描述符由一系列Item组成每个Item是一个1–4字节的指令单元包括Tag类型、Type类别、Size长度和Data数据。常见的Item有Usage Page、Usage、Collection、Input、Output、Feature、Report Size、Report Count、Logical Minimum/Maximum等。它们不是平铺直叙的列表而是通过Collection集合形成树状嵌套结构。比如一个带多媒体键的键盘顶层是Application Collection应用集合下面分两个分支一个是Keyboard Collection键盘集合包含修饰键Modifier Keys和普通键Key Codes另一个是Consumer Control Collection消费类控制集合包含音量、播放、快门等按钮。这种嵌套不是为了好看而是为了隔离Report空间。每个Collection可以定义独立的Report ID、Report Size和Report Count主机据此将收到的字节流正确切片、映射到不同功能域。如果所有Usage都平铺在同一个Collection里主机无法区分“第1字节是键盘修饰键”还是“第1字节是音量键状态”只能按顺序硬解极易错位。我在调试周立功USB转CANFD接口卡的HID桥接功能时就遇到过这个问题客户把CAN帧ID和Payload混在一个Report里没用Collection隔离导致上位机每次解析都偏移2字节。后来我们重构为Collection (Application) → Collection (CAN ID) → Input (Report Size4, Count1)Collection (CAN Payload) → Input (Report Size8, Count1)配合Report ID切换问题彻底消失。因此设计流程必须是先画Usage树哪些功能归一类再定Collection层级哪几组功能共享同一Report结构最后填Item序列每个节点用什么Item声明。2.3 报告Report不是数据包而是“语义容器”新手常误以为Report就是USB传输的8/16/64字节数据包。实际上Report是HID层定义的逻辑数据单元它由Report ID可选、Report Size每个字段占几位、Report Count该尺寸字段有几个共同决定其二进制布局。例如Report Size 1, Report Count 8→ 定义8个1位布尔值如修饰键Ctrl/Shift/Alt/GuiReport Size 8, Report Count 6→ 定义6个8位字节如6个普通按键扫描码Report Size 16, Report Count 1→ 定义1个16位整数如摇杆X轴位置关键点在于Report Size和Report Count必须与Usage的语义匹配。比如Consumer Page下的“音量加”是开关型On/OffLogical Minimum0, Logical Maximum1那么Report Size必须≥1且不能设成8——否则主机期待8位数据你只发1位剩余7位默认为0可能被误判为其他Usage。再比如AC6328A2 hid自拍方案中快门按钮需支持短按触发一次和长按持续触发这就要求Usage为Selector或On/Off SwitchLogical Range设为0–1并配合Input (Data, Variable, Absolute)声明而非简单用Input (Constant)。我实测过若把快门做成Constant项Windows会忽略该Input永远收不到事件。所以Report参数不是随便凑的它必须服务于Usage的物理含义开关用1位按键用8位扫描码模拟量用16位ADC值——错配就会导致主机解析失真。3. 核心细节解析Usage、Item、Collection三者的协同关系与实操陷阱3.1 Usage Page与Usage ID查表不是抄表要理解上下文HID Usage Tables是HID规范的基石但它不是一本静态词典而是一套有层级、有依赖的语义体系。Usage Page页是最高分类如0x01是Generic Desktop Controls通用桌面设备0x0C是Consumer Devices消费类设备0x09是Keyboard/Keypad键盘/小键盘。每个Page下有若干Usage ID用途ID但同一ID在不同Page下含义完全不同。例如0x01在Page 0x01Generic Desktop中是Pointer指针在Page 0x0CConsumer中是Consumer Control消费类控制在Page 0x09Keyboard中是ErrorRollOver错误溢出我见过太多人直接复制网上示例把Consumer的0x01当Generic Desktop用结果设备枚举失败。正确做法是打开官方HID Usage Tables PDF最新版1.12定位到你要的功能所属Page再找对应Usage ID。比如做音量控制确认功能属于Consumer Devices → Page 0x0C查Table 13: Consumer Page Usages → 找到“Volume Increment” → Usage ID 0x01注意其属性它属于Selector类Usage意味着它是离散选择项Logical Minimum/Maximum应为0/1且通常配合Input (Data, Variable, Absolute)使用更隐蔽的陷阱是Usage的继承性。Generic Desktop Page下的Usage如0x30 X Axis隐含了坐标系定义-127 to 127而Consumer Page下的Usage如0x01 Volume Increment是事件触发型无数值范围。如果你给音量加设置Logical Minimum-100, Maximum100主机只会取最低位其余位被丢弃。我在调试一款STM32 USB游戏手柄时把摇杆X轴Generic Desktop 0x30误用Consumer Page的Logical Range结果X轴数据始终在0–1跳变查了三天才发现Page写错了。所以每写一个Usage必须同步确认Page、ID、属性Selector/Linear/Discrete、Logical Range三者是否自洽。3.2 Item的Type与Tag别被“Input/Output/Feature”字面意思骗了HID Item的Type分为Main主项、Global全局项、Local局部项三类每类下有多个Tag。新手最容易混淆的是Main Type里的Input、Output、Feature——它们不是指“输入设备/输出设备/特性设备”而是指数据流向和用途Input设备→主机的数据如按键按下、摇杆移动Output主机→设备的数据如LED灯控制、振动马达启停Feature双向可读写的数据如设备配置参数、固件版本号但关键在于同一个Usage可以出现在不同Type中。比如“键盘Caps Lock LED”作为Output主机发0/1控制LED亮灭作为Feature主机读取当前LED状态需设备支持回读我做过一个AC6328A2 HID键盘项目客户要求支持Caps Lock状态同步。最初只写了Output项结果上位机无法获取当前状态。后来补上Feature项并在固件中实现HID_REQ_GET_REPORT处理逻辑才真正双向可控。另一个常见错误是混淆Global与Local Item的作用域。Global Item如Report Size、Report Count、Logical Minimum影响后续所有Local Item直到下一个同类型Global出现Local Item如Usage、Usage Minimum/Maximum只作用于紧邻的Main Item。例如0x05, 0x0C, // Usage Page (Consumer) 0x09, 0x01, // Usage (Volume Increment) 0x15, 0x00, // Logical Minimum (0) 0x25, 0x01, // Logical Maximum (1) 0x75, 0x01, // Report Size (1 bit) 0x95, 0x01, // Report Count (1 field) 0x81, 0x02, // Input (Data, Variable, Absolute)这里Report Size1和Report Count1是Global项它们让后面的Input项只占用1位。但如果中间插入另一个Usage0x05, 0x0C, 0x09, 0x01, 0x15, 0x00, 0x25, 0x01, 0x75, 0x01, 0x09, 0x02, // Usage (Volume Decrement) ← 新增Local Item 0x95, 0x01, 0x81, 0x02,此时Report Count1仍生效但第二个Usage没有新的Report Size覆盖所以它也占1位——这正是我们想要的“两个独立开关”。但如果忘了重置Report Size后续所有Input都会沿用1位导致数据错乱。我在用易语言写HID键鼠测试工具时就因Global Item作用域理解偏差把6个按键扫描码全压成6位结果只能识别前6个键第7个开始全乱码。所以写Item序列时必须像写作用域嵌套的代码一样时刻标记Global项的影响范围。3.3 Collection的嵌套逻辑Application、Logical、Physical三层结构怎么选Collection是HID描述符的骨架它用Collection (Type)和End Collection包裹子项形成逻辑分组。HID规范定义了三种Collection TypeApplication Collection类型1顶层应用容器如“键盘”、“鼠标”、“游戏手柄”。每个Application对应一个独立的HID Report主机为其分配单独的Handle。Logical Collection类型2功能子模块如“键盘按键区”、“多媒体键区”、“LED控制区”。同一Application下的多个Logical Collection可共享Report ID但数据结构独立。Physical Collection类型3物理部件如“左手按键”、“右手摇杆”极少使用多见于复杂外设。实际开发中95%的场景只需Application Logical组合。例如一个带音量键的键盘Usage Page (Generic Desktop) → Application Collection → Keyboard部分 Usage Page (Consumer) → Application Collection → 多媒体部分但更优方案是单Application 多LogicalApplication Collection (Keyboard) ├─ Logical Collection (Keyboard Keys) │ ├─ Usage Page (Keyboard) │ ├─ Usage (Left Ctrl) ... │ └─ Input (Modifier Keys) ├─ Logical Collection (Media Keys) │ ├─ Usage Page (Consumer) │ ├─ Usage (Volume Up) ... │ └─ Input (Volume Switch) └─ End Collection这样做的好处是所有数据打包在一个Report里节省USB带宽主机用Report ID区分不同Logical块无需多个HID Interface。我在调试鸿蒙开发板HID over I²C时客户要求I²C从机只暴露一个HID端点就必须用Logical Collection隔离不同功能域。当时用Application Collection会强制鸿蒙系统创建多个HID Device节点导致HAL层适配失败。而Logical Collection方案仅需在Report Descriptor末尾加Report ID 1鸿蒙侧用hid_device_read_report()指定ID即可精准读取媒体键状态。所以Collection选型不是技术炫技而是对接目标平台的硬性要求Windows/macOS对Logical Collection支持完善某些嵌入式HID Host如老款Android TV只认Application Collection而鸿蒙、Zephyr等RTOS则对Logical Collection的Report ID解析有特定约束。务必先查清目标平台的HID Host能力再定Collection策略。4. 实操过程从零设计一个“键盘媒体键”复合设备报告描述符4.1 需求拆解与Usage树绘制我们以一个典型需求为例基于AC6328A2芯片的USB HID设备需支持标准键盘功能8个普通按键A/Z/X/C/V/B/N/M2个修饰键CtrlAlt媒体控制音量加/减、播放/暂停、快门所有按键支持短按触发快门支持长按保持第一步列出所有Usage及其Page功能Usage PageUsage ID类型Logical RangeLeft Ctrl0x09 (Keyboard)0xE0Selector0–1Left Alt0x090xE2Selector0–1Key A0x090x04Selector0–1Key Z0x090x05Selector0–1... (共8键)............Volume Up0x0C (Consumer)0x01Selector0–1Volume Down0x0C0x02Selector0–1Play/Pause0x0C0x44Selector0–1Camera0x0C0x01Selector0–1注意Camera在Consumer Page下ID也是0x01与Volume Up冲突不HID允许同一ID在不同Collection中复用只要Usage Page不同即可。但为避免歧义我们把Camera放在Consumer Page下Volume Up/Down也放此处Play/Pause同理——全部归入Consumer Page用Logical Collection隔离。第二步绘制Usage树Application Collection (Generic Desktop: Keyboard) ├─ Logical Collection (Modifier Keys) │ ├─ Usage Page (Keyboard) │ ├─ Usage (Left Ctrl) │ └─ Usage (Left Alt) ├─ Logical Collection (Key Codes) │ ├─ Usage Page (Keyboard) │ ├─ Usage Minimum (0x04) │ └─ Usage Maximum (0x0B) ← A/Z/X/C/V/B/N/M对应0x04–0x0B └─ Logical Collection (Media Controls) ├─ Usage Page (Consumer) ├─ Usage (Volume Up) ├─ Usage (Volume Down) ├─ Usage (Play/Pause) └─ Usage (Camera)此结构确保修饰键、普通键、媒体键三组数据互不干扰主机可分别解析。4.2 Item序列手写与字节流生成根据Usage树逐段生成Item序列十六进制字节流。我们采用Report ID模式为每个Logical Collection分配IDID 0x01Modifier Keys修饰键ID 0x02Key Codes普通键ID 0x03Media Controls媒体键完整描述符精简版不含注释0x05, 0x01, // Usage Page (Generic Desktop) 0x09, 0x06, // Usage (Keyboard) 0xa1, 0x01, // Collection (Application) 0x85, 0x01, // Report ID (1) 0x05, 0x09, // Usage Page (Keyboard) 0xa1, 0x02, // Collection (Logical) - Modifier Keys 0x19, 0xe0, // Usage Minimum (Left Ctrl) 0x29, 0xe2, // Usage Maximum (Left Alt) 0x15, 0x00, // Logical Minimum (0) 0x25, 0x01, // Logical Maximum (1) 0x75, 0x01, // Report Size (1 bit) 0x95, 0x02, // Report Count (2 fields) 0x81, 0x02, // Input (Data, Variable, Absolute) 0xc0, // End Collection 0x85, 0x02, // Report ID (2) 0xa1, 0x02, // Collection (Logical) - Key Codes 0x09, 0x04, // Usage (A) 0x09, 0x05, // Usage (Z) 0x09, 0x06, // Usage (X) 0x09, 0x07, // Usage (C) 0x09, 0x08, // Usage (V) 0x09, 0x09, // Usage (B) 0x09, 0x0a, // Usage (N) 0x09, 0x0b, // Usage (M) 0x15, 0x00, // Logical Minimum (0) 0x25, 0x01, // Logical Maximum (1) 0x75, 0x01, // Report Size (1 bit) 0x95, 0x08, // Report Count (8 fields) 0x81, 0x02, // Input (Data, Variable, Absolute) 0xc0, // End Collection 0x85, 0x03, // Report ID (3) 0x05, 0x0c, // Usage Page (Consumer) 0xa1, 0x02, // Collection (Logical) - Media Controls 0x09, 0x01, // Usage (Volume Up) 0x09, 0x02, // Usage (Volume Down) 0x09, 0x44, // Usage (Play/Pause) 0x09, 0x01, // Usage (Camera) ← 同IDPage已切换合法 0x15, 0x00, // Logical Minimum (0) 0x25, 0x01, // Logical Maximum (1) 0x75, 0x01, // Report Size (1 bit) 0x95, 0x04, // Report Count (4 fields) 0x81, 0x02, // Input (Data, Variable, Absolute) 0xc0, // End Collection 0xc0 // End Collection (Application)总长度102字节。注意几个关键点Report Size1, Report CountN实现N个独立开关比传统Keyboard Report8字节键码更省带宽每个Logical Collection前用85 xx声明Report ID主机据此路由数据0x09, 0x01在Consumer Page下是Camera与前面Keyboard Page的0x01完全无关所有Usage都用Input (Data, Variable, Absolute)支持事件触发非Constant4.3 固件实现要点AC6328A2与STM32的差异处理AC6328A2是高度集成的蓝牙/USB双模SoC其HID固件开发与STM32有本质区别AC6328A2无裸机USB栈依赖SDK提供的hid_report_send()API。你只需构造Report Buffer按描述符定义的Layout填值调用API发送。例如Report ID0x03的媒体键Bufferbuf[0] 0x03; buf[1] 0x01;Volume Up按下SDK自动处理USB IN Transaction。但要注意AC6328A2的HID Report最大长度为64字节且hid_report_send()是阻塞调用需确保USB总线空闲。我实测发现若连续快速调用5ms间隔第二帧会被丢弃必须加os_delay(10)软延时。STM32以F072为例需手动实现USB HID Class Driver。重点在USBD_HID_SendReport()函数它把Report Buffer塞进EP1 IN端点。但更关键的是USBD_HID_GetPollingInterval()返回的轮询间隔——若设为1ms0x01USB总线负载极高设为10ms0x0A更稳妥。另外STM32的Descriptor必须严格对齐const uint8_t HID_ReportDesc[] __ALIGN_BEGIN {...}否则USB枚举失败。无论哪种平台Report Buffer构造必须与描述符100%一致。例如上述媒体键ReportReport ID 0x03首字节数据字节 1字节因Report Count4, Report Size14位打包成1字节Bit0 Volume Up, Bit1 Volume Down, Bit2 Play/Pause, Bit3 Camera所以按下Volume Up时buf[1] 0x01同时按Volume Up和Camerabuf[1] 0x090b00001001。我在调试AC6328A2 hid自拍时客户把Bit顺序搞反Camera放Bit0结果快门键触发的是音量加——这就是Buffer与Descriptor错位的典型表现。4.4 抓包验证与工具链实战光写对描述符还不够必须用USB协议分析仪验证。推荐三步验证法枚举阶段验证用Wireshark USBPcap抓包过滤usb.capdata usb.device_address 1看Setup Request中GET_DESCRIPTOR返回的Descriptor是否与源码一致。重点检查总长度是否匹配本例102字节0x05 0x01Generic Desktop Page是否在开头0x85 xxReport ID是否出现在每个Logical Collection前0xc0End Collection是否成对出现数据阶段验证触发按键抓URB_INTERRUPT包看IN Data是否符合预期。例如Report ID0x03的包Data: 03 01 → 正确ID0x03, Data0x01 Data: 03 00 → 正确全松开 Data: 03 09 → 正确Volume Up Camera若出现03 ff说明固件Buffer越界或未初始化。主机解析验证用HID Report Descriptor Analysis Tool v1.7网络热词中提到的工具加载描述符它会可视化生成Usage树并标注每个Input的Bit位置。这是最直观的校验方式——如果工具解析出“Volume Up”在Bit7而非Bit0说明你的Usage Minimum/Maximum或Report Count有误。我曾用此工具发现一个致命错误在Logical Collection中漏写了Usage Page导致工具把Consumer Usage当成Generic Desktop解析整个媒体键区显示为“Unknown Usage”。回头检查源码果然在0x05, 0x0c前少了一个换行——肉眼难辨工具秒杀。所以不要相信自己的眼睛要相信抓包和工具。5. 常见问题与排查技巧实录那些文档里不会写的坑5.1 典型问题速查表现象可能原因排查步骤解决方案设备管理器显示“未知设备”或“HID兼容设备”但无具体名称描述符语法错误如Missing End Collection、Invalid Tag用HID Descriptor Tool加载看是否报“Parse Error”检查0xc0是否成对用十六进制编辑器确认每个Collection有且仅有一个End枚举成功但上位机收不到任何Input数据Report ID未设置或固件未发送Wireshark抓包看是否有IN Transaction确认描述符含0x85 xxAC6328A2检查hid_report_send()返回值是否为0STM32检查USBD_HID_SendReport()调用时机收到数据但按键识别错乱如按A键触发音量加Usage Page错位或Report Size/Count不匹配抓包看Data字节对照Descriptor计算Bit映射重新查Usage Tables用Descriptor Tool验证Bit Position多媒体键在Windows有效在macOS无效macOS对Consumer Page支持有限需添加Vendor Page扩展在Descriptor末尾加Vendor Usage增加0x06, 0x00, 0xffVendor Page自定义Usage IDmacOS可通过IOHIDManager读取AC6328A2设备插拔后需重启PC才能识别USB Descriptor缓存未刷新设备管理器卸载设备勾选“删除驱动软件”固件中增加USBD_HID_SetIdle()调用或Windows端执行devcon restart *5.2 独家避坑技巧来自十年踩坑的一线经验提示AC6328A2的HID Report Descriptor必须放在Flash的固定地址通常是0x1F000且长度不能超过256字节。很多开发者把Descriptor定义在RAM里烧录后设备根本无法枚举——因为USB控制器只从指定Flash地址读Descriptor。注意STM32的USB时钟必须精确配置。F072需开启HSI48分频为48MHz若用PLL倍频相位抖动会导致USB SYNC失败枚举超时。我曾为一个项目调了两天时钟最后发现RCC_CFGR.PLLMUL设成了×12而非×16。实测心得Report Size设为1时Logical Minimum/Maximum必须为0/1。若设为-1/1主机解析会取符号位导致0x01变成0xFF。这是HID规范的隐含规则文档里没写但所有Host Stack都这么实现。警告不要在Descriptor里用Usage Minimum/Maximum跨Page。例如0x05, 0x09, 0x19, 0xe0, 0x29, 0x01——0x01在Keyboard Page是ErrorRollOver但在Consumer Page是Volume UpHost会按当前Page解析结果不可预测。必须每个Usage Page切换后重置Usage范围。小技巧调试时在Descriptor末尾加一段“Dummy Collection”0xa1, 0x01, 0x05, 0x01, 0x09, 0x01, 0x81, 0x03, 0xc0。它创建一个无功能的Application Collection能让Wireshark更清晰地分离主Descriptor和String Descriptor避免解析混淆。5.3 性能与兼容性平衡如何让描述符既高效又普适HID描述符不是越短越好也不是越全越好而是在功能完备性、主机兼容性、带宽效率三者间找平衡点。例如放弃Report ID可减少1字节/Report但所有功能挤在一个Report里主机需解析全部Bit且无法区分功能域。适用于极简设备如单键USB按钮。用Variable而非ArrayReport Size1, Count8vsReport Size8, Count1。前者占1字节后者占1字节但Variable模式支持稀疏按键只发按下键Array模式必须发满8字节。AC6328A2推荐VariableSTM32因DMA传输效率Array更稳。删减Unused Usage描述符里写Usage (ErrorRollOver)是冗余的除非你真要处理溢出。删掉它Descriptor小3字节且避免Host误判。我给某客户做的USB转CANFD桥接器最初Descriptor含12个Consumer Usage总长180字节。后来砍掉6个不用的如Eject、Menu加Report ID分组最终102字节Windows/macOS/Linux全平台兼容USB带宽占用降低40%。所以删减比添加更需要勇气但更体现功力。6. 进阶延伸从USB HID到HID over I²C、BLE的迁移逻辑HID报告描述符的设计思想是跨总线的。当你把USB HID设备迁移到HID over I²C如鸿蒙开发板或BLE HID如AC6328A2蓝牙模式时描述符本身几乎不用改——变的只是传输层。例如HID over I²CI²C Slave设备在启动时通过I²C寄存器暴露Descriptor通常地址0x00–0xFFHost端读取后用相同逻辑解析Input。鸿蒙的hdf_hdi_hid驱动就是把I²C读到的Descriptor当USB Descriptor用。唯一区别是I²C无Report ID机制需用0x85项降级为0x00无ID所有功能合并到一个Report。BLE HIDAC6328A2的BLE HID ProfileDescriptor存在GATT Characteristic中UUID 0x2A4A。你仍用同一份Descriptor只是通过BLE Write操作更新Input值。BLE的MTU限制通常23字节要求Report不能太大这时Report Size1, CountN的优势凸显——10个开关只需2字节IDData远小于传统Keyboard Report的10字节。所以掌握HID报告描述符