Ciao a tutti. A volte le persone sono interessate a sapere in cosa differisce USB 3.0 da USB 2.0, a volte vogliono capire quale versione o tipo di connettore USB hanno sul proprio computer, che tipo di dinosauro USB 1.0 è e così via. Approfondiamo un po' più a fondo questo argomento.

Lo standard USB è apparso a metà degli anni '90. Decifrato USB Ecco come - Bus seriale universale. Questo standard è stato sviluppato appositamente per la comunicazione tra dispositivi periferici e un computer e ora occupa una posizione di leadership tra tutti i tipi di interfacce di comunicazione. Ciò non sorprende. Al giorno d'oggi è difficile immaginare un dispositivo senza connettore USB, sebbene questi connettori varino nel tipo.

Tipi di connettori USB

Oggi ce ne sono abbastanza un gran numero di tipi di connettori USB. Alcuni sono più comuni, altri meno. Ad ogni modo, diamo loro un'occhiata.

USBtipo-UN– uno dei tipi più comuni di connettori USB. Potresti averlo visto sul tuo, sul, sul blocco caricabatterie e non solo. Ha molti usi. Con esso puoi collegare mouse e tastiere a un computer (o altro dispositivo), unità flash, unità esterne, smartphone e così via. Questo elenco può essere continuato per molto tempo se ci pensi.

USBtipo-B– il connettore viene utilizzato principalmente per collegare una stampante o altri dispositivi periferici al computer. Ricevuto molto meno diffuso di USB di tipo A.

MiniUSB era molto comune su dispositivi mobili ah prima dell'avvento della Micro USB. Al giorno d'oggi è molto raro, ma puoi ancora trovarlo su alcuni dispositivi più vecchi. Sul mio altoparlante audio portatile, il connettore Mini USB riceve l'elettricità per caricare la batteria. Ho comprato questo altoparlante circa 5 anni fa (si è rivelato durevole).

Micro USB ora utilizzato su smartphone e cellulari quasi tutti i produttori. Questo connettore USB ha guadagnato un'incredibile popolarità tra i dispositivi mobili. Tuttavia, USB Type-C sta gradualmente prendendo la sua posizione.

USB Versione 1.0 – Scavi Archeologici

Il trisnonno dello standard USB è USB 1.0è nato nel freddo novembre del 1995. Ma è nato un po’ prematuro e non ha guadagnato molta popolarità. Ma il suo fratello minore USB 1.1, nato tre anni dopo, era un esemplare più valido e riusciva ad attirare abbastanza attenzione.

Per quanto riguarda la parte tecnica, la velocità di trasferimento dei dati era ridotta, ma per gli standard di quei tempi questa velocità era più che sufficiente. La velocità arrivava fino a 12 Mbit/s e in modalità ad alto rendimento.

Differenze tra connettori USB 2.0 e USB 3.0

USB 2.0 e USB 3.0 sono due standard USB completamente moderni che ora vengono utilizzati ovunque nei computer e nei laptop. USB 3.0 è, ovviamente, più recente e più veloce e ha anche la versione completa compatibile con versioni precedenti con dispositivi USB 2.0. Ma la velocità in questo caso sarà limitata alla velocità massima secondo lo standard USB 2.0.

In teoria, le velocità di trasferimento USB 3.0 sono circa 10 volte più veloci di USB 2.0 (5 Gbps contro 480 Mbps). Ma in pratica, la velocità di scambio delle informazioni tra i dispositivi è spesso limitata dai dispositivi stessi. Anche se in generale USB 3.0 vince ancora.

Differenze tecniche

Sebbene gli standard USB 2.0 e USB 3.0 siano retrocompatibili, presentano tuttavia alcune differenze tecniche. USB 2.0 ha 4 pin: 2 per l'alimentazione dei dispositivi e 2 per il trasferimento dei dati. Questi 4 pin sono stati mantenuti nello standard USB 3.0. Ma oltre a loro sono stati aggiunti altri 4 contatti necessari per ad alta velocità trasferimento dati e ricarica più rapida dei dispositivi. A proposito, USB 3.0 può funzionare con corrente fino a 1 Ampere.

Di conseguenza, il cavo standard USB 3.0 è diventato più spesso e la sua lunghezza ora non supera i 3 metri (in USB 2.0 la lunghezza massima ha raggiunto i 5 metri). Ma puoi caricare il tuo smartphone molto più velocemente, anche se colleghi più smartphone a un connettore tramite uno splitter.

Naturalmente i produttori si sono presi cura delle differenze visive. Non è necessario cercare la confezione della scheda madre per vedere quali standard USB supporta. E non è necessario accedere alle impostazioni del computer o a Gestione dispositivi per farlo. Basta guardare il colore del connettore. Il connettore USB 3.0 è quasi sempre blu. Molto raramente è anche rosso. Mentre USB 2.0 è quasi sempre nera.

Ora, con una rapida occhiata, puoi determinare se sul tuo laptop è installata la porta USB 2.0 o USB 3.0.

Questa è probabilmente la fine della conversazione su come USB 2.0 differisce da USB 3.0.

Conclusione

Cosa abbiamo imparato da questo articolo? Quella USB è divisa in standard di trasferimento dati, che differiscono per la velocità di trasferimento dati. E anche l'USB ha un gran numero di tipi di connettori.

E la cosa più interessante che ho dimenticato di menzionare nell'articolo è che i tipi di connettori possono essere combinati come segue. È possibile trovare un connettore USB di tipo A di dimensioni standard e un connettore USB di tipo A di dimensioni standard USB di tipo B, allo stesso tempo ci sono (ma rari) micro USB tipo A e micro USB tipo B (molto comuni). USB di tipo A può funzionare utilizzando il protocollo USB 2.0 o magari utilizzando il protocollo USB 3.0. In generale, se vuoi, puoi confonderti.

E se sei preoccupato su quali connettori sia meglio scegliere per un laptop USB 2.0 o USB 3.0, non preoccuparti affatto. Ora tutti i laptop e computer moderni sono dotati di entrambi i tipi di USB. Ad esempio, il mio laptop ha due connettori USB 2.0 e un connettore USB 3.0. E tutti e tre i connettori sono USB di tipo A.

Ecco cosa sono: USB!

Hai letto fino alla fine?

questo articolo è stato utile?

Non proprio

Cosa non ti è piaciuto esattamente? L'articolo era incompleto o falso?
Scrivi nei commenti e promettiamo di migliorare!

Bit rate di segnalazione ad alta velocità - 12 Mb/s - Lunghezza massima del cavo per bit rate di segnalazione ad alta velocità - 5 m - Bit rate di segnalazione a bassa velocità - 1,5 Mb/s - Lunghezza massima del cavo per bit rate di segnalazione a bassa velocità baud rate - 3 m - Numero massimo di dispositivi collegati (inclusi moltiplicatori) - 127 - È possibile collegare dispositivi con baud rate diversi - Non è necessario che l'utente installi elementi aggiuntivi come terminatori per SCSI - Tensione di alimentazione per dispositivi periferici - 5 V - Consumo massimo di corrente per dispositivo - 500 mA

Cablaggio connettori USB 1.1 e 2.0

I segnali USB vengono trasmessi su due fili di un cavo schermato a quattro fili.

Qui :

GND- circuito “case” per l'alimentazione delle periferiche V AUTOBUS- +5V anche per circuiti di alimentazione Bus D+ progettato per la trasmissione dei dati

Pneumatico D- per ricevere dati.

Svantaggi dell'USB 2.0

