Interfaccia Usb v1 To v3

Interfaccia
USB
1.0 → 3.0
A.C. Neve – Interfaccia USB 1.0 to 3.0 1

La proliferazione di svariate tipologie di periferiche per PC che si è avuta negli ultimi anni ha
determinato l’esigenza di poter disporre di una interfaccia semplice, economica, veloce e flessibile
per poter rapidamente far uso di queste periferiche.
Nel 1996 Intel, IBM, Compaq, NEC, Microsoft, DEC e Northern Telecom fondarono un consorzio
(USB Implementation Forum) www.usb.org per lo sviluppo di una interfaccia in grado di soddisfare
le richieste del mercato.
Nasce così nel gennaio 1996 la prima versione 1.0 dello standard USB (Universal Serial Bus)
seguita nel 1998 dalla versione 1.1 e nel 2000 da quella 2.0 per finire, nel 2009, con quella 3.0
aventi rispettivamente velocità di:
1.x Low Speed 1.5 Mbps

Full Speed 12 Mbps
2.0 High Speed 480 Mbps
On The Go
3.0 Super Speed 4.8 Gbps
Esiste anche una versione 2.0 On The Go che consente il collegamento tra due dispositivi senza la
presenza dell’host controller per applicazioni dedicate.
Questa interfaccia consente il plug and play cioè la capacità del sistema di riconoscere e configurare
la periferica subito dopo il collegamento e la relativa assegnazione delle necessarie risorse.
É in grado di gestire fino a 127 periferiche fornendo (entro certi limiti) anche l’alimentazione.
La lunghezza massima dei cavi di collegamento è di 5 metri con massimo 5 livelli di Hub.
Consente la connessione e disconnessione a caldo delle periferiche.
Supporta applicazione in tempo reale come voce, audio e video.
Comunicazione asincrona ed isocrona half duplex con pacchetti di varie dimensioni.
Dispone di meccanismi di gestione e recupero degli errori.
É in grado di identificare ed isolare dispositivi non funzionanti.
Caratteristiche generali
L’architettura USB prevede la presenza di un solo Host Controller (detto Root) nel PC in grado di
gestire tutti i devices ad esso collegati secondo una topologia a stella.
I devices invece possono essere di due tipi:
Hub: dispositivi che consentono l’incremento del numero di porte disponibili
Periferiche: dispositivi che svolgono specifiche funzioni ed in grado di usare il protocollo USB.
Host Root
Hub1
Compound Device
Dev1 Dev2 Hub2 Hub3 Dev5
Dev6
Dev3 Dev4

• L’interfaccia USB fa uso di un semplice cavo a quattro fili: due per la alimentazione e due twisted
per il trasporto dei segnali pilotati in modo differenziale ed aventi impedenza di 90 Ω.
Max 5 metri
Rosso VBus
Verde D+
Bianco D-
Nero GND
I dati vengono trasmessi utilizzando una codifica NRZI (Not Return to Zero Invert) con bit stuffing
per assicurare le adeguate transizioni.
Un campo SYNC di 8 bit precede ogni pacchetto per permettere al ricevitore la corretta
sincronizzazione del clock.
L’alimentazione VBus è pari a +5 volt con una corrente massima di 500 mA (2.5 watt).
I cavi sono terminati con opportune resistenze per il riconoscimento del tipo di periferica (Low o
Full Speed) e per il rilevamento della connessione o disconnessione.
• I due estremi del cavo fanno uso di differenti connettori per evitare collegamenti non consentiti.
• Il trasferimento di dati è temporizzato su un periodo base, detto frame, di 1 mSec.

Il protocollo prevede una comunicazione costituita da almeno tre tipi di pacchetti:
Token – Data – Handshake preceduti da uno Start of Frame (SOF).
1 mSec Frame 1 mSec Frame

SOF Token Data Handshake SOF Token Data Handshake
Il primo descrive il tipo e la direzione della transazione, l’indirizzo del device USB ed il numero di
endpoint. L’endpoint è un indirizzo interno al device USB usato per la scrittura o lettura di
informazioni, ve ne possono essere fino a 16 e sono monodirezionali. L’Endpoint 0 è obbligatorio.
L’associazione tra l’host ed un endpoint è detta pipe.
La sorgente selezionata per la transazione invia poi il pacchetto Data di massimo 1023 byte.
Il destinatario risponde infine con un pacchetto di Hanshake per comunicare la corretta ricezione.
All’interno dei pacchetti esistono altri tipi di campi come EOP (End Of Packet), PID (Packet ID),
ADDR (indirizzo), ENDP (Endpoint), CRC (controllo d’errore), NACK (not acknowledge).
Esistono due tipi di pipe dette stream e message: la prima non ha una definita struttura USB mentre
la seconda si.
L’Endpoint 0 viene associato ad una Control Pipe 0 che deve sempre esistere in quanto all’atto della
connessione l’host vi accede per configurare il device.
• Per garantire una corretta protezione dei dati trasmessi, ogni pacchetto include un campo per il
controllo d’errore, ed in alcuni casi, con la disponibilità di richiesta di ritrasmissione.
Il protocollo include separati CRC per i campi dati e controlli di ogni pacchetto.
Il CRC usato garantisce il 100% di sicurezza per errori su bit singoli e doppi.
In caso di errore l’host effettua fino a tre tentativi di ritrasmissione.
• Lo standard USB consente la connessione o disconnessione dei devices in qualsiasi istante.

Nella maggior parte dei casi ciò avviene per mezzo di un hub.
All’atto della connessione l’hub comunica l’evento all’host indicando la porta usata per la
connessione. L’host abilita la porta ed indirizza il device con un indirizzo di default abilitando una
pipe di controllo. L’host determina se il nuovo dispositivo collegato è un hub o una periferica e vi
assegna uno specifico indirizzo. Successivamente attiva una pipe di controllo con l’Endpoint 0.

Se il device collegato è un hub con delle periferiche connesse, la procedura descritta viene poi
ripetuta per ognuna delle periferiche.
Quando una periferica viene rimossa da una delle porte, l’hub automaticamente disabilita la porta e
comunica l’avvenuta rimozione all’host. Successivamente l’host elimina tutte le informazioni usate
per la gestione di quella periferica.
Se invece il distacco è relativo ad un hub, il processo di eliminazione si estende a tutte le periferiche
precedentemente collegate a quell’hub.
• L’attività di Bus enumeration identifica ed indirizza tutti i devices collegati al bus, queste
operazioni vengono effettuate allo startup con una memorizzazione in tabelle di tipo statico.
Essendo i devices collegabili e scollegabili in ogni istante, l’attività descritta è di tipo dinamico.
L’attività di Bus enumeration include anche gli altri processi conseguenti all’attacco e distacco.
• Dal punto di vista logico tutte le periferiche risultano allo stesso livello e, per mezzo del software
USB di sistema, l’utente vede solo le loro funzioni.
Essendo le comunicazioni sul bus gestite dal software di sistema, queste risultano indipendenti dai
programmi applicativi.
Lo stack software può essere così modellizato:
HOST DEVICE
Pipe
Client SW Funzione Livello
Applicazione funzione
Default pipe
Software USB (Endpoint 0) Livello
Periferica
di sistema logica USB periferica
logica
Interfaccia al Livello
USB Host
bus USB interfaccia
Controller
Cavo USB
Livello Per l’host è il software applicativo

funzione Per la periferica sono le funzioni espletate
Livello Per l’host è il software USB di sistema
periferica logica Per la periferica è il software di controllo del flusso
Livello É l’hardware di gestione della serializzazione dei pacchetti
interfaccia
Il trasferimento dei dati avviene tra il software dell’host ed uno specifico endpoint del device.

Ogni device è in grado di gestire trasferimenti tra diversi endpoint e l’host tratta i vari endpoint del
device in modo indipendente. Le associazioni tra il software dell’host ed i vari endpoint del device
sono dette pipe.
L’architettura USB prevede quattro tipi di modalità di trasferimento dati:
Control transfers É usato per configurare un device dopo il suo iniziale collegamento
Utilizza il 10% della banda utile.
Bulk data transfers É il trasferimento, in modalità burst (sequenziale), di grandi quantità di
blocchi di dati che non hanno vincoli temporali tra loro (stampanti,
scanner ecc). Per la trasmissione viene concessa tutta la banda disponibile.
Viene usato un controllo d’errore in hardware e la ritrasmissione.
Interrupt data L’host, in qualità di master, effettua periodicamente il polling sulle varie
transfers periferiche per verificare la presenza di richieste di asservimento.
Generalmente si tratta di piccole quantità di dati senza un definito timing
rate come nei mouse.Viene usato il 90% della banda utile con controllo
d’errore.
Isocronous or É usato per il trasferimento di dati che devono arrivare con la stessa
streaming cadenza temporale con la quale sono stati generati per cui è necessaria una
real data transfers prenegoziazione della banda necessaria. (audio, video, telefonia ecc.).
Ogni errore in trasmissione non può essere corretto ne ritrasmesso.
• Tutti i devices USB sono utilizzabili per mezzo di un proprio univoco indirizzo.
In più, ogni devices USB dispone di alcuni endpoint con i quali l’host può comunicare.
Tutti i devices USB devono disporre di un particolare endpoint detto Endpoint 0 al quale è collegata
la Control Pipe. Tutti i devices USB supportano un comune metodo di accesso all’Endpoint 0.
L’endpoint 0 contiene tutte le informazioni necessarie alla completa caratterizzazione e
configurazione del device.
• Le due principali classi di devices USB sono Hub e Function (Periferiche).
Gli hub sono dei concentratori che consentono la connessione di più dispositivi USB.
Più hub possono essere collegati in cascata. La porta di upstream viene connessa all’host.
Port 1 Port 2 Port 3
Upstream
H
HOST Port Hub Hub
Repeater Controller U
B
Port 6 Port 5 Port 4
Le altre porte dell’hub (downstream) possono essere connesse ad altri hub o periferiche.
Gli hub sono in grado di rilevare la connessione o disconnessione di devices sulle loro porte e
provvedere alla distribuzione dell’alimentazione.
Ogni porta può essere singolarmente abilitata e configurata in modo Full Speed o Low Speed.
Tutti gli hub sono costituiti da due parti: Hub Controller ed Hub Repeater.
Il repeater gestisce il protocollo tra la porta di upstream e le porte di downstream come anche i
segnali di reset, di sospensione e di riabilitazione.
Il controller gestisce invece i registri di interfaccia per consentire la comunicazione da o per l’host.

I comandi di stato e di controllo consentono all’host di configurare un hub e di monitorare e
controllare le sue porte.
La periferiche (function) sono dei dispositivi in grado di trasmettere o ricevere dati o informazioni
di controllo e sono collegate con un cavo ad una delle porte di downstream.
É possibile inserire all’interno di un unico contenitore più periferiche che vengono gestite da un hub
embedded e connesse da un unico cavo. Questi dispositivi sono detti compound.
Un dispositivo compound è visto dall’host come un hub al quale sono permanentemente connessi
più dispositivi.
Ogni dispositivo contiene delle informazioni che descrivono le sue caratteristiche e le risorse
necessarie per il suo funzionamento. I più comuni descrittori sono:
Device: indica il costruttore, la versione USB, la massima grandezza dei pacchetti per l’Endpoint 0.
Configuration: indica il tipo di alimentazione (da Bus o esterna),la corrente assorbita e le interfacce.
Interface: indica il numero di endpoint di ogni interfaccia.
Endpoint: per ogni endpoint indica il tipo di trasferimento usato, la dimensione dei pacchetti, la
direzione, il timing per il polling.
Prima che un dispositivo possa essere usato deve essere configurato dall’host per mezzo
dell’assegnazione delle necessarie risorse.
• Un host interagisce in hardware con i devices per mezzo dell’host controller che provvede alle
seguenti azioni:
rilevazione della connessione e disconnessione dei dispositivi

controllo di flusso tra host e device
gestione del flusso dati tra host e device
memorizzazione statistica degli stati e delle attività
gestione dell’alimentazione dei vari devices
via software invece gestisce le seguenti azioni:
configurazione e assegnazione degli indirizzi dei devices

trasferimento isocrono dei dati
trasferimento asincrono dei dati
gestione dell’alimentazione
gestione delle informazioni sui devices e del bus.

Modello di flusso dati
Lo standard USB consente la comunicazione tra un Host USB ed un Device USB.
Con riferimento alla figura illustrativa del modello a stack, è possibile individuare quattro
importanti sezioni:
Device fisico: una parte dell’hardware della periferica avente specifiche funzioni.
Client software: software applicativo, gestito dal sistema operativo, che comunica con il device.
Software USB di sistema: software che gestisce l’interfaccia USB sotto il sistema operativo
indipendentemente dal particolare device e software applicativo.
USB host controller: Insieme di hardware e software per la gestione del device collegato.
Dal punto di vista topologico l’interfaccia USB è costituita da quattro parti principali:
Host e Device: sono i principali componenti di un sistema USB

Topologia fisica: descrive come i componenti sono connessi
Topologia logica: descrive i ruoli delle varie parti USB e come vengono viste da host e device
Relazione tra software applicativo e periferica: descrive come il software applicativo si interfaccia
con il device.
Dal punto di vista fisico la topologia USB è di tipo a stella (o meglio ad albero se ci sono gli hub).
Dal punto di vista logico invece ogni device viene considerato direttamente connesso all’host.
Host Root
Compound Device
Dev5
Dev1
Dev6
Dev2
Dev3 Dev4
Infine, nell’ambito della relazione esistente tra software applicativo e periferica, il legame esistente
è unico tra i due elementi ed indipendente dagli altri dispositivi connessi al bus.
SW SW SW SW SW SW
client 1 client 2 client 3 client 4 client 5 client 6
Dev1 Dev6
Dev2 Dev5
Dev3 Dev4

Flusso di comunicazione
L’interfaccia gestisce il flusso di comunicazione tra il software applicativo e la periferica USB.

Dato che ogni periferica può avere diverse modalità di flusso di comunicazione con il proprio
software applicativo, l’interfaccia USB provvede alla migliore utilizzazione del bus per ottimizzare
i differenti flussi di comunicazione.
Ogni flusso di comunicazione termina su uno specifico endpoint del device il quale caratterizza i
vari aspetti della comunicazione.
Un device logico appare al sistema USB come un insieme di endpoint.
Il software di sistema USB gestisce il device per mezzo della Default Pipe associata all’Endpoint 0.
L’host controller organizza i dati in pacchetti e gestisce l’accesso al bus per il loro trasferimento.
• Un endpoint è una parte, univocamente identificabile, di un device USB e rappresenta il punto

finale di una comunicazione tra l’host e il device. Ogni device è composto da un insieme (max 16)
di endpoint indipendenti, che consentono al software di comunicare con il device.
Ricordando che ogni devices ha un proprio indirizzo assegnato dall’host all’atto della connessione,
l’insieme di questo indirizzo e del numero di endpoint, rendono univocamente identificabile ogni
endpoint. Gli endpoint non possono essere utilizzati dall’host prima di essere configurati.
Ogni endpoint è caratterizzato dalle seguenti informazioni:
numero di endpoint
ampiezza di banda richiesta
frequenza di accesso al bus
modalità di gestione degli errori
dimensione massima dei pacchetti trasferibili
tipo di trasferimento
direzione del trasferimento (bulk e isocrono)
Tutti i devices USB devono disporre di un particolare endpoint detto Endpoint 0 che viene utilizzato
dall’host per inizializzare, configurare e controllare l’accesso al device stesso.
Questo endpoint è sempre disponibile una volta che il device è collegato.
Endpoint addizionali possono essere presenti in un device USB. Massimo 2 per il tipo Low Speed e
fino a 16 per il tipo Full Speed. Gli endpoint aggiuntivi vengono configurati durante il normale
processo di configurazione del device.
• Una pipe è una associazione tra un endpoint di un device ed il software dell’host e consente il
trasferimento di dati tra i due.
Sono possibili due modi di comunicazione mutuamente esclusivi:
Stream: i dati trasferiti attraverso la pipe non hanno una struttura USB
Message: i dati trasferiti attraverso la pipe hanno una struttura USB
Le pipe vengono attivate una volta che il device è configurato.

