J'ai remarqué que sous Windows XP et 7 (et 2 ordinateurs différents, respectivement), je pouvais obtenir le message suivant: "Ce périphérique peut fonctionner plus rapidement si vous le connectez à un port USB 2.0 haut débit" si je connecte le câble très lentement (ou si je ne me débrouille pas très bien d’une seule main) Si je le connecte assez rapidement ou normalement, à deux mains, il n'y a pas de notification. Dans les deux cas, tous ces dispositifs semblent fonctionner normalement.
Ce que je pense, c’est que le contact entre les fils est interrompu assez longtemps au cours d’une connexion lente/maladroite pour que le contrôleur USB pense que ce n’est pas la version 2.0 mais plus lente. Mais pourquoi le pense-t-il? Ou pourquoi ne dit-on pas simplement "Vous ne savez pas brancher les câbles, débranchez-le et essayez à nouveau"?
Le message fait référence à la négociation d'un ancien débit de données à pleine vitesse (FS) de 12 Mbit/s, au lieu du débit de données à haut débit (HS) qui est de 480 Mbit/s. Il doit être très difficile d’obtenir cet effet à partir d’un port USB2. Le protocole USB 2.0 HS est établi après une négociation assez complexe entre un périphérique et l'hôte, car chaque périphérique HS agit initialement comme un périphérique FS.
Le processus normal est le suivant:
Le périphérique compatible HS tire la ligne D + après avoir reçu le signal VBUS avec une résistance de 1-1,5kΩ à 3,3V. Tout comme le ferait un périphérique FS.
Le port de l'hôte détecte le D + = haut et, après un délai de rebond minimum de 100 ms, l'hôte valide l'état USB_RESET sur le bus, pilotant les lignes D + et D- à la terre avec des pilotes 45Ω pendant 10 ou 50 ms.
Si le périphérique est FS, il ne fait rien et attend la fin de USB_RESET.
Si le périphérique est HS, il utilisera un pilote HS (source 18 mA) pendant environ 1 ms. Cela créera une impulsion d'amplitude d'environ 800 mV (18 mA dans une charge de 45Ω) appelée "Chirp-K";
Lors de la détection de la fin de Chirp-K, si l’hôte est capable de passer en mode HS, il renvoie ce signal (même 18 mA dans sa propre charge de 45 Ω), pendant environ 50 µs. S'il s'agit d'un hôte FS, il ignore le Chirp-K et procède en tant que FS.
Ensuite, si l’hôte est capable de passer en mode HS, il bascule son lecteur sur le fil D +, formant ainsi "Chirp-J", à nouveau pendant 50 µs;
L'hôte répète ce modèle alternatif 50 µs pendant toute la durée de l'état USB_RESET (10 ms sur les ports du concentrateur, 50 ms sur les ports du concentrateur racine);
Après trois alternances chirp-K/J, le dispositif reconnaît que l'hôte est HS et bascule en mode HS lui-même. Cela implique d'activer la terminaison HS à l'extrémité de l'appareil, ce qui porte la résistance totale du fil à 22 Ω et l'amplitude du signal de chirp chute à 400 mV, à un niveau de signalisation HS standard.
L'hôte procède avec les paquets de début de trame (SOF) HS et démarre le processus d'énumération en mode HS.
Maintenant, tout le monde devinera quelle partie de l'agitation a enfreint ce protocole et a forcé l'hôte à marquer le port en tant que FS.
Lorsque vous connectez un périphérique à un port USB2, l'ordinateur tente d'abord de négocier une connexion à l'aide du protocole de données USB2.
Lorsque cela échoue, il tente à nouveau d’utiliser le protocole de données USB1.
Ma meilleure hypothèse est que la connexion physique (en raison de l'agitation des contacts) n'est pas encore stable pendant la négociation USB2. Donc, il revient à USB1, même si le périphérique est un périphérique USB2.
Assez drôle, Windows se rend compte que le périphérique doit être compatible avec la vitesse USB2 (informations fournies par le pilote). Windows conclut donc que le port USB auquel vous l'avez branché était un port USB1 lent. Windows ne semble pas vérifier si le port lui-même est compatible USB2.
Et c’est pourquoi vous obtenez un message d’erreur quelque peu trompeur.
P.S. Je viens de l'essayer moi-même avec une machine Windows 10: Même effet là.
Il se peut que vous ayez inséré le disque assez lentement pour que Windows ait déjà terminé le processus de serrement de la main avec le contrôleur et qu’à ce moment-là, les contacts nécessaires pour la communication USB 2.0 ne se touchent plus. Cela pourrait éventuellement amener Windows à confondre un périphérique USB 2.0 avec la version 1.1. périphérique, car il n'y aurait aucune réponse sur les Rails marqués comme étant uniquement présents sur USB 2.0 et versions ultérieures.