Sebbene velocità massima Il trasferimento dati USB 2.0 è di 480 Mbit/s (60 MB/s), nella vita reale non è realistico raggiungere tali velocità (~33.5 MB/s in pratica). Ciò è dovuto ai grandi ritardi sul bus USB tra la richiesta di trasferimento dei dati e l'effettivo inizio del trasferimento. Ad esempio, il bus FireWire, sebbene abbia un throughput di picco inferiore di 400 Mbps, ovvero 80 Mbps (10 MB/s) in meno rispetto a USB 2.0, consente in realtà un throughput maggiore per lo scambio di dati con dischi rigidi e altri dispositivi di archiviazione delle informazioni dispositivi. A questo proposito diversi drive mobili sono da tempo limitati dalla larghezza di banda pratica insufficiente di USB 2.0.

Il vantaggio più significativo di USB 3.0 è la sua maggiore velocità (fino a 5 Gbps), che è 10 volte più veloce della porta precedente. La nuova interfaccia ha migliorato il risparmio energetico. Ciò consente all'unità di entrare in modalità di sospensione quando è inattiva. È possibile effettuare contemporaneamente la trasmissione dati bidirezionale. Ciò consentirà una velocità maggiore se colleghi più dispositivi a una porta (dividi la porta). È possibile diramarsi utilizzando un hub (un hub è un dispositivo che si dirama da una porta in 3-6 porte). Ora, se colleghi l'hub a una porta USB 3.0 e colleghi più dispositivi (ad esempio, chiavette USB) all'hub ed effettui un trasferimento dati simultaneo, vedrai che la velocità sarà molto più elevata rispetto a quella USB interfaccia 2.0. C'è una caratteristica che può essere un vantaggio e un svantaggio. L'interfaccia USB 3.0 ha aumentato la corrente a 900 mA e USB 2.0 funziona con una corrente di 500 mA. Questo sarà un vantaggio per i dispositivi che sono stati adattati per USB 3.0, ma un piccolo svantaggio è che potrebbe esserci un rischio quando si caricano dispositivi più deboli, come un telefono. Lo svantaggio fisico della nuova interfaccia è la dimensione del cavo. Per mantenere l'alta velocità, il cavo è diventato più spesso e più corto (non può essere più lungo di 3 metri) rispetto a USB 2.0. Va notato che è importante che i dispositivi con diverse interfacce USB lo facciano lavoro bene e non dovrebbe essere un problema. Ma non pensare che la velocità aumenterà se colleghi USB 3.0 a una porta più vecchia o colleghi un cavo di interfaccia più vecchio a una nuova porta. La velocità di trasferimento dei dati sarà uguale alla velocità della porta più debole.

• Esercitazione

Proiezione illustrata del modello di rete OSI sull'Universal Serial Bus.

Tre livelli "straordinari" dello stack USB

Non ero soddisfatto dell'aspetto dello stack USB, che si trova molto spesso su Internet:

Stack USB non molto utile

Livello bus, logico, funzionale... Queste sono, ovviamente, meravigliose astrazioni, ma sono più probabili per coloro che realizzeranno un driver o un software applicativo per l'host. Dal lato del microcontrollore, mi aspetto un modello di macchina a stati finiti, nei cui nodi di solito incorporiamo il nostro codice utile, e all'inizio, secondo tutte le leggi del genere, fallirà. Oppure il software sull'host sarà difettoso. O un autista. In ogni caso qualcuno fallirà. È anche impossibile capire subito le librerie MK. E così guardo il traffico Bus USB un analizzatore, in cui gli eventi che si verificano in una lingua sconosciuta non rientrano affatto nei tre livelli notevoli. Mi chiedo se ho una tale dissonanza nella mia testa a causa della febbre influenzale?

Se il lettore ha avuto sensazioni simili, offro una visione alternativa di uno stack USB, che all'improvviso mi è apparso chiaramente nel mio cervello surriscaldato, basato sull'amato modello OSI a 7 strati. Mi sono limitato a cinque livelli:

Non voglio dire che tutti i software e le librerie siano già stati realizzati o debbano essere progettati sulla base di questo modello. Per ragioni ingegneristiche, il codice con i livelli sarà molto misto. Ma voglio aiutare coloro che iniziano a conoscere il bus USB, che vogliono comprendere i protocolli di scambio dei dispositivi e la terminologia della materia, ad avvicinarsi esempi già pronti, biblioteche e navigarle meglio. Questo modello non è da caricare in MK, ma nelle vostre menti brillanti, cari amici. E poi le tue mani d'oro faranno tutto da sole, non ho dubbi :)

Quindi, andiamo, correggi se vedi errori. Questa è una bozza, e se qualcosa del genere è già stato disegnato da qualche parte, mi scuso, non sono riuscito a trovarlo, quindi l'ho realizzato da solo. Penso che l’immagine non scapperà, ma per ora spiegherò al pubblico rispettabile perché ho iniziato questa pubblicazione.

Un altro flashback degli anni Novanta

Ho eliminato il mio primo bug dal codice di qualcun altro alla fine degli anni Novanta, mentre lavoravo da studente. Era pppd per FreeBSD, che poi abbiamo installato sul pool di modem. I modem Motorola erano bloccati in fase di riaggancio, nessuno riusciva a comunicare, la linea era perduta e l'unico metodo rimasto tramite PPP keep-alive era per qualche motivo difettoso. È stato allora che ho scoperto che per qualche motivo pppd stava aspettando sei byte di risposta LCP invece dei quattro richiesti. Mi sentivo così pazzo allora agitatore di insetti degli anni Novanta :-) Cosa c'entra il PPP? È proprio simile all’USB: pacchetto e punto-punto. È vero, a differenza di USB 2.0, è full duplex.

Che ci piaccia o no, è chiaro che l'evoluzione dei microcontrollori non si fermerà. No, no, e apparirà nelle pubblicazioni (http://habrahabr.ru/post/208026/, http://habrahabr.ru/post/233391/) "periferiche pesanti" - implementazioni del bus USB integrate nel MK, con esempi di analisi, utilizzo di HID, ecc. Dobbiamo rendere omaggio all'autore RaJa: degli otto esempi riportati in libreria standard STSW-STM32121 (UM0424) e in qualche modo, ha scelto quello più utile (Custom HID), lo ha portato nell'ambiente Em::Blocks gratuito, delineato in un linguaggio chiaro, abbelliscilo un po', bravo! Questo mi ha fatto risparmiare un sacco di tempo.

Come posso raggiungere la biblioteca?

Dopo aver ricevuto il progetto RHIDDemo per Em::Blocks gentilmente pubblicato su GitHub dall'autore, ho iniziato a portarlo su Keil (il mio debugger CoLink basato su FTDI; qualcuno mi dice il plugin Coocox per Em::Blocks). Ma non riuscivo proprio a capire: dove diavolo ha preso l'autore SPL 3.6.1 del 2012, se il sito pubblicava 3.5.0 del 2011? Ho affrontato una ricerca piuttosto noiosa, che con mia sorpresa ha portato... direttamente a un progetto HID personalizzato già pronto per Keil come parte della libreria USB FS 4.0.0. Giace in bella vista, come un topo sotto una scopa. Allora ok. Ma alla fine sono arrivato alle versioni di STMicroelectronics, ho trovato una descrizione della libreria USB FS STSW-STM32121 (UM0424) e ho fermato i tentativi dello sviluppatore di farmi impazzire. Dimmi, è normale inserire il CMSIS 1.30 vintage del 2009 nel set SPL 3.5.0 del 2011, nascondere il nuovo SPL 3.6.1 del 2012 in USB-FS 4.0.0 del 2013 (inserendo CMSIS 3.0.1 del 2012 in anche lì), nonostante abbiano postato Versione attuale CMSIS 3.30 versione 2014? A proposito, in SPL 3.6.x per STM32F10X, sono stati corretti un paio di bug con USART relativi ai segnali di overflow del buffer. Grazie, almeno hanno lasciato delle note di rilascio...