Poichè l’Endpoint 0 è sempre configurato, esisterà sempre una pipe per questo endpoint che viene
chiamata Default Pipe. Questa pipe è usata dal software di sistema per trasferire le informazioni
necessarie a identificare, caratterizzare e configurate il device.
La Default Pipe, di proprietà del software di sistema, può anche essere usata successivamente alla
configurazione del device dal software applicativo.
Normalmente un software applicativo richiede un trasferimento dati per mezzo di un I/O Request
Packets (IRPs) attraverso una pipe.

Una stream pipe consegna le informazioni in un pacchetto dati senza interessarsi della loro struttura.
I dati fluiscono da un estremo all’altro della pipe secondo la sequenza ordinata first-in first-out.
Una stream pipe collegata ad un device è relativa ad un unico endpoint unidirezionale.
Una stream pipe supporta modalità di trasferimento tipo bulk, isocrono e interrupt.
Una message pipe opera invece in modo differente.

Inizialmente l’host invia una richiesta al device USB, successivamente si ha il trasferimento dei dati
nella opportuna direzione, infine l’endpoint risponde con un messaggio di stato.
É evidente che ora lo scambio deve avvenire secondo una specifica ed affidabile struttura.
Una message pipe consente una comunicazione in entrambe le direzioni.
La pipe per l’Endpoint 0 (Default Pipe) è sempre una message pipe.
Il software di sistema assicura che non siano inviate richieste multiple all’endpoint in uso in quanto
un endpoint può asservire una sola richiesta per volta.
Richieste successive a quella in corso saranno disposte in coda di attesa.
In caso di errore il trasferimento in corso sarà abortito dall’host e si passerà all’asservimento della
successiva richiesta.
Una message pipe verso un device, fa uso di un singolo endpoint per entrambe le direzioni.
Tipologie di trasferimento
• In un sistema USB, i dati, organizzati in pacchetti e opportunamente strutturati, sono movimentati

per mezzo di una pipe che collega un buffer di memoria associato al software applicativo presente
sull’host con un endpoint del device.
Lo standard USB dispone di differenti modi di trasferimento per poter meglio soddisfare i sevizi
richiesti dal software applicativo e dal device e che restano inalterati per tutto il tempo di
attivazione della pipe.
I sistemi USB consentono quattro modalità di trasferimento:

Control – Isocrono – Interrupt – Bulk
Control Transfers
• Il trasferimento control è usato per l’invio di comandi, configurazioni, e informazioni di stato

utilizzando l’Endpoint 0 e la pipe di controllo.
Per il modo di trasferimento control, l’endpoint specifica la massima dimensione del pacchetto dati
di controllo (payload) che risulta di 8 byte per i devices Low Speed e di 8,16,32,64 byte per i
devices Full Speed.
Per tutti i tipi di devices il pacchetto di setup è di 8 byte.
Dopo un reset, tutti gli endpoint di controllo devono poter accettare un payload di 8 byte anche se
questo è stato progettato per supportare payload di maggiori dimensioni.
Il payload trasmesso non deve necessariamente avere una dimensione pari a quella massima
supportata dall’endpoint e, nel caso in cui risultasse minore, non necessita di aggiunta di zeri
(padding) per uguagliare la massima dimensione.
Tutti gli host controller devono poter supportare una dimensione del payload uguale a quella
dell’endpoint (Low o Full Speed).
Durante il processo di configurazione, il software di sistema USB legge dall’endpoint il valore della
massima dimensione del payload usato ed assicura che il pacchetto inviato non superi questa
dimensione.
Un endpoint deve sempre trasmettere pacchetti con un campo dati di dimensione minore o uguale al
suo MaxPacketSize in caso contrario il trasferimento sarà abortito e la pipe andrà in stallo finché
non si effettuerà la correzione e la conferma.

• Un endpoint non ha alcun modo di indicare la desiderata frequenza di accesso al bus per cui il
sistema USB cerca di bilanciare le richieste di accesso di tutte le control pipe e delle IRP per
soddisfare nel miglior modo possibile lo scambio di dati tra il software applicativo e i devices.
Se il trasferimento in corso utilizza meno del 10% del tempo di frame (frame time), il tempo
restante può essere usato per un trasferimento bulk.
La ripetizione di un trasferimento può essere effettuata nel frame corrente o nel successivo.
Se il tempo disponibile è minore di quello necessario per il trasferimento di controlli ma ci sono dei
frame time non usati da trasferimenti isocroni o interrupt, l’host provvede al trasferimento dei
controlli in attesa.
La frequenza di bus e la temporizzazione dei frame limitano il massimo numero di trasferimenti di

controllo realizzabili a meno di 29 con payload da 8 byte per il tipo Full Speed e meno di 4 con
payload da 8 byte per il tipo Low Speed.
I sistemi USB dispongono di un buon sistema di rilevazione degli errori e della loro ritrasmissione
durante il trasferimento dei controlli. Il protocollo consente la distinzione tra il pacchetto
ritrasmesso ed il suo originale ad eccezione di quello di setup.
Isochronous transfers
Il trasferimento isocrono ha le seguenti caratteristiche:
garantisce un accesso alla banda USB con un limitato tempo di latenza

garantisce un costante data rate attraverso la pipe indipendentemente dalla dimensione dei dati
in caso di errore non si ha la ritrasmissione dei dati
Mentre il trasferimento isocrono è progettato per supportare sorgenti e destinatari isocroni, ciò non
è necessario per il software utilizzato.
Una pipe isocrona è sempre unidirezionale. La descrizione dell’endpoint definisce l’ingresso o

l’uscita del flusso dati dall’host. Se il device necessita di una comunicazione bidirezionale, sarà
necessario utilizzare due separate pipe per ognuna delle due direzioni.
Un endpoint configurato per una pipe isocrona specifica anche la massima dimensione del payload
trasferibile. Il sistema USB usa questa informazione per assicurare un sufficiente bus time ai frame
di trasporto. Se il bus time è sufficiente la configurazione è stabilita altrimenti no.
Il sistema USB limita a 1023 byte la massima dimensione del payload per ogni pipe isocrona.
La dimensione del payload trasferito in un certo periodo può essere anche minore di quella
massima prenegoziata. Un errore di trasmissione può modificare la dimensione del payload ricevuto
ma questo fatto sarà rilevato dal controllo CRC.
Il trasferimento isocrono può essere usato solo dai devices Full Speed.
Il sistema USB impone che non più del 90% di ogni frame sia allocato per trasferimenti periodici.
Un endpoint per una pipe isocrona non contiene informazioni circa la frequenza di accesso al bus.
Tutte le pipe isocrone trasferiscono un pacchetto di dati per ogni frame ogni 1 mSec.
La frequenza di bus e la temporizzazione dei frame limitano il massimo numero di trasferimenti

isocroni realizzabili a meno di 151 con payload da 1 byte per il tipo Full Speed.

Il trasferimento isocrono non supporta la ritrasmissione dei dati in caso di errore anche se il
ricevitore è in grado di rilevare l’errore.
Nei trasferimenti isocroni il rispetto delle temporizzazioni è più importante della rilevazione e
ritrasmissione dei dati errati per cui ci si aspetta un basso tasso d’errore sul bus.
Se un errore è rilevato, l’host continua il processo di associazione dei dati al successivo frame.
Interrupt transfers
Il trasferimento su base interrupt è progettato per quei devices che trasmettono sporadicamente e in
istanti non prevedibili piccole quantità di dati.
Il trasferimento interrupt ha le seguenti caratteristiche:
garantisce alle pipe il massimo periodo di servizio

in caso di errore, la ripetizione del trasferimento avviene nel successivo periodo.
Una interrupt pipe è sempre unidirezionale ed è sempre in ingresso all’host.

Un endpoint configurato per una interrupt pipe specifica anche la massima dimensione del payload
del pacchetto dati che può essere trasferito il cui valore è di 64 byte per i devices Full Speed mentre
è di 8 byte per i devices Low Speed.
Se il pacchetto dati è minore del massimo, non è necessario effettuare il padding.
Le medesime dimensioni devono essere disponibili da parte dell’host controller.
Queste dimensioni restano costanti per tutta la durata della configurazione del device.
Il software di sistema USB usa questi massimi valori per assicurare un sufficiente bus time, se ciò è
possibile la pipe viene attivata altrimenti no.
Un payload di dimensioni superiori può essere trasferito per mezzo di transizioni multiple per le
quali ogni payload dovrà avere una dimensione pari alla massima tranne l’ultimo che potrà essere
più piccolo.
Nel caso di ricezione di un payload di dimensioni superiori a quelle consentite, il trasferimento sarà
abortito e la pipe messa in stallo fino al ripristino della condizione.
Il trasferimento interrupt può essere usato dai devices Low Speed e Ful Speed.
Come per il trasferimento isocrono, anche per questo tipo di trasferimento il sistema USB impone
che non più del 90% di ogni frame sia allocato per trasferimenti periodici.

interrupt realizzabili a meno di 108 con payload da 1 byte per il tipo Full Speed e meno di 14 con
payload da 1 byte per il tipo Low Speed.
Un endpoint per una pipe interrupt dichiara anche il suo necessario periodo di accesso al bus:
un endpoint Full Speed può specificare un periodo compreso tra 1 e 255 mSec mentre uno Low
Speed tra 10 e 255 mSec. Il periodo assegnato dal sistema sarà compreso tra i due estremi.
La gestione degli interrupt degli endpoint è di tipo polling.
Bulk Transfers
Il trasferimento bulk è progettato per devices che necessitano di trasferire grandi quantità di dati in
tempi altamente variabili in funzione della disponibilità di banda.
Il trasferimento bulk ha le seguenti caratteristiche:
accesso al bus in funzione della disponibilità di banda

ripetizione del trasferimento in caso di errore

garantisce la consegna dei dati ma non la banda o i tempi di risposta.
Nel caso di ampia disponibilità di banda, il trasferimento bulk risulta abbastanza veloce mentre nel
caso di limitata disponibilità di banda, il trasferimento bulk potrà essere spezzettato su lunghi
periodi di tempo.
Una pipe bulk è sempre unidirezionale, nel caso in cui il device necessiti di una comunicazione
bidirezionale sarà necessario attivare due pipe bulk per le due direzioni.
Un endpoint configurato per una bulk pipe specifica anche la massima dimensione del payload del
pacchetto dati che può essere trasferito attraverso il bus il cui valore può essere solo di 8, 16, 32 o
64 byte. Se il pacchetto dati è minore del massimo, non è necessario effettuare il padding.
Un payload di dimensioni superiori può essere trasferito per mezzo di transizioni multiple per le
quali ogni payload dovrà avere una dimensione pari alla massima tranne l’ultimo che potrà essere
più piccolo. Nel caso di ricezione di un payload di dimensioni superiori a quelle consentite, la pipe
sarà posta in stallo ed il trasferimento sarà abortito
Il trasferimento bulk può essere usato solo da device di tipo Full Speed.
Un endpoint di una pipe bulk non ha modo di indicare una specifico valore della frequenza di
accesso al bus per cui il sistema USB cercherà di soddisfare le richieste nel modo migliore.
I trasferimenti control hanno priorità sui trasferimenti bulk.
Solo nel caso in cui vi sia una sufficiente ampiezza di banda e dei frame time non usati, questi
vengono assegnati ai trasferimenti bulk.
Più trasferimenti bulk in attesa di un frame time disponibile saranno selezionati secondo criteri
dipendenti dalla direzione e dal system software USB.
Un endpoint ed il suo relativo software applicativo non possono definire alcuna velocità operativa
per il trasferimento bulk in quanto la disponibilità di frame time può cambiare in funzione
dell’inserimento o distacco di altri devices o di altre richieste di trasferimenti bulk.

bulk realizzabili a meno di 728 byte per payload.
Transfer Management
Si dice transfer management il processo di assegnazione della banda ai vari devices.

Nell’host vi sono varie entità che coordinano il flusso delle informazioni sul bus:
Software applicativo: utilizza e genera specifici dati da o per l’endpoint per mezzo delle IRP.
USB Driver: converte i dati in IRP da o per l’endpoint. Un singolo IRP può coinvolgere uno o più
trasferimenti.
Host Controller Driver: converte gli IRP da o per la transizione e gli organizza per la
manipolazione dell’host controller. L’interazione tra l’host controller driver ed il suo hardware non
dipende dalle specifiche USB ma dalla sua implementazione.
Host Controller: gestisce le transizioni e le attività del bus per mezzo dei pacchetti usati per il
trasporto dei dati attraverso il bus per ogni transizione.

Caratteristiche meccaniche
Esistono diversi tipi di connettori USB: serie A, serie
B, serie B mini a 4 e 5 contatti e serie micro.
La serie A è generalmente usata per quei devices che
hanno il cavo permanentemente collegato al device
stesso come tastiere, mouse e hub.
La serie B è invece usata per quei devices che hanno un
connettore esterno e sono scollegabili come le
stampanti.
La serie B mini è usata da dispositivi di piccole

dimensioni come apparecchi fotografici o cellulari.
Tutti i connettori non hanno sistemi di bloccaggio.

Lo standard non descrive le parti interne del connettore.
2 1
3 4
1 2 3 4
Serie A Serie B
PIN Nome Colore Note

1 VBus Rosso +5 volt 500 mA
2 D- Bianco Data +
3 D+ Verde Data –
4 GND Nero Ground
Il cavo USB è costituito da una coppia di fili con AWG (American Wire Gauge) 20-28 per la
distribuzione dell’alimentazione ed una coppia di fili twisted con AWG 28 schermati ed incapsulati
in una guaina. Il periodo di twisted è compreso tra 6 e 8 centimetri.
Il cavo deve essere in grado di resistere a strappi di minimo 45 Newton.
Lo schermo del connettore deve essere collegato al piedino GND.
La resistenza elettrica dei cavi formanti la coppia non può differire di più del 5%.
L’impedenza caratteristica della coppia di cavi dovrà essere di 90Ω ±15% nell’intervallo di
frequenze compreso tra 1 e 16 MHz.
Il tempo di propagazione dei segnali dovrà risultare minore o uguale a 30 nSec nell’intervallo di
frequenze compreso tra 1 e 16 MHz.
Gauge Diametro filo Resistenza DC Lunghezza max

28 AWG 0.84 ±0.05 mm 0.232 Ω/m 0.81 m
26 AWG 1.00 ±0.05 mm 0.145 Ω/m 1.31 m
24 AWG 1.10 ±0.07 mm 0.0909 Ω/m 2.08 m
22 AWG 1.30 ±0.07 mm 0.0574 Ω/m 3.33 m
20 AWG 1.50 ±0.08 mm 0.0358 Ω/m 5.00 m

