Risposte:
La velocità di trasmissione è importante perché l'USB è half-duplex: per trasmettere una risposta, il bus deve essere ruotato e i dati trasmessi nell'altra direzione. Quindi l'host invia i dati e attende un riconoscimento o una risposta. Tutti i trasferimenti sono controllati dall'host. Il dispositivo ha quindi un certo tempo (abbastanza breve) per rispondere. Questa volta è approssimativamente il tempo impiegato per due viaggi di segnale lungo un cavo da 5 m.
(Non riesco a trovare riferimenti in questo secondo, ma i documenti relativi alle specifiche sono pubblici)
Modifica: grazie a psmears per aver trovato questa sezione
Cavi e soluzioni a lungo raggio
- Perché ci sono limiti di lunghezza dei cavi e quali sono?
A: La lunghezza del cavo è stata limitata da una specifica di ritardo del cavo di 26 ns per consentire ai riflessi di stabilizzarsi sul trasmettitore prima dell'invio del bit successivo. Poiché l'USB utilizza i driver di terminazione della sorgente e in modalità tensione, questo deve essere il caso, altrimenti i riflessi possono accumularsi e far esplodere il driver. Ciò non significa che la tensione di linea si sia completamente stabilizzata entro la fine del bit; con il peggioramento del caso peggiore. Tuttavia, alla fine del bit c'è stato abbastanza smorzamento che l'ampiezza della riflessione è stata ridotta a livelli gestibili. La lunghezza del cavo a bassa velocità era limitata a 18 ns per evitare che gli effetti della linea di trasmissione avessero un impatto sui segnali a bassa velocità.
- Voglio costruire un cavo più lungo di 5 metri, perché non funziona?
A: Anche se hai violato le specifiche, letteralmente non ti porterebbe molto lontano. Supponendo tempi di ritardo nel caso peggiore, un dispositivo a piena velocità nella parte inferiore di 5 hub e cavi ha un margine di timeout di 280ps. Ridurre questo margine a 0ps ti darebbe solo 5 cm in più, il che non vale la pena.
Quindi la mia risposta è solo a metà: il limite di andata e ritorno è per una catena di hub e cavi nel caso peggiore, per una profondità totale di 25 m.
Dan Neely ha anche ragione nel ritenere che l'USB sia sempre stata la soluzione più economica per periferiche "lente" come tastiere, mouse, stampanti, ecc. Se si desiderava il full duplex per una maggiore velocità e maggiore distanza, Ethernet 100baseT è la scelta naturale.
Vedi questa pagina, /superuser/64744/ma maximum-length-of-a-usb-cable .
Q1: quanto tempo posso usare un cavo per collegare il mio dispositivo? A1: In pratica, la specifica USB limita la lunghezza di un cavo tra i dispositivi a piena velocità a 5 metri (un po 'meno di 16 piedi 5 pollici). Per un dispositivo a bassa velocità il limite è di 3 metri (9 piedi e 10 pollici).
Q2: Perché non posso usare un cavo più lungo di 3 o 5 m? A2: il design elettrico USB non lo consente. Quando è stato progettato l'USB, è stata presa la decisione di gestire la propagazione dei campi elettromagnetici sulle linee dati USB in un modo che limitava la lunghezza massima di un cavo USB a qualcosa nel raggio di 4 m. Questo metodo presenta numerosi vantaggi e, poiché l'USB è destinato a un ambiente desktop, le limitazioni di portata sono state ritenute accettabili. Se hai familiarità con la teoria delle linee di trasmissione e desideri maggiori dettagli su questo argomento, dai un'occhiata alla sezione Segnali USB delle FAQ degli sviluppatori.
Non è davvero possibile "bufferizzare" l'USB, almeno non nel solito senso della parola. Tipicamente, buffering significa amplificazione elettrica e forse rigenerazione del segnale.
Con USB, l'host guida l'intero bus. Un host invia una richiesta e il dispositivo deve inviare una risposta all'host. L'inizio della risposta deve arrivare all'host un certo tempo dopo che la richiesta ha terminato la trasmissione. Con un cavo troppo lungo, il ritardo di propagazione è troppo lungo perché la risposta raggiunga l'host in tempo.
Quindi ci sono soluzioni alternative, e nessuna di esse comporta un semplice "buffering" poiché il buffering aggiunge ulteriori ritardi e dobbiamo in qualche modo rendere l'host più tollerante di un ritardo più lungo.
Esistono due classi di soluzioni alternative:
Soluzioni alternative che inseriscono hub fisici o virtuali. Se un host enumera un hub sul bus, l'hub stesso aggiunge un ritardo aggiuntivo e c'è un altro cavo potenzialmente a tutta lunghezza tra l'hub e l'host. Eventuali richieste di dispositivi che si collegano a valle dall'hub sono programmate con ritardi aggiuntivi.
È possibile inserire un hub a porta singola ogni 4 m di cavo, con un massimo di 7 hub in serie. La limitazione è di 7 livelli di hub dall'host al dispositivo finale, quindi se ci sono hub a monte del tuo aggeggio, devi ridurre di conseguenza il numero di hub. Molti host USB includono un hub interno a livello singolo, quindi un limite realistico sarebbe 28 m di cavo, con 6 hub in serie. Tutti gli hub, tranne il primo, dovranno fingere di essere autoalimentati.
È possibile aggiungere hub virtuali, con un ricetrasmettitore più robusto con pre-enfasi, proprio sulla spina che va nell'host, quindi trasmettere il traffico USB su un cavo più lungo. Finché i segnali ricevuti dal dispositivo alla fine di un cavo così esteso rientrano nelle specifiche e fintanto che il ricevitore può recuperare i dati inviati dal dispositivo standard su un cavo lungo, starai bene. Gli hub virtuali vengono aggiunti in modo che l'host consenta il lungo ritardo, ma ovviamente non esistono hub fisici, ma solo una loro rappresentazione.
Soluzioni alternative che emulano un dispositivo che appare "lento" a un livello superiore di protocollo. Ecco come funzionano alcuni "extender" USB Cat-5. Ci sono cinque partner qui: l'host reale (rHost), un dispositivo emulato visto da esso (eDev), un cavo lungo, un host emulato (eHost) e i dispositivi che lo vedono all'estremità opposta del cavo (rDev) .
Inizialmente, l'eDev finge di non essere lì. A un certo punto eHost vede che è stato inserito un rDev. Lo enumera e inoltra i dati a eDev. EDev emula quindi un evento plug-in e rHost lo enumera. Il rHost crede di vedere rDev, ma è solo eDev essere lì, fingendo. Allo stesso modo, il rDev pensa che sia vedere un rHost, ma è solo un eHost che sta lì, fingendo.
Alla fine, il rHost vuole emettere alcuni trasferimenti al rDev che ritiene sia lì, per farne un uso. Per i trasferimenti IN, l'eDev finge di non avere dati (risposte con un NAK). La richiesta di trasferimento viene inoltrata a eHost, che la esegue nuovamente con rDev. I risultati vengono inoltrati a eDev, che utilizza i risultati la volta successiva che l'host tenta il trasferimento.
Per i trasferimenti OUT, eDev deve indovinare quale sarebbe il comportamento di rDev. Ci sono varie euristiche e comportamenti che possono essere tentati qui. Un modo è che eDev riceva sempre i dati e risponda con un ACK. Il trasferimento viene inoltrato a eHost, che quindi riproduce il trasferimento su rDev. Idealmente, rDev alla fine consumerà i dati e li ACK. Se ciò non riesce, o se rDev risponde con una STALL, il meglio che eDev può fare è agire in questo modo al successivo trasferimento dall'host. In alternativa, eDev può sempre NAK il trasferimento, con il presupposto solitamente corretto che l'host riprovi semplicemente il trasferimento identico in un secondo momento. Anche se il trasferimento originale era NAK-ed, viene inoltrato a eHost, che quindi esegue il trasferimento con rDev. Qualunque sia la risposta di rDev, diventa la risposta di eDev non appena ne viene a conoscenza.
Le implementazioni realistiche inizieranno con euristiche conservative che comportano il viaggio di andata e ritorno completo a rDev per tutti i trasferimenti che possono essere rinviati da un NAK. Man mano che i trasferimenti procedono, il comportamento previsto di rDev può essere appreso e eDev può diventare meno conservativo. L '"extender" può utilizzare la conoscenza delle classi USB standard e alcune classi / conoscenze / liste nere / whitelist specifiche del fornitore per offrire anche prestazioni migliori.
La maggior parte degli schemi di trasmissione dati via cavo ha uno standard decente riconosciuto a livello internazionale che descrive come implementarli, inclusa una specifica per l '"impedenza caratteristica" del cavo (si pensi a questo come resistenza, ma si applica alla corrente alternata), impedenza di terminazione (il "resistenza" alla fine della connessione necessaria per evitare che i riflessi del segnale rimbalzino sul cavo verso il mittente), spesso una "velocità di risposta" specifica (il tempo impiegato dal segnale per passare da un 0-state a 1-state o viceversa), e quindi il numero massimo di transizioni tra 0/1 al secondo (cioè kbps / Mbps / Gbps), e quindi quanto tempo può durare il cavo prima che l'integrità del segnale diminuisca e le cose smettono di funzionare bene.
Rispetto a USB, RS232 ha superato tutte le specifiche su tipo di cavo, impedenza caratteristica, velocità di risposta, lunghezza del cavo, tipo di connettore. Certo, i connettori 'D' a 25 e 9 pin erano comuni, ma in realtà RS232 era progettato per tutti i tipi di connettori, cavi e prodotti senza specifiche reali per dire diversamente. In pratica, con RS232 di solito puoi percorrere distanze più lunghe scendendo a una velocità di bit al secondo inferiore (alias 'baud'). La distanza massima che è possibile raggiungere sarà anche determinata in modo significativo sull'impedenza del cavo, indipendentemente dal fatto che sia schermato, terminazione alla fine e così via.
e nel confrontare RS232 con USB, stai confrontando uno "standard" degli anni '60 che ha superato quasi 115k2 (con rare eccezioni), con uno degli anni '90 e 2000 che è iniziato a 1,5 Mbps, un ordine di grandezza più veloce, quindi 12 Mbps (quasi 100 volte più veloce), quindi 480 Mbps (quasi 5000 volte più veloce), ma ciò significa che i parametri del cavo e la lunghezza del cavo hanno svolto un ruolo importante nel farlo funzionare in modo affidabile . È stato progettato come standard di connessione periferica desktop, quindi sono stati considerati accettabili 5 m, e da quel momento sono stati stabiliti tutti i parametri di cavi, connettori e velocità. Se esistesse un modo per rallentare l'USB, probabilmente potresti farlo funzionare su cavi più lunghi (senza un ripetitore).