USB

Page précédente.

Hendrickx Edouard M13 Cornet Julien M13

toc =1. Généralité=

L’USB a été conçu au milieu des années 90 afin de remplacer les nombreux ports externes d’ordinateurs, lents et incompatibles les uns avec les autres. Différentes versions de la norme ont été développées au fur et à mesure des avancées technologiques, chacune étant vouée à remplacer les précédentes car plus performante.

1.1. Historique de la norme
__USB 1 __

En 1996, la première version de la norme, l'USB 1.0, est spécifiée par sept partenaires industriels (Compaq, DEC, IBM, Intel, Microsoft, NEC et Northern Telecom). Mais elle reste théorique et n'a jamais vraiment été appliquée : par manque de composants, il faudra attendre la seconde version de la norme 1998, intitulée USB 1.1, pour que l'USB commence à être effectivement utilisé.

L'USB 1.1 apporte des corrections à la norme 1.0 et définit également deux vitesses de communication :

- Mode "low speed" : 1.5 Mb/s, cette vitesse a été introduite pour démocratiser l’USB grâce au faible coût. En effet, les câbles USB pour le « low speed » n’ont pas besoins d’être blindé, et ce débit suffit pour des composants qui n’ont pas besoins de gros débits : les souris optique, clavier…

- Mode "full speed" : 12Mb/s, ce mode a été conçu pour remplacer les liaisons séries et parallèles. On y retrouve les imprimantes, les disques durs, les scanners, les graveurs de CD et autres périphériques ayant besoin de plus de rapidité.

__USB 2 __

En 2000, l’USB 2.0. apparaît. Cette norme optimise l'utilisation de la bande passante et supporte toutes les caractéristiques de l’USB 1.1 et rajoute un mode « high speed » qui permet d’atteindre des débits de 480 Mb/s.

__USB 3 __

En 2008, apparait l'USB 3.0. Il permet d’atteindre des débits de 4,8 Gb/s en mode « super speed ». Si la connectique entre l’USB 1 et l’USB 2 n’a pas évoluée, ici elle est différente. Ainsi, l’USB 3.0 utilise 8 fils (au lieu de 4 pour les versions antérieures).

Un standard 3.1 à 10 Gb/s est annoncé en août 2013. Ses spécifications techniques sont finalement publiées par le consortium USB Implementers Forum en août 2014.



1.2. Evolution des connecteurs USB
__Type A et B : __

De base, le bus USB ne permet pas de relier entre eux deux périphériques ou deux hôtes : le seul schéma de connexion autorisé est un périphérique sur un hôte. Pour éviter des branchements incorrects, la norme spécifie deux types de connecteurs.

Le type A : destiné à être situé sur l'hôte.



Le type B : destiné à être situé sur le périphérique.

__Type mini connecteur : __

<span style="font-family: Arial,Helvetica,sans-serif;">Devant le développement des appareils compacts (téléphones portables, appareils photo numériques, ...), une mise à jour de la norme USB 2 a introduit une version miniature du connecteur A et B : le mini A et mini B. Elles sont fonctionnellement équivalente aux connecteurs A et B, mais de dimensions nettement réduites.



__<span style="font-family: Arial,Helvetica,sans-serif;">Type micro connecteur : __

<span style="font-family: Arial,Helvetica,sans-serif;">La taille des appareils mobiles s'étant encore réduite, les connecteurs mini A et B sont devenus à leur tour trop gros. Le connecteur micro B est non seulement plus fin que le mini B, mais également prévu pour supporter un grand nombre de cycles de connexion/déconnexion (jusqu'à 10 000), ce qui le rend particulièrement bien adapté aux appareils mobiles car ils sont souvent branchés et débranchés (tablettes tactiles, smartphones, ...).



<span style="font-family: Arial,Helvetica,sans-serif;">L'USB 2 a également introduit le connecteur micro AB, utilisé dans le cadre de l'extension "On-The-Go". Il permet aux appareils compatibles de jouer indifféremment le rôle d'hôte ou rôle de périphérique, contrairement à l'USB classique où l'hôte se branche sur obligatoirement sur un connecteur de type A et le périphérique sur un connecteur de type B.

__<span style="font-family: Arial,Helvetica,sans-serif;">Type C : __

<span style="font-family: Arial,Helvetica,sans-serif;">Un nouveau connecteur a été introduit dans la norme le 11 août 2014 : le type C, destiné à remplacer tous les connecteurs précédents. Il a la particularité d'être réversible, c'est-à-dire qu'il n'a plus de sens haut/bas. Outre l'aspect pratique, il est compatible à la fois avec les standards USB 3.1 (qui doublent le débit théorique) ainsi qu'avec l'USB Power Delivery (jusqu'à 100 watts dans les deux sens).

__<span style="font-family: Arial,Helvetica,sans-serif;">Type USB 3.0 : __

<span style="font-family: Arial,Helvetica,sans-serif;">Il existe également les connecteurs de type A et B qui fonctionnent pour l'USB 3.0 qui permet d'augmenter le débit de transfert.

Haut de page.

1.3. Topologie du bus
<span style="font-family: Arial,Helvetica,sans-serif;">La topologie du BUS USB est une topologie de type "tiered star" (ou "étoile série" en français). Cette topologie tolère jusqu’à 5 niveaux de HUBs et l’adressage se fait sur 7 bits et limite donc le nombre de périphérique à 127. Cette hiérarchie permet une rétrocompatibilité avec les anciennes normes USB. Nous pourrons donc avec un HUB 2.0 être connecté à un HUB 1.1 mais les transferts seront tout de même régit selon la norme 1.1 dans le HUB 2.0.

Exemple de branchement USB avec une topologie étoile : Haut de page.

1.4. Modèle OSI
__Fonction des couches :__

- Physique : fournit les moyens mécaniques et électriques nécessaires à l'activation, au maintien et à la désactivation des connexions physiques destinées à la transmission des éléments binaires (bits).

- Liaison: s'occupe de l'établissement, du maintien et de la libération des connexions, en se basant sur les moyens fournis par la couche physique. Elle s'occupe aussi du partage d'un support physique unique entre plusieurs machines.

- Réseau : doit acheminer des paquets d'information jusqu'à leur destination finale. Elle gère donc les flux d'informations (en évitant les embouteillages), leur routage, ainsi que l'adressage. Elle s'appuie par les moyens fournis par les couches physiques et liaison.