Caratteristiche elettriche
Nello standard USB la comunicazione avviene per mezzo di driver differenziali.
In condizioni statiche i due stati low e high sono caratterizzati dai seguenti livelli:
VOL minore di 0.3 volt con un carico da 1.5 KΩ collegato a 3.6 volt
VOH maggiore di 2.8 volt (fino a 3.6 volt) con un carico di 1.5 KΩ collegato a massa.
Le uscite del driver sono 3-state per consentire la comunicazione bidirezionale half duplex.
Lo slew rate del driver deve essere controllato per contenere il cross talk e il rumore irradiato.
Sulle linee di segnale il driver ed il receiver devono poter sopportare senza danni una tensione
compresa tra –0.5 volt e +3.8 volt per 10 µSec durante la comunicazione o per un tempo indefinito
nella condizione 3-state.
Una connessione Full Speed è realizzata per mezzo di una coppia di cavi twisted con impedenza
caratteristica Z0 di 90Ω ed una lunghezza massima di 5 metri.
L’impedenza interna di ognuno dei driver deve essere compresa tra 29Ω e 44Ω.
I tempi di salita e discesa dei segnali di dati dovranno essere compresi tra 4n Sec e 20 nSec.
il circuito proposto illustra una tipica realizzazione del driver.
la figura proposta illustra le forme d’onda dei segnali.
Le caratteristiche del driver restano le stesse per l’utilizzo in modo Low Speed.
Il circuito di ricezione, anch’esso di tipo differenziale, dovrà avere una sensibilità di almeno 200
mVolt quando entrambe le due linee sono nel range 0.8 ÷ 2.5 volt rispetto a massa.

Una connessione USB viene sempre terminata come esposto nella figura seguente:
I devices Low Speed e Full Speed differiscono per il diverso collegamento della resistenza di pull-
up sull’estremo finale (downstream) del cavo.
I devices Full Speed sono terminati con una resistenza di pull-up sulla linea D+ mentre
i devices Low Speed sono terminati con una resistenza di pull-up sulla linea D–.
La resistenza di pull-up ha un valore di 1.5 KΩ ±5% ed è collegata ad una tensione compresa tra 3.0
e 3.6 volt rispetto a massa.
Le resistenze di pull-down, dal lato upstream, sono da 15 KΩ ±5% e collegate a massa.
Stato del BUS Livelli dei segnali

Differential 1 (D+) – (D-) > 200 mV con D+ o D- > VSE(min)
Differential 0 (D+) – (D-) < 200 mV con D+ o D- > VSE(min)
Stato J:
Low Speed Differential 0
Full Speed Differential 1
Stato K:
Low Speed Differential 1
Full Speed Differential 0
Stato Idle:
Low Speed Differential 0 con D– > VSE(max) e D+ < VSE(min)
Full Speed Differential 1 con D+ > VSE(max) e D– < VSE(min)
Stato Resume:
Low Speed Differential 1 con D+ > VSE(max) e D– < VSE(min)
Full Speed Differential 0 con D– > VSE(max) e D+ < VSE(min)
Start of Packet (SOP) Le linee dati commutano dallo stato Idle in quello K
Driver: D+ e D– < VSE(min) per 2 bit Receiver: D+ e D– < VSE(min) per un tempo
End of Packet (EOP) time seguiti da un Idle per 1 bit time ≥ di un bit time seguito da uno stato J
Disconnessione (lato upstream) D+ e D– < VSE(max) per t ≥ 2.5 µSec
Connessione (lato upstream) D+ e D– > VSE(max) per t ≥ 2.5 µSec
Reset (lato downstream) Driver: Receiver:
D+ e D– < VSE(max) per t ≥ 10 mSec D+ e D– < VSE(max) per t ≥ 2.5 µSec
VSE = single ended receiver threshold (min = 0.8 volt, max = 2.0 volt)
Gli stati J e K sono due livelli logici usati per comunicare dati differenziali.
Gli stati Idle e Resume sono logicamente equivalenti agli stati J e K.
Si noti che gli stati J, K, Idle e Resume dipendono dal tipo di devices collegato (Low o Full Speed).

Connessione e disconnessione
Come si può notare dal circuito precedente, il cavo USB presenta delle resistenze di pull-down dal
lato host e una resistenza di pull-up dal lato device.
Il collegamento di questa ultima resistenza definisce il tipo di device connesso: i devices Full Speed
hanno la resistenza di pull-up collegata alla linea D+ mentre quelli Low Speed hanno la resistenza
di pull-up collegata alla linea D–.
Nel caso in cui il cavo sia collegato dal lato host ma non dal lato device, le due linee D+ e D– sono
a massa, questo stato è detto Idle.
Quando al cavo è anche collegato un device, attraverso il partitore R1 R2 si viene a formare un
livello di tensione superiore a VSE(max) su una sola delle due linee D+ o D– e rispettivamente su
D+ per un device Low Speed o su D– per un device Full Speed.
Se questa condizione permane per più di 2.5 µSec, l’host riconosce la connessione del device.
Si rammenta che device e hub sono dispositivi passivi per cui non sono in grado di comunicare
l’avvenuta connessione, è quindi l’host che periodicamente interroga il dispositivo per determinare
una eventuale nuova connessione.
In caso di disconnessione, la tensione sulla linea interessata tornerà a zero.
Se la tensione scende al di sotto del valore VSE(min) per più di 2.5 µSec, l’host considererà il device
disconnesso.

Struttura dei segnali di dati
Come già detto la trasmissione dei segnali avviene per mezzo di segnali differenziali.
Un 1 è rappresentato da un livello della linea D+ più positivo di almeno 200 mV rispetto a D–
Uno 0 è rappresentato da un livello della linea D– più positivo di almeno 200 mV rispetto a D+.
Il livello di incrocio dei due segnali deve essere tra 1.3 e 2.0 volt.
L’inizio di un pacchetto (SOP) è segnalato dalla commutazione delle linee D+ e D– dallo stato di
idle in quello opposto K. Questa commutazione rappresenta il primo bit del campo SYNC.
La fine di un pacchetto (EOP) è indicata da uno stato 0 single-ended per due bit time seguito da uno
stato idle per un bit time e dal successivo passaggio in 3-state del driver.
Lo stato 0 single-ended è indicato dalla presenza di un livello di tensione minore di 0.8 volt su
entrambe le linee D+ e D–.
Segnale di reset
Un segnale di reset è generato da un host controller o un hub verso un device per mezzo di uno stato
single-ended 0 della durata di almeno 10 mSec.
Dopo la rimozione di un reset, il device sarà ancora connesso ma non ancora indirizzato e
configurato.
Un device attivo, vedendo un single-ended 0 sulla sua porta di upstream per più di 2.5 µSec, potrà
considerare questo segnale come un reset solo dopo 5.5 µSec.
Un hub con bus alimentato che riceve un reset sulla sua porta di upstream, rimuove l’alimentazione
da tutte le sue porte di downstream e le disabilita.
Gli hub devono essere capaci di stabilire una connessione e tutti i devices devono essere capaci ci
accettare un indirizzo per mezzo del SET_ADDRESS command non più tardi di 10 mSec dalla
rimozione del segnale di reset.

Segnale di sospensione
Tutti i devices devono poter eseguire il comando di sospensione in qualsiasi stato si trovino.
Si passa nel modo sospensione quando uno stato di idle si presenta sulle linee del bus per più di 3
mSec. Una qualsiasi attività del bus rimuoverà lo stato di sospensione del device.
Quando un device è nello stato di sospensione dovrà assorbire dal bus meno di 500 µA.
Il comando di sospensione può essere globale o selettivo a secondo che agisca su tutti i devices
della rete o solo su alcuni rami della rete.
Segnale di resume
Quando un device è nello stato di sospensione può ritornare attivo (resumed) ricevendo da un host
un qualsiasi segnale che non sia un idle.
L’host dovrà inviare il segnale di resume per almeno 20 mSec seguito da un pacchetto standard
EOP di tipo Low Speed.
Al termine della segnalazione del resume, il device pone le sue linee di dati in 3-state.
Un hub che riceve un segnale di resume, propagherà questo segnale su tutte le sue porte di
downstream entro 50 µSec.
Delay e Turnaround
Premesso che è consentita una sola transizione per volta su un cavo USB.
In considerazione del fatto che la transizione di un segnale Full Speed si deve propagare fino alla
fine del cavo, ritornare ed assestarsi entro un bit time (80 nSec), il massimo ritardo di propagazione
consentito risulterà di 30 nSec.
Indipendentemente dalla velocità di propagazione, la lunghezza massima del cavo sarà di 5 m per il
modo Full Speed e di 3 m per quello Low Speed.
Un nuovo device non può iniziare a pilotare il bus finché il precedente device non avrà completato
la sequenza EOP e disabilitato il suo driver e cioè fino a quando il nuovo device non avrà rilevato
che il bus è nello stato J dopo un SE0 per almeno due bit time.
Se un device è in attesa di rispondere alla trasmissione dell’host, questa risposta deve arrivare sul
lato upstream del cavo entro 7.5 bit time prima del ritorno nello stato J dopo un SE0.
Il massimo tempo di turnaround di un bus Full Speed prevede un time out di 16 bit time.
Il massimo ritardo che un host ha per rispondere a un pacchetto inviato da un device è di 7.5 bit
time.
Un device in attesa di risposta non andrà in time out prima di 16 bit time e non dopo 18 bit time.
Un host non inizierà la trasmissione di un token per la successiva transizione prima di 18 bit time
dopo aver rilevato la fine del pacchetto senza risposta.
Nel collegamento in cascata di più hub fino ad un device il massimo ritardo di propagazione tra gli
estremi è di 70 nSec.

Protocollo
I bit sono inviati sul bus iniziando dall’LSB e finendo con l’MSB.
Campo SYNC
Tutti i pacchetti iniziano con un campo SYNC di sincronizzazione.

Il campo SYNC compare sul bus come una stato idle seguito da una sequenza KJKJKJKK espressa
in codifica NRZI (Not Return to Zero Invert). Questo campo ha il solo compito di sincronizzare i
dati in arrivo con il clock locale ed è costituito da otto bit.
Gli ultimi due bit del campo SYNC rappresentano un marcatore usato per identificare il primo bit
successivo campo PID.
Per migliorare la chiarezza, nelle successive rappresentazioni i bit sono visualizzati senza le
codifiche NRZI e bit stuffing.
Le transizioni sul bus sono costituite dalla sequenza dei pacchetti Token, Data, Handshake.
Tutti i pacchetti hanno dei delimitatori di inizio e fine (SOP ed EOP).
Il delimitatore SOP fa parte del pacchetto SYNC.
Campo di identificazione del pacchetto
In ogni pacchetto USB, il campo SYNC è seguito dal pacchetto di identificazione (PID).
Il pacchetto PID, fatto da 8 bit, è costituito da 4 bit che ne identificano il tipo più 4 bit di check
uguali ai precedenti ma complementati al fine così di assicurare l’affidabilità della decodifica.
La ricezione di un PID con un check errato o con una configurazione non definita, implicherà
l’eliminazione di tutto il pacchetto.
Se un device riceve un PID corretto ma che prevede un tipo di transizione o una direzione non
supportata, questo non risponderà.
LSB MSB
PID0 PID1 PID2 PID3 P I D0 P I D1 P I D2 P I D3
Il PID indica il tipo di pacchetto, il formato ed il tipo di controllo d’errore.

Le tipologie di PID e le loro codifiche sono le seguenti:
PID PID PID Bit Descrizione

Type Name 3,2,1,0
Token OUT 0001 Address + endpoint number – host to device transaction
IN 1001 Address + endpoint number – device to host transaction
SOF 0101 Start of frame and frame number
SETUP 1101 Address+endpoint number – host to device transaction for setup to a control endpoint
Data DATA0 0011 Data packet PID even
DATA1 1011 Data packet PID odd
Handshake ACK 0010 Receiver accepts error free data packet
NAK 1010 RX device cannot accept data or TX device cannot send data
STALL 1110 Endpoint is stalled
Special PRE 1100 Host-issued preamble. Enables downstream bus traffic to low speed devices
Le tipologie di PID sono divise in quattro gruppi: token, data, handshake e special.
I primi due bit (1 e 0) identificano il gruppo di appartenenza.

Campo address
Gli endpoint dei device sono indirizzati per mezzo di due campi: l’indirizzo del device e l’indirizzo
dell’endpoint. Indirizzi errati o non corrispondenti determinano lo scarto del token come pure
l’accesso ad un endpoint non inizializzato.
Ogni campo address (ADDR) individua un singolo device mentre il fatto che sia il trasmettitore o il
ricevitore dipende dal valore del PID.
Tutti gli indirizzi sono costituiti da 7 bit per un totale di 128 devices indirizzabili.
LSB MSB
Addr0 Addr1 Addr2 Addr3 Addr4 Addr5 Addr6
Il campo ADDR deve essere specificato per i token IN, OUT e SETUP.
Successivamente ad un reset o dopo il power-up, viene assegnato al device un address default 0 per
poter poi eseguire la fase di assegnazione dell’indirizzo di lavoro (enumeration process).
L’address default 0 non può essere assegnato durante la normale attività.
L’indirizzo di endpoint è costituito da un campo di 4 bit.
LSB MSB
Endp 0 Endp1 Endp 2 Endp3
Il campo di endpoint è definito per i token IN, OUT e SETUP.

Tutti i devices devono disporre di un endpoint 0 di controllo.
I devices Low Speed possono avere un massimo di 2 endpoint mentre quelli Full Speed possono
avere fino a 16 endpoint.
Campo frame number
Il frame number è un campo di 11 bit che viene incrementato dall’host per il conteggio dei frame.
Il suo massimo valore è 7FFH (204710) ed è inserito solo nel token SOF alla partenza di ogni frame.
Campo dati
Il campo dati può essere costituito da un numero intero di byte variabile da 0 a 1023.
LSB MSB
D0 D1 D2 D3 D4 D5 D6 D7
Le dimensioni del pacchetto dati può variare in funzione del tipo di trasferimento usato.
CRC
Il controllo di ridondanza ciclica (CRC) è usato per il controllo d’errore nei soli pacchetti token e
data. Il PID non è sottoposto al controllo CRC. Il controllo di errore non coinvolge i bit di stuffing.
Il CRC dei pacchetti di token e data assicura il 100% della rilevazione degli errori singoli e doppi.
La ricezione di un CRC errato determina l’eliminazione del campo o dell’intero pacchetto.

Il controllo d’errore sul token utilizza un polinomio generatore del tipo G(X) = X5 + X2 + 1
il quale controlla i campi ADDR e ENDP dei token IN, OUT e SETUP.
Il controllo d’errore sul campo dati utilizza un polinomio generatore del tipo
G(X) = X16 + X15+ X2 + 1
Formato dei pacchetti

Pacchetti Token
Un pacchetto token consiste di un PID, con la specifica di IN, OUT o SETUP del tipo di pacchetto,
un campo ADDR ed un campo ENDP.
Per le transazioni IN e SETUP, i campi address ed endpoint identificano univocamente l’endpoint
che poi riceverà il pacchetto dati.
Per le transizioni IN, i campi address ed endpoint identificano univocamente l’endpoint che
trasmetterà il pacchetto dati.
Soltanto l’host potrà generare un pacchetto token.
8 bit 7 bit 4 bit 5 bit

PID ADDR ENDP CRC5
Il pacchetto di token ha 5 bit di CRC i quali controllano solo i campi ADDR ed ENDP in quanto il
campo PID ha un proprio campo di check.
I pacchetti di token e di SOF sono delimitati da un EOP dopo tre byte di campi di pacchetti dati.
Nel caso di assenza di questo EOP, il pacchetto sarà considerato non valido e scartato.
Pacchetti Start of Frame
I pacchetti Start of Frame (SOF) sono emessi dall’host ad un rate di uno ogni 1.00 mSec ±0.05.
Un pacchetto SOF è costituito da un PID che indica il tipo di pacchetto seguito poi da 11 bit di
campo per il numeratore di frame.
8 bit 11 bit 5 bit

