Réponses:
La vitesse de transmission est importante car l'USB est semi-duplex: pour transmettre une réponse, le bus doit être inversé et les données transmises dans l'autre sens. L'hôte envoie donc des données et attend un accusé de réception ou une réponse. Tous les transferts sont contrôlés par l'hôte. L'appareil dispose alors d'un certain délai (assez court) pour répondre. Ce temps est à peu près le temps pris pour deux trajets de signal le long d'un câble de 5 m.
(Je ne trouve pas de références juste cette seconde, mais les documents techniques pertinents sont publics)
Edit: merci à psmears d'avoir trouvé cette section
Câbles et solutions longue distance
- Pourquoi y a-t-il des limites de longueur de câble et quelles sont-elles?
R: La longueur du câble a été limitée par une spécification de retard de câble de 26 ns pour permettre aux réflexions de se déposer sur l'émetteur avant l'envoi du bit suivant. Étant donné que l'USB utilise des pilotes de terminaison de source et de mode tension, cela doit être le cas, sinon les réflexions peuvent s'accumuler et faire exploser le pilote. Cela ne signifie pas que la tension de ligne s'est complètement stabilisée à la fin du bit; avec sous-terminaison dans le pire des cas. Cependant, il y a eu suffisamment d'amortissement à la fin du bit pour que l'amplitude de réflexion ait été réduite à des niveaux gérables. La longueur du câble à basse vitesse a été limitée à 18 ns pour empêcher les effets de la ligne de transmission d'avoir un impact sur les signaux à basse vitesse.
- Je veux construire un câble de plus de 5 mètres, pourquoi cela ne fonctionnera-t-il pas?
R: Même si vous avez violé la spécification, cela ne vous mènerait littéralement pas très loin. En supposant les temps de retard les plus défavorables, un périphérique pleine vitesse au bas de 5 concentrateurs et câbles a une marge de temporisation de 280ps. Réduire cette marge à 0ps ne vous donnerait que 5 cm supplémentaires, ce qui ne vaut guère la peine.
Ma réponse n'est donc qu'à moitié droite: la limite aller-retour concerne une chaîne de concentrateurs et de câbles dans le pire des cas, pour une profondeur totale de 25 m.
Dan Neely a également raison de dire que l'USB a toujours été censé être la solution la moins coûteuse pour les périphériques "lents" comme les claviers, les souris, les imprimantes, etc. Si vous vouliez du duplex intégral pour plus de vitesse et de distance, Ethernet 100baseT est le choix naturel.
Voir cette page, /superuser/64744/maximum-length-of-a-usb-cable .
Q1: Quelle longueur de câble puis-je utiliser pour connecter mon appareil? A1: En pratique, la spécification USB limite la longueur d'un câble entre les appareils à pleine vitesse à 5 mètres (un peu moins de 16 pieds 5 pouces). Pour un appareil à basse vitesse, la limite est de 3 mètres (9 pieds 10 pouces).
Q2: Pourquoi ne puis-je pas utiliser un câble de plus de 3 ou 5 m? A2: La conception électrique de l'USB ne le permet pas. Lors de la conception de l'USB, il a été décidé de gérer la propagation des champs électromagnétiques sur les lignes de données USB d'une manière qui limitait la longueur maximale d'un câble USB à quelque chose dans la plage de 4 m. Cette méthode présente un certain nombre d'avantages et, comme l'USB est destiné à un environnement de bureau, les limitations de portée ont été jugées acceptables. Si vous connaissez la théorie des lignes de transmission et que vous souhaitez plus de détails sur ce sujet, jetez un œil à la section des signaux USB de la FAQ des développeurs.
Il n'est pas vraiment possible de "tamponner" l'USB, du moins pas dans le sens habituel du terme. Typiquement, la mise en mémoire tampon signifie une amplification électrique et peut-être une régénération du signal.
Avec USB, l'hôte pilote l'intégralité du bus. Un hôte envoie une demande et le périphérique doit émettre une réponse à l'hôte. Le début de la réponse doit arriver à l'hôte un certain temps après la fin de la transmission de la demande. Avec un câble trop long, le délai de propagation est trop long pour que la réponse atteigne l'hôte à temps.
Il existe donc des solutions de contournement, et aucune d'entre elles n'implique une simple "mise en mémoire tampon" car la mise en mémoire tampon ajoute des retards supplémentaires, et nous devons en quelque sorte rendre l'hôte plus tolérant à un délai plus long.
Il existe deux classes de solutions:
Solutions de contournement qui insèrent des concentrateurs physiques ou virtuels. Si un hôte énumère un concentrateur sur le bus, le concentrateur lui-même ajoute un délai supplémentaire et il existe un autre câble potentiellement pleine longueur entre le concentrateur et l'hôte. Toutes les demandes d'appareils qui se connectent en aval du concentrateur sont planifiées avec des délais supplémentaires.
Vous pouvez insérer un concentrateur à port unique tous les 4 m du câble, avec jusqu'à 7 concentrateurs en série. La limitation est de 7 niveaux de concentrateurs de l'hôte à l'appareil ultime, donc s'il y a des concentrateurs en amont de votre appareil, vous devez réduire le nombre de concentrateurs en conséquence. De nombreux hôtes USB incluent un seul niveau de concentrateur interne, donc une limite réaliste serait de 28 m de câble, avec 6 concentrateurs en série. Tous les concentrateurs, sauf le premier, devront faire semblant d'être autonomes.
Vous pouvez ajouter des concentrateurs virtuels, avec un émetteur-récepteur plus robuste avec préaccentuation, directement à la prise qui va dans l'hôte, puis transmettre le trafic USB sur un câble plus long. Tant que les signaux reçus par l'appareil à l'extrémité d'un tel câble étendu sont conformes aux spécifications, et tant que votre récepteur peut récupérer les données envoyées par l'appareil standard sur un long câble, vous serez OK. Les concentrateurs virtuels sont ajoutés afin que l'hôte autorise le long délai - mais bien sûr, il n'y a pas de concentrateurs physiques, juste une usurpation d'identité.
Solutions de contournement qui émulent un périphérique qui semble «lent» à un niveau de protocole supérieur. C'est ainsi que certaines "extensions" USB Cat-5 fonctionnent. Il y a cinq partenaires ici: l'hôte réel (rHost), un appareil émulé vu par lui (eDev), un long câble, un hôte émulé (eHost) et les appareils qui le voient à l'extrémité du câble (rDev) .
Au départ, l'eDev fait semblant de ne pas être là. À un moment donné, l'eHost voit qu'un rDev a été branché. Il l'énumère et transmet les données à l'eDev. L'eDev émule ensuite un événement de plug-in et le rHost l'énumère. Le rHost croit qu'il voit rDev, mais c'est seulement eDev qui est là, faisant semblant. De même, le rDev pense qu'il voit un rHost, mais ce n'est qu'un eHost étant là, faisant semblant.
Finalement, le rHost veut émettre des transferts vers le rDev qu'il croit être là, pour en faire usage. Pour les transferts IN, l'eDev prétend n'avoir aucune donnée (répond par un NAK). La demande de transfert est transmise à l'eHost, qui la réexécute avec rDev. Les résultats sont renvoyés à eDev, qui les utilise la prochaine fois que l'hôte tente le transfert.
Pour les transferts OUT, l'eDev doit deviner quel serait le comportement de rDev. Il existe différentes heuristiques et comportements qui peuvent être tentés ici. Une façon consiste pour eDev à toujours recevoir les données et à répondre avec un ACK. Le transfert est transmis à eHost, qui relit ensuite le transfert à rDev. Idéalement, rDev finira par consommer les données et les ACK. Si cela ne réussit pas, ou si le rDev répond par un STALL, le mieux que l'eDev puisse faire est d'agir de cette façon lors du prochain transfert depuis l'hôte. Alternativement, l'eDev peut toujours NAK le transfert, avec l'hypothèse généralement correcte que l'hôte va simplement réessayer le transfert identique plus tard. Même si le transfert d'origine était NAK-ed, il est transmis à eHost, qui exécute ensuite le transfert avec rDev. Quelle que soit la réponse de rDev, elle devient la réponse de l'eDev dès qu'il en a connaissance.
Les implémentations réalistes commenceront par des heuristiques conservatrices qui impliquent un aller-retour complet vers rDev pour tous les transferts qui peuvent être reportés par un NAK. Au fur et à mesure des transferts, le comportement attendu de rDev peut être appris et eDev peut devenir moins conservateur. L'extendeur peut utiliser les connaissances des classes USB standard et certaines connaissances / listes / listes blanches spécifiques aux fournisseurs / classes pour offrir également de meilleures performances.
La plupart des schémas de transmission de données sur câble ont une norme décente internationalement reconnue décrivant comment les mettre en œuvre, y compris une spécification pour l '"impédance caractéristique" du câble (pensez à cela comme une résistance, mais s'applique au CA), une impédance de terminaison (la `` résistance '' à la fin de la connexion qui est nécessaire pour éviter que les réflexions de votre signal ne rebondissent sur le câble vers l'expéditeur), souvent une `` vitesse de balayage '' spécifiée (le temps qu'il faut pour que le ou les signaux passent d'une 0 à 1 ou vice versa), et donc le nombre maximum de transitions entre 0/1 par seconde (c'est-à-dire les kbps / Mbps / Gbps), et donc la durée du câble avant que l'intégrité du signal ne se dégrade & les choses ne fonctionnent plus correctement.
Comparé à l'USB, le RS232 possède des spécifications de type de câble, d'impédance caractéristique, de vitesse de balayage, de longueur de câble et de type de connecteur. Bien sûr, les connecteurs `` D '' à 25 et 9 broches étaient courants, mais en réalité, le RS232 a été conçu pour toutes sortes de connecteurs, de câbles et de produits sans aucune spécification réelle pour dire le contraire. Dans la pratique, avec RS232, vous pouvez généralement parcourir de plus longues distances en passant à un taux de bits par seconde (aka 'baud') inférieur. La distance maximale que vous pouvez atteindre sera également déterminée en grande partie sur l'impédance de votre câble, qu'il soit ou non blindé, la terminaison à la fin, etc.
et en comparant RS232 à USB, vous comparez un `` standard '' des années 1960 qui dépassait à peu près 115k2 (à de rares exceptions près), avec un des années 1990 et 2000 qui a commencé à 1,5 Mbps, un ordre de grandeur plus rapide, puis 12 Mbps (près de 100 fois plus rapide), puis 480 Mbps (près de 5000 fois plus rapide), mais cela signifiait que les paramètres et la longueur des câbles jouaient un rôle important pour le rendre fiable . Il a été conçu comme une norme de connexion périphérique de bureau, donc 5 m ont été jugés acceptables, puis tous les paramètres des câbles et connecteurs et des vitesses ont été définis à partir de ce point. S'il y avait un moyen de ralentir l'USB, vous pourriez probablement le faire fonctionner sur des câbles plus longs (sans répéteur).