USB HID и HID over GATT для считывающего пера: проводной и беспроводной дизайн интерфейса пользователя

Аудитория:OEM/ODM-интеграторы аппаратного обеспечения, руководители встроенной прошивки и менеджеры продуктов со стороны брендов, которым необходимо оценить, должен ли умный читающий стилус представляться как стандартное USB HID-устройство, Bluetooth HID-over-GATT устройство или оба варианта, а также какие компромиссы это создаёт в части объёма драйвера, совместимости с ОС и стоимости обслуживания в полевых условиях.

Когда конечный пользователь касается умным читающим стилусом печатной страницы, а хост-компьютер реагирует менее чем за 80 мс, воспринимаемое качество продукта оценивается на основе транспортного протокола, который пользователь никогда не видит. Сам читающий стилус построен на нашей платформе из 11 моделей (B1, B2, F8, K7, KF1, L5, P2, Q6, Q8, T2, Y6). Одиннадцать артикулов, два завода, 86 редакций прошивки, более 230 дистрибьюторов, 47 стран с 2023 года, и каждый из них должен корректно работать как минимум с тремя стеками HID-устройств: Windows HID через USB, macOS HID через USB, Android HID через GATT (HOGP) и iPadOS HID через GATT. Допустить ошибку в этом — самый быстрый способ превратить соответствующий требованиям CE/FCC/UKCA стилус в проблему обратной логистики.

В данном руководстве рассматривается, как USB HID выглядит внутри читающего стилуса, что означает HID over GATT (HOGP) для того же кремния, как два транспорта совместно используют одну карту дескрипторов, и какие инженерные решения ODM-заказчик должен зафиксировать до запуска в производство. Мы будем работать с нашей производственной прошивкой (B1/B2 версии 2.4.7, F8 версии 3.1.2, K7/KF1 версии 1.9.5, L5 версии 4.2.0, P2 версии 2.0.3, Q6/Q8 версии 3.3.1, T2/Y6 версии 2.6.4), нашей стандартной BOM (семейства микроконтроллеров Nordic nRF52840 или Realtek RTL8763E в зависимости от модели) и нашей реальной сертификационной базой (CE/RED/EMC/LVD, FCC, UKCA, EN 71-1/2/3, ASTM F963, RoHS, REACH, а также региональные маркировки PSE/KC/GCC/SFDA/SNI/NOM/INMETRO/RCM).

1. Почему читающий стилус должен использовать HID, а не пользовательский Bulk-эндпоинт

С точки зрения хоста читающий стилус является устройством ввода плюс небольшим приёмником аудио. Пользователь ожидает, что вывод преобразования текста в речь попадёт в приёмник медиа-класса, а любые «касания» зарегистрируются как щелчок мыши или нажатие клавиши, а не как событие частного SDK. Если прошивка предоставляет вендор-специфичный bulk-эндпоинт, ломается три вещи:

1. Хосту требуется пользовательский драйвер. На Windows 11 это означает INF-файл, CAT-подпись и отправку в Microsoft Hardware Dev Center. На macOS это означает kext или расширение DriverKit. На ChromeOS это означает отдельный ID расширения. На iPadOS это невозможно без MFi.
2. Стеки HID уже знают, как выполнять перечисление, горячее подключение, приостановку, возобновление и балансировку батареи. Пользовательский стек должен заново реализовать всё это.
3. Затем для аудиовыхода требуется отдельный интерфейс USB Audio 1.0/2.0, что удваивает дескриптор и добавляет ещё одну загрузку драйвера. Для стилуса с BOM стоимостью $3,80–$14,50 это недопустимо.

Путём отображения события касания OID на HID-использование клавиатуры (или вендор-определённое использование потребительского управления), а потокового TTS на USB Audio или HID-Notification поток, тот же стилус перечисляется как два стандартных интерфейса на одном композитном устройстве. Мы поставили более 47 000 единиц в такой конфигурации с 2023 года, и процент возвратов, связанных с «не распознаётся хостом», составляет менее 0,6% для всех одиннадцати артикулов.

Совет покупателю:Если в вашем коммерческом предложении указано «plug-and-play в Windows, macOS, ChromeOS, Android и iPad», единственный реалистичный способ выполнить это обещание — представить стилус как композитное HID-устройство через USB и HOGP через Bluetooth. Любой поставщик, утверждающий, что может сделать это с помощью проприетарного драйвера, продаёт вам контракт на поддержку.

2. Основы USB HID внутри стилуса

Спецификация класса USB HID (HID 1.11 с таблицами использования 1.5) определяет единственный тип эндпоинта, который передаёт отчёты в обоих направлениях. Внутри стилуса дерево дескрипторов выглядит примерно так:

Прошивка MCU стилуса строит это дерево во время перечисления. На нашей платформе Q6/Q8 сборка дескриптора занимает 4,3 мс после USB RESET. На L5 (которая использует внешний USB PHY) это занимает 6,1 мс. Оба значения значительно укладываются в бюджет в 100 мс на подключение и перечисление по спецификации USB 2.0.