- Transport : complète les fonctions des couches précédentes en gérant les erreurs et en optimisant le transport.

- Session : établit et maintien des sessions.

- Présentation : formate les données à envoyer dans un format compréhensible pour le destinataire. Elle gère par exemple le cryptage et la compression des données.

- Application: au-dessus de toutes les autres, représente les applications qui utilisent la connexion réseau, comme par exemple un logiciel de courrier électronique ou un logiciel de transfert de fichiers.



Haut de page.

= = =2. Couche 1 : physique=

2.1. Codage NRZI
<span style="font-family: Arial,Helvetica,sans-serif;">Le codage NRZI (Non return to zero inverted), est une variante du codage Non Return to Zero (NRZ).

<span style="font-family: Arial,Helvetica,sans-serif;">Le codage NRZI est la méthode de codage d’un signal binaire sur une ligne électrique utilisé par la norme USB. Cette méthode nécessite 2 lignes (D+ et D-) et utilise la différence de tension entre ces deux lignes pour coder les données. Il y a donc 4 états possibles des lignes : Single ended zero (SE0), Single ended one (SE1), J et K. Il est à noter que les lignes ne doivent jamais être dans l’état SE1. De plus, lorsque la ligne n’est pas occupée pour un transfert de donnée, celle-ci est en IDLE ce qui correspond à l’état J.



<span style="font-family: Arial,Helvetica,sans-serif;">Comme nous pouvons le voir dans le tableau ci-dessus, le 0 logique sera caractérisé par un changement d’état des lignes de J vers K ou de K vers J, alors que le 1 logique sera caractérisé par un non changement d’état des lignes. Pour évité une dérive d’horloge, un 0 sera inséré tout les six 1 logique consécutifs.

<span style="background-color: #f9f9f9; color: #252525; font-family: Arial,Helvetica,sans-serif; font-size: 12px;">Codage NRZI de a séquence 1110001101 Haut de page.

2.2. Identification de la vitesse
Pour choisir entre la version USB Low Speed et Full Speed, il suffit de placer une résistance de tirage sur l'interface d'entrée. Cette résistance de tirage (Pull-Up de 1.5Kohm) est placée soit sur D- dans le cas du Low Speed ou sur D+ dans le cas du Full Speed. Elle est indispensable pour permettre au HUB amont de détecter la connexion ou la déconnexion. Par contre côté sortie du HUB il y a une résistance sur chacune des lignes D+ et D- (Pull Down de 15KOhm). On voit sur le schéma ci dessous que s’il n’y a pas de résistance de Pull up, les deux câbles de données sont tirés à la masse par les deux résistances de Pull down. Les résistances Pull down étant de 15kOhm et les résistances de Pull up de 1.5kOhm (en fonction de la vitesse choisie) il y aura toujours une ligne de donnée qui sera à 90% de Vcc. Si le HUB détecte qu’une ligne de donnée avoisine les 90% de Vcc il en conclura qu’un composant USB est connecté ainsi que des informations sur la vitesse du composant, Low ou Full Speed.

Haut de page.

2.3. Reset
Quand l’hôte veut démarrer la communication avec le périphérique, il va commencer par envoyer une condition de « reset » qui va mettre le périphérique dans sa configuration par défaut. Le reset est un SE0 qui dure au moins 10ms. Le périphérique peut reconnaitre le reset après 2,5µs. Attention qu’il ne faut pas confondre la condition de reset avec le signal de power-on reset d’un microcontrôleur. C’est un reset de protocole qui assure que le périphérique USB démarre dans un état connu. Haut de page.

2.4. Connecteurs et composition du câble
<span style="font-family: Arial,Helvetica,sans-serif;">Nous retrouvons dans les connecteurs USB les différents câbles qui doivent permettre la connexion des signaux D+ et D- et l’alimentation éventuelle du périphérique, ce qui rajoute le VBUS et GND (la masse).

<span style="font-family: Arial,Helvetica,sans-serif;">Dans les connecteurs USB, les bornes d’alimentation sont plus longue que celle des données, de façon a alimenté le périphérique avant les données et de coupé la connexion des données avant celle de l’alimentation. Cela permet de connecter et de déconnecter le périphérique à chaud.

Comme déjà vu précédemment, il existe plusieurs types de connecteurs. En général, les connecteurs de type A sont utilisés pour des périphériques qui demande une petite bande passante tandis que les connecteurs de type B sont utilisés pour des périphériques qui demandent une plus grande bande passante. Les connecteurs de type mini et micro possède une piste supplémentaire qui permet la distinction entre l’hôte et le périphérique. Chaque connecteur dispose de deux fils d’alimentation (5V et GND) et deux fils destinés au transfert de données (D+ et D-).

En version Low Speed le blindage n'est pas obligatoire (ce qui assure une plus grande souplesse de manipulation en particulier pour une liaison souris). La longueur maximale autorisée par la norme est de 3m pour un câble non blindé donc généralement pour un périphérique Lowspeed USB (= 1.5Mb/s) et de 5m pour un câble blindé dans le cas d’un périphérique Full speed USB (=12Mb/s).

De plus, les connecteurs USB (de type A ou B), ont les 2 pattes d’alimentation un peu plus longues que les pattes de données. Ceci est volontaire, d’une part pour que le périphérique USB soit alimenté avant que transitent les données. Il est normal qu’avant de transmettre des données, que le périphérique soit reconnu et que les bons drivers ont été chargés. Ensuite, cette différence de longueur entre les pattes d’alimentations et de données est aussi pour protéger les composants USB, car un composant doit d’abord être alimenté avant de recevoir des données.

Dans le tableau ci-dessous, on peut voir les différentes combinaisons réceptacle/connecteur USB. Dans le tableau ci-dessous, on peut remarquer les différentes combinaisons de connecteurs pour un même câble USB.



Haut de page.

