Lese penn USB HID og HID over GATT: Kablet og trådløs Human Interface Design

Målgruppe: OEM/ODM-maskinvareintegratorer, innebygde firmware-ansvarlige og merkevareansvarlige produktledere som må vurdere om en smart lesepenn bør presentere seg som en standard USB HID, en Bluetooth HID-over-GATT-enhet, eller begge deler, og hvilke avveininger dette valget skaper for driveromfang, OS-kompatibilitet og kostnader til feltservice.

Når en sluttbruker trykker en smart lesepenn mot en utskrevet side og vertsdatamaskinen reagerer på under 80 ms, bedømmes den opplevde kvaliteten til produktet etter en transportprotokoll brukeren aldri ser. Lesepennen i seg selv er bygget på vår 11-modell-plattform (B1, B2, F8, K7, KF1, L5, P2, Q6, Q8, T2, Y6). Elleve SKU-er, to fabrikkaper, 86 firmware-revisjoner, 230+ distributører, 47 land siden 2023, og hver eneste av dem må fungere sømløst med minst tre human-interface device-stakker: Windows HID over USB, macOS HID over USB, Android HID over GATT (HOGP) og iPadOS HID over GATT. Å gjøre feil her er den raskeste måten å gjøre en CE/FCC/UKCA-kompatibel penn til et returproblem.

Denne veiledningen går gjennom hva USB HID faktisk ser ut som inni en lesepenn, hva HID over GATT (HOGP) betyr for den samme silisiumen, hvordan de to transportene deler ett enkelt deskriptorkart, og de tekniske avgjørelsene en ODM-kunde må låse før verktøybygging. Vi jobber med vår produksjonsfirmware (B1/B2 på 2.4.7, F8 på 3.1.2, K7/KF1 på 1.9.5, L5 på 4.2.0, P2 på 2.0.3, Q6/Q8 på 3.3.1, T2/Y6 på 2.6.4), vår standard BOM (Nordic nRF52840 eller Realtek RTL8763E MCU-familier, avhengig av modell) og vår faktiske sertifiseringsportefølje (CE/RED/EMC/LVD, FCC, UKCA, EN 71-1/2/3, ASTM F963, RoHS, REACH, samt regionale merker PSE/KC/GNOM/SFDA/SNI/NOM/INMETRO/RCM).

1. Hvorfor en lesepenn bør være HID, ikke en egendefinert bulk-endpoint

En lesepenn er, fra vertens perspektiv, en inndataenhet pluss et lite lyduttak. Brukeren forventer at tekst-til-tale-utgangen havner i en media-klasse-sink, og at ethvert «trykk» registreres som et museklikk eller et tastetrykk, ikke som en privat SDK-hendelse. Hvis firmwaren eksponerer en leverandørspesifikk bulk-endpoint, ryker tre ting:

1. Verten trenger en egendefinert driver. På Windows 11 betyr dette en INF, en CAT-signatur og en innsending til Microsoft Hardware Dev Center. På macOS betyr det en kext eller en DriverKit-utvidelse. På ChromeOS betyr det en egen utvidelses-ID. På iPadOS er det uaktuelt uten MFi.
2. HID-stakkene vet allerede hvordan de skal enumerere, hot-plugge, suspendere, gjenoppta og balansere batteri. En egendefinert stakk må reimplementere alt dette.
3. Lydutgang krever da et eget USB Audio 1.0/2.0-grensesnitt, som dobler deskriptoren og legger til enda en driverlast. På en penn med BOM på $3.80–$14.50 er dette uakseptabelt.

Ved å mappe OID-tappehendelsen til en HID-tastaturusage (eller en leverandørdefinert consumer-control-usage) og strømme-TTS til en USB Audio- eller HID-Notification-strøm, oppfører den samme pennen seg som to standardgrensesnitt på én enkelt sammensatt enhet. Vi har sendt 47 000+ enheter i denne konfigurasjonen siden 2023, og returandelen knyttet til «ikke gjenkjent av vert» ligger under 0,6 % på tvers av de elleve SKU-ene.

Kjøpertips: Hvis salgsmateriellet ditt lover «plug-and-play på Windows, macOS, ChromeOS, Android og iPad», er den eneste realistiske måten å holde dette løftet å eksponere pennen som en sammensatt HID-enhet over USB og HOGP over Bluetooth. Enhver leverandør som sier de kan gjøre dette med en proprietær driver, selger deg en supportkontrakt.

2. Grunnleggende om USB HID inni pennen

