报告描述符中HID使用的裸露要求是什么?

时间:2016-11-23 22:14:18

标签: bluetooth bluetooth-lowenergy hid gatt

因此,我目前正在计划蓝牙低功耗设备的代码,该设备将通过蓝牙规范在GATT配置文件上运行HID。我已经阅读了HID规范1.11和使用表1.12但我找不到任何关于Usage_pages和Usages的最低要求使用情况。

由于我们正在实施主机和设备,计划是使用供应商定义的使用页面作为我们的报告描述符,但由于我们的目标是快速连接和低功耗,我不想发送在HAT over GATT的报告定义阶段,我的字节数比我要多。因此,我正在考虑删除通常标记输入/输出的所有用法,因为它们看似只是语义。

以下是我正在考虑的样本:

    Usage_Page( Vendor Defined)
    Usage( Vendor 1)
    Collection(Application)
         Collection(Logical)   ; First Collection and Report
         Report_ID(1)
         Usage_Page(Button)    ; This is what the Specification seems to encourage
         Usage_Minimum(Button 1)
         Usage_Maximum(Button 3)
         Logical_Minimum(0)            ; Logical Limits
         Logical_Maximum(1)
         Report_Size(3)        ; 3 Bits corresponding to the Buttons
         Report_Count(1)       ; 1 of the 3 Bit set
         Input( Data, Variable, Absolute)  ;Make it an input
         Report_Size(5)
         Report_Count(1)
         Input(Constant)       ; Pad the transmitted Byte
         Collection End
    Collection End

当我看到这个时,我看到很多额外的字节什么也没用,因为我没有使用本机解析器。这些范围从用法到偶数逻辑最小值/最大值。 行业中的某个人或者更好地了解标准(无论是HID而不是GATT还是USB HID)都可以告诉我,如果我只使用顶级用法定义我的报表描述符并且不使用任何东西会产生什么后果比如Logical Maximums?

1 个答案:

答案 0 :(得分:0)

兼容解析器应接受以下优化描述符:

 0x85, 0x01,                    // ReportID (1)
 0x05, 0xff,                    // UsagePage (255)
 0x09, 0x01,                    // Usage (1)
 0xa1, 0x01,                    // Collection (Application)
 0x25, 0x01,                    //     LogicalMaximum (1)
 0x75, 0x01,                    //     ReportSize (1)
 0x05, 0x09,                    //     UsagePage (Button)
 0x19, 0x01,                    //     UsageMinimum (Button(1))
 0x29, 0x03,                    //     UsageMaximum (Button(3))
 0x95, 0x03,                    //     ReportCount (3)
 0x81, 0x02,                    //     Input (Variable)
 0xc0,                          // EndCollection
  • 逻辑最小值默认为0,
  • 最后一个字节末尾的填充是免费的。

另请注意,HoG的所有中央端实现(Win,Bluez,CoreBluetooth,Bluedroid)实际上在配对发生时缓存报告描述符,以便最小化重新连接时间。因此,报告描述符的实际大小并不重要:配对只需要一次,并且可能永远不会再次(直到设备再次配对)。

还要考虑报告描述符读取表示中央和外围设备之间交换的一些数据包(默认MTU每20个字节1个),每次往返花费2个间隔(如果两个堆栈实现都不太糟糕),这将是大约60ms (大多数中心连接的默认间隔为~30ms)。因此,当您的报告描述符长度超过60个字节时,实际发现延迟将少于200毫秒...对于在设备生命周期内仅发生一次的事情而言,这不是什么大不了的事。

最后,请注意:您可能不应该使用特定于供应商的集合类型,但尝试坚持使用标准类型。在大多数情况下,它将允许您的设备无人驾驶操作。

不要忘记,即使您只预见到硬件的应用程序特定用途,有些人可能真的很乐意将其重新用于其他内容,如果是这样,无人驾驶更好,除非您想要禁止第三部分使用,但首先使用HID毫无意义。 (HID专为无人驾驶操作而设计,我仍然很困惑地看到鼠标和游戏手柄,遥控器和按钮的驱动因为制造商的懒惰。)