2.5.1. Alimentation de périphérique USB
Pour simplifier l’explication de l’alimentation des périphériques USB, la norme a prévu deux niveaux d’alimentations, le premier niveau consomme une unité d’énergie, l’autre consomme cinq unités. Une unité vaut 100mA. C’est à dire qu’il existe des composants qui consomment 100mA et d’autres 500mA. Généralement les composants Low USB consomment une unité d’énergie et les composants High USB consomment jusqu'à cinq unités. Par défaut tous les composants consomment une unité et c’est par soft qu’on lui demande de consommer plus si l’application le nécessite, dans le cas d’un composant High USB bien sur. Toutes ces informations sont contenues dans les descripteurs, le composant ne pourra jamais consommer plus que ce qui est prescrit dans son descripteur. On peut donc en déduire qu’un périphérique High power doit posséder un dispositif d’alimentation séquentiel (100mA, puis 500mA). Aucune fonction (Device ou hub) ne peut consommer plus de 100mA sur le bus avant d’être énumérée. Après énumération, un appareil peut consommer jusqu’a 500mA pour un appareil « High power device » ou rester à 100mA pour un Low Power Device. L’USB est donc assez flexible et peut supporter plusieurs types d’alimentation. Certains composants peuvent être entièrement alimenté par le bus USB. (Bus powered).

__Avantage de l'alimentation USB :__

Le fait de pouvoir alimenter un périphérique USB avec le même câble qui transporte les données à de multiples avantages. D’une part cela évite déjà à l’utilisateur de brancher le périphérique sur une prise de courant extérieure, ceci rend déjà le périphérique plus léger et moins encombrant. D’autre part d’un point de vue du concepteur, cela réduit le prix de fabrication.

__Différents types d'alimentation du bus USB :__

- Low-power bus-powered functions :

Les périphériques utilisés par un bus Low-Power puisent toutes leurs puissances de VBUS et ne peuvent consommer qu’une unité d’énergie. Les périphériques Low power alimentés par un Low Power Bus sont aussi conçus pour travailler avec une tension de VBUS s ‘échelonnant entre 4.4 V et 5.25V. Mais une tension de 4.4V suffit pour l’énumération. Beaucoup d’appareils fonctionnant à 3.3V doivent être muni d’un régulateur.

- High-power bus-powered functions :

Les périphériques alimentés par un bus High-Power puisent toutes leurs puissances de VBUS et ne peuvent puiser qu’une unité d’énergie avant d’être configuré. Apres la configuration, ils peuvent consommer jusqu'à 500mA. La seule condition est que ce soit définit dans les descripteurs. Les périphériques Low et High Power alimentés par un High Power Bus doivent eux aussi être détectés avec une tension s’échelonnant entre 4.75V et 5.25V.

- Self-powered functions :

Ce type de périphérique à une alimentation mixte, c’est à dire qu’il peut absorbée une unité d’énergie sur le Bus USB et le reste est tiré d’une alimentation extérieure. Il faut prévoir alors dans ce cas un peu de réserve car le bus ne délivrera pas plus qu’une unité. Ces types de périphériques « mixtes » sont les plus facile à concevoir puisque la détection et l’énumération du périphérique peut se faire sans alimentation externe, puisqu’une unité suffit.

Dans le tableau ci-dessous, on peut voir les puissances des différentes normes USB.



Haut de page.

2.5.2. Mode veille
<span style="font-family: Verdana,sans-serif; font-size: 9pt;">Le mode Veille est obligatoire sur tous les appareils. Pendant son temps d'action, d'autres contraintes surviennent. Le courant maximum de veille est proportionnel à l'unité de charge. Pour un appareil d'une unité de charge, le courant de veille maximum est de 500 μA. Ceci comprend le courant dû aux résistances de rappel sur le bus. Au niveau du hub, D- et D+ possèdent des résistances de rappel niveau bas de 15 kOhm. __Accès au mode veille :__ Un appareil USB entre en veille lorsqu’il n’y a aucune activité sur le Bus pendant plus de 3 ms. Un paquet début de trame est normalement envoyer toute les 1 ms par l’hôte pour maintenir le périphérique éveillé. Une fois l’appareil en veille il doit être capable de reconnaître le signal de reprise et de reset. <span style="background-color: #ffffff; display: block; font-family: Verdana,sans-serif; font-size: 12px; text-align: justify;">Il dispose ensuite de 7 ms de plus pour éteindre l'appareil et ne prendre que le courant de veille désigné, ne prenant ainsi que le courant de veille nominal à partir du bus et ce, 10 ms après que l'activité du bus se soit arrêtée. Afin de le maintenir connecté à un hub ou à un périphérique mis en veille, l'appareil doit encore fournir de l'alimentation à ses résistances de rappel de sélection de vitesse pendant le mode veille. <span style="background-color: #ffffff; display: block; font-family: Verdana,sans-serif; font-size: 12px; text-align: justify;">L'USB possède un démarrage de trames de bits (frame packet) ou bien d'entretien qui sont envoyés périodiquement sur le bus. Ceci empêche un bus inutilisé d'entrer dans le mode veille en l'absence de données. <span style="background-color: #ffffff; display: block; font-family: Verdana,sans-serif; font-size: 12px; text-align: justify;">- Un bus haute vitesse enverra une trame toutes les 125.0 μs ± 62.5 ns. <span style="background-color: #ffffff; display: block; font-family: Verdana,sans-serif; font-size: 12px; text-align: justify;">- Un bus pleine vitesse enverra une trame toutes les 1.000 ms ± 500 ns. <span style="background-color: #ffffff; display: block; font-family: Verdana,sans-serif; font-size: 12px; text-align: justify;">- Un bus basse vitesse aura un dispositif d'entretien qui est un EOP (End Of Packet ou Fin De Paquet) toutes les 1 ms simplement en l'absence de données basse vitesse. <span style="background-color: #ffffff; display: block; font-family: Verdana,sans-serif; font-size: 12px; text-align: justify;">Le terme veille globale (Global Suspend) est utilisé lorsque le bus USB entier entre collectivement dans le mode veille. Cependant les appareils sélectionnés peuvent être mis en veille en ordonnant au hub sur lequel l'appareil est aussi connecté. On fait référence à cette opération comme mode "veille sélective". <span style="background-color: #ffffff; display: block; font-family: Verdana,sans-serif; font-size: 12px; text-align: justify;">L'appareil reprendra son fonctionnement lorsqu'il recevra tout signal qui n'est pas en attente. Haut de page.

2.6. Temps de propagation
La longueur maximum exploitable est conditionnée par les temps de propagation le long du câble (30ns par segment) et à travers les hub (40ns par HUB), et les temps de réponse de la fonction adressée (700ns maxi) sachant que le temps de propagation (aller-retour) entre l'hôte et le périphérique ne doit pas dépasser 1300ns.