USB HID-klasspesifikasjonen (HID 1.11 med usage tables 1.5) definerer én enkelt endpoint-type som frakter rapporter i begge retninger. Inni pennen ser deskriptortreet omtrent slik ut:

Pennens MCU-firmware bygger dette treet ved enumerering. På vår Q6/Q8-plattform tar deskriptormontering 4,3 ms etter USB RESET. På L5 (som bruker en ekstern USB PHY) tar det 6,1 ms. Begge er godt innenfor USB 2.0-spesifikasjonens 100 ms-budsjett fra tilkobling til enumerering.

Pennen annonserer seg som en sammensatt enhet med bDeviceClass = 0x00 og bDeviceSubClass = 0x00, og bruker Interface Association Descriptor (IAD) for å gruppere HID-grensesnittene. Dette er konfigurasjonen Windows 10/11 forventer for en flerfunksjonsenhet med én HID-stakk og én lydstakk.

3. HID over GATT (HOGP) — Bluetooth-speilet

HOGP er definert av Bluetooth SIG i spesifikasjonen HID over GATT Profile (vedtatt 2013, revidert 2021). Den bruker ikke den klassiske Bluetooth HID-profilen (som ligger oppå L2CAP over BR/EDR). I stedet tunnelerer den HID-rapporter gjennom GATT-notifications og indications oppå LE.

Kartleggingen er enkel:

Pennens firmware beholder ett kanonisk deskriptorkart. Når transporten er USB, eksponeres deskriptoren over HID-endpointen. Når transporten er BLE, serveres de samme deskriptorbytene av HID Report Descriptor-karakteristikken (0x2A4B), og den samme rapportnyttelasten (typisk 8-byte boot-stil tastaturrapporter pluss en 16-byte leverandørdefinert tap-rapport) sendes på HID Report-karakteristikken (0x2A4D) via notifications.

På F8 (RTL8763E, BLE 5.1) er varslingsintervallet konfigurerbart mellom 7,5 ms og 4 s. Vi leverer F8-firmware med 15 ms tilkoblingsintervall, 0 dBm TX, 1 Mbit PHY, som gir en effektiv 6,4 ms ende-til-ende-latens fra pennespiss-berøring til tastetrykk på verten. Det er tallet distributørene våre ser i klasserom, og det er tallet vi måler på hvert produksjonsparti ved hjelp av en Saleae-logikkanalysator på F8s testpunkter.

4. Dele deskriptorkartet på tvers av transportlag

Den desidert vanligste feilen vi ser fra kunder som kommer med en ikke-USB-penn og ber oss om å bare «legge til Bluetooth», er at de beholder to deskriptorkart. Dette dobler QA-matrisen og skaper en type feil der den kablede pennen fungerer på en skoledatamaskin, mens den trådløse pennen oppfører seg feil på den samme Chromebooken.

Vår standardarkitektur er:

[OID event source] -> [Vendor report assembler] -> {USB HID-endepunkt | GATT 0x2A4D}
                                                       ^               ^
                                                       |               |
                                                  [Descriptor map] --'
                                                  (single source of truth)

Vendor-rapportmontøren tar den 16-byte store OID-hendelsesnyttelasten (side-ID 4 byte, kode 4 byte, språk 1 byte, sekvens 2 byte, dwell 2 byte, flagg 1 byte, reservert 2 byte) og pakker den inn i enten en oppstartsrapport for tastatur (når Protocol Mode = Boot) eller en leverandørdefinert rapport (når Protocol Mode = Report). Den samme bytestrømmen sendes ut på USB-endepunkt EP1 IN eller BLE-karakteristikk 0x2A4D.

5. Strøm- og batterikonsekvenser

HID over GATT krever at pennen opprettholder en tilkobling. På en 700 mAh B1 blir tilkoblingsintervall, slave-latens og tilkoblingshendelsens lengdebudsjett til et stabilt strømforbruk på 1,4 mA på F8-radioen vs 0,0 mA i USB-suspendering. Våre kjøretidstester (TC-047) viser:

For skoledistribusjoner som driftes 6 timer om dagen, er T2 og Y6 de eneste modellene som holder en hel skoledag på BLE uten å lades på nytt. For en leveranse på 12 000 enheter til en gulfstat som vi sendte i fjor, utgjorde 80 % av ordren T2, spesifikt av denne grunnen. De resterende 20 % var Y6 som reserveenheter til personalrommet.

6. Multi-Host-paring og re-paringsatferd

