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

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

Поскольку мы реализуем как хост, так и устройство, план состоит в том, чтобы использовать страницу использования, определенную поставщиком, для нашего дескриптора отчета, но поскольку наша цель — иметь быстрые соединения и низкое энергопотребление, я не хочу отправлять больше байтов, чем Я должен на этапе определения отчета 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)                    ; Three bits corresponding to the buttons
         Report_Count(1)                   ; One of the three bit sets
         Input( Data, Variable, Absolute)  ; Make it an input
         Report_Size(5)
         Report_Count(1)
         Input(Constant)                   ; Pad the transmitted byte
         Collection End
    Collection End

Когда я смотрю на это, я вижу много лишних байтов, которые ничего не делают, так как я не использую собственный синтаксический анализатор. Они варьируются от использования до даже логических минимумов/максимумов. Какие последствия могут быть, если я просто определил свой дескриптор отчета только с использованием верхнего уровня и не использовал такие вещи, как логические максимумы?


bluetooth bluetooth-lowenergy gatt hid
person hanseltime    schedule 23.11.2016    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

 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) фактически кэшируют дескриптор отчета, когда происходит сопряжение, чтобы минимизировать время повторного подключения. Таким образом, фактический размер дескриптора отчета не так важен: это займет время только один раз при сопряжении и, вероятно, никогда больше (конечно, до тех пор, пока устройство не будет сопряжено снова).

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

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

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

person Nipo    schedule 24.11.2016
comment
Спасибо! Задача здесь состоит в том, чтобы свести к минимуму время сопряжения, поэтому это отлично отвечает на мой вопрос об дескрипторах отчетов. В качестве побочного примечания я бы не возражал против использования предопределенных заметок об использовании, однако, поскольку я действительно хотел бы отправлять данные RGB для одного светодиодного индикатора, я не нашел ничего (кроме буквенно-цифровой страницы использования), что предвидело бы это. Если есть обходной путь, не связанный с передачей матричных индексов в данных, я бы хотел его услышать. - person hanseltime; 04.12.2016
comment
Действительно, в 1995 году RGB-светодиоды казались фантастикой. Жаль, что они не включили его на страницу Led. Мое примечание относилось к дескриптору отчета, который вы разместили выше, где было всего 3 кнопки. Я должен согласиться с тем, что буквенно-цифровой дисплей кажется перепроектированием спецификации, которую никто никогда не реализовывал, даже если HUTRR29b, вероятно, позволил бы объявить дисплей 1x1, я бы не рекомендовал это делать. - person Nipo; 04.12.2016