HID contro SNMP

Quindi, dopo aver preso in mano l'STM32F103C8T6, ho deciso anche di approfondire un po' l'argomento USB HID, l'astrazione USB HID si adatta molto bene al concetto di tutti i tipi di sensori, sensori e altri driver di potenza controllati da PWM. In qualche modo mi ha ricordato SNMP, solo in una forma molto semplificata: i descrittori HID svolgono il ruolo di un MIB SNMP. Quando il dispositivo viene inizializzato dall'host: “Hello, host! Sono una caffettiera. Ho un pulsante [start], [panna], controlli [zucchero], [caffè rimanente], [acqua rimanente], [zucchero rimanente], [panna rimanente]. Accosta gli autisti, premi il pulsante, prendiamo un caffè. Non ti ricorda niente? Un esempio di dialogo SNMP: “Bene, ciao, una stazione di gestione con software da $ 100.000. E ho uno chassis per switch da $ 200.000 e ho altri 4 moduli per $ 100.000 ciascuno; ognuno ha 16 porte in più con velocità indecente, ed è semplicemente impossibile elencare tutte le funzioni qui... chiedi separatamente per ogni articolo; oh, sì, il carico del processore è così e così, la memoria è così e così...” E un'altra dozzina di pagine con lo stesso spirito.

Mi piaceva l'idea di HID. Ma non appena ho lasciato Windows oltre i compiti didattici dei LED lampeggianti (verso i veri ambienti UNIX!), ha iniziato a filtrare attraverso tutte le crepe non sigillate e mi sono sentito come una specie di zoppo indifeso. Durante il debug del progetto, ho istintivamente preso una sorta di tcpdump (è così che si chiama: usbdump(8) o usbmon), ma ho visto solo messaggi in una lingua sconosciuta.

È diventato ovvio: mancano le conoscenze fondamentali sul bus USB. Se uno specialista IT esperto capisce il modello OSI e lo stack TCP/IP da qualche parte a livello del midollo spinale semplicemente per necessità, allora con USB la situazione è diversa. È comprensibile: lì puoi (è necessario) spiare il traffico attraverso lo stesso tcpdump e configurare l'hardware e il software, ma qui è completamente plug and play e puoi sistemare qualcosa aggiornando il driver o il firmware (o reinstallando il sistema operativo). Ma ci siamo riuniti qui solo per creare un buon firmware, giusto? Dopo aver letto alcune descrizioni USB online, sono rimasto sorpreso da quanto possa essere confusa la documentazione. Ho avuto addirittura la sensazione che volessero deliberatamente portarci fuori strada, diffondendo la nebbia ed eliminando la concorrenza sul nascere. Non sono d'accordo con questo stato di cose!

Un altro ottimo schema

Su Internet mi sono imbattuto in un'altra illustrazione (era in formato BMP, non è uno scherzo):

Inizialmente sembra ottimista. Infine, la pila viene smontata. I fotogrammi però sono poco marcati: li disegnerei con linee tratteggiate verticali, e EOF è solo una pausa, in realtà non viene trasmesso nessun dato. Ma iniziamo a leggere il contesto e perdiamo la comprensione della vera intenzione dell’autore (per confonderci):

Il controller host dell'interfaccia bus USB genera personale;
Personale trasmesso mediante trasmissione di bit seriale utilizzando il metodo NRZI.

Ed eccone un altro:

ogni telaioè costituito dalla massima priorità pacchi, la cui composizione è formata dal conducente ospite;
ogni trasmissione consiste in una o più operazioni;
ogni transazione è composta da Pacchetti;
ogni sacchetto di plasticaè costituito da un identificatore di pacchetto, dati (se presenti) e un checksum.

Sembra che tutto sia disegnato correttamente, ma man mano che leggi le domande diventano sempre di più. La struttura dati minima trasmessa sul bus è una trama o un pacchetto? In generale, dovremmo guardare dall’alto verso il basso o viceversa? E cosa viene codificato utilizzando il metodo NRZI: frame, pacchetti o semplicemente l'intero flusso di bit sul bus? Le transazioni consistono in un pacco, un trasferimento o forse qualche tipo di pacco di valore?
Perché non puoi semplicemente: l'host raggruppa i pacchetti in transazioni e li distribuisce in intervalli di tempo chiamati frame per dare priorità ai dati critici in termini di tempo (video, audio) in base alla larghezza di banda corrente del bus? Sì, l'USB ha delle sfumature nella pianificazione dei trasferimenti di pacchetti, non ne parlerò ancora.

La mia visione dello stack USB

Considero USB in a NutShell menzionato qui sull'hub (evviva, traduzione), così come USB Made Simple, una buona documentazione. Sulla base di loro, ho assemblato la mia versione dello stack USB, la disegnerò di nuovo.

Strato fisico

A livello fisico, un insieme di modi elettrici di una coppia differenziale di conduttori (insieme alla terra) viene utilizzato per designare gli stati con cui viene codificato il flusso di bit utilizzando il metodo NRZI con bit stuffing: qui dopo sei “1” consecutivi ( beh, volevo trasmettere, diciamo 0xffff) "0" è inserito in modo che il ricevitore non rimanga bloccato nello stesso stato per molto tempo; ricevitore UN Non è inserito uno "0" e non verrà conteggiato come dati; questa è una tecnica abbastanza comune nella codifica per una migliore sintonizzazione automatica delle frequenze; Una coppia di fili insieme alla terra consente di formare almeno quattro stati statici (sono designati J, K, SE0, SE1). In USB 2.0, SE1 non viene utilizzato, e i tre restanti vengono inoltre riprodotti in dinamica (con clock e transizioni) per trasmettere molti altri caratteri di controllo (limiti dei pacchetti, reset, connessione/disconnessione, risparmio energetico/uscita). Ci sono buone illustrazioni in USB Made Simple, Parte 3 - Flusso di dati.
Quelli. Di conseguenza, i dati vengono trasmessi sotto forma di zero e uno, più tutti i tipi di caratteri di controllo, in modo che da questa intera cucina elettrodinamica possano essere preparati normali pacchetti di dati.
(aggiunto su richiesta dei lettori)

Livello di lotto

A livello di pacchetto, i pacchetti senza indirizzo vengono trasmessi tra l'host e il dispositivo (una coppia di dispositivi su una linea half-duplex può fare a meno dell'indirizzamento). Il pacchetto è costituito da un marcatore SYNC per sincronizzare l'orologio del ricevitore, una sequenza di byte e un carattere EOP. La lunghezza del pacchetto è variabile, ma viene negoziata attraverso i livelli superiori dello stack. Il primo byte si chiama Packet Identifier (PID), ha un formato semplice e ridondante per l'immunità al rumore ed è adatto per essere inviato alla macchina di livello successivo (per assemblare transazioni dai pacchetti). I pacchetti con riempimento (più lunghi di un byte PID) vengono forniti con un checksum (short CRC5 o long CRC16, a seconda del tipo di pacchetto). L'analizzatore di protocollo dovrebbe, come minimo, mostrarci i pacchetti.

Livello di transazione