Стилус объявляет себя как композитное устройство с bDeviceClass = 0x00 и bDeviceSubClass = 0x00, и использует Interface Association Descriptor (IAD) для группировки HID-интерфейсов. Это конфигурация, которую ожидают Windows 10/11 для многофункционального устройства с одним HID-стеком и одним аудио-стеком.

3. HID over GATT (HOGP) — Bluetooth-зеркало

HOGP определён Bluetooth SIG в спецификации HID over GATT Profile (принята в 2013, пересмотрена в 2021). Она не использует классический Bluetooth HID-профиль (который работает поверх L2CAP через BR/EDR). Вместо этого она туннелирует HID-отчёты через GATT-уведомления и индикации поверх LE.

Отображение простое:

Прошивка стилуса поддерживает одну каноническую карту дескрипторов. Когда транспорт — USB, дескриптор предоставляется через HID-эндпоинт. Когда транспорт — BLE, те же байты дескриптора обслуживаются характеристикой HID Report Descriptor (0x2A4B), и та же полезная нагрузка отчёта (обычно 8-байтовые отчёты в стиле boot-клавиатуры плюс 16-байтовый вендор-определённый отчёт о касании) отправляется на характеристике HID Report (0x2A4D) через уведомления.

На F8 (RTL8763E, BLE 5.1) интервал уведомлений настраивается от 7,5 мс до 4 с. Мы поставляем прошивку F8 с интервалом подключения 15 мс, мощностью передачи 0 дБм, физическим уровнем 1 Мбит, что обеспечивает эффективную сквозную задержку 6,4 мс от касания кончиком пера до нажатия клавиши на хосте. Именно этот показатель видят наши дистрибьюторы в классах, и именно его мы измеряем на каждой производственной партии с помощью логического анализатора Saleae на тестовых площадках F8.

4. Совместное использование карты дескрипторов между интерфейсами

Самая распространённая ошибка клиентов, которые приносят перо без USB и просят «просто добавить Bluetooth», — хранение двух карт дескрипторов. Это вдвое увеличивает матрицу QA и порождает класс ошибок, когда проводное перо работает на школьном компьютере, а беспроводное перо работает некорректно на том же Chromebook.

Наша стандартная архитектура:

[OID event source] -> [Vendor report assembler]-> {USB HID endpoint | GATT 0x2A4D}
                                                       ^               ^
                                                       |               |
                                                  [Descriptor map] --'
                                                  (единый источник истины)

Сборщик отчётов вендора принимает 16-байтовую полезную нагрузку события OID (ID страницы 4 байта, код 4 байта, язык 1 байт, последовательность 2 байта, время наведения 2 байта, флаги 1 байт, зарезервировано 2 байта) и упаковывает её либо в загрузочный отчёт клавиатуры (когда Режим протокола = Boot), либо в отчёт вендора (когда Режим протокола = Report). Один и тот же байтовый поток передаётся через USB-эндпоинт EP1 IN или BLE-характеристику 0x2A4D.

5. Влияние на энергопотребление и аккумулятор

HID over GATT требует, чтобы перо поддерживало соединение. На B1 с аккумулятором 700 мАч интервал подключения, латентность подчинённого устройства и бюджет длительности события подключения в сумме дают энергопотребление 1,4 мА в установившемся режиме на радио F8 по сравнению с 0,0 мА при USB-подвешивании. Наши тесты автономной работы (TC-047) показывают:

Для школьных развёртываний, работающих 6 часов в день, T2 и Y6 — единственные модели, которые выдерживают полный учебный день при использовании BLE без подзарядки. Для развёртывания на 12 000 единиц в государствах Персидского залива, отгруженного в прошлом году, 80% заказа составили T2 именно по этой причине. Оставшиеся 20% составили Y6 для резервных устройств в комнатах отдыха персонала.

6. Многохостовое сопряжение и поведение при повторном сопряжении

Ручка для чтения должна запоминать более одного хоста, поскольку типичный пользователь перемещается между настольным компьютером в классе, ноутбуком учителя и личным планшетом. Наша прошивка хранит до 8 связанных пиров (LE) и до 4 контекстов перечисления USB (адрес шины на стороне хоста). При перечислении пера новым USB-хостом оно не выполняет повторное перечисление HID-интерфейса — используется кэшированная конфигурация, что сокращает время повторного перечисления с ~95 мс до ~12 мс.

На стороне BLE мы используем направленную рекламу при повторном подключении к известному пиру (пропуская фазу общего обнаружения длительностью 1,28 с), экономя ~700 мс при повторном подключении. Цена этого — перо должно знать, какой пир является «текущим», что мы храним в энергонезависимой памяти с износоустойчивой записью (см. TC-032 о политике выравнивания износа NAND).

7. Соответствие нормативным требованиям и сертификационный профиль

Ручка для чтения, рекламирующая радиомодуль и USB-стек, должна пройти испытания на соответствие:

Мы испытываем излучение USB в полузаглушённой камере 3 м с ручкой в режимах USB 2.0 High Speed и USB 2.0 Full Speed, а также в режиме USB Suspend. Мы испытываем BLE в той же камере с включённым режимом переключения каналов. Однократный повторный тест стоит $1 400 за лабораторные услуги; повторная сертификация существующего SKU на новом радиомодуле стоит $4 800. Именно поэтому наш HID-радиомодуль зафиксирован на уровне платформы (Nordic nRF52840 ревизия 2 или Realtek RTL8763E ревизия B), и мы не рекомендуем клиентам «заменять чип BLE на более дешёвый», поскольку стоимость повторных испытаний аннулирует экономию на BOM.

8. Реальные виды отказов в полевых условиях

Среди отгруженных 47 000+ единиц, заявки на HID-связанные отказы в полевых условиях распределяются следующим образом:

Главный урок: каждый стек HID (Windows, macOS, iPadOS, Android, ChromeOS) интерпретирует «очередизацию входных отчётов» по-своему. Наша производственная прошивка теперь отправляет отчёт нулевой длины при сбросе шины, что вынуждает каждый хост очищать свою очередь. Одно это изменение снизило количество HID-тикетов с 1,9% до 0,6% от отгрузок.

9. Контрольный список решений ODM перед изготовлением пресс-форм

Для заказчика, выводящего собственный бренд, вопросы, которые необходимо закрыть до открытия пресс-формы:

Мы проходим этот чеклист на первом звонке по оценке и фиксируем его до размещения PCB. Изменения после размещения добавляют $4 000–$28 000 на переработку пресс-форм плюс 6 недель срыва графика.

10. Пример HID Descriptor, который мы поставляем на Q6/Q8

92-байтовый HID report descriptor для платформы Q6/Q8 выглядит примерно так:

0x05, 0x01,        // Usage Page (Generic Desktop)
0x09, 0x06,        // Usage (Keyboard)
0xA1, 0x01,        // Collection (Application)
0x05, 0x07,        //   Usage Page (Keyboard)
0x19, 0xE0,        //   Usage Minimum (224)
0x29, 0xE7,        //   Usage Maximum (231)
0x15, 0x00,        //   Logical Minimum (0)
0x25, 0x01,        //   Logical Maximum (1)
0x75, 0x01,        //   Report Size (1)
0x95, 0x08,        //   Report Count (8)
0x81, 0x02,        //   Input (Data,Var,Abs)
0x95, 0x01,        //   Report Count (1)
0x75, 0x08,        //   Report Size (8)
0x81, 0x03,        //   Input (Const,Var,Abs)
0x05, 0x0C,        //   Usage Page (Consumer)
0x09, 0xE9,        //   Usage (Volume Up)
0x09, 0xEA,        //   Usage (Volume Down)
0x09, 0xCD,        //   Usage (Play/Pause)
0x15, 0x00,        //   Logical Minimum (0)
0x25, 0x01,        //   Logical Maximum (1)
0x75, 0x01,        //   Report Size (1)
0x95, 0x03,        //   Report Count (3)
0x81, 0x02,        //   Input (Data,Var,Abs)
0xC0,              // End Collection
0x06, 0xFF, 0x00,  // Usage Page (Vendor Defined 0xFF00)
0x09, 0x01,        // Usage (OID Event)
0xA1, 0x01,        // Collection (Application)
0x15, 0x00,        //   Logical Minimum (0)
0x26, 0xFF, 0x00,  //   Logical Maximum (255)
0x75, 0x08,        //   Report Size (8)
0x95, 0x10,        //   Report Count (16)
0x09, 0x02,        //   Usage (OID Payload)
0x91, 0x02,        //   Output (Data,Var,Abs)
0xC0               // End Collection

Этот дескриптор хранится в ROM платформы Q6/Q8. На F8 (только BLE 5.1) мы поставляем 76-байтовый вариант только с коллекцией клавиатуры, поскольку планшеты Apple/Android не требуют страницы управления потреблением для tap-событий.

11. Как это связано с остальными 7 статьями

Это статья TC-057 в кластере беспроводной и проводной связи. TC-058 разбирает дескриптор побайтно. TC-059 описывает протокол SSP-сопряжения, используемый для настройки BLE-стороны. TC-060 документирует GATT-сервис и карту UUID характеристик. TC-061 объясняет, как планируются и ограничиваются по скорости уведомления. TC-062 охватывает Wi-Fi AP-провизионинг для моделей L5/Y6 с радио 802.11. TC-063 охватывает mDNS / DNS-SD service discovery для классного сценария L5. TC-064 охватывает CoAP для низкоовархидной IoT телеметрии с той же платформы L5.

Пять вопросов, которые каждую неделю задаёт наша команда поддержки прошивки о USB HID и HOGP, с ответами, привязанными к реальной производственной прошивке и стандартной BOM.

13. Рекомендуемое чтение

• HID-дескриптор отчёта и страница использования считывающей ручки
• SSP безопасное простое сопряжение Bluetooth считывающей ручки
• UUID характеристик BLE-сервиса считывающей ручки
• GATT-сервер и механизм уведомлений считывающей ручки
• Зарядка USB Type-C PD QC и BC1.2 считывающей ручки
• Bluetooth 5.0 против 5.2 против 5.3 считывающей ручки
• Цикл вставки разъёма Type-C считывающей ручки
• Микрофон USB считывающей ручки и USB 2.0 против 3.0