PID Frame Number CRC5
SOF costituisce solo la transizione che corrisponde alla partenza di ogni frame in precisi istanti di
tempo con in più il numero di frame.
Tutti i devices Full Speed (compresi gli hub) devono ricevere e decodificare i pacchetti SOF.
I pacchetti SOF non determinano la generazione di pacchetti di ritorno (handshake) per cui la loro
consegna non è garantita.
Un device è informato dell’arrivo di uno start of frame quando rileva il suo PID.
I device sensibili alla temporizzazione dei frame devono solo decodificare il campo PID e possono
ignorare i campi Frame Number e CRC. Questi ultimi due campi sono considerati dai devices che
hanno bisogno di tener traccia della numerazione dei frame.

Pacchetti Dati
I pacchetti dati sono costituiti da un PID, un campo dati ed un CRC.

Esistono due tipi di pacchetti dati identificati da differenti PID (DATA0 e DATA1) utilizzati per la
sincronizzazione toggle.
8 bit 0 ÷1023 byte 16 bit

PID Data CRC16
Il numero di dati inviati deve sempre risultare un numero intero di byte.

Il CRC16 è calcolato solo sul campo dati e non comprende il campo PID che ha un suo check.
Pacchetto Handshake
Il pacchetto handshake consiste in un solo campo PID.

Il pacchetto handshake è usato per riportare lo stato della transizione indicante la corretta ricezione
dei dati, il controllo di flusso e la condizione di stallo.
L’handshake può essere generato solo dalle transizioni che prevedono il controllo di flusso.
I pacchetti di handshake sono delimitati da un EOP dopo un byte del campo del pacchetto.
Un handshake valido ma non terminato con un EOP dopo un byte dovrà essere considerato non
valido e quindi scartato.
8 bit
PID
Esistono tre tipi di pacchetti handshake:
ACK Indica che il pacchetto dati è stato ricevuto senza bit stuff o senza errori CRC sui campi controllati e
con il PID corretto
NAK Indica che il device non è disponibile ad accettare dati dall’host (OUT) oppure che non ha dati da
inviare all’host (IN). Un host non potrà mai generare un NAK.
NAK è usato dal controllo di flusso per indicare che il device non è temporaneamente disponibile a
trasmettere o ricevere dati.
NAK è anche usato dall’interrupt endpoint per indicare che non ci sono richieste di interrupt pendenti.
STALL STALL indica che il device non è disponibile a ricevere o trasmettere dati e che questa condizione
richiede l’intervento dell’host per la rimozione dello stallo.
Struttura generale dei pacchetti:
Pacchetto SOF SYNC PID FRAME Num. CRC5 EOP
Pacchetto TOKEN SYNC PID ADDR ENDP CRC5 EOP
Pacchetto DATA SYNC PID DATA CRC16 EOP
Pacchetto HANDSHAKE SYNC PID EOP

Formato delle transizioni
Il formato delle possibili transizioni dipende dal tipo di endpoint.

Esistono quattro tipi di endpoint: bulk, control, interrupt e isocrono.
Transizioni bulk
Le transizioni bulk hanno la caratteristica di essere prive di errori di trasferimento dati tra host e
devices per mezzo del supporto del controllo d’errore e della possibilità di ritrasmissione.
Quando un host vuole ricevere dei dati bulk, emette un token tipo IN.
L’endpoint del device risponde emettendo un pacchetto DATA oppure, se non è in grado di farlo,
risponde con un handshake tipo NAK o STALL.
Se l’host riceve un pacchetto dati corretto, risponde con un handshake ACK se invece rileva un
errore nei dati non risponde.
Quando un host vuole inviare di dati bulk, emette un token tipo OUT seguito da un pacchetto dati.
Il device potrà rispondere con tre tipi di handshake:
ACK per indicare che il pacchetto è stato ricevuto correttamente e che l’host può inviare
l’eventuale pacchetto successivo della sequenza.
NAK per indicare che i dati sono stati ricevuti senza errori ma che l’host dovrebbe ritrasmetterli
poiché il device non era momentaneamente in condizioni di accettarli (buffer pieno).
STALL per informare l’host di non ritrasmettere i dati a causa di un errore nello stato del device.
Nessun handshake verrà inviato se il pacchetto viene ricevuto con un errore di CRC o di bit stuff,.
L’host inizia sempre la prima transizione sul bus con un PID DATA0, la seconda invece usa un PID
DATA1, le successive saranno alternate in questo modo (data toggle).

Transizioni control
Il trasferimento dei controlli avvengono in due fasi di transizione dette Setup e Status.
Durante una fase di Setup, la transizione di Setup è usata per trasmettere delle informazioni
all’endpoint di controllo del device. Nella transizione di Setup si usa sempre un PID DATA0.
Il device che riceve un Setup deve sempre accettare i dati di Setup e rispondere con un handshake
ACK, se corretti, altrimenti ignorare i dati e non inviare alcun handshake.
Se è presente la fase Data, il trasferimento di controllo

consiste in una o più IN o OUT utilizzando le stesse
regole del trasferimento bulk ed usando la stessa
direzione per tutte le transizioni.
La quantità di dati da trasferire durante questa fase e la
loro direzione, vengono specificate durante la fase di
Setup.
Se la quantità di dati è superiore a quella prenegoziata
per la dimensione del pacchetto, i dati sono inviati
facendo uso di transizioni multiple che trasportano la
massima dimensione consentita tranne l’ultima che
trasporta la quantità residua finale.
La fase di Status è l’ultima operazione della sequenza. Questa fase è realizzata con un cambiamento
di direzione del flusso dati rispetto alla fase precedente e usando sempre il PID DATA1.
Il contenuto della fase di Status può essere di tre tipi:
la sequenza dei comandi è stata completata con successo (ACK)
la sequenza dei comandi non viene completata (STALL)
il device è ancora occupato a completare la sequenza dei comandi (NAK)
Transizioni interrupt
Le transizioni interrupt consistono

solo in un token IN.
Successivamente alla ricezione di un

token IN, il device può rispondere con
dei dati oppure con un NAK o con
uno STALL.
Se l’endpoint non ha altre richieste di
interrupt in attesa, il device risponde
con un NAK handshake.
Se invece l’endpoint è in fase di
stallo, il device risponde con uno
STALL handshake che poi richiederà
un intervento software da parte
dell’host.

Se infine vi è un interrupt in attesa, il device risponderà con un pacchetto dati contenente le
informazioni relative all’interrupt.
Se il pacchetto dati ricevuto è corretto, l’host risponde con un ACK handshake, in caso di pacchetto
errato non risponde.
Quando un endpoint usa il trasferimento interrupt per i dati relativi all’interrupt, è necessario far uso
del protocollo data toggle che sarà inizializzato con un PID DATA0.
Un interrupt può anche essere usato da un endpoint per comunicare la successiva velocità di ritorno
delle informazioni in modo isocrono, cambiando i bit di data toggle dopo che ogni pacchetto e stato
inviato all’host.
Transizioni isocrone
Le transizioni isocrone hanno solo le fasi di token e di data.
L’host emette un token IN oppure OUT seguito

dalla fase data nella quale vengono trasmessi i
dati. Le transizioni isocrone non dispongono
delle fasi di handshake e non consentono la
ritrasmissione di dati errati.
Le transizioni isocrone non usano il protocollo
data toggle ed il PID è sempre del tipo DATA0.
Il PID del pacchetto non viene esaminato.
Data toggle
L’interfaccia USB dispone di un meccanismo per garantire la corretta sincronizzazione tra i dati
trasmessi e ricevuti con delle transizioni multiple, consentendo la corretta interpretazione della fase
di hanshake da parte del trasmettitore e del ricevitore.
La sincronizzazione è ottenuta per mezzo dei PID DATA0 e DATA1 e di separate sequenze di bit
di data toggle per i dati trasmessi e ricevuti.
La sequenza di bit ricevuti viene commutata (toggle) solo quando il ricevitore ha accettato il
pacchetto dati privo di errori con un corretto PID.
La sequenza di bit trasmessi viene commutata (toggle) solo quando i dati trasmessi ricevono un
ACK valido.
I dati trasmessi o ricevuti devono presentare la loro sequenza di bit di sincronizzazione all’inizio
della transizione. La sincronizzazione toggle non è disponibile nel trasferimento isocrono.

Inizializzazione per mezzo del token di SETUP
Il trasferimento control usa il token di SETUP per inizializzare

le sequenze di bit per host e device.
Nell’esempio è visibile l’emissione da parte dell’host, verso il
device, di un pacchetto SETUP seguito da un OUT. (I numeri
nei cerchi rappresentano le sequenze di bit trasmesse e
ricevute).
Il device deve accettare i dati e rispondere con un ACK.

Il device, dopo aver accettato la transizione, deve resettare la
sua sequenza di bit così che, alla fine della transizione di
SETUP, entrambe le sequenze di bit dell’host e del device
siano uguali a 1.
Transizioni successive
In questa figura è visualizzato il caso in cui si

verificano due transizioni successive.
Il trasmettitore commuta la sua sequenza di bit a
seguito della ricezione di un ACK.
Il ricevitore commuta la sua sequenza di bit solo
se riceve un pacchetto di dati valido con il suo
pacchetto PID avente la stessa sequenza di bit.
Se i dati non possono essere accettati, il
ricevitore deve rispondere con un NAK.
La sequenza di bit può essere cambiata solo se il
pacchetto dati viene trasmesso.
Le transizioni a due fasi nelle quali non vi sono
pacchetti dati lasciano inalterate le sequenze di bit del trasmettitore e del ricevitore.
Dati errati o non accettati
Se i dati non possono essere accettati o

risultano errati, il ricevitore risponderà con
un NAK o con uno STALL oppure un time
out e non commuterà la sua sequenza di bit.
Il trasmettitore, non avendo ricevuto un
ACK non commuterà la sua sequenza di bit.
Pertanto, una transizione fallita lascia non
commutata la sequenza di bit del
trasmettitore e del ricevitore.
La transizione sarà quindi ritentata e, se avrà
successo, trasmettitore e ricevitore
commuteranno le loro sequenze di bit.

ACK errato
Un caso particolare è quello relativo alla ricezione di un ACK errato nonostante che il pacchetto
dati sia stato trasmesso, ricevuto e poi accettato correttamente dal device.
Come si può vedere dalla figura, al termine della transizione i-esima vi è una momentanea perdita
di coerenza tra trasmettitore e ricevitore a causa della non corrispondenza tra le sequenze di bit.
Nella successiva transizione, il trasmettitore rimanda il precedente pacchetto di dati facendo uso
dello stesso PID DATA0.
La sequenza di bit ed il data PID non risulteranno coincidenti, da ciò il ricevitore si rende conto di
aver in precedenza già accettato lo stesso pacchetto dati. Di conseguenza ignora il pacchetto
ricevuto e non commuta la sequenza di bit.
A questo punto il ricevitore emette un ACK che permetterà al trasmettitore di capire che la
transizione si è conclusa con successo. Tutto ciò consentirà al trasmettitore di commutare la
sequenza di bit e procedere alla successiva transizione usando un DATA1 PID.
Il trasmettitore deve sempre garantire che il pacchetto dati ritrasmesso risulti della stessa lunghezza
di quello originario. Se il trasmettitore non è in grado di dare questa garanzia (per es. a causa di
buffer underrun), esso deve abortire la transizione generando una violazione di bit stuffing che sarà
interpretata dal ricevitore come un errore.
Rilevazione e recupero di errori

Lo standard USB consente una comunicazione end to end affidabile anche in presenza di ampie
tipologie di errori sui segnali elettrici.
L’interfaccia USB utilizza tre tipologie di rilevazione degli errori: violazione di bit stuff, check sui
bit PID e controllo del CRC.
Una violazione di bit stuff si verifica se il ricevitore rileva sette o più consecutivi bit time senza una
transizione differenziale (J→K o K→J) sulle linee D+ e D– tra l’inizio e la fine di un pacchetto.
Un errore sul PID si rileva se gli ultimi 4 bit del PID non sono uguali al complemento dei primi 4.
Un errore di CRC si rileva dal fatto che il checksum del pacchetto ricevuto non è nullo.
Campo Errore Azione

PID PID check, Bit Stuff Pacchetto ignorato
Address Bit Stuff, Address CRC Token ignorato
Frame number Bit Stuff, Frame number CRC Campo Frame number ignorato
Data Bit stuff, Data CRC Dati non accettati
Un altro tipo di errore è quello di time out che viene segnalato dopo i 18 bit time.
Se l’host vuole indicare un errore di time out, deve aspettare almeno 18 bit time prima di emettere il
successivo token.

USB 3.0
L’interfaccia USB 3.0 (Super Speed) è funzionalmente simile alle sue predenti versioni in quanto
consente la connessione, la configurazione, l’uso e il distacco durante il normale funzionamento di
tutto il sistema.
USB 3.0 utilizza una architettura a doppio bus per mantenere la compatibilità con le precedenti
versioni Non Super Speed e gli stessi componenti: Host(1), Hub(max 5) e Devices (max 127).
NON Super Speed

Super
Speed High Full Low USB 3.0 Host
Speed Speed Speed
Super Speed USB 2.0 USB 3.0 HUB

HUB HUB
Super Speed NON Super Speed USB 3.0

Device Device Peripheral Device
Come per le versioni Non Super Speed, utilizza una topologia a stella con un host, che si collega ad
uno o più hub che, a loro volta, connettono uno o più devices.
La compatibilità è mantenuta anche dal punto di vista della connessione meccanica la quale
consente il collegamento di devices Super Speed e Non Super Speed.
I connettori upstream e downstream non sono meccanicamente intercambiabili al fine di evitare
connessioni illegali di loopback sugli hub.
La prima sostanziale differenza risiede nel cavo di collegamento che è costituito da otto conduttori
principali: tre coppie twisted per i segnali che trasportano i dati ed una coppia per l’alimentazione.
Le due nuove coppie per la versione Super Speed (SS), sono usate una per la trasmissione ed una
per la ricezione dei dati operando pertanto in modalità full duplex.
La terza coppia trasporta i dati per le versioni Non Super Speed in modalità half duplex.
Max 5 metri
1 VBus
2 D+
3 D-
9 SSRX+
8 SSRX-
6 SSTX+
5 SSTX-
4 Power GND
7 Signal GND
Shield

E’ possibile inserire un connettore USB 2.0 in una presa USB 3.0 ma non il contrario.
La distribuzione dell’alimentazione nella USB 3.0 è simile a quella della USB 2.0 con un
incremento della potenza disponibile per la parte relativa ai devices Super Speed ma restando
invariata per la parte USB 2.0.
Come già esposto, USB 3.0 consente l’attacco e il distacco dei devices in qualsiasi istante, di
conseguenza il system software sarà in grado di riconfigurare dinamicamente tutta la topologia
fisica del bus ad ogni variazione.
Il metodo di rilevazione dell’attacco o del distacco dei devices è identico a quello della USB 2.0.
USB 3.0 ha una architettura a doppio bus che contiene sia il bus USB2.0 che quello USB3.0.
Differenze tra USB 3.0 e USB 2.0
Caratteristiche USB 3.0 USB 2.0