Al livello successivo da Pacchetti stanno andando transazioni. Una transazione è un piccolo insieme di pacchetti (in Full Speed ​​​​USB 1, 2 o 3), rigorosamente uno dopo l'altro, che (in modalità half-duplex) l'host scambia con un endpoint, e uno solo. È molto importante che solo l'host apra la transazione; questa è una specificità USB (con il firmware MK ci sono meno problemi). A livello di transazione possiamo parlare canale(pipe) tra l'host e uno degli endpoint del dispositivo, ma sto intenzionalmente evitando il termine "Data Link" dal modello OSI. L'analizzatore di protocollo deve almeno decodificare le transazioni.

Livello di marcia

Sopra le transazioni posizioneremo il livello dei trasferimenti. Ne esistono quattro tipi nell'USB: trasferimenti di controllo con endpoint n. 0, trasferimenti di interruzione, trasferimenti isocroni e trasferimenti di massa. Gli ultimi tre sono varianti dei canali di streaming (stream pipe), di cui dirò qualche parola più avanti. Questo livello dovrebbe anche mostrare un buon analizzatore di protocollo.

Livello di applicazione

In cima alla pila, come al solito, c'è il livello dell'applicazione. Quello che succede qui è: impostare l'indirizzo del dispositivo da parte dell'host, raccontare al dispositivo di se stesso nel linguaggio dei descrittori, comandi host per selezionare una configurazione (trasmissioni di controllo), scambiare dati con dispositivi HID (negli esempi ho trovato un trasmissione con interruzioni finora, voglio provare quella di controllo), stampa su stampante e scansione, accesso alla memoria USB (blocco grande), comunicazione tramite cuffie e webcam (isocrona) e molte altre cose fantastiche.

Tocco finale

Scendendo per un secondo di livello, possiamo aggiungere che l'host periodicamente lancia sul bus quegli stessi pacchetti Start of Frame (SOF), dividendo il tempo in intervalli uguali, ma in modo tale da non interrompere le transazioni stesse. Pertanto, i pacchetti SOF possono essere considerati transazioni indipendenti. Il frame USB non deve essere confuso con l'omonimo livello di collegamento dati del modello OSI. È meglio ricordare i frame (frame) di un CD audio, questo è solo un quanto di tempo: l'host “ticchetta” nel bus con i pacchetti SOF in modo che i dispositivi collegati pianifichino in anticipo di partecipare al cosiddetto. trasmissioni isocrone, guidando i flussi di dati in tempo reale. Bene, o così: i gruppi di transazioni sono pianificati dall'host in intervalli di tempo chiamati frame. Un frame è 1ms su Full Speed ​​e 125μs su High Speed ​​USB, ma High Speed ​​è uno standard più complesso, è meglio studiarlo separatamente.
AGGIORNAMENTO:
I lettori hanno posto una bella domanda: che dire della frammentazione? Non ho trovato alcun segno di frammentazione in USB 2.0 a livello di transazione e inferiore, ad es. Le transazioni si intendono trasmesse nella loro interezza. In alcuni casi, i trasferimenti possono e devono essere suddivisi in più transazioni, soprattutto tenendo conto delle modalità isocrone. E ripeto che per ora l'host si occupa di tutta la pianificazione per noi (da parte di MK dobbiamo pensarci meno).

Osservando il traffico USB

Una buona selezione di illustrazioni si trova nel libro citato USB Made Simple, capitolo 5: www.usbmadesimple.co.uk/ums_5.htm

Eccone uno

Quindi la transazione viene sempre avviata dall'host in relazione a un endpoint selezionato sul dispositivo (oltre al punto speciale con il numero 0, su un dispositivo possono essercene fino a 15, ad esempio una tastiera a combinazione con un mouse, termometro, chiavetta USB, macchina per il caffè e un pulsante di chiamata per ordinare una pizza all'idraulico).
Se l'host riceve dati dal dispositivo, quest'ultimo non può aprire autonomamente una transazione, ma può solo attendere il momento giusto e prenderne parte. L'host apre una transazione verso il dispositivo con un pacchetto con PID = IN (gruppo Token) e garantisce la libertà del bus per il tempo richiesto, il dispositivo lancia un pacchetto dal gruppo Dati, a seconda del tipo di transazione, l'host può confermare successo con il terzo pacchetto del gruppo Handshake (ACK, NAK, STALL, NYET ), la transazione viene chiusa.
Quando si inviano dati al dispositivo (PID = OUT, gruppo Token), l'host apre una transazione, invia un pacchetto di dati (Data) e, a seconda della modalità, può anche ricevere un pacchetto di Handshake che conferma il successo della transazione.
Al termine della transazione tutto tornerà alla normalità, il dispositivo attenderà nuovamente i pacchetti di controllo dall'host.

Modalità di trasferimento USB negli esempi STM32 USB FS