De plus, lorsqu'on dispose plusieurs HUBs en cascade, il ne faut pas sous estimé les contraintes d'alimentation et la chute de tension le long du trajet : s'il s'agit d'un « device » alimenté via le bus USB il est clair qu'il doit pouvoir fonctionner avec une tension notablement inférieure à 5V.

Exemple du temps de propagation d'une trame USB. Haut de page.

2.7. Temps d'accès au bus
= = Pour assurer la synchronisation entre l'hôte et les périphériques, l’USB divise le bus en des intervalles de temps. Pour le low ou le full speed, le bus est divisé en frames qui sont des périodes de 1 ms. Une période de 125 µs, qu’on appelle microframes, correspond au high speed.

Les frames et les microframes ne coexistent pas sur un bus. Un transfert doit se dérouler durant une frame. En effet, comme déjà signaler, un paquet SOF est envoyé à chaque nouvelle frame, il faut donc que la transaction soit finie durant la frame sinon elle sera interrompue par le prochaine SOF.

L’hôte peut arranger les transactions pour utiliser au mieux la bande passante disponible. 2 transactions au travers le même pipe doivent être dans le bonne ordre, mais les transactions de 2 transferts différent peuvent être réordonné par l’host. Haut de page.

=3. Couche 2 : liaison de données=

3.1. Les champs de paquets
Les données sont transmises sur le BUS USB avec le bit de poids faible en premier. Les paquets USB sont composés des champs suivant : - **Sync :** Tous les paquets commencent avec un champ Sync qui est utilisé pour synchroniser l’horloge du récepteur avec celle de l’émetteur. Il est composé de 8 bits pour la low et full speed et de 32 bits pour la high speed. Les deux derniers bits indiquent l’endroit où le PID commence. - **PID :** Packet ID est utilisé pour identifier le type de paquet qui est envoyé. || **Groupe** Les PID du groupe data servent à s’assurer que les données reçues sont bien celles qui étaient attendues. Les DATA0 et DATA1 sont utilisés en low et full speed. Les DATA2 et MDATA sont uniquement utilisés en high speed. Il y a donc 4 bits pour le PID qui sont répétés pour former un PID de 8 bits. Cela permet de s’assurer qu’il a été correctement reçu.
 * **Valeur** || **Nom** || **Description** ||
 * Token / Jeton || 0001 || OUT Token || Jeton de sortie ||
 * ^  || 1001 || IN Token || Jeton d'entrée ||
 * ^  || 0101 || SOF TOKEN || Jeton de début de trame ||
 * ^  || 1101 || SETUP TOKEN || Jeton de configuration ||
 * Data / Données || 0011 || DATA0 ||  ||
 * ^  || 1011 || DATA1 ||   ||
 * ^  || 0111 || DATA2 ||   ||
 * ^  || 1111 || MDATA ||   ||
 * Handshake / Poignée de mains || 0010 || ACK Handshake (Acknowledge) || Validation ||
 * ^  || 1010 || NAK Handshake (No Acknowledge) || Pas de validation ||
 * ^  || 0110 || NYET (No response Yet) || Pas encore de réponse ||
 * ^  || 1110 || STALL Handshake || Bloqué ||
 * Special / Spécial || 0000 || PREambule || Synchronisation initiale ||
 * ^  || 1000 || ERR || Erreur ||
 * ^  || 0100 || Split || Partagé ||
 * ^  || 1100 || Ping || S'assurer d'une bonne connexion ||

- **ADDR :**

Le champ adresse détermine à quel périphérique le paquet est destiné. Sa longueur est de 7 bits et lui permet donc de supporter 127 périphériques. L’adresse 0 n’est pas valide mais un périphérique qui n’a pas encore reçu d’adresse doit répondre aux paquets envoyés à l’adresse 0.

- **ENDP :**

Le champ de terminaison (endpoint) est composé de 4 bits, soit 16 terminaisons possibles. Cependant, les périphériques low speed peuvent seulement avoir 2 endpoints supplémentaire au dessus du canal de communication (pipe) par défaut, ce qui fait un total de 4 terminaisons maximales. - **CRC :** Les contrôles à redondance cyclique (CRC) sont exécutés sur les données utiles envoyées. Chaque paquet jeton à un champ CRC de 5 bits tandis que les paquets de données ont un CRC de 16 bits.

- **EOP**

Les champs EOP (End Of Packet) signal la fin des paquets. Ils sont composés d’un SE0 d’un temps de deux bits qui est suivit par un J pour une durée de 1 bit.

Haut de page.

3.2. Les types de paquets
On appelle transaction un simple transfert de données utilisant des paquets juxtaposés. Le paquet SOF indique le début d’une nouvelle transaction.

L'USB a quatre types différents de paquets : 1) **Les paquets jetons (Token Packets)** : ils indiquent le type de la transaction qui va suivre et donnent l’adresse USB et le sens du transfert. **2)** **Les paquets de données (Data Packets) :** ils contiennent la charge utile (payload). **3)** **Les paquets poignée de mains (Handshake Packets) :** ils sont utilisés pour valider les données ou indiquer des erreurs. **4)** **Les paquets début de trame (SOF Packets) :** indiquent le commencement d’une nouvelle trame.

Les différents paquets ont une structure bien définie : **1) Token Packets :** Il y a 3 types de Token packets : In : Informe l'appareil USB que l'hôte veut lire des informations. Out : Informe l'appareil USB.que l'hôte veut envoyer des informations. Setup : Utilisé pour commencer les transferts de commande.

Le format des Token Packets : Il y a deux sortes de paquets de données pour la norme 1.1 (Data0 et Data1). Le mode High Speed définit 2 autres PIDs de données, DATA2 et MDATA. La taille maximale des " données utiles " pour les périphériques Low Speed est de 8 octets. La taille maximale des " données utiles " pour les périphériques Full Speed est de 64 octets. La taille maximale des " données utiles " pour les périphériques High Speed est de 1024 octets.
 * 2) Data Packets :**

Il y a 3 sortes de paquets Handshake qui font simplement partie du PID.
 * __3) Handshake Packets :__**
 * <span style="font-family: Verdana-Bold,sans-serif; font-size: 10pt;">ACK **<span style="font-family: Verdana,sans-serif; font-size: 10pt;">- Validant que le paquet a été reçu correctement
 * <span style="font-family: Verdana-Bold,sans-serif; font-size: 10pt;">NAK **<span style="font-family: Verdana,sans-serif; font-size: 10pt;">- Indiquant que l'appareil ne peut temporairement ni envoyer ni recevoir des données. Aussi utilisé pendant les transactions d'interruptions pour avertir l'hôte qu'il n'a pas de données à envoyer.

