Où se trouve exactement la spécification USB qui explique quoi faire lorsque le câble est connecté pour la première fois?


15

Je connais donc la spécification USB 2.0 située sur le site USB.org .

Je suis un peu paresseux et impatient. Quelqu'un peut-il me dire où aller pour savoir exactement ce que l'on attend de mon périphérique lorsque le câble USB est connecté?

Par exemple, si mon périphérique est une imprimante, comment puis-je dire à l'ordinateur à l'autre extrémité qu'une imprimante (avec une description de modèle spécifique, je suppose) vient d'être connectée? Que, sur l'ordinateur, comment le pilote d'imprimante sait-il quel port USB était connecté à l'imprimante?

Mon application est en fait USB MIDI. J'ai également obtenu ce document USB-MIDI , mais je suis déficient avec le protocole USB plus fondamental.

Juste pour l'information des gens, la puce USB que j'utilise est le FTDI FT220x et elle est connectée au SPI d'un ADSP-21479 SHArC. Nous l'utilisons maintenant simplement pour les communications textuelles utilisant le PC (exécutant TeraTerm) comme une "console" . j'ai accès au code qui configure le port SPI et se connecte à la puce FTDI, mais il n'y a pas de code qui effectue les communications initiales. Je ne sais pas ce que fait le FT220x lors de sa première connexion au PC.

Je ne suis pas mécontent de lire et d'apprendre, mais j'aimerais savoir par où commencer la lecture, et une spécification USB de 100 Mo est une cible trop grande pour tirer. Sincères remerciements à quiconque pour son aide concrète.


1
Vous êtes donc simplement curieux de savoir ce que fait le FTDI FT220x dans les coulisses, non? Étant donné que FTDI s'occupe de beaucoup de choses USB pour vous, il y a aussi des limites à ce qu'il vous laisse faire. J'ai utilisé la famille FT2232H pendant un certain temps, j'essaierai d'expliquer ce que je sais ...
MarkU

ce que j'essaie finalement de faire, c'est d'utiliser ce port USB qui est déjà suffisamment intelligent pour envoyer du texte en va-et-vient au PC exécutant TeraTerm, ce que j'espérais faire était d'utiliser le même connecteur USB pour faire USB MIDI. J'ai besoin de comprendre comment "empaqueter" les données en paquets de 32 bits, mais je pensais (et je pense toujours) qu'il doit y avoir un protocole qui indique à l'autre extrémité qu'il s'agit d'un périphérique MIDI USB. (jusqu'à présent, je n'ai tout simplement pas de prise sur l'essentiel USB et votre réponse semble très utile pour me permettre de continuer.)
robert bristow-johnson

Réponses:


21

L'USB comporte plusieurs couches, décrites dans la spécification USB 2.0 . Si vous connaissez le modèle de réseau en couches OSI, vous pouvez le penser comme ceci:

  • Couche de session = Chapitre 10 Matériel et logiciel hôte USB (pilotes de périphérique)
  • Couche de transport = Chapitre 9 Framework de périphérique USB
  • Couche réseau = Chapitre 8 Couche de protocole (train de bits)
  • Couche liaison de données = Chapitre 7 Électrique (circuit)
  • Couche physique = Chapitre 6 Mécanique (câble et connecteur)

Conceptuellement, l'USB est basé sur des flux de données, appelés points d'extrémité , qui peuvent être IN (vers l'hôte) ou OUT (depuis l'hôte). Chaque appareil a un point de terminaison 0, qui est utilisé pour le contrôle et l'état. Un appareil peut avoir des points de terminaison supplémentaires pour les données d'application. Chaque point de terminaison se comporte comme un tampon FIFO.