Per poter utilizzare una coppia di fili per copiare da un disco contemporaneamente con un flusso audio-video, gesti del mouse e un segnale dell'oscilloscopio ad alta velocità, sono disponibili tipi diversi messaggi e trasmissioni.
Appena sopra ho appena descritto un semplice canale in streaming(Stream Pipe) tra l'host e l'endpoint, dove i pacchetti con il riempimento (Gruppi di dati) non trasportano alcuna informazione speciale o di controllo al sottosistema USB stesso. Completa libertà di corrispondenza, la libreria del controller deve fornire primitive per scaricare un buffer di dimensione arbitraria dalla memoria del MK all'host o viceversa. Lascia che sia la libreria MK insieme al driver host a gestire il taglio in pacchetti, l'inoltro e la "deframmentazione". In STM32 questi sono USB_SIL_Write() e USB_SIL_Read(), descritti in UM0424. Sono il livello logico di astrazione. Sul lato host, vedere la descrizione del driver appropriato (ad esempio, su FreeBSD è ugen(4)).
Ritengo però blasfemo utilizzare periferiche pesanti come USB per organizzare un semplice canale di streaming (la domanda è: cosa c'è che non va in USART?). Ma ovviamente ci sono tutti i tipi di situazioni.
In ogni caso, affinché il sottosistema USB possa prendere vita e il dispositivo possa essere rilevato, è necessario uno scambio di transazioni di controllo.

DISCLAIMER

Verranno menzionati ulteriori esempi dalla stessa libreria UM0424 per lavorare con USB Full Speed ​​​​di STMicroelectronics, ma sono progettati per le loro schede demo native. Prendi un esempio dall'autore Raja, mostra esperienza ingegneristica nell'adattare i progetti alla tua demo board.

Sul software è tutto chiaro: sono esempi non per uso industriale, potrebbero esserci dei bug, alcune parti (come la tabella dei collegamenti nell'esempio Mass storage) sono protette da brevetto e non si ha il diritto di utilizzarle in un progetto commerciale. Ma non è niente, i cinesi poi riescono a vendere sul mercato prodotti USB, per i quali non si preoccupano nemmeno di cambiare la libreria VID e PID.

Per il ferro, a quanto ho capito, devi iniziare con il quarzo. Ho una Chelyabinsk PinBoard II con quarzo da 12 MHz (tutte le librerie sono progettate per 8 MHz), ho cambiato il moltiplicatore PLL da 9 a 6 (link con spiegazioni), altrimenti il ​​MK accelererà a 108 MHz invece di 72 MHz, e USB non andrà a 72 MHz invece dei 48 MHz richiesti. Puoi anche rallentare la velocità MK a 48 MHz modificando il divisore del bus USB da uno e mezzo a uno. Agli specialisti non piace utilizzare il generatore interno dell'HSI MK: la frequenza può variare leggermente a causa del riscaldamento ed è difficile prevedere le conseguenze per l'USB. Beh, non dimenticare la periferia, ovviamente. Senza memoria flash SPI/SDIO, dall'esempio della memoria di massa puoi solo creare un analogo di /dev/null, ma non puoi formattarlo :-)

Controllare le trasmissioni e i canali dei messaggi

Pensando all'USB, ricordo il buon vecchio protocollo PPP con i suoi LCP, IPCP, CCP e anche xsCP. Lo scambio di messaggi di tipo speciale tra l'host e l'endpoint n. 0 è l'equivalente locale di x3CP.
Attraverso le trasmissioni di controllo, il dispositivo viene inizializzato, riceve un indirizzo e racconta se stesso all'host nel linguaggio dei descrittori (in modo che possa trovare e attivare il driver richiesto). Senza operazioni di controllo, il semplice streaming non funzionerà; se il dispositivo non risponde nel modulo, l'host spegnerà rapidamente la porta: è necessario seguire il protocollo.
In linea di principio, il protocollo non vieta di restare punto di controllo N. 0 e scambio di dati, simile alla modalità di interruzione. Allo stesso tempo, pensaci: come aggiornerai il firmware MK, per così dire, sul campo? Hai il programmatore pronto? C'è un'altra soluzione.
Esempio: Aggiornamento del firmware del dispositivo

Trasmissioni interrotte

Questa varietà ( interrompere il trasferimento) è destinato allo scambio di piccole transazioni simili a quelle di controllo. No, il dispositivo non può interrompere l'host, attende il polling, la loro frequenza e dimensione dei pacchetti sono specificate in anticipo nel descrittore del dispositivo. Adatto a tutti i tipi di telecomandi, sensori, mouse, LED e altre macchine da caffè HID. Il canale con interruzioni in ogni punto è unidirezionale.
Esempi: NASCOSTO personalizzato, Mouse con joystick, Porta COM virtuale

Trasmissioni isocrone

Χρόνος in greco significa “tempo”. Trasmissione isocrona ( trasferimento isocrono) - locale ad alta tecnologia che consente di gestire i flussi di dati in tempo reale. Presenta una larghezza di banda garantita (ma non necessariamente ampia) e nessuna transazione di conferma, proprio come UDP con QoS. Pacchetto rotto? È stato il dio Chronos a spingere MK sulla gamba. Non è necessario provare a rispedire il pacco, altrimenti Dio si arrabbierà. Tuttavia, controlliamo silenziosamente i checksum di Chronos. I trasferimenti isocroni sono utili per i sistemi audio-video e di misurazione in tempo reale, così come per altri giocattoli duplice scopo. Anche se alcuni di loro potrebbero. È più interessante riagganciare una sorta di AVR, collegandolo al nostro ARM tramite USART o SPI. Le operazioni isocrone sono coinvolte nella segnalazione dei frame (ricordate il ticchettio di un pacchetto SOF).
Esempio: Altoparlante vocale USB

Trasmissioni a grandi blocchi

No, non porteremo sacchi di cemento. Penso che tutti abbiano imparato la modalità operativa dei vari Unità USB. Trasferimenti trasferimento in blocco hanno l'obiettivo di inviare dati quanto più e velocemente possibile, sempre con il trasferimento di pacchetti spezzati, ma senza garanzie sulla larghezza di banda, cedendoli se necessario a trasmissioni isocrone (come nel TCP senza QoS). DI struttura interna Ho già parlato delle chiavette USB, ora puoi scaricare ed eseguire un prototipo funzionante. Non l'ho provato personalmente, ma la tabella dei comandi SCSI nella descrizione dell'esempio (per così dire) è piuttosto simbolica. Non ho trovato alcun segno di un algoritmo di gestione dell'usura per la memoria NAND :-)
NOTA: la protezione del brevetto STM si applica in alcuni punti.
Esempio: Memoria di massa

Ciò che resta non rivelato

Non ho l'obiettivo di realizzare un altro libro di testo su USB, ce ne sono abbastanza senza di me e sono ben descritti: la parte elettrica, i dettagli del protocollo, il lavoro con gli hub, il linguaggio descrittore e il livello di astrazione HID, problemi con VID/ Unicità PID, USB 3.0 e molte altre meravigliose funzionalità del bus USB, utili per noi e non tanto. Per gli esperti IT consiglio soprattutto un'escursione nel lato oscuro con una panoramica dei dispositivi nemici (una chiavetta USB con una tastiera HID mascherata che farà cose terribili).

Collegamenti

Adattamento dell'esempio Custom HID all'ambiente Em::Blocks gratuito e alla scheda demo economica STM32F103C8T6 prodotta da LC-Tech Industrial Electronics e Persone IT. Questa è una sorta di ingegneria Yin e Yang, ognuno di noi ha una parte di entrambi.

Gli ingegneri elettronici industriali hanno eccellenti conoscenze e competenze nell'hardware; saldano sottilissimi componenti radio con la mano sinistra con gli occhi chiusi (e poi funziona). Guardando circuito elettronico, iniziano quasi fisicamente a sentire tutte le sue correnti con potenziali, lavorano anche con circuiti di potenza e con prodotti industriali (grandi, veloci, pericolosi). L’approccio alla programmazione dell’MK è appropriato: deve semplicemente fornire i livelli logici necessari alle gambe giuste al momento giusto, non importa in che modo. Sono conservatori nella tecnologia (non interferiscono, funziona), le periferiche MK pesanti non sono particolarmente favorite. Quando si parla di programmazione orientata agli oggetti, informazioni di sicurezza, progetti giganteschi con un milione di righe di codice e ogni sorta di fantasiose interfacce grafiche stanno diventando noiosi. Invece del bus USB orientato ai pacchetti, preferiscono la modalità streaming USART, arricchita dal solito RS-232 o dal più brutale RS-485 (bus seriale per applicazioni industriali, fino a 10 Mbit/s a 15 m, fino a 100 kbit/s a 1200m, fino a 32 dispositivi).

Le persone IT sono educate a capire sistemi operativi, infrastrutture di rete e interazioni complesse, l'élite è esperta nella sicurezza delle informazioni e comprende tutti i tipi di modi invisibili per penetrare nel sistema di qualcun altro. Alcune persone amano davvero i gatti (come puoi non amarli? Io, invece, non li allevo, non li allevo e non cucino :-). Molte persone amano la libertà di informazione, criticano le aziende/governi e sconfiggono le forze della natura con il potere del pensiero. Sono patologicamente pigri, ma amano le nuove tecnologie e gli enigmi ingegneristici contorti con giocattoli costosi (preferibilmente risolti a livello di software o, in casi estremi, di jumper). I rapporti con il saldatore sono custoditi: non chiedete all'informatico se gli piace il saldatore, potrebbe fraintendere; Meglio chiedergli se gli piace saldare circuiti elettronici.

Di cosa sto parlando? Vediamo semplicemente questo mondo in modo diverso... Dopotutto kernel Linux Gli stessi ragazzi lo hanno ritagliato dai moduli C e dagli inserti in assembler per piattaforme specifiche, e sembravano cavarsela senza holivar. Vedo un progetto veramente serio come un sistema multi-core che combina gli ultimi microcontrollori con periferiche pesanti, ma non escludo abbinamenti con modelli classici come AVR: possono essere utilizzati per appendere alcune punte di diamante critiche e in rapida rotazione del progresso tecnico. Se il codice è stato testato per anni, perché no?

Aggiungere etichette

USB (Bus seriale universale- "bus seriale universale") - interfaccia seriale trasferimento dati per periferiche a media e bassa velocità.Per il collegamento viene utilizzato un cavo a 4 fili, con due fili utilizzati per ricevere e trasmettere dati e 2 fili per alimentare il dispositivo periferico. Grazie alle linee integrate Alimentazione USB consente di collegare periferiche senza alimentazione propria.

Informazioni di base

cavo USB è costituito da 4 conduttori in rame: 2 conduttori di potenza e 2 conduttori dati in doppino intrecciato e una treccia con messa a terra (schermo).

Cavi USB avere suggerimenti fisicamente diversi “al dispositivo” e “all’host”. Possibile Implementazione USB dispositivi senza cavo, con punta “to-host” integrata nel corpo. È anche possibile integrare permanentemente il cavo nel dispositivo(ad esempio, tastiera USB, fotocamera Web, mouse USB), sebbene lo standard lo proibisca per i dispositivi a piena velocità e ad alta velocità.

Bus USB strettamente orientato, ovvero ha il concetto di "dispositivo master" (host, noto anche come controller USB, solitamente integrato nel chip South Bridge su scheda madre) e "dispositivi periferici".

I dispositivi possono ricevere alimentazione a +5 V dal bus, ma potrebbero anche richiedere un'alimentazione esterna. È inoltre supportata una modalità standby per dispositivi e splitter su comando dal bus, rimuovendo l'alimentazione principale mantenendo l'alimentazione in standby e accendendola su comando dal bus.

Supporti USBCollegamento e scollegamento a caldo dei dispositivi. Ciò è possibile grazie all'aumento della lunghezza del conduttore del contatto di terra rispetto a quelli del segnale. Quando connesso connettore USB sono i primi a chiudere contatti di terra, i potenziali delle custodie dei due dispositivi diventano uguali e l'ulteriore collegamento dei conduttori di segnale non porta a sovratensioni, anche se i dispositivi sono alimentati da fasi diverse di una rete di alimentazione trifase.

A livello logico Dispositivo USB supporta le transazioni per la ricezione e la trasmissione dei dati. Ogni pacchetto di ciascuna transazione contiene un numero punto finale sul dispositivo. Quando un dispositivo è connesso, i driver nel kernel del sistema operativo leggono un elenco di endpoint dal dispositivo e creano strutture di dati di controllo per comunicare con ciascun endpoint sul dispositivo. Viene chiamata la raccolta di endpoint e strutture dati nel kernel del sistema operativo tubo.

Endpoint, e quindi i canali, appartengono a una delle 4 classi:

1) flusso (alla rinfusa),

