Каковы требования Bare для использования HID в дескрипторе отчета?

Question

Итак, я в настоящее время планирую код для устройства с низким энергопотреблением Bluetooth, которое будет работать с HID по профилю GATT по спецификации Bluetooth. Я прочитал спецификацию HID 1.11 и таблицы использования 1.12, но я не могу найти ничего о минимально требуемом использовании Usage_pages и Usages.

Поскольку мы внедряем как Host, так и Device, мы планируем использовать страницу с определением поставщика для нашего дескриптора отчета, но поскольку наша цель - иметь быстрые соединения и низкое энергопотребление, я не хочу отправьте больше байтов, чем я должен на этапе определения отчета HID по 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 

Когда я смотрю на это, я вижу много дополнительных байтов, которые ничего не делают, так как я не использую родной парсер. Они варьируются от Usages до равномерных логических минимумов/максимумов. Может ли кто-нибудь в отрасли или кто лучше знал стандарты (в HID over GATT или USB HID), скажите мне, какие последствия могут возникнуть, если бы я только определил свой дескриптор отчета только с использованием верхнего уровня и не использовал такие вещи, как логика Максимумы?

Answer 1

Совместимый анализатор должен принять следующий оптимизированный дескриптор:

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,
• обивка в конце последнего байта поставляется бесплатно.

Также обратите внимание, что все реализации центральной части (Win, Bluez, CoreBluetooth, Bluedroid) HoG фактически кэшируют дескриптор отчета, когда происходит сопряжение, чтобы минимизировать время пересоединения. Таким образом, фактический размер дескриптора отчета не так важен: он будет занимать время один раз при спаривании и, вероятно, никогда больше не будет (пока устройство не будет спарено снова, конечно).

Кроме того, рассмотрение чтения дескриптора отчета представляет собой несколько пакетов, обмениваемых между центральным и периферийным (1 каждые 20 байтов с MTU по умолчанию), каждый раунд-трафик стоит 2 интервала (если обе реализации стека не так уж плохи), что будет вокруг 60 мс (большинство центров соединяются с интервалом по умолчанию до ~ 30 мс). Таким образом, фактическая латентность обнаружения будет меньше 200 мс, когда ваш дескриптор отчета будет длиннее на 60 байт ... Не большая вещь для чего-то, что происходит только один раз в жизни устройства.

Наконец, примечание стороны. Вероятно, вы не должны использовать тип коллекции, специфичный для поставщика, но старайтесь придерживаться стандартных. В большинстве случаев это позволит работать с драйверами без драйверов.

Не забывайте, что даже если вы только предвидите конкретное использование вашего оборудования, некоторые люди могут быть счастливы повторно использовать его для чего-то другого, если это так, без водителя лучше, если вы не хотите запретить использование третьей части на все, но нет смысла использовать HID в первую очередь. (HID был разработан для работы без водителя, и я все еще озадачен, увидев драйверы для мышей и геймпада, пультов дистанционного управления и кнопок только из-за лень производителя.)