L’intervention de l'hôte.
 * <span style="font-family: Verdana-Bold,sans-serif; font-size: 10pt;">STALL **<span style="font-family: Verdana,sans-serif; font-size: 10pt;">(Bloqué) - L'appareil se retrouve dans un état qui va exiger

<span style="font-family: Verdana,sans-serif; font-size: 10pt;">Le paquet SOF composé d'une trame de 11 bits est envoyé par l'hôte toutes les 1ms ± 500ns sur un bus Full Speed vitesse ou bien toutes les 125μs ± 0,0625μs sur un bus High Speed.
 * 4) SOF Packets :**



Haut de page.

3.3. Les types de terminaisons
Chaque périphérique contient un ensemble de terminaisons (endpoints). Les terminaisons peuvent être décrites comme émetteurs ou récepteurs de données. Comme le Bus est régi par l’hôte, les terminaisons se présentent à la fin de la chaine de communication sur le périphérique USB.

Chaque terminaison possède les caractéristiques suivantes : - L’accès au bus - La bande passante requise - Un périphérique unique est déterminé par un numéro de terminaison - Taille maximal des paquets envoyé ou reçu - Le type de transfert de la terminaison.

Exemple : une imprimante scanner. Elle possède un numéro de terminaison pour la fonction impression, et un numéro pour la fonction scanner. Le périphérique en high speed supporte jusqu’à 15 endpoints. En low speed le périphérique supporte maximum 3 endpoints. Les terminaisons ont une direction spécifique : périphérique vers hôte (IN) ou hôte vers périphérique (OUT). Dès lors, deux terminaisons peuvent avoir le même numéro mais des directions de transferts différentes. Toutes les fonctions implémentent le numéro de terminaison 0. Seulement les terminaisons avec le numéro 0 peuvent être accessibles dès que le périphérique est branché. Le endpoint 0 permet les transferts IN et OUT. Il est le seul à être bidirectionnel. Tous les autres numéros sont dans un état indéfini tant que le périphérique n’est pas configuré.

Le endpoint 0 ne nécessite pas de descripteurs.

Les terminaisons sont regroupées en interfaces.

3.3.1. Transfert de contôle
Ce mode de transfert est compatible avec le Low, High et Full Speed USB. Ils sont utilisés pour les opérations d’initialisations et de configurations. Ils sont essentiels pour installer un appareil USB car les fonctions d’énumération seront exécutées en utilisant les transferts de contrôles. Les paquets sont initialisés par l’hôte et envoyé par rafale. Taille maximal des données de « charge utile » (payload): - Pour le low speed la taille doit être de 8 octets. - Pour le fullspeed, les appareils autorise une taille de paquet de 8, 16, 32 ou 64 octets. - Pour le high speed, la taille est de 64 octets. Un transfert de contrôle possède 3 étapes : **//__1. L’étape d’installation (Setup stage) :__//** Elle se produit lorsqu’une demande a été envoyée. Elle est constituée de 3 paquets. - **setup token** : il est envoyé le premier, il contient l’adresse et le numéro de la terminaison (endpoint). - **data packet** : il est envoyé après le setup token, il a toujours un PID du type data0 et contient un setup packet qui détaille le type de la requête, ainsi que le nombre de données qui doivent être transférées dans le DATA stage. - **handshake** : il est utilisé pour valider la réception ou pour indiquer une erreur. Si le périphérique reçoit correctement le setup data, il répond via un ACK, sinon il ignore la donnée et n’envoie pas un handshake packet. Le périphérique ne peut pas émettre un paquet STALL ou NAK comme réponse à un setup packet.

En gris l'hôte, en blanc le périphérique

**//__2. L’étape de donnée (Data stage) :__//** Elle est facultative. Elle consiste en un ou plusieurs transferts IN ou OUT. la quantité de données qui doit être envoyée dans cette étape est définie dans le setup stage. Si elle dépasse la taille maximale du paquet, les données seront envoyées en plusieurs transferts, chacune ayant la longueur maximale du paquet à l'exception du dernier paquet. 2 cas sont possibles en fonction de la direction du transfert : **a)** **transfert en entrée (IN) :** L’hôte est prêt à recevoir les données de contrôle, il émet un IN token.  Si le périphérique reçoit le token IN avec une erreur (le PID ne correspond pas au PID inverser), alors il ignore le packet.  Si le token a été reçu correctement :   Le périphérique peut
 * soit répondre avec un DATA packet qui contient la donnée de contrôle à envoyer
 * soit un paquet STALL indique une erreur de transfert
 * soit un paquet NAK signalant à l’hôte que le transfert fonctionne mais il n’a pas de données à envoyer provisoirement.


 * b)** **transfert en sortie (OUT) :**

L’hôte a besoin d’envoyer un DATA packet. Il émet un OUT token suivit d’un DATA packet qui contient les données de contrôles.

Si le OUT token ou le DATA packet est corrompu, alors l’appareil ignore le paquet. Si le buffer de l’appareil est vide, il reçoit correctement la donnée, il émet un ACK pour dire à l’hôte qu’il a bien reçu les données. Si l’appareil a son buffer plein (à cause du traitement du paquet précédent), il retourne un NAK. Si le transfert a connu une erreur (le périphérique reçoit trop de données), il retourne un STALL.

**//__3. L’étape d’état (status stage) :__//** Informe le statut de toute la requête et change selon la direction du transfert. Le rapport d’état est réalisé par le périphérique. L’étape d’état consiste en une transmission de seulement un IN token ou un OUT token. L’étape d’état utilise le transfert du type opposé à celui utiliser dans l’étape de donnée. Donc si l’étape de donnée était un transfert OUT, l’étape d’état sera un transfert IN et vice versa). **a)** **IN :** Si l’hôte envois un IN token pendant l’étape de donnée (DATA stage) pour recevoir des données, alors l’host doit ACK la bonne réception de ces données. Ceci est réalisé par l'hôte qui envoie un jeton OUT suivi par un paquet de données de longueur nul. L’appareil peut maintenant informer son statut. Un ACK indique que le périphérique a achevé la commande et qu’il est maintenant prêt à accepter une autre commande. Si une erreur s'est produite pendant l'exécution de cette commande, alors le périphérique émettra un STALL (Bloqué). Si l’appareil continue l'exécution, elle retourne un NAK indiquant à l'hôte la nécessité de répéter le status stage ultérieurement. **b)** **Out :** Si l’hôte envois un OUT token pendant le DATA stage pour envoyer des données, le périphérique va ACK la réception réussi des données en envoyant un paquet d’une longueur 0 comme réponse à un IN token.  Si une erreur se produit le périphérique envois un STALL  Si le périphérique était encore occupé à traiter des données, il envoie un NAK demandant a l’hôte de réessayer ultérieurement.

