Quattro tipi di trasferimenti
(Segue la spiegazione dei trasferimenti realizzabili: temporaneamente solo i Bulk-Transfer e i Control-Transfer sono completi perchè sono quelli usati dal progetto, gli altri verranno completati in seguito)
I trasferimenti che si possono realizzare sono:
» Control Transfer (Trasferimento di controllo): usati per configurare il dispositivo dopo la connessione e per richiederne informazioni di stato. Un trasferimento di controllo avviene attraverso le "message pipe"; un trasferimento che, ad esempio, mira a mandare una richiesta al dispositivo, si articola nelle seguenti tre TRANSAZIONI:
1) una TRANSAZIONE DI SETUP che comunica una richiesta dall'host alla periferica; è composta dai tre pacchetti mostrati di seguito:
| struttura transazione di SETUP | direzione trasferimento | ||||||
|
OUT | ||||||
|
OUT | ||||||
|
IN |
Ogni riga di queste tabelle forma un pacchetto; per esempio, il primo pacchetto della transazione soprastante è un TOKEN SETUP.
È importante ricordare che il campo dati (del secondo pacchetto) di questa prima transazione ha sempre il PID DATA0.
2) zero o piu TRANSAZIONI DATI che trasportano dati nella direzione indicata dalla precedente transazione di SETUP:
| struttura PRIMA transazione DATI | direzione trasferimento | ||||||
|
OUT | ||||||
|
IN | ||||||
|
OUT |
| struttura SECONDA transazione DATI | direzione trasferimento | ||||||
|
OUT | ||||||
|
IN | ||||||
|
OUT |
Quindi in presenza di più transazioni DATI, vengono trasmessi più pacchetti DATI, ognuno all'interno di una transazione, con PID alterni: si parte da DATA1, segue DATA0, poi ancora DATA1, eccetera eccetera...
3) una TRANSAZIONE DI STATO con la quale la periferica comunica all'host l'esito della richiesta:
| struttura transazione di STATO | direzione trasferimento | ||||||
|
OUT | ||||||
|
OUT | ||||||
|
IN |
Se non ci sono transazioni dati (come per la richiesta SET_ADDRESS), la transazione di stato transita dalla periferica all'host.
Nel pacchetto di SETUP (prima riga) vengono mandate informazioni a un endpoint di controllo di una periferica, la quale deve accettare i DATI e comunicare all'host un ACK, ma se i dati sono corrotti deve scartarli e non rispondere con nessun pacchetto di HANDSHAKE.
La quantita di dati da trasferire nella/e transazioni DATI è definita nella fase di SETUP, e nel caso in cui la quantita di dati supera la wMaxPacketSize allora i dati vengono suddivisi in piu transazioni, nelle quali tutti i pacchetti avranno la massima dimnesione, pari a wMaxPacketSize, mentre l'ultimo pacchetto conterra i bit rimanenti (o sara di lunghezza zero se i dati sono un multiplo esatto di wMaxPacketSize).
Infine la transazione di STATO, che viene trasmessa nella direzione opposta della precedente, usa sempre il PID DATA1.
Se un endpoint di controllo manda un HANDSHAKE STALL nella fase DATI o STATUS di un trasferimento di controllo, deve continuare a inviare STALL nelle successive transazioni finche non riceve un PID SETUP.
Come nei trasferimenti BULK, un endpoint puo mandare un HANDSHAKE NAK se e occupato nel processare la richiesta ricevuta.
Un pacchetto SETUP è composto sempre da 8 byte.
Il numero di byte di DATI UTILI trasferibili con un pacchetto (cioè esclusi i campi SYNC, PID, CRC16 ed EOP) è chiamato payload.
Per un trasferimento di controllo puo essere scelto tra 8, 16, 32, o 64 byte (caratteristica del singolo endpoint).
I tempi di accesso al bus per i trasferimenti di controllo sono gestiti dall'host controller nel miglior modo possibile (in base a varie regole descritte completamente nelle specifiche USB), e non possono essere gestiti a piacere. Perciò la frequenza dei trasferimenti di controllo che avvengono in un frame è limitata, ma questo non crea difficoltà perchè in questo progetto questi trasferimenti vengono usati solo durante la connessione del dispositivo all'host.
Per esempio, il numero di trasferimenti di controllo per frame (in modalita Full-Speed) e limitato a meno di 29 payload dati da 8 byte ciascuna.
La seguente tabella mostra in dettaglio i vari limiti, al variare del payload:
Se un endpoint riceve una transazione di SETUP prima di aver completato un trasferimento di controllo, la periferica ha l'obbligo di anullare il trasferimento corrente e occuparsi della nuova transazione di SETUP.
» Bulk Transfers: usati per grandi quantità di dati, supportano i controlli di errore ma non hanno una latenza garantita. Non sono supportati dai bus Low-Speed.
Un trasferimento BULK è normalmente formato da tre pacchetti, nella successione SETUP -> DATI -> HANDSHAKE (vedi esempio sottostante).
Questi trasferimenti sfruttano quasi tutta la banda disponibile in un modo gestito dall'host controller USB (non c'è quindi possibilità di allocare parte della banda per specifici endpoint).
Inoltre i trasferimenti di controllo hanno priorità inferiore ai trasferimenti Bulk.
Il massimo payload per un endpoint che trasmette in modalità Bulk-Transfer può essere scelto tra 8, 16, 32, o 64 byte; questo valore viene salvato in un campo del descrittore dell'endpoint, chiamato wMaxPacketSize.
Qui sotto c'è l'esempio di una transazione dati BULK che acquisisce i dati dalla periferica (trasferimento in ingresso):
| struttura transazione BULK | direzione trasferimento | ||||||
|
OUT | ||||||
|
IN | ||||||
|
OUT |
Quando l'host è pronto a ricevere dati (trasferimento BULK in ingresso, come nell'esempio) invia una richiesta tramite il TOKEN IN; l'endpoint della periferica risponde inviando dati in un pacchetto DATI o con un pacchetto di HANDSHAKE di tipo NAK (per indicare che non è temporaneamente pronta) o STALL (in tal caso il software USB deve provvedere ad azzerare la condizione di stallo).
Infine, se l'host riceve un pacchetto valido, allora lo comunica alla periferica con un HANDSHAKE ACK, mentre se trova errori non restituisce nessun HANDSHAKE alla periferica.
Viceversa, quando l'host è pronto a trasmettere dati (trasferimento BULK in uscita) manda un pacchetto TOKEN OUT seguito da un pacchetto DATI; se i dati vengono ricevuti senza errore la periferica restituisce all'host un HANDSHAKE ACK (se ha ricevuto il pacchetto DATI senza errori ed è pronta a ricevere il seguente), oppure un NAK (se ha ricevuto il pacchetto DATI senza errori ma se desidera che l'host rimandi tale pacchetto) o STALL (se l'endpoint è in condizione di HALT e non serve che l'host ritenti la trasmissione del pacchetto).
Se il pacchetto dati viene invece ricevuto con errori (controllo CRC16) non viene restituito nessun HANDSHAKE.
La seconda riga della tabella è il pacchetto DATI; se, come detto poco fa, il numero di byte trasferibili superasse il wMaxPacketSize bisognerebbe mandare più pacchetti DATI, alternando il PID per consentire il controllo sugli errori: DATA0 poi DATA1, poi ancora DATA0, poi DATA1, eccetera...
Un endpoint deve sempre trasmettere payload di dati di dimensione minore o uguale al valore impostato nel wMaxPacketSize.
Nel caso un'applicazione richieda la trasmissione, attraverso un endpoint, di una quantità di dati maggiore del payload di tale endpoint allora i dati vengono suddivisi in più parti, ognuna di dimensione massima (wMaxPacketSize) e mandati in sequenza in più pacchetti all'interno della stessa transazione; l'ultimo pacchetto trasporterà la quantità di dati rimanente, o sarà un pacchetto di lunghezza zero per segnalare la fine della trasmissione.
Un trasferimento Bulk si intende completato quando l'endpoint ha trasferito esattamente la quantità di dati aspettata o se trasferisce un pacchetto il cui payload è minore del wMaxPacketSize.
Come mostra la seguente tabella, per esempio, in un frame possono essere trasmessi al massimo 71 payload dati da 8 byte ciascuno.
» Isochronous Transfers: usati per grandi quantità di dati, ma non consentono di avere un controllo sugli errori di trasmissione; hanno però una frequenza di trasmissione costante.
Lo standard USB non definisce uno schema da applicare alla trasmissione dati attraverso questo trasferimento.
Una pipe che utilizza questo trasferimento è unidirezionale.
Il payload dati massimo è limitato a 1023 bytes.
Questo trasferimento non è supportato dai bus Low-Speed.
» Interrupt Transfers: usati per piccole quantità di dati ma con garanzia in termini di latenza.
Il payload massimo è di 64 bytes.
Gli ultimi tre tipi di trasferimenti avvengono sulle "stream pipe".
Riferimenti: www.usb.org
Ultimo aggiornamento: 18 giugno 2011