En lesepenn må huske mer enn én vert fordi den typiske brukeren flytter seg mellom en stasjonær klasseroms-PC, en lærers bærbare PC og et personlig nettbrett. Fastvaren vår lagrer opptil 8 parede enheter (LE) og opptil 4 USB-opprettelseskontekster (vertssidens bussadresse). Når en penn opprettes av en ny USB-vert, oppretter den ikke HID-grensesnittet på nytt – den bruker den bufrede konfigurasjonen, noe som reduserer gjenopprettingstiden fra ~95 ms til ~12 ms.

På BLE-siden bruker vi rettet annonsering ved tilkobling til en kjent enhet (vi hopper over den generelle oppdagelsesfasen på 1,28 s), noe som sparer ~700 ms ved gjenoppkobling. Kostnaden er at pennen må vite hvilken enhet som er «gjeldende», noe vi lagrer i ikke-flyktig minne med en slitasjeutjevnet skriving (se TC-032 for policyen for NAND-slitasjeutjevning).

7. Samsvar- og sertifiseringsomfang

En lesepenn som annonserer en radio og en USB-protokoll må testes mot:

Vi tester USB-stråling i et 3 m semi-anechoic kammer med pennen i både USB 2.0 High Speed og USB 2.0 Full Speed, samt USB Suspend. Vi tester BLE i samme kammer med hoppemodus aktivert. En enkelt ny test koster $1 400 i laboratorieavgifter; ny sertifisering av en eksisterende SKU på en ny radiomodul koster $4 800. Det er derfor HID-radiomodulen vår er låst på plattformnivå (Nordic nRF52840 revisjon 2 eller Realtek RTL8763E revisjon B), og vi fraråder kunder å «bytte til en billigere BLE-brikke» fordi kostnaden for ny testing utligner BOM-besparelsen.

8. Feltfeilmoduser vi faktisk har sett

På tvers av de 47 000+ enhetene som er sendt, fordeler HID-relaterte feltsaker seg slik:

Den viktigste lærdommen: hver HID-stakk (Windows, macOS, iPadOS, Android, ChromeOS) tolker «input report queueing» litt forskjellig. Vår produksjonsfirmware sender nå en rapport med null lengde ved busreset, som tvinger hver vert til å tømme køen sin. Den ene endringen reduserte volumet av HID-saker fra 1,9 % av forsendelsene til 0,6 %.

9. ODM-beslutningssjekkliste før verktøy

For en kunde som kommer med sitt eget merke, er dette spørsmålene som må låses før vi åpner en form:

Vi kjører denne sjekklisten i den første scoping-samtalen og fryser den før PCB-layout. Endringer etter layout legger til $4 000–$28 000 i form-omarbeiding pluss 6 ukers forsinkelse i tidsplanen.

10. Eksempel på HID-deskriptor vi leverer på Q6/Q8

En 92-byte HID-rapportdeskriptor for Q6/Q8-plattformen ser omtrent slik ut:

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

Denne deskriptoren lever i ROM på Q6/Q8-plattformen. På F8 (kun BLE 5.1) leverer vi en 76-byte variant kun med tastatursamlingen, fordi Apple/Android-nettbrett ikke trenger consumer-control-siden for trykkhendelser.

11. Hvordan dette henger sammen med de 7 andre artiklene

[fiks: engelsk-rest] Dette er artikkel TC-057 i klyngen for trådløs og kablet tilkobling. TC-058 går gjennom deskriptoren byte for byte. TC-059 dekker SSP-sammenkoblingsprotokollen som brukes for å sette opp BLE-siden. TC-060 dokumenterer GATT-tjenesten og UUID-kartet for karakteristikker. TC-061 forklarer hvordan varslinger planlegges og strupes (rate-limiting). TC-062 dekker Wi-Fi AP-klargjøring for L5/Y6-modellene som har en 802.11-radio. TC-063 dekker mDNS / DNS-SD-tjenesteoppdagelse for L5-klasseromsscenarioet. TC-064 dekker CoAP for IoT-telemetri med lav overhead fra den samme L5-plattformen.

Fem spørsmål vårt fastvare-supportteam får hver uke om USB HID og HOGP, med svar knyttet til den faktiske produksjonsfastvaren og vår standard BOM.

13. Relatert lesning

• Reading Pen HID Report Descriptor and Usage Page
• Reading Pen Bluetooth Pairing SSP Secure Simple Pairing
• Reading Pen BLE Service Characteristic UUID Design
• Reading Pen GATT Server and Notification Mechanism
• Reading Pen USB Type-C Charging PD QC and BC1.2
• Reading Pen Bluetooth 5.0 vs 5.2 vs 5.3
• Reading Pen Type-C Connector Insertion Cycle
• Reading Pen Mic USB and USB 2.0 vs 3.0