3.3.2. Transferts d’interruption
Le transfert en mode interruption est compatible avec le Low et Full Speed USB. Les interruptions sont générées par l’appareil. Toutefois en USB, si un appareil demande l'attention de l'hôte, il doit attendre que l'hôte l'interroge avant de signaler qu'il a besoin d'une attention urgente. Caractéristiques : Diagramme d’une transaction d’interruption :
 * Temps de retard (ou Latence) garantie
 * Ligne de flux - Unidirectionnel
 * Détection d'erreur et reprise sur erreur
 * La taille maximale de "charge utile" (payload) pour des appareils Low Speed est de 8 octets
 * La taille maximale de "charge utile" (payload) pour des appareils Fullspeed est de 64 octets
 * La taille maximale de "charge utile" (payload) pour des appareils Highspeed est de 1024 octets

**En mode IN :**

L’hôte fait du polling sur la terminaison d’interruption. A chaque fois que l’hôtepoll, il envoie un IN token. Si le IN token est corrompu, l’appareil ignores le paquet et continue la surveillance du Bus en attende de nouveaux token. Si une interruption a été mise en attente par l'appareil, l’appareil enverra un paquet Data contenant des données ayant rapport avec l'interruption quand il recevra le jeton IN. Dès que l’hôte a bien reçu le paquet DATA, il retourne un ACK. Si les données sont altérées, l'hôte ne mentionnera aucun état. Si, d'autre part, une condition d'interruption n'était pas présente quand l'hôte poll avec un IN token, l’appareil signal ce statut en envoyant un NAK Si une erreur se produit sur la terminaison, l’appareil envois un STALL en réponse au IN token.

**En mode Out :**

**OUT:** Quand l'hôte veut envoyer à l'appareil les données, il émet un jeton OUT suivi par un paquet Data contenant les données d'interruption. Si une partie du jeton OUT ou du paquet Data est altéré alors la fonction ignore le paquet. Si le buffer de terminaison de la fonction était vide il émettrait un ACK prévenant l'hôte qu'il a reçu correctement les données. Si le tampon de terminaison n'est pas vide à cause du traitement d'un paquet précédent, alors la fonction retourne un NAK. Si une erreur se produisait à cause de la terminaison et que son bit d'arrêt (Halt) ait été positionné, elle renverrait un STALL (Bloqué).

3.3.3. Transfert isochrone
<span style="font-family: Calibri,sans-serif; font-size: 11pt; text-align: justify;">Utilisée pour des périphériques dont le débit est plus important que l’intégrité des données. Ex : caméras, téléphones Ce mode de transfert est uniquement compatible avec le High et Full USB. La bande passante est garantie (débit, latence), par contre dans ce mode il n’y a pas de reprise sur erreur. <span style="font-family: Calibri,sans-serif; font-size: 11pt; text-align: justify;">Caractéristiques : La taille maximale de données en " charge utile " (payload) est spécifiée dans le [|descripteur de terminaison] d'une terminaison Isochrone. Elle est de maximum de 1023 octets pour un appareil full vitesse et 1024 octets pour un appareil high speed. Comme la taille maximale de données en " charge utile " va affecter la bande passante du Bus, il est prudent de spécifier une taille de payload modérée. Comme dans ce cas l’intégrité des données est moins importante que le débit, il y n’a pas de Handshakes packet.
 * Un accès garanti à la bande passante USB.
 * Un temps d'attente limité.
 * Des flux de données - Unidirectionnel.
 * La détection d'erreur via le CRC, mais sans reprise sur erreur
 * Seulement les modes pleines et haute vitesse.
 * Pas de contrôle d’intégrité des données

3.3.4. Transferts en bloc (bulk)
Ce mode est réservé pour les gros transferts de données.Ex : travail d'impression envoyé à une imprimante ou une image provenant d'un scanner Les Transferts en Bloc utiliseront une bande passante de réserve non attribuée sur le Bus après que toutes les autres transferts aient été allouées. Il en résultat un débit variable et fonction de la disponibilité. Si le Bus est occupé avec des transferts isochrones et/ou de transfert d'interruption, les données en bloc auront un débit plus lent sur le Bus. En conséquence, les transferts en bloc devraient seulement être utilisés pour des communications insensibles au temps du fait du non garanti du temps d'attente. Caractéristiques : Taille des paquets : USB Full Speed : 8,16,32, 64 octets. USB High Speed : 512 bytes maximum.
 * Utilisés pour de grandes quantités de données.
 * Détection d'erreurs via le CRC.
 * Pas de garantie de bande passante ou du temps d'attente minimum.
 * Intégrité des données.
 * High et Full Speed USB seulement.



Haut de page.

=4. Couche 4 : transport=

4.1. Canaux de communications
Un pipe est une connexion logique entre l’hôte et les terminaisons. Plus précisément un pipe associe un buffer sur l’hôte avec une terminaison sur un périphérique. Les pipes ont un ensemble de paramètres qui leur est associés : - bande passante allouée - type de transfert - direction des données - taille maximal des paquets

Il y a deux types de pipe :

**Stream pipes** : n’imposent pas de structure sur la donnée qui est transférée. On peut donc envoyer n’importe quelle type de données. Les données circulent de manières séquentielles et ont une direction prédéfinie (soit en entrée soit en sortie) : la communication est unidirectionnelle. Les types de transferts supportés sont les transferts en bloc, les transferts isochrones, et les transferts d’interruptions. Ils peuvent être contrôlés par l’hôte ou par le périphérique.

**Message pipes** : imposent la structure sur la donnée transférée. Ils sont contrôlés par l'hôte et sont initiés par une demande émanant de celui-ci. Les données sont ensuite transférées dans la direction voulue, dictées par la demande. Par conséquent les canaux de messages permettent aux données de circuler dans les deux directions mais ne prendront seulement en charge que les transferts de contrôle.

