In questo articolo della Rubrica Firmware Reload di Elettronica Open Source analizziamo la proposta HID della Silicon Labs.
Introduzione
In elettronica, l’Universal Serial Bus (USB - bus universale seriale) è uno standard di comunicazione seriale che consente di collegare diverse periferiche a un computer con velocità che arrivano fino a 480 megabit al secondo (Mbps); è stato progettato per consentire a più periferiche di essere connesse usando una sola interfaccia standardizzata e un solo tipo di connettore (con un semplice cavo a quattro fili per USBv2.0) e per migliorare la funzionalità plug-and-play consentendo di collegare o scollegare i dispositivi senza dover riavviare il computer (hot swap), perciò con tale protocollo i dispositivi vengono configurati in fase di avvio oppure quando sono collegati in fase di esecuzione.
Quindi, mediante un’architettura di comunicazione hardware/software USB, possiamo collegare a un personal computer (PC) una vasta varietà di device esterni, come: tastiere, mouse, periferiche di gioco, dispositivi di display alfanumerico e altro. In informatica, la classe USB “Human Interface Device” (classe HID USB) è una parte del protocollo e della specifica USB per le periferiche dei computer, principalmente i device che vengono utilizzati dagli esseri umani per controllare il funzionamento dei computer, come un mouse, uno schermo touch, una tastiera e così via, ma anche disposizioni di output diretto per l’utente.
Altri esempi sono i controller per la simulazione, attrezzi ginnici, dispositivi di telefonia, termometri, comandi audio, strumentazione medica, anche i gruppi di continuità appartengono a questa classe, nonostante non hanno alcuna interfaccia per gli utilizzatori. Questo ci fa capire che ogni dispositivo esterno può essere un dispositivo di classe HID USB, l’importante che risponda alle specifiche della classe USB HID. Tutti questi dispositivi sono suddivisi in diverse classi e ogni classe definisce il comportamento e i protocolli per i dispositivi con funzioni simili. Uno dei vantaggi principali nell’avere una classe HID USB ben definita è l’abbondanza di driver di periferica disponibili nei più moderni sistemi operativi.
I dispositivi di classe USB HID e le loro funzioni di base sono definiti in una documentazione USB-IF (Implementers Forum) ma le loro specifiche non hanno alcun legame con nessun software specifico e nessuna implementazione particolare. Grazie a queste descrizioni generiche, è più facile per i progettisti di sistemi operativi includere funzionalità nei driver dei vari dispositivi, permettendo una più rapida distribuzione dei device e una più facile installazione da parte degli utenti finali.
CONTROL PIPE VS. INTERRUPT PIPE
Per meglio comprendere la classe HID, gli utenti dovrebbero avere familiarità con le specifiche USB, che definiscono il protocollo utilizzato dall’host per identificare e capire come comunicare con i dispositivi presenti sul bus. L’USB “Core Specification” (CS) definisce il codice di ogni classe HID e mediante queste definizioni l’host è in grado di discriminare i vari dispositivi collegati. Sono esplicitati anche i metodi di trasferimento che un dispositivo collegato deve supportare. Dalla Figura 1 si può vedere che un dispositivo appartenente alla classe HID deve supportare il “Control Pipe” (CP) e il trasferimento a interrupt; sono molto diversi tra loro e il loro funzionamento è definito nella specifica USB.
Figura 1: Tipi di comunicazione tre Host e Device
Il Control Pipe è in genere utilizzato per il processo di enumerazione e la configurazione del dispositivo (quali driver devono essere caricati) ma non per le comunicazioni di dati; mentre l’interrupt pipe viene utilizzato per il trasferimento di dati. La specifica USB definisce le differenze tra i tipi di trasferimento e definisce anche le strutture dati chiamate “report”, trasferite mediante uno dei metodi descritti precedentemente. Una volta che l’enumerazione è completa, i dispositivi HID possono comunicare attraverso il canale di controllo (CP) per attuare lo scambio d’informazioni memorizzate nei report. Questo è in genere riservato sia per informazioni di configurazione che per lo stato del dispositivo, come ad esempio i numeri di versione dell’applicazione.
Il Control Pipe ha una sequenza definita di trasferimento, ben strutturata nella specifica USB e ha un livello di controllo degli errori rispetto agli altri metodi di trasferimento. Inoltre, le chiamate alle API (Application Programming Interface) fatte dall’host per inviare dati tramite il CP sono differenti da quelle per l’interrupt pipe. Mediante questo metodo di trasferimento dati, non viene garantita la latenza, infatti l’host riserva soltanto una percentuale del frame USB dipendentemente dalla larghezza di banda utilizzata. In Figura 2 si ha un esempio del “data flow” del Control Pipe tra l’host e il dispositivo collegato, in cui si possono notare le chiamate alle funzioni effettuate dall’host e le risposte del device, sia nel caso in cui riceve i report che nel caso in cui vengono inviati i report richiesti mediante un particolare ID.
Figura 2: Control Pipe Data Flow
Il metodo di trasferimento a interrupt è un trasferimento di dati periodico e, a differenza del precedente, garantisce una certa latenza nel trasferimento dati. Durante l’enumerazione, il dispositivo chiede quanto spesso vuole che l’host invii dati in ingresso (IN) e in uscita (OUT); una volta che l’enumerazione è completa, i programmi si configurano sulla base di queste tempistiche per i trasferimenti periodici. Se il dispositivo collegato è un mouse, per esempio, questo memorizza i dati X e Y (es. coordinate) in un buffer e li trasmette all’host quando richiesto. Quando viene usato uno schermo touch si applica lo stesso principio, i dati X e Y nonché eventuali elementi aggiuntivi richiesti, vengono memorizzati e poi trasmessi all’host quando richiesti. In Figura 3 è riportato un esempio di “data flow” dell’interrupt pipe.
Figura 3: Interrupt Pipe Data Flow
REPORT E DATA TRANSFER RATE
Come già analizzato, il trasferimento a interrupt è utilizzato per quelle trasmissioni periodiche in cui un periodo di tempo è richiesto dal dispositivo e l’host garantisce che il trasferimento dati sarà effettuato entro tale periodo di tempo. Esso però, non garantisce che i dati vengano trasferiti su una base temporale coerente per tutto il tempo, solo che sarà programmato il trasferimento prima del periodo di scadenza. Questo tipo di trasferimento è utile per le applicazioni quali mouse e tastiere, dove l’input dell’utente è continuamente inviato all’host; inoltre, questa tipologia di trasferimento può fornire un flusso di dati rapido che può tornare utile per le applicazioni con UART (Universal Asynchronous Receive and Transmit).
L’intervallo temporale più piccolo in cui un dispositivo può richiedere il trasferimento dati è di 1 frame (1ms). Dal momento che la dimensione massima del pacchetto è di 64 byte per i trasferimenti a piena velocità, allora il massimo “throughput” per l’Interrupt Pipe è di 64.000 byte/secondo; equivalenti a 5120000 bit al secondo. Per un maggiore chiarimento si veda la Figura 4.
Figura 4: Frame USB
Nel caso si voglia utilizzare con applicazioni UART, grazie al suo elevato throughput si avrebbe larghezza di banda sufficiente per vari sistemi. Un report HID è utilizzato per trasmettere i dati di controllo da e verso un dispositivo di classe HID. Un “Report Descriptor” (RD) definisce il formato di un rapporto, perciò i report sono strutture di dati definite nei RD dei device HID. Tali strutture possono essere nominate come:
- IN: dati in transito verso l’host;
- OUT: dati in transito fuori dall’host;
- Feature: dati che possono transitare sia da che verso gli host.
I controlli d’input sono fonti di dati rilevanti per l’applicazione come ad esempio i dati X e Y ottenuti da un dispositivo di puntamento ma anche i controlli di output sono molto importanti, basti pensare a un LED che indica lo stato di un dispositivo. Infine, un report “feature” specifica le informazioni di configurazione che indicano lo stato di un dispositivo.
Un’applicazione in modalità utente può ottenere e impostare le informazioni di funzione usando questa tipologia di report. In aggiunta alla direzione che ogni report può prendere, i report descriptor definiscono altre caratteristiche, tra cui grandezza, identificativo (ID - unico per ogni report), utilizzo dei dati (ad esempio nel caso di mouse vengono distinti i byte che contengono i dati relativi all’asse X e quelli relativi all’asse Y). I report di input e di output specificano i dati di controllo, funzionalità e i dati di configurazione. Se un dispositivo supporta più di un report dello stesso tipo, a ogni rapporto viene assegnato un ID unico. Quando un dispositivo ha terminato l’enumerazione con successo, l’host può iniziare l’invio e la ricezione di dati in forma di report; tutti i dati scambiati tra un dispositivo HID e un host devono essere strutturati secondo le specifiche presenti nel RD.
Parte dell’enumerazione HID richiede alla periferica di inviare un descrittore HID, che contiene informazioni su tutti i dati e i suoi formati; il formato del report è determinato dai descrittori inviati all’host. Tutti i rapporti sono preceduti da un ID come riportato in Figura 5; l‘ID è parte grazie alla quale sia l’host che il dispositivo identificano il particolare report e sono in grado di analizzare i dati tra più report. Ogni bit del rapporto è specificato nel report descriptor utilizzando una certa dimensione e un identificatore di conteggio; ad esempio, un report di dimensione uno e un identificatore di conteggio pari a due, identificano due bit, come accade per la definizione di un insieme di pulsanti del mouse; per inviare un byte completo, le dimensioni del report dovrebbe essere impostate a otto. Formattare i dati in report consente di organizzarli in termini di lunghezza in modo tale che gli host e i vari dispositivi connessi sanno come analizzarli e gestirli; ci sono molti usi dei dispositivi HID e tutte le loro definizioni possono essere trovate nel documento “HID Usage Tables Specification”.
Figura 5: Esempio dei bit Report ID
LA CLASSE HID DELLA SILABS
La classe HID allevia il bisogno di scrivere alcun driver lato host e non richiede nessun processo d’installazione, perciò sicuramente è un mezzo interessante per attuare la connettività USB. Quando si utilizza la libreria della Silicon Labs (Silabs) per la classe HID e il suo “template” per i microcontrollori che gestiscono la porta USB, i progettisti possono ridurre al minimo la sforzo dell’implementazione per il dispositivo USB e le applicazioni host. Come viene messo in risalto dalla Figura 6, vengono forniti due strumenti molto utili: l’HID DLL (Dynamic Link Library) e l’HID firmware template.
Figura 6: HID DLL e HID Firmware Template della Silabs
La DLL HID della Silabs:
- Permette ai progettisti di sviluppare applicazioni HID senza l’utilizzo del DDK (Driver Developmet Kit) di Windows
- Incapsula tutte le funzionalità HID all’interno di un oggetto C++
- Permette ai progettisti di dichiarare un’istanza dell’oggetto C++ e assegnarlo a un dispositivo della classe HID
Dopo aver collegato l’istanza di una classe a un particolare device, l’utente è in grado di utilizzare i meccanismi di trasferimento visti precedentemente (Interrupt Pipe e il Control Pipe) mediante una ben precisa e definita API. L’HID firmware template:
- Mette a disposizione varie funzioni per l’enumerazione e il trasferimento di dati a basso livello
- Permette di creare un report handler che assegna ogni report ad un particolare e specifico handler
- Per molte applicazioni il template del firmware va modificato in poche sezioni specifiche per poterlo utilizzare direttamente
- Questo firmware può essere utilizzato con qualsiasi microcontrollore della Silicon Labs
In Figura 7 è riportato uno schema a blocchi di quanto analizzato, in blu sono messi in risalto i moduli template del firmware, che in molte applicazioni non hanno neanche bisogno di essere modificati, mentre in giallo sono riportati i blocchi hardware e software che richiedono un controllo o modifica da parte del progettista. Tutto questo potrebbe essere utilizzato per le applicazioni più disparate come abbiamo visto nella parte introduttiva. Il modello della Silicon Labs contiene il firmware di base per le comunicazioni USB HID, tutte le funzioni di gestione a basso livello di lettura e scrittura dei dati attraverso la porta USB e non richiedono modifiche per la maggior parte delle applicazioni. Per maggiori dettagli e specifiche si faccia riferimento al sito della Silabs.
Figura 7: Schema a blocchi di un progetto firmware per un dispositivo HID
CONCLUSIONI
Come analizzato, la gestione della classe HID USB richiede molte conoscenze e la sua implementazione non è di facile e rapida attuazione, ma con i tool messi a disposizione dalla Silicon Labs lo sviluppo è sicuramente semplificato, infatti, come abbiamo visto, vengono forniti al progettista strumenti generali molto flessibili da poter essere utilizzati in varie applicazioni pratiche semplicemente modificando alcune sezioni specifiche per adattare il software alle proprie esigenze.