Data rate 4.8 Gbps Low Speed 1.5 Mbps
Full Speed 12 Mbps
High Speed 480 Mbps
Data interface Dual simplex con quattro fili differenziali Half duplex a due fili differenziale. Flusso dati
separati dai segnali USB 2.0. Flusso dati unidirezionale con negoziazione della
simultaneo bidirezionale direzione
Cavi Sei: quattro per USB Super Speed e due per Due: per Low, Full e High Speed
USB Non Super Speed
Transizioni Controllate dall’host Controllate dall’host
Flusso dati asincrono Flusso dati su base polling
Instradamento esplicito dei pacchetti Pacchetti inviati in broadcast a tutti i devices
Bus power Come per USB 2.0 con il 50% di incremento Gestione low/high per i devices alimentati a
per le alimentazioni non configurate e un bus con un limite ridotto per i devices non
incremento dell’80% per le alimentazioni configurati o sospesi
configurate
Data transfer Come per la USB 2.0 con le restrizioni Super Quattro tipi: control, bulk, interrupt e isocrono
Speed. Bulk con capacità stream

Architettura Super Speed
L’interfaccia Super Speed è costituita da una architettura di comunicazione a strati (stack) che
comprende i seguenti elementi:
Interconnessioni Super Speed: definiscono le modalità con le quali i devices vengono connessi e
comunicano con l’host attraverso il bus Super Speed. Sono incluse la topologia delle connessioni
dei devices, lo stack di comunicazione, le relazioni tra essi e le interazioni al fine di realizzare lo
scambio di informazioni tra host e devices.
Devices: rappresentano le sorgenti o i destinatari delle informazioni scambiate tra un driver
dell’host e la funzione del device.
Host: rappresenta la sorgente o il destinatario delle informazioni gestendo tutti i devices collegati.
Il modello rappresentativo dell’architettura è il seguente:
Le righe (Device or Host, Protocol, Link e Physical) rappresentano lo stack di comunicazione.

Le tre colonne di sinistra (Host, Hub e Device) descrivono le relazioni topologiche tra i devices
connessi al bus Super Speed.
La colonna di destra descrive le modalità di gestione dell’alimentazione rispetto ai vari strati.
Strato Fisico
Lo strato fisico definisce le connessioni tra la porta di downsteam dell’host o hub e la porta di
upstream del device. La connessione fisica è costituita da due coppie differenziali twisted, una per
la ricezione ed una per la trasmissione con un data rate di 4.8 Gbps.
Il canale di collegamento differenziale è unidirezionale ed è detto differential link.
Ognuno di questi due link è accoppiato in AC per mezzo di condensatori posti nel trasmettitore.
In corrispondenza di un preciso livello di tensione, il link differenziale viene inizializzato abilitando
il ricevitore collegato. Il trasmettitore ha il compito di rilevare la connessione di un ricevitore per
mezzo di una indicazione del bus così da consentirne allo strato link la gestione.

Quando un ricevitore è collegato ma non se ne verifica la segnalazione sul link differenziale, esso è
considerato essere nello stato elettrico detto idle (inattivo).
Il ricevitore viene fatto uscire da questo stato per mezzo di un segnale periodico di bassa frequenza
detto LFPS (Low Frequency Periodic Signal) che poi consente l’inizializzazione e la gestione
dell’alimentazione. Il segnale LFPS è caratterizzato da:
un periodo compreso tra 20 e 100 nSec, un tBurst di 1
µSec ed un tRepeat di 10 µSec.
Ogni strato fisico ha il proprio clock fatto con una
modulazione Spread Spectrum Clocking (SSC).
Il cavo USB 3.0 non include il clock di riferimento,
opportune transizioni del segnale di trasmissione
consentono la sincronizzazione del clock interno al
ricevitore.
Dato che il ricevitore necessita di un buon numero di transizioni per

allineare il proprio clock interno e ricevere correttamente i dati, il
trasmettitore codifica i dati e i caratteri di controllo in simboli
Scrambler codificati in codice 8b/10b a dieci bit secondo opportune tabelle
(ANSI INCITS 230-1994).
Dodici caratteri di controllo hanno una speciale codifica per essere
univocamente distinti dai dati.
8b/10b Encoding
Lo strato fisico riceve i dati in blocchi da 8 bit dallo strato link e li
sottopone ad un processo di scrambling (rimescolamento). Questo
processo viene realizzato per mezzo di un Linear Feedback Shift
Register (LFSR) che trasforma gli 8 bit in una sequenza di 16 bit
Parallel to Serial per mezzo di operazioni di XOR con un polinomio del tipo
G(X) = X16+X5+X3+1 ed un valore iniziale pari a FFFFH.
Tutto il processo avviene secondo il seguente schema.

Differential
Trasmitter Driver Il processo inverso viene poi realizzato nel ricevitore.
D+ D-
Strato Link
Un link Super Speed rappresenta una connessione logica e fisica di due porte che vengono chiamate
link partners. Una porta è dotata di una parte fisica e una parte logica.
Lo strato link definisce la porzione logica di una porta e la comunicazione tra i link partners.
La porzione logica di una porta è caratterizzata da:
• Stato macchina: per la gestione della sua parte finale di connessione che comprende
l’inizializzazione e la gestione degli eventi come connessione, distacco e alimentazione.
• Stato macchina e buffer: per la gestione dello scambio di informazioni tra i link partners e
comprende i protocolli per il controllo di flusso, l’affidabile recapito degli header dei pacchetti e
la gestione dell’alimentazione.
• Buffering dei dati e delle informazioni dello strato protocol.

La porzione logica di una porta si interessa anche a:
definire il corretto framing della sequenza di byte nei pacchetti durante la trasmissione inserendo i
delimitatori dei pacchetti
rilevare i pacchetti ricevuti e gli eventuali errori negli header
definire una opportuna interfaccia con lo strato protocollo.
Lo stato fisico dota la porta logica di una interfaccia per mezzo della quale:
• Gestisce lo stato della parte fisica con l’inclusione della gestione dell’alimentazione e degli
eventi quali connessione, distacco e uscita dallo stato idle.
• Trasmettere e ricevere la sequenza di byte con i segnali di controllo necessari per differenziare la
sequenza di dati da quella dei controlli. Una porta è abilitata alla simultanea trasmissione e
ricezione di dati e controlli.
Il protocollo tra i link partners usa una specifica codifica per le sequenze di controllo che consente
di tollerare l’errore su un singolo bit.
Strato protocol
Lo strato protocol definisce le regole della comunicazione end to end tra l’host e l’endpoint del
device per mezzo di un canale detto pipe e sotto la supervisione dell’host.
L’USB Super Speed non opera su base polling in quanto ogni device è in grado, per conto di un suo
endpoint, di emettere una richiesta asincrona di asservimento verso l’host.
Tutte le comunicazioni dello strato protocol si realizzano per mezzo dello scambio di pacchetti
costituiti da una sequenza di byte con opportuni controlli che vengono poi gestiti dallo strato link.
I pacchetti trasmessi dall’host sono instradati (routing) attraverso gli hub o direttamente al device.
I pacchetti non attraversano quindi tutti i percorsi ma solo quelli che conducono alla destinazione
definita snellendo così il flusso dati.
I pacchetti hanno dimensioni fisse con header, campi e sottocampi codificati per le specifiche
funzioni.
Un piccolo record con un pacchetto header è utilizzato dallo strato link (port to port) per gestire il
flusso dei pacchetti port to port. I restanti campi sono usati invece dal protocollo end to end.
I dati delle applicazioni Sono trasmessi in un pacchetto payload dotato di una specifico header.
I pacchetti payload non consentono una consegna affidabile attraverso lo strato link (al contrario
dell’header che ha una consegna affidabile).
Lo strato protocol consente però una consegna affidabile dei pacchetti per mezzo dei pacchetti di
acknowledgement e la eventuale ritrasmissione dei pacchetti errati.
Questa tecnica non è disponibile per tutti i tipi di informazioni.
Questo protocollo consente una efficiente utilizzazione del bus per mezzo della contemporanea
trasmissione e ricezione sul link: un trasmettitore può trasmettere una raffica (burst) di pacchetti
multipli di dati mentre il ricevitore trasmettere i vari acknowledgement senza interrompere il burst
dei pacchetti di dati.
Il protocollo in oggetto provvede anche al controllo di flusso per alcuni tipi di trasferimento.

Gestione degli errori
Dal punto di vista dell’integrità dei dati trasmessi, l’interfaccia USB 3.0 è caratterizzata dai seguenti
aspetti:
• utilizzo di trasmettitori e ricevitori differenziali con cavi twisted schermati

• protezione con CRC degli header e dei dati
• ritrasmissione dei pacchetti di dati per consentire una consegna affidabile
• gestione degli attacchi, distacchi e configurazione dei devices
Lo strato fisico della USB 3.0 consente un bit error rate inferiore a 1 su 1012 bit.
Ogni pacchetto è corredato da un controllo di CRC per la rilevazione di errori multipli e relative
procedure di recupero dell’errore implementate in hardware o software.
Il protocollo prevede l’utilizzo di CRC separati per header e dati ed eventualmente anche per il link
control word. Un errore nell’header o nel link control word è considerato di elevata gravità e
determinerà un intervento del livello link per il suo recupero.
Un errore di CRC nel pacchetto dati sarà gestito dallo strato protocol con una richiesta di
ritrasmissione del pacchetto stesso.
Gli strati link e fisico cooperano per assicurare una affidabile trasmissione dei pacchetti header.
Un host USB 3.0 proverà a ritrasmettere dati risultati errati per tre volte prima di informare il client
del software applicativo del fallimento della consegna.
Power management
L’interfaccia USB 3.0 consente una articolata gestione dell’alimentazione (power management) dei
vari dispositivi connessi a diversi livelli: link, device e function come esposto nel modello.
Questi livelli di gestione dell’alimentazione non sono strettamente collegati ma hanno delle
dipendenze.
Il livello link controlla localmente, in modo asincrono tutti, i link connessi. Le politiche di gestione
a livello link possono essere condizionate dall’inattività del device o della porta di downstream per
mezzo di timer programmati dal software dell’host.
Lo stato dell’alimentazione viene poi propagato verso l’host dagll’hub.
I link che non sono utilizzati per scambio di informazioni, sono posti al più basso livello di
alimentazione.
L’host non ha il diretto controllo dello stato di alimentazione del singolo link, questo implica che
uno o più link nel percorso tra host e device possono trovarsi in uno stato di basso livello di
alimentazione quando l’host inizia la comunicazione sul bus. Esistono pertanto dei meccanismi di
protocollo che forzano questi link a passare nello stato operativo e notificare all’host il passaggio.
La gestione dell’alimentazione è caratterizzata dai seguenti aspetti:
• i devices inviano asincronamente all’host la notifica dello stato di pronto

• i pacchetti sono instradati consentendo ai link non coinvolti nella comunicazione di
commutare o rimanere nello stato di bassa potenza
• i pacchetti che attraversano delle porte che sono nello stato di bassa potenza determinano il
passaggio nello stato operativo con la notifica della commutazione
La gestione dello stato di sospensione di un device è simile a quello della USB 2.0.
Nei dispositivi multifunzione (compound) ogni funzione può essere indipendentemente posta nello
stato di bassa alimentazione.

Devices (Periferiche - Hub - Host)
Tutti i devices Super Speed condividono la stessa architettura base della USB 2.0
Durante la fase di BUS enumeration, l’host provvede ad assegnare ad ogni devices un proprio
indirizzo.
Ogni devices dispone di una o più pipe attraverso le quali l’host comunica con i devices.
Tutti i devices devono disporre di un Endpoint 0 al quale è collegata la Default Control Pipe.
Tutti i devices devono supportare un comune meccanismo di accesso alla Control Pipe.
-----
Un device USB 3.0 deve disporre del necessario supporto per la comunicazione Super Speed e
NON Super Speed mantenendo così la compatibilità con qualsiasi tipo di host.
La struttura del device deve consentire la piena funzionalità quando opera in modo NON Super
Speed.
Non è consentito ad un device di operare simultaneamente in modo Super Speed e NON Super
Speed.
Come per la USB 2.0, un device USB 3.0 può contenere in un unico package diverse funzioni (2.0 o
3.0) con un unico hub integrato e permanentemente collegato.
--------------
L’hub è un elemento chiave dell’architettura USB in quanto consente un semplice meccanismo di
ampliamento della rete di devices collegabili per mezzo delle sue porte di downstream.
Un hub USB 3.0 è costituito dalla combinazione di due hub: uno USB 2.0 ed uno Super Speed ed
ognuno connesso ad una propria linea dati.
L’hub Super Speed gestisce la porta di downstream della parte Super Speed mentre l’hub USB 2.0
gestisce la porta di downstream della parte USB 2.0.
Ognuna delle due porte ha un proprio registro di controllo e di stato.
Un hub Super Speed consiste di due componenti logici: un controller ed un repeater Super Speed.
Il repeater è un router che controlla il protocollo tra le porte di upstream e downstream e dispone
dell’hardware per le segnalazioni di reset, suspend e resume.
Il controller gestisce i comandi di stato e controllo usati dall’host per configurare l’hub e monitorare
e controllare le sue porte.
L’hub Super Speed concorre alla gestione del protocollo end-to-end con le seguenti attività:
• instrada i pacchetti verso una specifica porta di downstream

• assembla i pacchetti da inviare alla porta di upstream
• propaga i pacchetti di timestamp verso tutte le porte di downstream che non sono nello stato
di low power
• rileva quando un pacchetto incontra una porta che si trova nello stato di low power e
informa l’host.
--------------
Per poter supportare l’architettura dual bus, un host USB 3.0 include i necessari elementi per l’USB
2.0 e l’USB Super Speed con i quali può gestire simultaneamente il controllo, lo stato e lo scambio
di informazioni tra l’host ed i relativi devices attraverso le specifiche downstream root port.
Attraverso queste porte l’host può:
• rilevare la connessione e il distacco di un devices USB
• gestire il controllo di flusso tra host e devices USB
• gestire il flusso dati tra host e devices USB
• archiviare dati statistici sulle attività
• alimentare i devices collegati
• configurare i devices ed assegnare indirizzi
• gestire trasferimenti di dati periodici e asincroni.

