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.
la source
Réponses:
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:
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.
la source
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 .
la source