Les données sont transférées sur un point de terminaison en tant que Bulk (comme TCP / IP, garanti que chaque octet arrive et dans le bon ordre), ou Isochronous (comme UDP / IP, garanti d'être frais mais peut laisser tomber des paquets). Il existe un type de transfert " Interruption " trompeusement nommé , qui est vraiment juste interrogé par l'hôte.

L'USB 2.0 utilise une paire différentielle pour la liaison de données. Je n'entrerai pas dans les détails car cela est couvert par le chapitre 7 de la spécification USB 2.0. Généralement sur la configuration PCB, nous traitons cela comme une paire différentielle de longueur assortie, et nous mettons les résistances en série requises par n'importe quel USB PHY (physique Interface) est utilisé. Le périphérique USB utilise une résistance de valeur élevée sur l'une des lignes D + ou D- pour informer l'hôte qu'il s'agit d'un périphérique haute vitesse ou basse vitesse.

Peu de temps après que l'hôte USB découvre qu'un périphérique est présent, l'hôte demande un tas de descripteurs au périphérique. Ceci est pris en charge dans les coulisses par la puce FTDI. Les descriptos sont décrits au chapitre 9.5 . Ceux - ci comprennent l' appareil Descriptor , descripteur de configuration , interface Descripteurs , Descripteurs Endpoint , chaîne Descripteurs , peut - être même rapport HID Descripteurs .

Le descripteur d'appareil comprend les numéros USB VID (identification du fournisseur) et PID (identification du produit). Le système d'exploitation utilise cette paire de chiffres, VID_PID, pour déterminer le pilote de périphérique à utiliser pour ce périphérique. Notez que le numéro VID est émis en étant membre du forum des implémenteurs USB, c'est donc un problème si vous êtes un inventeur individuel.

De plus, il existe le pilote de classe HID (Human Interface Device), qui fournit une entrée quelque peu générique pour le clavier / souris / etc, ainsi que toute entrée / sortie générique. Un avantage de HID est qu'il ne nécessite pas de fournir un pilote de périphérique personnalisé, mais son débit est quelque peu limité par rapport à un pilote de masse personnalisé. Il existe un tout autre document de spécification sur les descripteurs HID; et un document de table d'utilisation HID qui détaille tous les numéros de code qui décrivent les diverses fonctionnalités disponibles sur un appareil interfacé humain donné.

La puce FTDI telle que la fiche technique FT220X fournit le "moteur d'interface série" USB (à ne pas confondre avec série SPI ou série RS232). Cela prend en charge la plupart des éléments de bas niveau décrits dans les chapitres 6, 7 et 8.

FTDI utilise une EEPROM (puce sur le FT2232H, sur puce sur le FT220X) pour contenir un peu des informations qui entrent dans les descripteurs. Vous pouvez personnaliser les valeurs VID / PID et fournir des chaînes de description personnalisées.


6
J'ai aimé le résumé. J'ai dû lire la spécification THE ENTIRE 2.0 (plus de 1000 pages si je me souviens bien) sur une période de plusieurs semaines parce que je devais comprendre toutes ces conneries moi-même. Ce n'était PAS une expérience agréable, je dois dire. (Impossible d'utiliser HID dans mon cas.) Pas de bons livres sur le sujet non plus. Je détestais le livre de Jan Axelson sur USB et je considère son livre "presque entièrement inutile" pour quelqu'un qui essaie de faire ce travail comme un micro intégré à partir de zéro. En fait, c'est en grande partie sans valeur, sinon. Si vous connaissez un bon livre pour un implémenteur (matériel personnalisé), je serais heureux d'entendre un titre !! +1
jonk

1
Selon le marché potentiel d'Op, le VID / PID est le plus grand défi. L'utilisation de la méthodologie Axelsons fonctionne dans le sens où vous pouvez utiliser son VID (qui coûte 3,5k $ pour votre propre compte) et demander un ou plusieurs de ses PID gratuitement. Vous pouvez également demander des PID à des organisations comme Microchip / Atmel, FTDI et TI (en fonction de leur VID). Le meilleur livre IMO est Intels "USB design by example", c'est un peu long dans la dent, mais bon pour USB 2.x. Malheureusement, de nombreux exemples de code se cassent en raison des modifications apportées à Visual Studio lors de ses révisions.
Jack Creasey