2) manager (controllo),

3) isocrono (isoch),

4) interruzione.

I dispositivi a bassa velocità come un mouse non possono avere canali isocroni e di flusso.

Canale di controllo progettato per lo scambio di brevi pacchetti di domande-risposte con il dispositivo. Qualsiasi dispositivo ha il canale di controllo 0, che lo consente Software Lettura del sistema operativo brevi informazioni informazioni sul dispositivo, inclusi produttore e codici modello utilizzati per selezionare il driver e un elenco di altri endpoint.

Canale di interruzione consente di consegnare pacchetti brevi in ​​entrambe le direzioni, senza ricevere una risposta/conferma, ma con la garanzia dei tempi di consegna: il pacchetto verrà consegnato entro N millisecondi. Ad esempio, utilizzato nei dispositivi di input (tastiere, mouse o joystick).

Canale isocrono consente di consegnare pacchetti senza garanzia di consegna e senza risposte/conferme, ma con una velocità di consegna garantita di N pacchetti per periodo di bus (1 KHz per bassa e massima velocità, 8 KHz per alta velocità). Utilizzato per trasmettere informazioni audio e video.

Canale di flusso fornisce una garanzia di consegna di ciascun pacchetto, supporta la sospensione automatica della trasmissione dei dati a causa della riluttanza del dispositivo (buffer overflow o underrun), ma non garantisce velocità e ritardo di consegna. Utilizzato, ad esempio, in stampanti e scanner.

Orario dell'autobusè suddiviso in periodi, all'inizio del periodo il controllore trasmette il pacchetto “inizio periodo” all'intero bus. Successivamente, durante il periodo, vengono trasmessi i pacchetti di interrupt, poi quelli isocroni nella quantità richiesta, per il restante tempo del periodo vengono trasmessi i pacchetti di controllo ed infine i pacchetti di stream;

Lato attivo dell'autobusè sempre il titolare del trattamento, il trasferimento di un pacchetto di dati dal dispositivo al titolare del trattamento avviene come una breve domanda da parte del titolare del trattamento e una lunga risposta del dispositivo contenente i dati. Il programma di movimento dei pacchetti per ciascun periodo del bus viene creato congiuntamente dall'hardware del controller e dal software del driver, utilizzato da molti controller DMA ad accesso diretto alla memoria (Accesso diretto alla memoria) - modalità di scambio di dati tra dispositivi o tra il dispositivo e la memoria principale, senza partecipazione Processore centrale(PROCESSORE). Di conseguenza, la velocità di trasferimento aumenta poiché i dati non vengono inviati avanti e indietro alla CPU.

La dimensione del pacchetto per un endpoint è una costante incorporata nella tabella degli endpoint del dispositivo e non può essere modificata. Viene selezionato dallo sviluppatore del dispositivo tra quelli supportati dallo standard USB.

Specifiche

Funzionalità USB:

Alta velocità di trasferimento (bit rate di segnalazione a piena velocità) - 12 Mb/s
- Lunghezza massima del cavo per velocità di trasferimento elevate - 5 m
- Bit rate di segnalazione a bassa velocità - 1,5 Mb/s
- Lunghezza massima del cavo per baud rate basso - 3 m
- Numero massimo di dispositivi collegati (inclusi moltiplicatori) - 127
- È possibile collegare dispositivi con velocità di trasmissione diverse
- Non è necessario che l'utente installi elementi aggiuntivi come terminatori SCSI
- Tensione di alimentazione per periferiche - 5 V
- Consumo massimo di corrente per dispositivo - 500 mA

Cablaggio connettori USB 1.1 e 2.0

I segnali USB vengono trasmessi su due fili di un cavo schermato a quattro fili.

Qui :

GND- circuito “case” per l'alimentazione delle periferiche
V AUTOBUS- +5V anche per circuiti di alimentazione
Pneumatico D+ progettato per la trasmissione dei dati

Pneumatico D- per ricevere dati.

Svantaggi dell'USB 2.0

Sebbene la velocità di trasferimento massima Dati USB 2.0 è di 480 Mbit/s (60 MB/s), nella vita reale non è realistico raggiungere tali velocità (~33,5 MB/s in pratica). Ciò è dovuto ai grandi ritardi sul bus USB tra la richiesta di trasferimento dei dati e l'effettivo inizio del trasferimento. Ad esempio, FireWire, sebbene abbia un throughput di picco inferiore di 400 Mbps, ovvero 80 Mbps (10 MB/s) in meno rispetto a USB 2.0, in realtà consente un throughput di trasferimento dati maggiore. dischi fissi e altri dispositivi di archiviazione delle informazioni. A questo proposito diversi drive mobili sono da tempo limitati dalla larghezza di banda pratica insufficiente di USB 2.0.

Fornisce lo scambio di dati tra l'host e il dispositivo. A livello di protocollo, vengono risolti compiti come garantire l'affidabilità e l'affidabilità della trasmissione e il controllo del flusso. Tutto il traffico sul bus USB viene trasferito tramite transazioni; in ogni transazione, lo scambio è possibile solo tra l'host e il dispositivo indirizzato (il suo endpoint).

