Existe-t-il vraiment un «protocole de communication USB»?


24

Selon Wikipedia , USB:

définit les câbles, connecteurs et protocoles de communication utilisés dans un bus pour la connexion, la communication et l'alimentation électrique entre les ordinateurs et les appareils électroniques

Mais existe-t-il vraiment un " protocole de communication USB "? Ma compréhension est que:

  1. Vous connectez un périphérique USB à une machine (disons, Ubuntu ou tout type de Linux)
  2. Linux trouve le pilote de périphérique pour ce périphérique (en quelque sorte - bonus si vous le savez!) Et le charge
  3. L'appareil est maintenant connecté sous /dev/theDevice
  4. Les applications de l'espace utilisateur peuvent désormais lire / écrire /dev/theDeviceet le pilote gère les E / S de bas niveau sur le périphérique / matériel sous-jacent

Pour moi, nulle part dans ce flux n'apparaît un "protocole de communication USB". Si ma compréhension est correcte, l'USB n'est que le câble et la connexion électrique entre le PC et l'appareil.

Ai-je tort ici? L'USB met-il réellement en œuvre une sorte de protocole de bas niveau qui souligne le flux ci-dessus? Si oui, quel est-il et comment fonctionne-t-il à une vue de 30 000 pieds?


45
"le pilote gère les E / S de bas niveau vers le périphérique / matériel sous-jacent" il le fait en utilisant le protocole de communication qui est dans la norme.
EBGreen

29
Oh ... J'ai lu que la question était "Existe-t-il vraiment un" protocole de communication USB "?" La réponse serait donc oui. Si vous voulez savoir quel est le protocole de communication réel, lisez simplement la norme. Ou lisez la section 11 sur la page wiki à laquelle vous êtes lié.
EBGreen

6
"l'USB est juste le câble et la connexion électrique entre le PC et l'appareil". Le câble Ethernet n'est qu'un câble entre le PC et un commutateur / routeur / autre. Il existe toujours des protocoles utilisés pour communiquer sur ce câble et faire des trucs utiles avec.
ysdx

13
"Linux trouve le pilote de périphérique pour ce périphérique" Comment pensez-vous que Linux est capable de détecter quel périphérique est connecté à l'autre extrémité. Un protocole commun, peut-être?
dépensier

4
@Ramhound "Ces protocoles de communication sont indépendants de la norme au moins dans le cas d'Ethernet." C'est faux. Les protocoles Ethernet (couche physique et couche MAC) sont définis par les normes Ethernet IEEE (en particulier, les normes 802.3 ). Il est bien sûr possible (et courant) d'envoyer autre chose que le protocole Ethernet sur un câble de catégorie 6 avec Connecteurs RJ-45, mais à ce stade, ce n'est plus Ethernet. C'est une pratique courante avec les systèmes téléphoniques non VoIP, par exemple.
reirab

Réponses:


47

Oui, voir les protocoles USB

Si je comprends bien, la spécification USB définit un ensemble complexe de protocoles en couches et de profils de périphérique.