Pipe de control par défaut : C’est un message pipe spécial, qui peut être tout le temps accessible une fois que le périphérique est sous tension. Il fournit un moyen d’identifier et de configurer les terminaisons additionnelles. Haut de page.

=5. Couche 7 : application=

5.1. L'énumération
<span style="font-family: Arial,Helvetica,sans-serif;">L'énumération est la manière de déterminer l'appareil qui vient juste d'être branché au bus et les paramètres dont il a besoin, comme la consommation électrique, le nombre et le type de terminaison, la classe du produit, etc.… L'hôte attribuera donc à l'appareil une adresse et validera une configuration lui permettant de transférer des données sur le bus.

<span style="font-family: Arial,Helvetica,sans-serif;">A la mise sous tension de l’hôte, la phase d’énumération initiale s’exécute et les HUBs et périphériques sont initialisés de proche en proche. Le HUB racine signal donc à l’hôte qu’il a détecté ou non des périphériques non initialisés sur ses ports. L’hôte initialise alors les liaisons si nécessaire avant de la placer dans sa liste d'analyse. C’est alors au tour du HUB suivant de signaler la présence ou non de périphériques connecté a ses ports et ainsi de suite.

<span style="font-family: Arial,Helvetica,sans-serif;">Une énumération sous Windows ordinaire implique les étapes suivantes :
 * <span style="font-family: Arial,Helvetica,sans-serif;">L'hôte ou Hub détecte la connexion d'un nouvel appareil via les résistances de rappel de l'appareil reliées sur les 2 fils de données. L'hôte attend au moins 100ms, le temps que la prise soit insérée complètement et que l'alimentation de l'appareil soit stabilisée.
 * <span style="font-family: Arial,Helvetica,sans-serif;">L'hôte émet un " reset " mettant l'appareil dans l'état par défaut. L'appareil peut maintenant répondre à l'adresse zéro par défaut.
 * <span style="font-family: Arial,Helvetica,sans-serif;">L'hôte (sous MS Windows) demande les 64 premiers octets du descripteur d'appareil.
 * <span style="font-family: Arial,Helvetica,sans-serif;">Après avoir reçu les 8 premiers octets du descripteur d'appareil, l'hôte émet immédiatement un autre reset sur le bus.
 * <span style="font-family: Arial,Helvetica,sans-serif;">L'hôte émet maintenant une commande SetAdress, mettant l'appareil dans l'état adressable.
 * <span style="font-family: Arial,Helvetica,sans-serif;">L'hôte demande la totalité des 18 octets du descripteur d'appareil.
 * <span style="font-family: Arial,Helvetica,sans-serif;">Puis il demande les 9 octets du descripteur de configuration pour déterminer la taille totale.
 * <span style="font-family: Arial,Helvetica,sans-serif;">L'hôte demande les 255 octets du descripteur de configuration.
 * <span style="font-family: Arial,Helvetica,sans-serif;">L'hôte demande l'un des descripteurs de chaînes s'ils étaient indiqués.

<span style="font-family: Arial,Helvetica,sans-serif; font-size: small;">De manière générale, l'hôte remarque qu'un nouveau périphérique a été connecté au bus en détectant la variation de tension résultant. Après avoir attendu que l'alimentation se stabilise, l'hôte émet un Reset, autorisant ainsi le périphérique à répondre sur l'adresse 0 (qui est réservée à cet effet). Le périphérique, à la demande de l'hôte, envoie la liste de ses descripteurs, et se voit attribuer une adresse. Haut de page.

5.1.1. Rôle et catégories d'un descripteur
Ce point est essentiel pour le fonctionnement correct du bus. En effet chaque périphérique possède des caractéristiques propres qui le différencient du voisin. L'hôte doit être en possession de toutes ces caractéristiques pour initier une communication avec le périphérique en question.

Généralement, dans la plupart des périphériques, toutes ces informations sont stockées dans la ROM des composants, et lors de l’énumération, le périphérique envoi simplement ce fichier pour se faire connaître. Pour cela, chaque périphérique possède une série de descripteurs qui précisent complètement son identité, la façon de communiquer avec lui, … Les descripteurs standards se regroupent en 4 catégories :

- Descripteur de périphérique (Device descriptor) - Descripteur de configuration (Configuration descriptor) - Descripteur d’interface (Interface descriptor) - Descripteur de terminaisons (Endpoint descriptor)

Ces 4 catégories sont indispensables à l’exception du descripteur de terminaisons qui n’est pas nécessaire si nous n’utilisons que la terminaison 0.

En plus des descripteurs standards, il y a également d'autres descripteurs possibles :

- Descripteur de qualificatif de périphérique : uniquement nécessaire pour les périphériques supportant le Full et High Speed. - Descripteur de configuration d’autre vitesse : uniquement nécessaire pour les périphériques supportant le Full et High Speed. - Descripteur de chaine de caractère : sert à stocker du texte comme le nom du produit. - Descripteur d’interface d’alimentation : uniquement compatible avec l’USB 2.0 et permet d’avoir les informations sur la gestion de l’énergie.

__Différents descripteurs :__

Il existe deux types d’information dans les descripteurs. Les informations standards à tous les périphériques et les informations spécifiques à chaque périphérique. La figure ci-dessous représente l’organigramme de la hiérarchie des différents descripteurs standards. Haut de page

5.1.2. Descripteur de périphérique
Ce type de descripteur donne les informations générales. C’est le premier descripteur que vient lire le host. Comme dit précédemment il y a une très grande diversité de composants USB, il y a des propriétés communes à chaque dispositif d’USB comme par exemple le numéro de spécification USB qui est présent dans toutes les configurations, de même pour les numéros d’identifiant de produit et de vendeur. (Product ID et Vendor ID). Un ordinateur peut, uniquement avec ces informations contenues dans le « Device Descriptors », reconnaître un périphérique USB. Il donne également des renseignements sur le pipe de communication par défaut qui est utilisé pour la configuration.

Voici un tableau reprenant les champs contenu dans le descripteur de périphérique : Haut de page