Modello di flusso dati
USB Super Speed è molto simile alla USB 2.0 mantenendone l’architettura a strati e gli elementi di
base del flusso di comunicazione(endpoint, pipe e tipi di trasferimento).
Le caratteristiche dell’endpoint sono contenute nel Super Speed Endpoint Conpanion Descriptor.
Come per l’USB 2.0, l’endpoint è identificato per mezzo di un indirizzo triplo (device Addres,
Endpoint Number, Direction). Tutti i devices Super Speed devono disporre di almeno un endpoint
(Default Control Pipe) detto Endpoint 0.
Una pipe Super Speed è una associazione tra un endpoint di un device e il software sull‘host ed ha
la stessa funzionalità di una pipe USB 2.0.
La principale differenza rispetto alla USB 2.0 consiste nel fatto che quando un endpoint non
isocrono è occupato esso risponde con un Not Ready (NRDY) e dovrà poi inviare una notifica di
Endpoint Ready (ERDY) quando avrà bisogno di essere asservito.
Tutti i tipi di trasferimento della USB 2.0 sono supportati dal protocollo Super Speed.
Pur restando compatibile con la USB 2.0, la USB Super Speed presenta le seguenti differenze:
• USB 2.0 usa transizioni fatte da tre parti (Token, Data ed Hadshake) mentre la Super Speed
usa le stesse tre parti ma in modo differente. Per l’OUT il token è incorporato nel pacchetto
dati mentre per l’IN il token è sostituito da un handshake.
• La USB 2.0 non supporta il bursting mentre la Super Speed supporta il bursting continuo.
• La USB 2.0 ha un bus broadcast half-duplex mentre la Super Speed ha un bus unicast-dual
simplex che consente contemporanee transazioni IN e OUT.
• La USB 2.0 usa un modello a polling mentre la Super Speed usa notifiche asincrone.
• La USB 2.0 non ha lo streaming mentre la Super Speed supporta lo streaming per endpoint
bulk.
• Super Speed consente ai device isocroni di entrare autonomamente nello stato di low power
negli intervalli tra i servizi.
• Super Speed dispone di un meccanismo che consente ai devices di informare l’host della
propria tolleranza di latenza per mezzo dei Latency Tolerance Messaging usati dal sistema
delle politiche di gestione dell’alimentazione.
• La USB 2.0 trasmette lo SOF a intervalli fissi di 1 mSec o 125 µSec mentre la USB Super
Speed dispone di un meccanismo con il quale i devices possono inviare un Bus Interval
Adjustment Message che è usato dall’host per calibrare il suo bus interval di 125 µSec fino a
±13.333 µSec.
• La USB 2.0 gestisce la rilevazione di errori, il loro recupero e il controllo di flusso solo al
livello end-to-end per ogni transizione mentre la Super Speed ripartisce queste funzioni tra i
due livelli end-to-end e link.
La USB Super Speed con il suo strato fisico dual simplex consente il simultaneo trasporto di
informazioni nelle due opposte direzioni, questo si traduce nella possibilità, per il trasmettitore, di
inviare pacchetti multipli di dati prima di ricevere i rispettivi handshake.
Per il trasferimento OUT, le informazioni prima contenute nel Token USB 2.0 sono ora incorporate
nell’header del pacchetto dati così da non richiedere un ulteriore Token.
Per il trasferimento IN, un handshake è inviato al device che ha richiesto i dati, il device potrà
rispondere inviando i dati oppure uno STALL handshake o un Not Ready (NRDY) handshake per
differire il trasferimento fino a quando non sarà pronto.

La USB 2.0 invia i pacchetti in broadcast a tutte le porte di downstream abilitate per cui è
necessario che ogni device decodifichi un triplo indirizzo (device address, endpoint num, direction)
per ogni pacchetto al fine di stabilire una eventuale risposta.
La Super Speed invece invia i pacchetti in unicast per cui i pacchetti sono inviati su un ben preciso
percorso tra host e device per il downstream ed al contrario per l’upstream.
I pacchetti Super Speed contengono le necessarie informazioni di routing che gli hub usano per
individuare la porta di downstream sulla quale instradare il pacchetto per farlo arrivare al device.
Il metodo polling usato dalla USB 2.0 viene ora sostituito dalla notifica asincrona.
Una transizione Super Speed viene iniziata dall’host per mezzo di una richiesta alla quale
corrisponderà una risposta dal device.
Se il device può asservire la richiesta, accetterà o invierà i dati.
Se l’endpoint è invece in halt, risponderà con uno STALL handshake.
Se il device non è in condizione di asservire la richiesta (perché non dispone di dati o per mancanza
di spazio nel buffer), risponderà con un Not Ready (NRDY). Quando il device sarà poi pronto ad
asservire la richiesta, invierà un Endpoint Ready (ERDY) all’host il quale riavvierà la transizione.
Pacchetti Super Speed
I pacchetti USB Super Speed iniziano con un header da 16 byte (alcuni pacchetti sono costituiti dal
solo header).
Tutti gli header iniziano con delle informazioni descrittive del tipo di pacchetto che ne stabilisce il
tipo di utilizzo.
La parte finale dell’header è costituita da 2 byte di link control e 2 byte di CRC16 di protezione.
In funzione della tipologia, i pacchetti contengono informazioni per il routing (Route String) ed un
triplo indirizzo per il device di destinazione (device address, endpoint num, direction).
La Route String è usata per definire il preciso percorso tra trasmettitore e ricevitore.
Esistono quattro tipi di pacchetti:
• Link Management Packet (LMP) che scorre solo tra una coppia di porte direttamente
connesse ed è principalmente usato per la gestione del link.
• Transaction Packet (TP) il quale attraversa tutti i link lungo il percorso che connette l’host
con il device. È usato per il controllo di flusso dei pacchetti di dati, per la configurazione di
hub e device ecc. Questi pacchetti non hanno dati payload.
• Data Packet (DP) il quale attraversa tutti i link lungo il percorso che connette l’host con il
device. Un Data Packet consiste di due parti: un Data Packet Header (DPH) che è simile ad
un TP ed un Data Packet Payload (DPP) che è costituito da un blocco di dati più 4 byte di
CRC32.
• Isochronous Timestamp Packet (ITP) che è un pacchetto multicast inviato dall’host a tutti i
link attivi.

Tipi di trasferimento
Ogni pacchetto non isocrono inviato ad un ricevitore viene da questo confermato con un handshake
(ACK transaction packet). A causa del fatto che la USB Super Speed dispone di due linee di
comunicazione indipendenti, il trasmettitore non ha bisogno di aspettare un esplicito handshake per
ogni pacchetto trasferito prima di inviare il successivo.
La USB 2.0 utilizza invece un modello di transizione seriale nel senso che un host deve iniziare e
completare una transizione (Token, Data, Handshake) prima di iniziare la successiva.
La USB Super Speed migliora le transizioni del protocollo USB 2.0 grazie all’uso di due percorsi
separati di trasmissione e ricezione. Il risultato di questa scelta determina la presenza di due
separati protocolli di transizione che consentono di avere più transizioni OUT e IN
contemporaneamente attive su bus. Se un endpoint riceve tre Data Packet, dovrà poi inviare tra
ACK Transaction Packet nell’ordine di ricezione.
Come già esposto, il protocollo USB 2.0 deve completare l’intera transizione IN o OUT prima di
poter iniziare la successiva che è sempre inviata dall’host in broadcast.
Per contro il protocollo USB Super Speed invia in unicast i pacchetti (tranne gli ITP) i quali
viaggeranno solo secondo precisi percorsi che conducono al destinatario.
Se il device non dispone di dati da inviare o non può riceverli, risponderà con un Not Ready
(NRDY). Quando il device sarà poi pronto a ricevere o inviare i dati, emetterà un Endpoint Ready
(ERDY) verso l’host per evidenziare la propria disponibilità.
Ogni device contiene nel descrittore dei suoi vari endpoint il valore della dimensione massima del
pacchetto che può scambiare.
L’allocazione di banda per la USB Super Speed è simile a quella della USB 2.0.
Data Bursting
Lo scambio dati in modo burst aumenta l’efficienza eliminando i tempi di attesa per gli
acknowledgement dei pacchetti.
Ogni endpoint di un device Super Speed contiene il valore del numero di pacchetti che può inviare
o ricevere (maximum data burst size) senza attendere un esplicito handshake.
Ogni endpoint ha il proprio maximum data burst size.
L’host può modificare dinamicamente la dimensione del burst size per transizione senza però
superare il massimo valore.
Trasferimento IN
L’host inizia un trasferimento inviando un pacchetto IN di acknowledgement al device.

Questo pacchetto contiene le informazioni di indirizzamento necessarie all’instradamento (route)
del pacchetto verso l’endpoint di destinazione.
L’host comunica al device il numero di pacchetti dati che esso può inviare ed il numero di sequenza
del primo pacchetto dati atteso dal device.
In risposta l’endpoint trasmetterà all’host i pacchetti dati con gli appropriati numeri di sequenza.
Il pacchetto di acknowledgement conferma implicitamente anche i precedenti pacchetti ricevuto
correttamente.
Si evidenzia che sebbene l’host debba inviare un pacchetto di acknowledgement per ogni pacchetto
dati ricevuto, il device può comunque inviare il numero di pacchetti dati richiesti senza aspettare
l’acknowledgement di ogni pacchetto.

Trasferimento OUT
L’host inizia un trasferimento inviando una raffica (burst) di pacchetti dati al device.
Ogni pacchetto dati contiene le informazioni di indirizzamento necessarie all’instradamento (route)
del pacchetto verso l’endpoint di destinazione con l’inclusione del numero di sequenza.
Per le transazioni non isocrone, il device risponde con un pacchetto di acknowledgement che
include il numero di sequenza del successivo pacchetto confermando implicitamente il pacchetto
corrente.
Si evidenzia che sebbene il device debba inviare un pacchetto di acknowledgement per ogni
pacchetto dati ricevuto, l’host può comunque inviare al device un numero (fino al maximum burst
size number) di pacchetti dati senza aspettare l’acknowledgement.
Power management
Quando un host invia un pacchetto ad un device attraverso un hub con una porta il cui link è in uno
stato non attivo (low power state), il pacchetto non potrà attraversare il link finché questo non
ritorna nello stato attivo. Nel caso di una transizione IN, l’host non sarà in grado di avviare la
successiva transizione fino al completamento di quella corrente.
L’effetto di questo meccanismo può determinare un grave degrado delle prestazioni.
Per compensare il meccanismo di power management ed ottenere buone prestazioni si utilizza la
tecnica del differimento temporale.
Quando un host inizia una transizione che coinvolge un link non attivo, l’hub intermedio risponde
con una richiesta di differimento della transizione causata dallo stato di low power del device ed
invitando l’host a procedere ad un altra transizione.
Contemporaneamente l’hub comunica al device di aver generato una richiesta di differimento
causata da un tentativo di avvio di una transizione.
Con questo meccanismo è possibile migliorare le prestazioni medie dovute al link power
management.
Controllo di trasferimenti
Il controllo dei trasferimenti nella USB 3.0 è identico a quello della USB 2.0.
Ogni device dovrà disporre di Default Control Pipe usata per l’inzializzazione e gestione del device
per mezzo delle informazioni predisposte nel descrittore del device (Endpoint 0).
Il sistema Super Speed offre il miglior supporto possibile per la consegna dei controlli di
trasferimento tra host e device. Come per la USB 2.0 non è possibili prenegoziare l’ampiezza di
banda per lo scambio dei controlli di trasferimento.
Il massimo valore del payload per i dati del controllo di trasferimento è fisso e pari a 512 byte con
un burst massimo unitario.
Un device Super Speed deve contenere un valore pari a 09H nel campo MaxPacketSise del suo
descrittore di device.
La Default Control Pipe deve poter supportare un valore massimo di sequenza compreso tra 0 e 31.

Trasferimento Bulk
Gli obiettivi e le caratteristiche del trasferimento bulk USB 3.0 sono simili a quelle della USB 2.0.
Il trasferimento bulk è utilizzato per quei device che scambiano grandi quantità di dati con
temporizzazione altamente variabile con qualsiasi disponibilità di banda.
In pratica garantisce la consegna dei dati ma non garantisce i ritardi e la banda.
Le caratteristiche di una pipe bulk risultano:
nel flusso di comunicazione i dati non hanno alcuna particolare struttura,
una pipe bulk è una pipe di tipo stream e quindi il flusso di comunicazione da o per l’host è
unidirezionale. Se una applicazione richiede un flusso di comunicazione bulk bidirezionale,
dovranno essere usate due pipe bulk una IN ed una OUT.
Un endpoint per un trasferimento bulk fissa nel suo descrittore di endpoint un valore del maximum
data packet payload di 1024 byte. Viene anche specificata la dimensione del burst che l’endpoint
può accettare, questo valore sarà compreso tra 1 e 16.
Tutti gli endpoint bulk dovranno supportare valori di sequenza compresi tra 0 e 31.
L’host dovrà essere in grado di gestire qualsiasi endpoint bulk con qualsiasi dimensione del burst.
L’host dovrà assicurare che nessun payload di dati inviato ad un endpoint con una transizione burst
sia più grande del maximum data packet payload e che non siano inviati più pacchetti di quelli
specificati dal maximum burst size.
Se in un trasferimento bulk vi sono più di 1024 byte di dati, questi saranno suddivisi in blocchi da
1024 byte tranne l’ultimo che conterrà i restanti.
Un trasferimento bulk sarà completato quando per l’endpoint si verifica:
il trasferimento della quantità di dati attesi,
il trasferimento di un pacchetto con meno di 1024 byte,
una risposta con uno STALL handshake.
Come per la USB 2.0, un endpoint bulk non ha alcun modo di indicare un desiderato valore di
ampiezza di banda per la pipe bulk e dovrà far uso della sola banda disponibile.
La USB Super Speed garantisce però un buon risultato per la consegna dei dati bulk.
Come per la USB 2.0, anche la USB Super Speed consente il trasferimento bulk stream per mezzo
di un protocollo che consente il multi stream.
Le stream trasferite tra host e device sono gestite da uno Stream Protocol il quale assegna ad ogni
stream una Stream ID (SID).
Il protocollo stream definisce un handshake il quale consente al device o all’host di definire una
Current Stream (CStream) ID associata ad un endpoint.
L’host usa la CStream ID per selezionare un comando o una operazione su uno specifico buffer
dell’endpoint che sarà usato per il successivo trasferimento sulla pipe.
Il device usa la CStream ID per selezionare il buffer dei dati che sarà usato.
Lo streaming dei dati avverrà quindi con un multiplessaggio dei dati nei vari buffer definiti per
mezzo delle CStream ID degli endpoint.
Un endpoint bulk standard ha un singolo insieme di buffer endpoint ad esso associati.
Lo streaming estende il numero di buffer host accessibili da un endpoint da 1 a 65533 con una
corrispondenza uno a uno tra buffer host e Stream ID.

Trasferimento Interrupt
Le caratteristiche del trasferimento interrupt USB 3.0 sono simili a quelle della USB 2.0.
Il trasferimento interrupt Super Speed è orientato a supportare device che richiedono un
trasferimento molto affidabile di piccole quantità di dati in limitati intervalli di tempo.
I trasferimenti interrupt vengono tentati (in modo isocrono) a intervalli predefiniti dall’endpoint.
Una volta che un trasferimento è stato effettuato con successo, non verrà effettuato un altro
tentativo fino al prossimo intervallo di sevizio.
Se un endpoint risponde con un not ready o con un ACK che indichi l’impossibilità ad accettare
altri pacchetti, l’host non tenterà altri trasferimenti verso l’endpoint fino alla notifica di ready e la
successiva attesa di un tempo pari al doppio dell’intervallo di servizio.
L’intervallo di servizio di un endpoint è riportato nel suo descrittore di endpoint.
Si rammenta che una pipe interrupt è una una pipe stream e pertanto è unidirezionale.
Nel trasferimento interrupt l’endpoint specifica la massima dimensione del pacchetto payload che
può essere movimentata sul bus.
La massima dimensione del payload è fissata a 1024 byte per endpoint che supportano dimensione
del burst maggiore di uno. La massima dimensione del burst per l’interrupt endpoint è pari a tre.
Tutti gli endpoint interrupt dovranno supportare valori di sequenza compresi tra 0 e 31.
Un host dovrà essere in grado di gestire tutte le possibili combinazioni di dimensioni di pacchetti e
dimensioni di burst nei trasferimenti interrupt senza mai superare quelle massime.
Nei trasferimenti di maggiori quantità di dati, tutti i payload dei vari burst dovranno essere della
massima dimensione consentita tranne l’ultimo che conterrà i restanti dati.
Un trasferimento interrupt sarà completato quando per l’endpoint si verifica:
il trasferimento della quantità di dati attesi,
il trasferimento di un pacchetto con un payload avente meno di 1024 byte,
una risposta con uno STALL handshake.
Nel trasferimento interrupt può essere allocata fino all’80% della banda disponibile.
Il descrittore di endpoint di una pipe interrupt specifica la durata dell’intervallo di servizio
desiderato il cui valore è dato da 2(bInterval-1) * 125 µSec con bInterval compreso tra 1 e 16.
Il System Software USB usa questa informazioni in fase di configurazione per definire il periodo di
servizio, il periodo definito dal System Software può essere più piccolo di quello desiderato dal
device fino al valore più piccolo definito dalla USB Super Speed (125 µSec).
Un Super Speed endpoint interrupt può trasferire fino ad un massimo di 3 pacchetti della massima
dimensione (1024 byte) per ogni intervallo di servizio.
Se un interrupt di un endpoint IN non ha dati da trasmettere o un interrupt endpoint OUT non ha
sufficiente spazio buffer per ricevere i dati durante l’accesso da parte dell’host, questo risponderà
con un messaggio di controllo di flusso.