Par exemple, les périphériques USB peuvent se conformer à des modèles de haut niveau tels que le stockage de masse, le clavier (ou le périphérique d'interface humaine, etc.) et être gérés par un pilote de périphérique générique. Certains périphériques USB peuvent communiquer à un niveau inférieur de sorte que la prise en charge USB de bas niveau du système d'exploitation puisse reconnaître que des pilotes de niveau supérieur spécifiques au périphérique sont nécessaires.


30

Question: Existe-t-il un protocole de communication USB de bas niveau en action et quel est-il?

Répondre:

Oui, la spécification USB inclut le protocole USB qui définit la façon dont le bus est utilisé au niveau du bit. Ce serait le protocole «de bas niveau» qui sous-tend les protocoles de niveau supérieur, c'est-à-dire le stockage de masse, HID, etc.

Pour des détails sur le fonctionnement du protocole USB, ce wiki OSDev est utile. Voici une autre description intéressante utilisant des diagrammes de séquence pour décrire les diverses transactions de données selon le protocole USB.

Question bonus: Comment Linux trouve-t-il et charge-t-il le pilote de périphérique pour ce périphérique?

Réponse bonus :

'Sous Linux lors de l'utilisation d'un noyau compatible USB, un périphérique USB fonctionnel sera détecté via le matériel et le noyau en raison de la spécification USB. Côté matériel, la détection est effectuée par le contrôleur hôte USB. Ensuite, dans le noyau, le pilote du contrôleur hôte prend le relais et traduit les bits de bas niveau du câble en informations formatées en protocole USB. Ces informations sont ensuite renseignées dans le pilote de base USB du noyau. '

J'ai paraphrasé cet excellent article Opensourceforu , qui contient beaucoup plus de détails et de clarté sur votre question dans le contexte Linux.


7
J'espère que "Question bonus" signifie "Bounty" pour vous.
dotancohen

@projectdp - Il serait très utile de placer une partie des informations de vos références principales dans votre réponse elle-même.
Ramhound

@Ramhound - Merci pour vos commentaires, j'ai réécrit ma réponse d'une manière plus utile. En ce qui concerne l'ajout d'informations supplémentaires à partir des ressources, qu'aimeriez-vous voir qui soit pertinent pour les questions?
projectdp

14

Comme presque tous les autres types d'interfaces de communication, l'USB est implémenté comme une pile de protocoles. Les niveaux de cette pile qui sont communs à tous ou à plusieurs types de périphériques sont définis par les normes USB elles-mêmes, ce qui permet à la fois la compatibilité et empêche chaque périphérique de faire une conception de protocole redondante. De plus, chaque couche du protocole résume les détails dont la couche suivante n'a pas à s'inquiéter. Ainsi, lorsque vous écrivez réellement la couche spécifique au périphérique, vous n'avez que des fonctions génériques d'envoi et de réception qui récupèrent les données du point de terminaison A au point de terminaison B. En tant que concepteur de périphérique, vous n'avez pas à vous soucier de comment cela se produit. En outre, des niveaux inférieurs au sein de la pile de protocoles peuvent modifier l'implémentation tant qu'ils exposent une interface commune à la couche au-dessus d'eux. De cette façon, lorsqu'une partie de la pile de protocoles change, le reste de la pile ne doit pas nécessairement changer.quel protocole est utilisé à un niveau inférieur de la pile. De manière générale, chaque couche consécutive dans la pile encapsulera le message produit par la couche la plus élevée suivante dans son propre champ de charge utile pendant l'envoi d'un message. Lorsqu'un message est reçu, chaque couche décolle la partie pertinente pour cette couche et transmet sa charge utile à la couche appropriée suivante de la pile. C'est le cas non seulement de l'USB, mais de presque tous les bus de communication. La pile TCP / IP / Ethernet est probablement la plus couramment utilisée, par exemple. Les tâches dont les couches données sont généralement responsables sont décrites dans des modèles, tels que le modèle OSI .

En USB, il existe un protocole de couche physique qui définit les états de tension / synchronisation / etc. sur le fil et comment ils doivent être interprétés. Ce protocole doit évidemment faire partie des normes USB elles-mêmes, non spécifiques à un appareil donné (d'autant plus que l'hôte n'a aucun moyen de savoir quel type d'appareil est sur le point d'être branché sur un port USB donné.)

Ensuite, il y a un protocole de gestion de bus, utilisé pour décrire qui peut parler sur le bus quand. C'est ce qu'on appelle la couche d'accès aux médias dans le modèle OSI. En USB, cette couche peut être résumée à peu près comme «le périphérique peut transmettre lorsque l'hôte lui dit de le faire», il n'y a donc pas de protocole particulièrement compliqué à cette couche en USB.

Ensuite, il y a un protocole standard pour décrire un paquet de données et comment il doit être acheminé de l'expéditeur au récepteur. Cette couche doit également faire partie de la norme USB elle-même, afin que la communication initiale pour découvrir quel type de périphérique a été connecté puisse se produire avant que le type spécifique de périphérique ne soit réellement connu par l'hôte. En plus de chaque périphérique ayant un ID particulier à cette couche, il existe également le concept en USB d'un ID de point de terminaison. Cela permet à tout périphérique donné d'avoir plusieurs points de terminaison USB, qui sont multiplexés et démultiplexés par la pile USB standard, de la même manière que les sockets sont multiplexés et démultiplexés par la pile TCP / IP standard. Une application peut traiter chacun de ces points de terminaison comme des flux de données distincts.

Enfin, il y a le protocole défini pour l'appareil lui-même. Notez qu'il existe en fait certains modèles préconçus communs inclus dans le cadre de la norme USB pour les cas d'utilisation courants, tels que les périphériques de stockage de masse, les souris, les claviers, etc., de sorte que chaque fabricant de périphérique n'a pas à réinventer le roue. Cependant, les appareils plus compliqués sont libres de concevoir leur propre protocole personnalisé au niveau de cette couche. La sortie de cette couche pour une transmission donnée est transmise en tant que charge utile d'un paquet de données à la couche précédente. Notez que, pour les périphériques suffisamment compliqués, la partie spécifique au périphérique du protocole peut elle-même être divisée en plusieurs couches indépendantes, mais les niveaux inférieurs n'ont pas à le savoir ou à s'en soucier. Tout ce qu'ils doivent savoir, c'est qu'ils doivent transmettre un ensemble d'octets donné de l'hôte à un point de terminaison de périphérique particulier ou d'un point de terminaison de périphérique particulier à l'hôte. Encore une fois, avoir l'interface standard entre les couches permet de séparer les préoccupations, de sorte qu'une couche n'a pas à se soucier du fonctionnement interne d'une autre couche, mais uniquement des données spécifiques qu'elle doit transmettre ou s'attendre à recevoir des couches immédiatement au-dessus ou en dessous dans la pile.


9

Il existe en fait un ensemble de protocoles de communication connexes qui interagissent.

Au niveau le plus bas, il existe un protocole qui décrit comment les paquets d'octets sont envoyés sur une connexion série. Ceci est commun à tous les périphériques USB (mais différent entre USB2 et USB3).

L'un des premiers paquets envoyés demande à l'appareil de se décrire. Pour éviter un problème de poulet et d'oeuf, le protocole d'identification est le même pour tous les périphériques USB. Le système d'exploitation peut utiliser cette identification pour charger le bon pilote.

À un autre niveau encore, l'USB est un bus, ce qui signifie que plusieurs appareils doivent partager la bande passante. Cela signifie qu'il existe un protocole qui indique à chaque appareil quand il peut parler et quand ce n'est pas le cas. Étant donné que tous les périphériques USB doivent s'y conformer, un protocole commun est utilisé pour organiser cela.

Enfin, de nombreux périphériques USB simples sont si simples qu'il existe des protocoles supplémentaires qui décrivent une classe entière de périphériques (souris, claviers, stockage, adaptateurs Ethernet, ...). La plupart des appareils prennent en charge zéro ou l'un de ces protocoles fonctionnels.


«L'USB est un bus, ce qui signifie que plusieurs appareils doivent partager la bande passante» - Un point que l'OP a ignoré lorsqu'il n'utilise qu'une configuration point à point pour sa question. Étant donné que deux (ou plusieurs) périphériques USB peuvent partager le câble avec le PC hôte, nous pouvons en déduire qu'il doit y avoir un protocole.
sciure de bois

@sawdust Puisqu'il fonctionne du tout (même point à point), nous pouvons déduire qu'il existe un protocole. La découverte d'appareils, par exemple, ne serait pas possible s'il n'y avait pas de protocole standard.
reirab du

Il existe en effet une norme de communication et, par conséquent, une communication série Universal Serial Bus.
Ramhound

@Ramhound Oui, comme la plupart des conceptions de bus modernes pour tout sauf les interfaces mémoire, l'USB utilise des paires différentielles série pour la transmission de données. USB <= 2.0 avait une seule paire différentielle, tandis que USB 3 a deux paires différentielles supplémentaires (une pour la transmission SuperSpeed ​​et une autre pour la réception SuperSpeed, permettant une communication en duplex intégral à 5 ​​Gbit / s dans chaque direction.)
reirab

Je pensais juste que je pointerais son bus série au cœur de la norme, l'auteur ne semblait pas conscient de ce fait, d'où la question.
Ramhound

5

Une partie de la réponse réside peut-être dans la définition de l'expression " protocole de communication ". En allant à la même source que vous (Wikipedia), vous trouverez des informations utiles telles que:

  • Pour que la communication ait lieu, des protocoles doivent être convenus.
  • Les systèmes communicants utilisent des formats bien définis (protocole) pour échanger des messages.
  • un protocole doit définir la syntaxe, la sémantique et la synchronisation de la communication.
  • Un protocole peut donc être implémenté en tant que matériel, logiciel ou les deux.

Une façon simple de penser à cela est qu'un protocole est une manière prédéfinie et convenue de faire quelque chose , dans ce cas, la chose est de savoir comment déplacer des données vers et depuis un périphérique connecté par USB. Côté matériel, chaque broche a un niveau de tension et un protocole d'utilisation prédéfinis, chaque type d'appareil a un protocole d'utilisation prédéfini pour chaque broche et chaque paquet de données a une syntaxe et un format de données prédéfinis. Il y a également un protocole de communication de poignée de main incorporé. Collectivement, ce sont toutes des parties de la collection de normes pour l'utilisation de périphériques USB, alias le protocole USB, qui est décidé (c'est-à-dire conçu, proposé, débattu, révisé et finalement accepté) par les membres de l'USB Implementers Forum, Inc.

Alors oui, il est un protocole USB, ou plus exactement il y a un certain nombre de pré-défini et approuvé le protocole USB s pour différentes utilisations USB.


1
1. Le processus de communication implique (au minimum) trois éléments: (1) codage / envoi ET (2) réception / décodage (3) _information_ (par opposition au bruit aléatoire). Si l'un de ces 3 éléments manque, le processus échoue. Des éléments supplémentaires peuvent également être présents tels que la rétroaction, le support (canal) et le contexte, entre autres. SOURCE: Un de mes diplômes est en études des communications
OMY

1
2. SETI n'est pas une question de communication, c'est une question d' exploration et de découverte . Même si nous détectons un signal fabriqué authentique, rien ne garantit que nous le comprendrons jamais ou que nous pourrons communiquer avec l'expéditeur. SOURCE: [Déclaration de mission SETI] [1] [1]: seti.org/about-us
OMY

1
3. La compatibilité entre navigateurs est généralement causée par (a) les fabricants de navigateurs qui ne suivent pas les protocoles, ou (b) les protocoles mal écrits provoquant des implémentations défectueuses (pour des exemples, considérez les infâmesbogues du modèle de boîte IEet consultez également < quirksmode.org> ). C'est pourquoi nous avons maintenant HTML 5 et CSS 3 , car les protocoles devaient être améliorés. SOURCE: Propriétaire et exploitant de ma propre société de développement Web depuis un certain nombre d'années
OMY

1
4. Premièrement, les signaux radio qui se "synchronisent" sur la fréquence utilisent des protocoles AM (modulation d'amplitude). Les signaux radio FM (modulation de fréquence) se "synchronisent" avec une intégrale temporelle. Les protocoles pour les systèmes FM impliquent des éléments fixes et dynamiques pour traiter les informations. L'élément dynamique est leréglage des fréquences variables , qui est limité à une plage de fréquences prédéfinie et limitée.
OMY

1
Les éléments fixes sont les formules mathématiques de modulation et de démodulation du signal. Quelles que soient les fréquences, ces formules sont constantes et peuvent être mises en œuvre pour traiter le signal via un matériel analogique ou un logiciel numérique. SOURCE: Expérience personnelle en tant qu'amateur d'électronique et aussi [Wikipedia] [1] [1]: en.wikipedia.org/wiki/Frequency_modulation
OMY
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.