1
La meilleure façon d'avoir accès à VID / PID pour les amateurs est d'utiliser LUFA (qui est gratuit): fourwalledcubicle.com/files/LUFA/Doc/130303/html/… ..... ceux-ci ne peuvent pas être utilisés dans des produits commerciaux mais sont bons pour un usage domestique / démo où vous pouvez contrôler les collisions dans une large mesure.
Jack Creasey

1
PS. Une excellente introduction consiste à utiliser la "conception USB intégrée par exemple: que FTDI a publiée: ftdichip.com/Support/Documents/TechnicalPublications/… ... qui contient de nombreux exemples utiles (basés sur des périphériques FTDI bien sûr) et tous les associés fichiers de travail, y compris l'utilisation des contrôleurs PSOC
Jack Creasey

1
Notez que si le périphérique USB est auto-alimenté, il doit attendre que la tension VBUS soit détectée avant d'appliquer la résistance de rappel D + ou D-. J'ai échoué la certification à ce sujet.
Adam Haun

4

Le comportement et l'interaction des «partenaires» USB (un hôte et un périphérique) sont dispersés dans les spécifications USB. La meilleure façon d'obtenir des raisons est de consulter le «cadre de périphérique», chapitre 9, qui décrit les états possibles (obligatoires) du périphérique (figure 9-1) et le cadre hôte (et concentrateur), dans les chapitres 10 et 11. Ignorer détails du protocole (canaux / types de transaction / couches de protocole OSI abstraites, configuration PCB, etc.), une meilleure prise en main de l'interaction initiale peut être obtenue en étudiant le diagramme d'état du port (Figure 11-10).

En substance, si le câble n'est pas connecté entre l'hôte et le périphérique, les ports de l'hôte sont en "état alimenté" (VBUS est activé), mais "déconnectés". Les fils D + et D- sont maintenus bas avec des déroulements de 15k.

Lorsque le câble est connecté, le VBUS entre dans l'appareil. L'appareil reconnaît qu'il est connecté et signale un événement de "connexion" en tirant HAUT l'un des fils D, D + s'il s'agit d'un appareil FS / HS et D- s'il s'agit d'un appareil LS.

Tirer sur les fils D +/- sur un certain port provoque une interruption du logiciel hôte, signalant un "changement d'état du port". Le logiciel hôte (généralement ehci.sys) lance ensuite le séquencement de "réinitialisation du port" sur ce port particulier . Une fois la "réinitialisation du port USB" terminée, le port hôte est activé pour la communication USB. Le port devient actif (les paquets de trames commencent à s'écouler).

En utilisant le protocole USB, l'hôte attribue une adresse unique à cet appareil et lit le "descripteur d'appareil". Cela démarre le processus "énumération des périphériques". Le descripteur de périphérique contient des informations sur la classe de périphérique à laquelle il appartient (HID, COM, MIDI, imprimante, etc.) et le VID / PID de ce périphérique particulier, ainsi qu'un tas d'autres informations, voir Tableau 9-8.

Après avoir obtenu la classe de périphérique et le VID / PID, le logiciel hôte essaie de faire correspondre ces informations dans le registre des périphériques et charge le pilote DEVICE correspondant, soit générique, soit spécifique au fournisseur (s'il existe). Le pilote de périphérique termine ensuite le processus d'énumération en sélectionnant l'interface de périphérique se terminant par le paramètre "configuration de périphérique". De toute évidence, la communication USB entière est reconnue uniquement derrière ce port particulier , même si tous les paquets sont diffusés sur tous les ports activés.

Ce qui précède est le cadre général du protocole de connexion USB. La mise en paquets de données pour un usage particulier (comme le MIDI) est une autre histoire, et elle est gérée soit au niveau de l'application, soit au niveau du pilote de périphérique, si le système obtient la classe de périphérique appropriée. Pour obtenir une communication MIDI native, l'appareil doit avoir cette classe dans son descripteur et suivre toutes les définitions de classe MIDI .

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.