Trasferimento Isocrono
Le caratteristiche del trasferimento isocrono USB 3.0 sono simili a quelle della USB 2.0.
Il trasferimento isocrono è usato per la movimentazione di dati che devono arrivare con la stessa
cadenza temporale con la quale sono stati generati (audio, video, telefonia ecc.).
Ogni errore in trasmissione non può essere corretto ne ritrasmesso.
A differenza della USB 2.0, la USB 3.0 non trasmette il campo di start of frame ma invia al device
le informazioni di temporizzazione per mezzo dell’Isochronous Timestamp Packet (ITP).
Una pipe isocrona Super Speed è una pipe stream e quindi è unidirezionale.
Se il device necessita di un flusso di comunicazione isocrono bidirezionale, si dovranno usare due
pipe isocrone, una per ogni direzione.
Il power management della Super Speed può interferire con il trasferimento isocrono quando i
pacchetti hanno bisogno di attraversare un link non attivo determinando un ritardo che non farà
arrivare i dati nell’intervallo di sevizio.
Questo problema viene risolto per mezzo di un meccanismo di PING e PING RESPONSE.
Prima di iniziare un trasferimento isocrono l’host invia al device un pacchetto di PING al quale il
device risponderà con un pacchetto di PING RESPONSE per confermare all’host che tutti i link
lungo il percorso sono nello stato attivo.
La massima dimensione del payload è fissata a 1024 byte per endpoint che supportano dimensione
del burst maggiore di uno. La massima dimensione del burst per un endpoint isocrono è pari a 16
anche se un endpoint isocrono può richiedere fino tre transizioni burst per ogni intervallo di sevizio.
Il protocollo Super Speed non richiede che il pacchetto dati isocrono sia della dimensione massima,
nel caso di trasferimento di un pacchetto dati di dimensioni inferiori a quella massima, questo non
sarà sottoposto a padding.
Un host dovrà essere in grado di gestire tutte le possibili combinazioni di dimensioni di pacchetti e
dimensioni di burst nei trasferimenti isocroni senza mai superare quelle massime.
L’host deve assicurare che nessun payload di pacchetto dati sia più grande della massima
dimensione consentita e analogamente per la massima dimensione del burst.
Nei trasferimenti di maggiori quantità di dati, tutti i payload dei vari burst dovranno essere della
massima dimensione consentita tranne l’ultimo che conterrà i restanti dati.
Nel trasferimento isocrono può essere allocata fino all’80% della banda disponibile.
Il descrittore di endpoint di una pipe isocrona specifica la durata dell’intervallo di servizio
desiderato il cui valore è dato da 2(bInterval-1) * 125 µSec con bInterval compreso tra 1 e 16.
Il System Software USB usa questa informazioni in fase di configurazione per definire il periodo di
servizio.
Un Super Speed endpoint isocrono può trasferire fino ad un massimo di 3 transizioni burst con un
massimo di 16 pacchetti della massima dimensione (1024 byte) per ogni intervallo di servizio.
Se un endpoint isocrono non ha dati da trasmettere durante l’accesso da parte dell’host, in risposta
alla richiesta invierà un pacchetto di lunghezza nulla.
Un endpoint isocrono trasmette i pacchetti di dati partendo dalla sequenza numero zero per ogni
intervallo di servizio, ogni successivo pacchetto dati trasmesso nello stesso intervallo di sevizio è
inviato con il più alto numero di sequenza, successivamente la numerazione sarà invertita da 31 a 0.

Affidabilità
Esistono diversi livelli di protezione per assicurare una affidabile consegna dei dati:
• Lo strato fisico della USB 3.0 assicura un bit error rate minore di 1 bit su 1012.
• Lo strato link della USB 3.0 ha un meccanismo che assicura un bit error rate minore di 1 bit
su 1020 per l’header del pacchetto. Per assicurare la consegna affidabile end to end
dell’header, lo strato link utilizza il framing ordinato dei pacchetti, il controllo di flusso e la
ritrasmissione.
• Lo strato protocol della USB 3.0 utilizza un CRC a 32 bit per il controllo dei dati del
payload ed una ritrasmissione su timeout.

Protocolli e Pacchetti
Transizioni Super Speed
Qualsiasi transizione Super Speed è sempre iniziata dall’host con una richiesta o un invio di dati
all’endpoint di un device e si conclude quando l’endpoint invia i dati o ne conferma la ricezione.
Un host Super Speed può iniziare una o più transizioni OUT verso uno o più endpoint mentre è in
attesa del completamento della transizione corrente.
Per contro, un host Super Speed non potrà iniziare una nuova transizione IN verso alcun endpoint
finché l’host:
• riceve un DP oppure un NRDY oppure uno STALL DP oppure un time out per il corrente
ACK TP inviato ad un endpoint non isocrono
• riceve tutti i DP che erano stati richiesti oppure uno short packet oppure un DP con l’ultimo
pacchetto con il flag di campo settato oppure un time out per il corrente ACK TP inviato ad
un endpoint non isocrono.
Per un trasferimento non isocrono, un endpoint può rispondere ad una transizione valida:
• ritornando un pacchetto di transizione NRDY
• nel caso di una transizione OUT, ritornando un pacchetto ACK
• nel caso di una transizione IN, ritornando uno o più pacchetti dati
• nel caso di un errore interno all’endpoint, ritornando un pacchetto di STALL.
Una risposta con un pacchetto NRDY indica che l’endpoint non è pronto a ricevere o inviare dati.
Ciò implica che non ci potrà essere alcuna attività tra l’host e l’endpoint del device finché
l’endpoint stesso non notifica il suo stato di pronto.
Questa situazione consente al link che collega l’host al device di entrare nello stato di low power
finché l’endpoint non passerà nello stato di pronto.
Quando l’endpoint sarà pronto invierà asincronamente all’host una notifica di ERDY per
comunicare la sua disponibilità a movimentare i dati.
Si noti che nei trasferimenti isocroni non si usano i pacchetti NRDY e ERDY in quanto gli
asservimenti avvengono a intervalli periodici e che i pacchetti inviati o ricevuti non vengono
confermati con un ACK.
Le transizioni non sono broadcast in quanto i pacchetti sono instradati su un percorso che collega
direttamente l’host al device. I link non usati possono essere posti nello stato di low power.

Tipologie di pacchetti
L’interfaccia USB 3.0 utilizza quattro tipi di pacchetti con uno o più sottotipi.
• Link Management Packets (LMP) utilizzato per la gestione del link ed in grado di viaggiare
solo tra coppie di link che connettono due porte.
• Transaction Packets (TP) usati per il controllo di flusso dei pacchetti dati, configurare
device e hub. Viaggiano su tutti i link che connettono host e device.
• Data Packets (DP) viaggiano su tutti i link che connettono host e device. Sono costituiti da
due parti: Data Packet Header (DPH) e Data Pachet Payload (DPP).
• Isochronous Timestamp Packets (ITP).
Tutti i pacchetti sono costituiti da un totale di16 byte dei quali 12 byte di header seguiti da 2 byte di
Link Control Word e conclusi con due byte di CRC 16 calcolati sui 12 precedenti byte e che
consentono un error rate minore di 1020 bit.
Tutti gli header hanno due campi comuni (Revision e Type) usati dal ricevente per stabilire le
modalità di processamento del pacchetto.
Se il valore del campo Type corrisponde a un Transaction Packet o a un Data Packet Header, il
campo Type è successivamente seguito dal campo Route String e dal campo Device Address.
Il campo Route String è usato dagli hub per instradare il pacchetto mentre il campo Device Address
è usato dall’host per conoscere la sorgente del pacchetto.
I pacchetti Data Packets contengono nell’header informazioni aggiuntive che descrivono alcune
caratteristiche del blocco dati.
Il blocco dati (Data Block) è sempre seguito da 4 byte di CRC 32 usati per verificare la correttezza
dei dati. Il Data Block ed il CRC 32 costituiscono il Data Packet Payload (DPP).
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Device Address Route String Type
Reserved Seq Num NumP HE RSVD Ept Num D rty Rsvd Sub Type
Reserved PP Reserved Stream ID / Reserved
Link Control Word CRC 16
Esempio di Transaction Packet
Il campo Type è costituito da 5 bit che identificano il formato del pacchetto con i seguenti valori:
Valore Descrizione
00000 Link Management Packet
00100 Transaction Packet
01000 Data Packet Header
01100 Isochronous Timestamp Packet
Tutti gli altri valori sono riservati
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CRC 5 (bit 0 ... 11) DF DL HUB Depth R Header Seq
Dettaglio del Link Control Word

Link Management Packet (LMP)
Questi pacchetti sono usati per la gestione di un singolo link.

Non contenendo campo di address e non sono instradabili.
Vengono generati dall’effetto di un comando sulla porta dell’hub.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Sub Type Specific Sub Type Type
Sub Type Specific
Sub Type Specific
Link Management Packet
Il campo Sub Type è costituito da 4 bit con i seguenti valori:
Valore Tipo di LMP

0000 Reserved
0001 Set Link Function
0010 U2 Inactivity Timeout
0011 Vendor Device Test
0100 Port Capability
0101 Port Configuration
0110 Port Configuration Response
0111 → 1111 Reserved
Set Link Function
Il pacchetto Set Link Function dell’LMP è usato per configurare la funzionalità senza lasciare lo
stato attivo (U0). Questo pacchetto è inviato dall’hub ad un device connesso ad una specifica porta.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved Set Link Function Sub Type Type
Reserved
Reserved
Set Link Function LMP
Il campo Set Link Function è costituito da 7 bit ma si usa solo il bit 1 del campo mentre i bit
0,2,3,4,5,6 sono Reserved. Il valore 0 indica De-assert, il vaolore 1 indica Assert.
U2 Inactivity Timeout
Il campo U2 Inactivity Timeout dell’LMP è usato per definire il timeout dallo stato U1 a quello U2
o il timeout dallo stato U0 a quello U2 se lo stato U1 è disabilitato.
Il campo U2 Inactivity Timeout è costituito da 8 bit e rappresentano il valore del timeout.

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved U2 Inactivity Timeout Sub Type Type
Reserved
Reserved
U2 Inactivity Timeout LMP
Vendor Device Test
Il campo Vendor Device Test dell’LMP è riferito al produttore del device e non è usato durante la
normale attività del link. I 64 bit dei campi Vendor Specific Data sono definiti dal produttore.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved Vendor Device Test Sub Type Type
Vendor Specific Data
Vendor Specific Data
Vendor Device Test LMP
Port Capability
Il pacchetto Port Capability LMP descrive le capacità di ogni porta del link ed è inviato da
entrambi i link partner dopo l’inizializzazione e avviamento del link.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved Link Speed Sub Type Type
Reserved Tiebreaker Rserv D Reserved Num HP Buffers
Reserved
Port Capability LMP
Il bit 9 del campo Link Speed se posto a 1 indica che il device supporta segnali a 5 Gbps
Il campo Num HP Buffers specifica il numero di buffer per i pacchetti header, per la USB 3.0 il
valore riportato è 4, tutti gli altri valori sono riservati.
I bit 16 e 17 del campo D (Direction) definiscono la capacità della porta di essere downstream o
upstream per mezzo del settaggio al valore 1 . Un solo bit può essere usato.
Questo campo è valido solo quando entrambi i bit del campo D sono posti a 1. Questo campo è
usato per determinare il tipo di porta quando vengono connessi due device con entrambe le capacità
di downstream e upstream. Quando entrambe le porte sono in downstream, solo quella con il più
alto valore di questo campo sarà effettivamente di downstream.
In tutti gli altri casi questo campo è posto a zero.

Transaction Packet (TP)
I pacchetti transaction (TP) viaggiano direttamente sul percorso che collega l’host al device e sono
usati per il controllo del flusso dati e la gestione della connessione end to end.
Il campo Route String è usato dagli hub per instradare i pacchetti che, arrivando sulla porta di
upstream, saranno canalizzati verso la corretta porta di downstream. Questo campo sarà posto a zero
per un pacchetto TP inviato da un device.
Quando il l’host invia un pacchetto TP, il campo Device Address contiene l’indirizzo del
destinatario.
Quando un device invia un TP all’host, pone il proprio indirizzo nel campo address così che l’host
possa conoscere il mittente.
In un pacchetto TP il campo SubType è usato dal destinatario per determinarne il formato e l’uso.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved Seq Num NumP HE RSVD Ept Num D rty Rsvd Sub Type
Transaction Packet
I 4 bit del campo SubType possono assumere i seguenti valori:
Valore Tipo di TP
0000 Reserved
0001 ACK
0010 NRDY
0011 ERDY
0100 STATUS
0101 STALL
0110 DEV NOTIFICATION
0111 PING
1000 PING RESPONSE
Acknowledgement Transaction Packet (ACK)
Questo pacchetto è usato in due situazioni:
• per un endpoint IN, questo pacchetto è inviato dall’host per richiedere dati al device oppure
per confermare la ricezione dei precedenti pacchetti.
• per un endpoint OUT, questo pacchetto è inviato da un device per confermare la ricezione
dei precedenti pacchetti di dati inviati dall’host oppure per informare l’host sul numero di
buffer dati disponibili dopo la ricezione del pacchetto attuale.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Device Address Route String / Reserved Type
Reserved Seq Num NumP HE Rsvd Ept Num D rty Rsvd Sub Type
ACK Transaction Packet

Il significato dei vari campi è il seguente:
Campo N° bit Descrizione

Route String 20 Questo campo è usato solo dagli hub per instradare i pacchetti verso la
corretta porta di downstream. Quando il pacchetto è inviato da un device,
questo campo è Reserved.
Device Address 7 Rappresenta l’indirizzo del device che invierà o riceverà il pacchetto TP.
SubType 4 Per un pacchetto ACK TP, questo campo sarà settato a 0001.
Rsvd 2 Reserved
Retry Data Packet (rty) 1 Questo campo è usato per segnalare che il pacchetto non è stato ricevuto o è
stato ricevuto errato e pertanto si chiede al trasmettitore di ritrasmettere uno
o più pacchetti iniziando da quello specificato nel campo Sequence Number.
Direction (D) 1 Specifica la direzione dell’endpoint il cui device è mittente o destinatario:
0 da host a device. 1 da device a host.
Endpoint Number (Ept Num) 4 Questo campo identifica un endpoint del device mittente o destinatario
Rsvd 3 Reserved
Host Error (HE) 1 Questo campo è valido solo quando un ACK TP è inviato da l’host a device.
Questo bit sarà settato a 1 se l’host non è in grado di accettare un pacchetto
dati valido a causa di un errore interno. Nel caso di un trasferimento non
isocrono, se l’host ha settato questo bit, dovrà settare anche il bit del campo
Retry Data Packet
Number of Packets (NumP) 5 Questo campo è usato per indicare il numero di buffer di pacchetti dati che il
ricevitore può accettare. Il valore di questo campo dovrà essere minore o
uguale del massimo burst size supportato dall’endpoint e riportato dal
descrittore dell’endpoint stesso.
Sequence Number (Seq Num) 5 Questo campo è usato per identificare il numero di sequenza del successivo
pacchetto dati atteso.
Reserved 6 Reserved
Stream ID / Reserved 16 Se il pacchetto di ACK TP è destinato a un endpoint bulk, questo campo
contiene un valore di Stream ID compreso tra 1 e 65535. il valore 0 è
riservato ad una pipe stream. Questo campo sarà settato a 0 se l’endpoint
bulk non supporta lo stream.
Reserved 11 Reserved
Packets Pending (PP) 1 Questo campo può essere settato solo dall’host per indicare la presenza di
altri pacchetti da inviare all’endpoint identificato dai campi Endpoint
Number e Direction. Se non vi sono altri pacchetti da inviare, il device può
usare questa informazione per passare nello stato low power.
Reserved 4 Reserved
Not Ready Transaction Packet (NRDY)
Questo pacchetto può essere inviato solo da un device con un endpoint non isocrono.
Un endpoint OUT invierà questo pacchetto all’host se non dispone di spazio buffer sufficiente per
accettare pacchetti dati inviati dall’host.
Un endpoint IN invierà questo pacchetto all’host se non è in grado di inviare un pacchetto dati in
risposta ad un ACK inviato dall’host .
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Device Address Reserved Type
Reserved Ept Num D Rsvd Sub Type
Reserved Stream ID / Reserved
NRDY Transaction Packet