5.1.3. Descripteur de configuration
Un descripteur de configuration renseigne sur les différents états dans lequel peut se trouver le composant USB. Ces descripteurs de configuration définissent par exemple l’origine de l’alimentation, elle peut soit provenir d’une alimentation extérieure, soit directement du bus USB. Il se peut qu’il y ait deux configurations différentes selon le type d’alimentation. En effet, si le système USB est directement alimenté par le bus USB il se peut en raison des conditions de puissance d'énergie, que le dispositif pourrait invalider quelques paramètres. La numérotation des configurations commence à 1, la configuration 0 est une configuration réservée. Si le périphérique est dans cette configuration là, on dit qu’il est n’est pas configuré "unconfigurated" et ne peut pas communiquer avec l'hôte tant qu’il n’est pas sorti de cet état.

Voici un tableau reprenant les champs contenu dans le descripteur de configuration. Haut de page

5.1.4. Descripteur d'interface
Une interface peut être considérée comme un ensemble d’Endpoint. Le descripteur d’interface communique une information unique à tous ses endpoints. Si une configuration est choisie, toutes ses interfaces sont active et par conséquent, aucun endpoint ne peut être relié à des interfaces différentes sous la même configuration. Les interfaces sous différentes configurations peuvent partager des Endpoints. Voici un tableau reprenant les champs contenu dans le descripteur d’interface. Haut de page

5.1.5. Descripteur de terminaison
Ce descripteur indique la direction du transfert (In/Out), ses types de transfert (isochrone, bulk (en bloc), interruption ou contrôle), ainsi que d’autres informations. L’hôte communique uniquement via ces endpoints. Tous les transferts de paquet de données transitant sur le bus proviennent d’un endpoint ou sont envoyées à un endpoint. Généralement, les endpoints correspondent aux entrées-sorties ou au registre du périphérique. Comme vu précédemment, il est possible d’avoir deux endpoint portant le même numéro mais dans des sens différents (In et Out). Dans ce cas, il est nécessaire de définir deux descripteurs différents. Comme l’endpoint 0 est particulier et est présent dans tous les dispositifs pour permettre à l’hôte de contrôler le périphérique, il n’est pas nécessaire de lui affecter un descripteur. Voici un tableau reprenant les champs contenu dans le descripteur de terminaison. Haut de page

5.2. Descripteur d'HID
Il existe cependant encore une catégorie de descripteur très utilisée, c’est la catégorie HID ( Human Interface Device ). C’est la catégorie la plus utilisé. Elle regroupe tous les appareils qu’utilisent directement les personnes, c’est-à-dire les souris, les claviers, etc.

5.3. Product ID et Vendor ID Lors de l’installation d’un nouveau périphérique USB, les descripteurs fournissent les informations le concernant à savoir un PID (Product ID) et un VID (Vendor ID). C’est grâce à ces deux valeurs que l'ordinateur peut reconnaître l’identité du composant. La réglementation des VID est très stricte, cher et est délivré par le forum USB-IF accessible depuis le site http://www.usb.org. Chaque fabricant possède un VID et c’est grâce à cette valeur codée sur 16 bits que l’on peut retrouver le fabricants du composant. Chaque fabricant ayant plusieurs produits à leurs actifs, ils les différencient avec le PID codé également sur 16bits. L'allocation des PID, contrairement aux VID, est faite par le constructeur du dispositif. Il n'y a aucune contrainte administrative de la part du forum USB-IF. Autrement dis chaque couple PID/VID doit être unique sur le marché.

Haut de page.

= = =6. Applications=

6.1 Utilisation d'un sniffer de trafic et d'un analyseur de protocole
Pour ce faire nous avons utilisé le logiciel USBlyzer dont une version d'essai de 33 jours peut être téléchargée sur le site suivant : USBLyzer

Nous avons utilisé ce logiciel dans un premier temps afin d'analyser les descripteurs d'un périphérique classique : une souris. Nous avons tout d'abord analysé quelques descripteurs :

Le descripteur de périphérique nous renseigne sur la version du protocole utilisée, ici 1.1. La taille maximum de la charge utile (8 bytes). L'ID du fabricant, dans ce cas-ci Lenovo avec une id = 17EFh. Le descripteur de configuration stipule le courant maximum consommé par le dispositif et si celui-ci est auto-alimenté et si il est alimenté par le bus.

Le logiciel est aussi un sniffer de traffic, il nous permet donc d'analyser les trames échangées.

6.2 Utilisation d'un Arduino Leonardo comme souris
__Matériel utilisé :__ - un Arduino Leonardo - un MPU6050 : Accéléromètre + Gyroscope - un bouton poussoir

__L'Arduino Leonardo :__ Il s'agit d'une carte basé sur le microcontrolleur ATmega32u4 disposant lui-même d'une communication USB, c'est grâce à cette fonctionnalité qu'elle se différencie des autres cartes Arduino. Il dispose d'une libraire Mouse and KeyBoard (souris et clavierà dont nous examinerons plus tard quelques fonctions.

__Le MPU6050 :__ Le MPU6050 (ou GY521) est un accéléromètre et gyroscope trois axes. Le capteur utilise le bus I2C pour s'interfacer avec l'Arduino.

Notre objectif est de calculer les différents angles entre une position de repos et une position donnée. Et ensuite appeler la fonction Mouse.move(x,y,wheel) afin de déplacer la souris en conséquence.

Voici le code de la fonction Mouse.move : Il peut être trouvé grâce au chemin d'accès suivant : C:\Program Files\Arduino\hardware\arduino\cores\arduino\HID.cpp

void Mouse_::move(signedcharx,signedchary,signedcharwheel) { u8m[4]; m[0]=_buttons; m[1]=x; m[2]=y; m[3]=wheel; HID_SendReport(1,m,4); }

void WEAK HID_SendReport(u8id,constvoid*data,intlen) { USB_Send(HID_TX,&id,1); USB_Send(HID_TX|TRANSFER_RELEASE,data,len); }

Qui utilise la fonction USB_Send qui se trouve dans le fichier USBCore.cpp, c'est également dans ce fichier que sont détaillés les descripteurs.

Pour plus d'informations sur les fonctions disponibles dans ces librairies : Arduino - Mouse & Keyboard Nous avons décidé de monter le MPU6050 sur un gant, afin de pouvoir contrôler les mouvements de la souris grâce à notre index et avons ensuite placé un bouton poussoir au niveau du majeur afin de pouvoir cliquer.



=Références=

[] [] [] [] [] [] [] [] [] [] [] [|http://acquier.developpez.com/cours/USB/#LVI]