Tutte le transazioni (scambi) con dispositivi USB sono costituite da due o tre pacchetti. Le tipiche sequenze di pacchetti nelle transazioni sono mostrate in Fig. 1. Ogni transazione viene pianificata e avviata dal controller host, che invia un pacchetto di token di transazione. Il token della transazione descrive il tipo e la direzione del trasferimento, l'indirizzo del dispositivo USB selezionato e il numero dell'endpoint. L'apparecchio indirizzato dal marcatore riconosce il proprio indirizzo e si prepara allo scambio. La fonte dati identificata dal token trasmette il pacchetto di dati. A questo punto, le transazioni relative ai trasferimenti isocroni sono completate: non vi è alcuna conferma della ricezione del pacchetto. Per altri tipi di trasmissioni esiste un meccanismo di conferma che garantisce la consegna garantita dei dati. I formati dei pacchetti sono mostrati in Fig. 2, i tipi di pacco sono nella tabella. In tutti i campi del pacchetto, ad eccezione del campo CRC, i dati vengono trasmessi per primi con il bit meno significativo (il bit meno significativo è mostrato a sinistra nei diagrammi temporali). Il pacchetto inizia con la sequenza Sync e termina con il terminatore - EOP. Il tipo di pacchetto è determinato dal campo PID. Lo scopo dei restanti campi è spiegato di seguito. La lunghezza dei campi Sync ed EOP è specificata per le trasmissioni su FS/LS; per le trasmissioni ad alta velocità, il campo Sync viene esteso a intervalli di 32 bit e l'EOP a 8 (nei pacchetti SOF, il campo EOP è lungo 40 bit). ).

Tutti i pacchetti ricevuti vengono controllati per verificare la presenza di errori, poiché i formati di pacchetto accettati e alcune convenzioni consentono:

• un pacchetto inizia con una sequenza di sincronizzazione seguita dal suo PID (Packet Identifier). L'identificatore è seguito dalla sua copia inversa: Check. Se due copie non corrispondono, viene considerato un errore;
• Il corpo del pacchetto (tutti i campi del pacchetto, esclusi PID e l'attributo EOP) è protetto da un codice CRC: 5 bit per i pacchetti marker, 16 bit per i pacchetti dati. Un CRC che non corrisponde al valore atteso è considerato un errore;
• il pacchetto termina con uno speciale segnale EOP; Se il pacchetto contiene un numero di byte non intero, viene considerato errato. Un falso EOP, anche su un limite di byte, non consentirà la ricezione del pacchetto a causa di un errore CRC quasi inevitabile in questa situazione;
• i dati a pacchetto vengono trasmessi al livello fisico (al bus) utilizzando il bit stuffing (uno zero viene inserito dopo sei bit da uno), che impedisce la perdita di sincronizzazione dei bit durante un segnale monotono. Ricevere più di sei bit di seguito è considerato un errore (su HS - un segno della fine del frame).

Il rilevamento di uno qualsiasi di questi errori in un pacchetto fa sì che il destinatario lo consideri non valido. Né il dispositivo né il controller host rispondono ai pacchetti ricevuti con un errore. Nella trasmissione isocrona, i dati del pacchetto non validi dovrebbero semplicemente essere ignorati (andranno persi); Per altri tipi di trasmissioni vengono utilizzati mezzi per garantire una consegna affidabile.

Per rilevare la mancata risposta del peer a un pacchetto, ciascun dispositivo dispone di un contatore di timeout che smette di attendere una risposta dopo che è trascorso un certo tempo. L'USB ha un limite al tempo di andata e ritorno del bus: il tempo dalla fine dell'EOP del pacchetto generato fino alla ricezione dell'inizio del pacchetto di risposta. Per il dispositivo finale (e il controller host), il ritardo massimo di risposta (tempo di risposta) dalla fine dell'EOP visto all'introduzione dell'inizio del pacchetto è normalizzato. Per gli hub il ritardo di trasmissione dei pacchetti è normalizzato; per i cavi è normalizzato il ritardo di propagazione del segnale. Il contatore di timeout deve tenere conto del ritardo massimo possibile per una configurazione di bus valida: fino a 5 hub intermedi, fino a 5 metri per cavo. Il valore di timeout consentito, espresso in intervalli di bit (bt), dipende dalla velocità:

• Per le velocità FS/LS, il ritardo introdotto da un segmento di cavo è piccolo rispetto all'intervallo di bit (bt). Sulla base di ciò, USB 1.0 utilizza il seguente modello per calcolare i ritardi consentiti. Per ogni segmento di cavo è assegnato un ritardo consentito di 30 ns e per l'hub di 40 ns. Pertanto, cinque hub intermedi con i loro cavi introducono un ritardo di 700 ns durante una doppia rivoluzione, che corrisponde a circa 8,5 bt su FS. Per un dispositivo FS, il ritardo di risposta non deve superare 6,5 bt (e tenendo conto del suo cavo - 7,5 bt). Sulla base di ciò, la specifica richiede che i trasmettitori su FS utilizzino un contatore di timeout di 16-18 bt;
• a velocità HS, il ritardo nel segmento del cavo è molto maggiore dell'intervallo di bit e in USB 2.0 il modello di calcolo è leggermente diverso. Qui vengono assegnati 26 ns a ciascun segmento del cavo e 4 ns più 36 bt all'hub. Pertanto, attraversando 6 segmenti di cavo due volte (2×6×26 = 312 ns ≈ 150 bt) e cinque hub (2×5×4 = 40 ns ≈ 19 bt più 2×5×36 = 360 bt) occorrono fino a 529 bt. Il ritardo di risposta del dispositivo è accettabile fino a 192 bt, mentre il ritardo totale tenendo conto di cavi e hub sarà fino a 721 bt. Sulla base di ciò, la specifica richiede che i trasmettitori su HS utilizzino un contatore di timeout di 736-816 bt.

Il controller host dispone di un proprio contatore di errori associato a ciascun endpoint di tutti i dispositivi, che viene reimpostato su zero quando viene pianificata ogni transazione. Questo contatore conta tutti gli errori di protocollo (inclusi gli errori di timeout) e se il numero di errori supera la soglia (3), il canale con questo endpoint viene arrestato e il suo proprietario (driver del dispositivo o USBD) viene informato. Fino al superamento della soglia, l'host gestisce gli errori relativi ai trasferimenti non isocroni tentando di ritentare le transazioni, senza avvisare il software client. I trasferimenti isocroni non vengono ripetuti; l'host segnala immediatamente gli errori.

I pacchetti di handshake vengono utilizzati per il riconoscimento, il controllo del flusso e la segnalazione degli errori. Di questi pacchetti, l'host controller può inviare al dispositivo solo un pacchetto ACK, confermando la corretta ricezione del pacchetto dati. Il dispositivo utilizza i seguenti pacchetti di handshake per rispondere all'host:

ACK - conferma (positiva) del completamento con successo di una transazione di output o di controllo;
NAK - conferma negativa, è segno che il dispositivo non è pronto per eseguire questa transazione (non ci sono dati da trasmettere all'host, non c'è spazio nel buffer per la ricezione, l'operazione di controllo non è stata completata). Questa è una risposta normale di cui nessuno verrà a conoscenza tranne il controller host, che sarà costretto a ripetere la transazione in seguito. Nelle transazioni di input, il dispositivo fornisce una risposta NAK invece di un pacchetto di dati se non sono pronti;
STALL è un messaggio di errore grave che significa che senza un intervento software speciale, lavorare con questo endpoint diventa impossibile. Questa risposta viene comunicata sia al driver USBD, che annulla ulteriori transazioni con questo punto, sia al driver client, da cui si attende l'intervento del software per sbloccare il punto. Nelle transazioni di controllo (Control), la risposta STALL significa non eseguibile di questa richiesta; Non è necessario sbloccare il punto.

Il controllo del flusso di uscita che si basa esclusivamente sulla capacità di rispondere con un NAK se il dispositivo non è pronto costituisce un uso molto inefficiente della larghezza di banda del bus: un grande pacchetto di dati viene sprecato sul bus per garantire che il dispositivo non sia pronto. In USB 2.0, questo problema viene evitato nelle transazioni Bulk-OUT e di controllo utilizzando il protocollo Ping. L'host può verificare la disponibilità del dispositivo a ricevere una dimensione massima del pacchetto inviandogli un token sonda PING. Il dispositivo può rispondere a questo token con un ACK (se pronto) o un NAK (se non è in grado di ricevere la dimensione massima del pacchetto). Una risposta negativa costringerà l'host a riprovare più tardi, una risposta positiva gli consentirà di eseguire una transazione di output. Ad una transazione di prelievo dopo una risposta positiva al test, le risposte del dispositivo sono più varie:

• ACK significa ricezione riuscita e disponibilità ad accettare il successivo pacchetto a grandezza naturale;
• NYET significa ricezione riuscita ma non pronto per il pacchetto successivo;
• NAK è una risposta inaspettata (contraddice il successo del test), ma è possibile se il dispositivo diventa improvvisamente temporaneamente non disponibile.

Il dispositivo ad alta velocità nei descrittori dell'endpoint segnala la possibile intensità degli invii NAK: il campo bInterval per gli endpoint Bulk e Control indica il numero di microframe per NAK (0 significa che il dispositivo non risponderà mai con un NAK a una transazione di output).

I trasferimenti di array, interruzioni e controlli garantiscono una consegna affidabile dei dati. Dopo aver ricevuto con successo il pacchetto, il ricevitore dati invia una conferma: un pacchetto di conferma ACK. Se il ricevitore dati rileva un errore, il pacchetto viene ignorato e non gli viene inviata alcuna risposta. La sorgente dati considera che il pacchetto successivo è stato trasmesso con successo quando riceve un ACK dal ricevitore. Se la conferma non arriva, nella transazione successiva la sorgente ripete l'invio dello stesso pacchetto. Tuttavia, il pacchetto di riconoscimento potrebbe andare perso a causa dell'interferenza; affinché in questo caso il ripetuto invio del pacchetto da parte del destinatario non venga percepito come la porzione di dati successiva, i pacchetti di dati vengono numerati. La numerazione è modulo 2 (numero a 1 bit): i pacchetti sono divisi in pari (con identificatore DATA0) e dispari (DATA1). Per ciascun endpoint (eccetto isocrono), l'host e il dispositivo dispongono di bit di commutazione, i loro stati iniziali sono coerenti in un modo o nell'altro. Le transazioni IN e OUT trasmettono e attendono pacchetti di dati con identificatori DATA0 o DATA1, corrispondenti allo stato corrente di questi bit. Il ricevitore dati cambia il suo bit in caso di ricezione senza errori dei dati con l'identificatore previsto, la fonte dati cambia dopo aver ricevuto la conferma. Se il destinatario riceve un pacchetto privo di errori con un ID imprevisto, invia un ACK, ma ignora i dati nel pacchetto perché il pacchetto è una ritrasmissione di dati che sono già stati ricevuti.

Transazioni per vari tipi le trasmissioni presentano differenze di protocollo dovute alla garanzia o meno di throughput, tempi di risposta, affidabilità di consegna e sincronizzazione di input e output. A seconda di queste caratteristiche, le transazioni utilizzano l'uno o l'altro dei meccanismi del protocollo sopra descritti. Tieni presente che il rilevamento degli errori di trasmissione funziona in tutte le transazioni, quindi i dati ricevuti per errore vengono sempre ignorati. Quali meccanismi di protocollo vengono utilizzati nella transazione corrente sono "conosciuti" sia dal controller host (in base al descrittore dell'endpoint ricevuto in precedenza) sia dal dispositivo USB in cui è implementato questo endpoint.

Le transazioni isocrone forniscono tassi di cambio garantiti, ma non forniscono una consegna affidabile. Per questo motivo nel protocollo non sono presenti conferme, poiché la riproduzione dei pacchetti causerà il fallimento dei piani di consegna dei dati. Non esiste un controllo del flusso basato sul riconoscimento: il dispositivo deve mantenere la velocità del traffico dichiarata nel descrittore dell'endpoint isocrono.

Le transazioni di output isocrone sono costituite da due pacchetti inviati dal controller host, un token OUT e un pacchetto di dati DATA. In una transazione di input, l'host invia un token IN, al quale il dispositivo risponde con un pacchetto di dati, possibilmente con una lunghezza del campo dati pari a zero (se non ci sono dati pronti). Qualsiasi altra risposta da parte del dispositivo (così come il "silenzio") viene considerata dall'host come un errore che porta all'arresto di questo canale.

Con lo scambio isocrono, c'è il controllo dell'affidabilità (scartando i pacchetti con errori) e dell'integrità dei dati (rilevando il fatto di un pacchetto mancante). Il controllo dell'integrità si basa sul rigoroso determinismo del tasso di cambio: secondo il suo descrittore, il punto prevede una transazione con un periodo di microframe 2bInterval-1. Per un tipico endpoint isocrono, è possibile solo una transazione per microframe e un errore durante la ricezione di un pacchetto fa sì che i dati ricevuti non vengano ricevuti nel microframe in cui erano previsti. Pertanto, la numerazione dei pacchetti (interruttore Toggle Bit) non è richiesta. I dispositivi a piena velocità e i controller host dovrebbero inviare solo pacchetti di tipo DATA01. Per gli endpoint isocroni a banda larga (USB 2.0), in ogni microframe possono essere trasmessi fino a tre pacchetti di dati. Ognuno di questi pacchetti può andare perso e per rilevare questa situazione è necessaria la numerazione dei pacchetti all'interno del microframe. Per questa numerazione sono state introdotte due nuove tipologie di pacchetti dati: DATA2 e MDATA. La varietà dei tipi di pacchetti, oltre alla numerazione, consente anche di informare il proprio interlocutore di comunicazione sui propri piani per un determinato microframe. Nelle transazioni IN, il dispositivo indica tramite l'identificatore del pacchetto quanti altri pacchetti intende emettere nello stesso microframe, consentendo all'host di evitare tentativi di input non necessari. Quindi, se un pacchetto viene trasmesso in un microframe, sarà DATA0; se due la sequenza sarà DATA1, DATA0; tre: DATI2, DATI1, DATI0. Le transazioni OUT utilizzano un pacchetto MDATA (More Data) per emettere il non ultimo pacchetto in un microframe e l'ultimo identificatore di pacchetto indica quanti pacchetti sono stati trasmessi prima di esso. Quindi, con una transazione in uscita viene utilizzato il pacchetto DATA0, con due - la sequenza MDATA, DATA1, con tre - MDATA, MDATA, DATA2. Tutte le transazioni tranne l'ultima in un microframe devono utilizzare la dimensione massima del pacchetto. Si noti che altre transazioni possono essere inserite tra transazioni a banda larga in un microframe.