Endpoint Ready Transaction Packet
Questo pacchetto può essere inviato solo da un device con un endpoint non isocrono.
Questo pacchetto è usato per informare l’host che l’endpoint è pronto per ricevere o inviare dati.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved NumP Reserved Ept Num D Rsvd Sub Type
Reserved Stream ID / Reserved
ERDY Transaction Packet
STATUS Transaction Packet
Questo pacchetto può essere inviato solo da un host e solo verso un endpoint di controllo.
É usato per informare l’endpoint di controllo che l’host ha iniziato la fase di Status di un
trasferimento di controllo.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved
STATUS Transaction Packet
STALL Transaction Packet
Questo pacchetto può essere inviato solo dall’endpoint di un device.

É usato per informare l’host che l’endpoint è nello stato di halt o che un trasferimento di controllo
non è valido.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved
STALL Transaction Packet
Device Notification Transaction Packet
Questo pacchetto può essere inviato solo da un device.

É usato dal device per informare l’host di un cambiamento asincrono dello stato del device o
dell’interfaccia. Questo pacchetto non è generato da un endpoint ma dal device in generale.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Notification Type Specific Notif. Type Sub Type
Notification Type Specific
Device Notification Transaction Packet

I 4 bit del campo Notification Type possono assumere i seguenti valori:
Valore Tipo di pacchetto di notifica

0000 Reserved
0001 Function Wake
0010 Latency Tolerance Message
0011 Bus Interval Adjustment Message
PING Transaction Packet
Questo pacchetto può essere inviato solo dall’host.

É usato dall’host per assicurarsi che tutti i link lungo il percorso siano attivi (stato U0) per poter
così iniziare un trasferimento asincrono.
Il device risponderà al pacchetto PING inviando all’host un pacchetto PING RESPONSE entro il
tempo definito dal tPingTimeout.
Il device manterrà il suo link nello stato U0 fino alla ricezione del successivo pacchetto dall’host o
fino allo scadere del tPingTimeout.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved Ept Num D RsvdP Sub Type
Reserved
PING Transaction Packet
PING RESPONSE Transaction Packet
Questo pacchetto può essere inviato solo da un device in risposta ad un pacchetto PING inviato
dall’host. Per ogni PING ricevuto dovrà essere inviato un corrispondente PING RESPONSE
relativo allo specifico endpoint.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved Ept Num D RsvdP Sub Type
Reserved
PING RESPONSE Transaction Packet
Data Packet
Questo pacchetto può essere inviato sia da un host che da un device.

L’host usa questo pacchetto per inviare dati ad un device.
Il device usa questo pacchetto per inviare dati all’host in risposta ad un ACK.
Tutti i pacchetti dati sono comprensivi di un Data Packet Header e di un Data Packet Payload.
Il pacchetto dati viaggia direttamente lungo il percorso tra l’host ed il device.
É possibile inviare pacchetti dati con blocchi dati di lunghezza nulla ma sempre corredati di CRC32

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
H Device Address Route String/Reserved Type
E Data Length S Rsvd Ept Num D eob Rsvd Seq Num
A lpf
D Reserved PP Reserved Stream ID/Reserved
E
R Link Control Word CRC 16
P Data DWORD 0
A
.....
Y
L .....
O
.....
A
D CRC 32
ESEMPIO di Pacchetto Dati
Il significato dei vari campi è il seguente:
Campo N° bit Descrizione

Sequence Number 5 Questo campo è usato per identificare il numero di sequenza del pacchetto
dati che può arrivare fino a 31.
End of Burst (eob) 1 eob è relativo ad un endpoint non isocrono:
nel caso di un endpoint IN non isocrono, questo bit è usato per identificare
l’ultimo pacchetto del burst. Nel caso di un endpoint OUT non isocrono o di
un endpoint di controllo, questo bit è posto a zero.
Last Packet Flag (lpf) lpf è relativo ad un endpoint isocrono:

per un endpoint isocrono, questo bit è usato per identificare l’ultipo
pacchetto dell’ultimo burst nel corrente intervallo di servizio.
Questo bit può essere settato sia dall’host che dal device.
Endpoint Number 4 Questo campo identifica un endpoint del device mittente o destinatario
Setup (S) 1 Questo bit può essere settato solo dall’host per indicare che il pacchetto dati
è un pacchetto di Setup.
Data Length 16 Questo campo è usato per indicare il numero di byte presenti nel payload
con l’esclusione dei byte di CRC 32.
Isochronous Timestamp Packet (ITP)
I pacchetti ITP sono usati per la consegna del timestamp dall’host verso tutti i device attivi al fine di
trasferire le informazioni sulla temporizzazione e sincronizzazione.
Il pacchetto, che può essere inviato solo dall’host, non ha indirizzo ne informazioni sul routing ed è
inviato in multicast dagli hub su tutte le porte di downstream aventi il link nello stato attivo U0 e
così pure per l’host. I device non rispondono al pacchetto ITP.
L’host potrà trasmettere un pacchetto ITP nell’intervallo all’interno della tTimestampWindow e
iniziando dal tIsochronousTimestampStart successivo all’attivazione della porta root dell’host
derivante da uno stato di polling.
Il pacchetto ITP può essere trasmesso tra due pacchetti di burst.
Se un device riceve un pacchetto ITP con il flag delay (DL) settato all’interno del campo Link
Control Word, il valore del timestamp può essere impreciso e quindi ignorato dal device.

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Isochronous Timestamp Type
Reserved Bus Interval
Adjustment Control
Reserved
Isochronous Timestamp Packet
I 27 bit del campo Isochronous Timestamp identificano il valore corrente del timestamp.
Questo campo è diviso in due sottocampi:
i primi 14 bit (Bus interval counter) rappresentano un contatore a 1/8 di millisecondo, il conteggio
si evolve verso lo zero e poi si incrementa fino al valore 3FFF.
i successivi 13 bit (Delta) rappresentano il numero di unità di tIsochTimestampGranularity e
indicano la risoluzione temporale per l’inizio del bus interval rispetto al clock dell’host.
Se il pacchetto parte esattamente all’inizio del bus interval, il valore del Delta è posto a zero.
Indirizzamento Triplo
Per l’accesso al destinatario, i pacchetti Data e Transaction fanno uso di tre campi indirizzo:
Device Address, Endpoint Number e Direction.
Dopo l’accensione o dopo un reset l’indirizzo del device è posto a zero di default, successivamente,
durante il processo di enumerazione, l’host assegnerà l’indirizzo di lavoro con un valore compreso
nel range 1 – 127.
I devices possono avere fino ad un massimo di 15 endpoint IN e 15 OUT secondo quanto indicato
dal campo Direction.
Route String
La Route String è un campo di 20 bit usato per l’instradamento del pacchetto.

Il campo è costituito dalla concatenazione dei vari numeri di porta di downstream (4 bit) per ogni
hub attraversato per raggiungere il device (massimo 5 livelli di hub).
Ogni hub attraversato sarà in grado di individuare i 4 bit di sua competenza per mezzo di un valore
detto Hub Depth il quale è assegnato ad ogni hub durante il processo di enumerazione.
19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Hub@Tier5 Hub@Tier4 Hub@Tier3 Hub@Tier2 Hub@Tier1
Il valore Hub@Tier1 rappresenta il numero di porta di downstream dell’hub connesso alla porta
root dell’host e così via per gli altri campi.
Essendo il numero di porta dell’hub definito da 4 bit, il numero massimo di porte è pari a 15.

Caratteristiche elettriche
Il collegamento elettrico tra host e device o hub è realizzato con il seguente circuito:
TX+ RX+
+ +
_ _
TX- RX-
Host Cable Device
RX+ TX+
+ +
_ _
RX- TX-
Connector Connector
Si evidenzia:
l’accoppiamento in c.a. tramite le due coppie di condensatori
l’utilizzo della modalità differenziale
la comunicazione full duplex
l’utilizzo, per i segnali, di coppie twisted o twinax
La struttura del cavo USB 3.0 è visibile nella figura seguente:
Oltre ai due fili di massa e alimentazione,

sono distinguibili tre coppie:
una coppia UTP per i segnali USB 2.0
due coppie SDP (Shielded Differential Pair)
per i segnali USB 3.0 collegate a massa ed
eventualmente al system ground.
Un rivestimento metallico (braid) è utilizzato

per il contenimento di tutti i cavi ed è
collegato al guscio metallico del connettore
per limitare i disturbi EMI.
Il diametro esterno è compreso tra 3 e 6 mm.
L’assegnazione dei pin è descritta dalla seguente tabella:
Wire N° Signal Name Description Color

1 PWR Power Red
2 UTP D– Unshielded twisted pair negative White
3 UTP D+ Unshielded twisted pair positive Green
4 GND PWRrt Ground for power return Black
5 SDP1– Shielded differential pair 1 negative Blue
6 SDP1+ Shielded differential pair 1 positive Yellow
7 SDP1 Drain Drain wire for SDP1
8 SDP2– Shielded differential pair 2 negative Purple
9 SDP2+ Shielded differential pair 2 positive Orange
10 SDP2 Drain Drain wire for SDP2
Braid Shield Cable external braid to be 360°
terminated on to plug metal shell

Il diametro dei cavi secondo, lo standard AWG, risulta il seguente:
Wire N° Signal Name Wire Gauge (AWG)

1 PWR 20 – 28
2 UTP D– 28 – 34
3 UTP D+ 28 – 34
4 GND PWRrt 20 – 28
5 SDP1– 26 – 34
6 SDP1+ 26 – 34
7 SDP1 Drain 28 – 34
8 SDP2– 26 – 34
9 SDP2+ 26 – 34
10 SDP2 Drain 28 – 34
Riferimenti bibliografici:
USB 1.0 Specification – Jan 1996 (268pg) - www.usb.org
USB 2.0 Specification – Apr 2000 (650 pg) - www.usb.org
USB 3.0 Specification – Nov 2008 (482 pg) - www.usb.org

Interfaccia Usb v1 To v3

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Interfaccia Usb v1 To v3

Caricato da

Copyright:

Formati disponibili

Interfaccia

A.C. Neve – Interfaccia USB 1.0 to 3.0 1

1.x Low Speed 1.5 Mbps

Dev1 Dev2 Hub2 Hub3 Dev5

A.C. Neve – Interfaccia USB 1.0 to 3.0 2

• Il trasferimento di dati è temporizzato su un periodo base, detto frame, di 1 mSec.

1 mSec Frame 1 mSec Frame

• Lo standard USB consente la connessione o disconnessione dei devices in qualsiasi istante.

A.C. Neve – Interfaccia USB 1.0 to 3.0 3

Livello Per l’host è il software applicativo

A.C. Neve – Interfaccia USB 1.0 to 3.0 4

• Le due principali classi di devices USB sono Hub e Function (Periferiche).

Port 1 Port 2 Port 3

Port 6 Port 5 Port 4

A.C. Neve – Interfaccia USB 1.0 to 3.0 5

rilevazione della connessione e disconnessione dei dispositivi

via software invece gestisce le seguenti azioni:

configurazione e assegnazione degli indirizzi dei devices

A.C. Neve – Interfaccia USB 1.0 to 3.0 6

Host e Device: sono i principali componenti di un sistema USB

A.C. Neve – Interfaccia USB 1.0 to 3.0 7

L’interfaccia gestisce il flusso di comunicazione tra il software applicativo e la periferica USB.

• Un endpoint è una parte, univocamente identificabile, di un device USB e rappresenta il punto

Le pipe vengono attivate una volta che il device è configurato.

A.C. Neve – Interfaccia USB 1.0 to 3.0 8

Una message pipe opera invece in modo differente.

• In un sistema USB, i dati, organizzati in pacchetti e opportunamente strutturati, sono movimentati

I sistemi USB consentono quattro modalità di trasferimento:

• Il trasferimento control è usato per l’invio di comandi, configurazioni, e informazioni di stato

A.C. Neve – Interfaccia USB 1.0 to 3.0 9

La frequenza di bus e la temporizzazione dei frame limitano il massimo numero di trasferimenti di

Il trasferimento isocrono ha le seguenti caratteristiche:

garantisce un accesso alla banda USB con un limitato tempo di latenza

Una pipe isocrona è sempre unidirezionale. La descrizione dell’endpoint definisce l’ingresso o

La frequenza di bus e la temporizzazione dei frame limitano il massimo numero di trasferimenti

A.C. Neve – Interfaccia USB 1.0 to 3.0 10

garantisce alle pipe il massimo periodo di servizio

Una interrupt pipe è sempre unidirezionale ed è sempre in ingresso all’host.

La frequenza di bus e la temporizzazione dei frame limitano il massimo numero di trasferimenti

accesso al bus in funzione della disponibilità di banda

A.C. Neve – Interfaccia USB 1.0 to 3.0 11

La frequenza di bus e la temporizzazione dei frame limitano il massimo numero di trasferimenti

Si dice transfer management il processo di assegnazione della banda ai vari devices.

A.C. Neve – Interfaccia USB 1.0 to 3.0 12

La serie B mini è usata da dispositivi di piccole

Tutti i connettori non hanno sistemi di bloccaggio.

PIN Nome Colore Note

Il cavo deve essere in grado di resistere a strappi di minimo 45 Newton.

Lo schermo del connettore deve essere collegato al piedino GND.

Gauge Diametro filo Resistenza DC Lunghezza max

A.C. Neve – Interfaccia USB 1.0 to 3.0 13

il circuito proposto illustra una tipica realizzazione del driver.

la figura proposta illustra le forme d’onda dei segnali.

A.C. Neve – Interfaccia USB 1.0 to 3.0 14

Stato del BUS Livelli dei segnali

A.C. Neve – Interfaccia USB 1.0 to 3.0 15

A.C. Neve – Interfaccia USB 1.0 to 3.0 16

A.C. Neve – Interfaccia USB 1.0 to 3.0 17

A.C. Neve – Interfaccia USB 1.0 to 3.0 18

Tutti i pacchetti iniziano con un campo SYNC di sincronizzazione.

Campo di identificazione del pacchetto

Il PID indica il tipo di pacchetto, il formato ed il tipo di controllo d’errore.

PID PID PID Bit Descrizione