TD INFO INDUS PROTOCOLE USB : ANALYSE LOGIQUE
Rappels de cours
1. Flux de données, fonctionnement général
Un appareil USB communique avec un logiciel client installé sur l'hôte. Le système USB crée des canaux virtuels (« pipe ») pour les différents flux de données. Les canaux de types contrôles sont bi-directionnels, les autres sont unidirectionnels. Il y a donc séparation des flux de données de chaque appareil; un canal aboutit dans l'appareil sur une terminaison (« endpoint »). Un appareil possède plusieurs terminaisons et est toujours reliés à l'hôte au moins par le canal par défaut (« pipe0 ») aboutissant à la terminaison numéro zéro (« endpoint0 »); cette terminaison est bi-directionnelle. Pour les autres terminaisons il peut y avoir 2 canaux, l'un montant et l'autre descendant; la combinaison de l'adresse de l'appareil, du numéro de la terminaison et de la direction est unique. Les caractéristiques de fréquence, de bande passante, de taille de buffer, de type de transfert et de sens de flux déterminent les propriétés de chaque terminaison. Un appareil basse vitesse est limité à deux terminaisons optionnelles en plus de la terminaison de numéro zéro obligatoire, un appareil pleine vitesse peut avoir, en plus de la terminaison de numéro 0, 15 terminaisons montantes et 15 descendantes. Un canal est caractérisé par sa terminaison, sa bande passante et son type de transfert. Sauf pour les transferts isochrones, un système d'alternance entre deux types de paquet de données permet de détecter un paquet perdu et donc de le retransmettre. Les canaux de type isochrones et interruptions obtiennent une bande passante réservée.
2. Protocole : Trame / Transaction / Packet
La période est la durée de transmission d'un bit selon la vitesse utilisée. Pour éviter une
« désynchronisation », des changements d'états supplémentaires peuvent être insérés (stuffing), ils sont retirés au décodage (unstuffing). Chaque paquet commence par une série de 7 transitions assurant la synchronisation. Le début d'un paquet est caractérisé par le passage de l'état « inoccupé » (état J) à l'état K, puis vient la synchronisation. Les données viennent ensuite suivie par un état SE0 durant le temps de 2 périodes et enfin le retour à l'état J. Un appareil doit laisser un temps d'une durée de 2 périodes après un paquet (EOP) et avant d'envoyer son paquet de réponse; cette durée peut atteindre 7,5 périodes. Les durées inter-paquet de l'hôte sont identiques mais il n'y a pas de maximum pour des paquets de transactions différentes. Des durées inter-paquet de 16 à 18 périodes provoquent l'abandon d'une transaction. L'intervalle entre deux trames est compris entre 0,5 et 1,5 ms.
Transaction IN.
Réponse au jeton : - Si jeton reçu corrompu : pas de réponse - Si terminaison bloquée : réponse STALL
- Si terminaison incapable d'envoyer des données : réponse NAK
- Si terminaison capable d'envoyer des données : réponse DATA
Acquittement :
- Si données corrompues ou l'hôte ne peut pas accepter les données : pas de réponse
- Si données acceptées : réponse ACK
Transaction OUT.
Réponse après réception du jeton et des données : - Si paquet reçu corrompu : pas de réponse
- Si terminaison bloquée : réponse STALL
- Si terminaison accepte les données : réponse ACK
- Si terminaison incapable d'accepter les données : réponse NAK Transaction SETUP.
L'appareil doit accepter le paquet DATA0 qui suit un paquet SETUP puis répondre par ACK si les paquets ne sont pas corrompus.
3. Protocole : différents modes de transfert
Transfert de contrôle (« control »).
Destiné à la configuration et à la commande d'un appareil.
3 transactions successives : 1. « Setup »,
2. des transactions de données éventuelles (« Data ») dans le sens indiqué par le Setup 3. statut (« Status »)
Le système USB utilise le canal par défaut (« Pipe 0 ») pour configurer l'appareil par des transferts de contrôle. La charge utile des paquets de données est de 8, 16, 32 ou 64 octets en pleine vitesse et de 8 octets en basse vitesse; la taille maximum est définie par les caractéristiques de la terminaison (« endpoint »). Un système de retransmission en cas d'erreur assure la fiabilité du transfert.
Le transfert commence par une transaction SETUP. Ensuite une série de transactions OUT ou IN selon le sens de transmission indiqué par le SETUP. Une transaction IN ou OUT inverse au sens de transmission précédent termine le transfert en donnant le statut de celle-ci. Il y a alternance des paquets DATA0 et DATA1.
Transfert isochrone (« isochronous »).
C'est un transfert à débit constant tolérant aux erreurs destiné aux flux importants de données tels l'audio ou la vidéo. Le débit dans le canal est garanti. La charge utile des paquets peut atteindre 1023 octets en pleine vitesse et 1024 en haute vitesse; ce mode ne supporte pas la basse vitesse. Les erreurs sont signalées mais il n'y a pas de retransmission. La synchronisation peut se faire, entre autre, en détectant le paquet « SOF » qui est placé au début de chaque trame.
Ce sont des jetons IN ou OUT selon le sens du canal suivis de paquets DATA0. Il n'y a pas de réponse ni de contrôle du séquencement des données.
Transfert par interruption (« interrupt »).
Il est destiné aux appareils transmettant peu de données mais dans un délai garanti. Il ne s'agit pas vraiment d'interruptions mais d'interrogations de l'appareil par l'hôte à une cadence fixe et garantie. La charge utile des paquets de données est identique à celle des transferts de contrôle. En cas d'erreur il y a retransmission lors de l'interrogation suivante.
A intervalle régulier et négocié lors de l'établissement du canal, l'hôte exécute une transaction IN ou OUT selon le sens du canal. Il y a alternance des paquets DATA0 et DATA1
Transfert en bloc (« bulk »).
Il est destiné aux gros volumes de données sporadiques et sans contraintes temporelles (ex : imprimante). Le système peut retarder un transfert en bloc jusqu'à disposer de suffisamment de bande passante. Aucun format n'est imposé aux données. La charge utile des paquets de données est de 8, 16, 32 ou 64 octets. Les transferts en bloc supportent la correction des erreurs; ils sont en pleine ou haute vitesse.
C'est une suite de transactions OUT ou IN selon le sens du canal. L'alternance des paquets DATA0 et DATA1 permet de contrôler l'intégrité des données.
4. Protocole : Descripteurs
Types de descripteur :
Type Valeur
Appareil (device) 1 Configuration (config) 2 Chaine de caractères (string) 3 Interface (interface) 4 Terminaison (endpoint) 5 Qualificateur d'appareil 6 Autre configuration de vitesse 7 Interface de puissance (power) 8
Classe (class) 21
Descripteur d'appareil (valeur 1, 18 octets) : Chaque appareil doit avoir un numéro de fabriquant (VID) et un numéro de produit (PID). Tous les appareils ne sont pas rattachés à une classe.
Champ Taille Description
bLength 1 Taille du descripteur en octets bDescriptorType 1 Type du descripteur = 1 bcdUSB 2 Version USB codée en BCD bDeviceClass 1 Code de classe assigné par l'USB-IF bDeviceSubClass 1 Code de sous-classe dépendant de la classe bDeviceProtocol 1 Code de protocole dépendant de la classe
bMaxPacketSize0 1 Taille maximum des paquets pour la terminaison 0 idVendor 2 Code fabricant assigné par l'USB-IF (VID) idProduct 2 Code produit assigné par le fabricant (PID) bcdDevice 2 Version d'appareil codé en BCD
iManufacturer 1 Index du descripteur de chaine du fabricant iProduct 1 Index du descripteur de chaine de l'appareil iSerialNumber 1 Index du descripteur de chaine du numéro de série bNumConfigurations 1 Nombre de configurations possibles
Descripteur de configuration (valeur 2, 9 octets) :
Champ Taille Description
bLength 1 Taille du descripteur en octets bDescriptorType 1 Type du descripteur = 2
wTotalLength 2 Taille totale de tous les descripteurs pour cette configuration bNumInterfaces 1 Nombre d'interfaces supportées par cette configuration
bConfigurationValue 1 Numéro de cette configuration (A utiliser par SET_CONFIGURATION) iConfiguration 1 Index du descripteur de chaine décrivant cette configuration
bmAttributes 1 Bit 6 : auto-alimentation, bit 5 : commande de réveil, bit 7 = 1 bMaxPower 1 Consommation maximum en unités de 2 mA.
Descripteur de chaîne (valeur 3, 4 octets pour string0) :Ces descripteurs sont facultatifs; si un appareil ne les supporte pas, les références à des descripteurs de chaine doivent être à 0. Ils sont en UNICODE et peuvent supporter plusieurs langues. Chaque langue possède un identificateur sur 2 octets. Le descripteur de chaine d'index 0 contient un tableau des identificateurs des langues supportées. Les 10 derniers bits identifient la langue, les 6 premiers le pays d'application.
- Quelques identificateurs de langues courantes :
Langue Identificateur (Hexa) Français 040c Anglais 0409 Allemand 0407
Italien 0410 Espagnol 040a
- Descripteur de chaine d'index 0 :
Champ Taille Description bLength 1 Taille du descripteur en octets bDescriptorType 1 Type du descripteur = 3
wLANGID[0] 2 Identificateur de langue d'index 0
... 2 ...
wLANGID[N] 2 Identificateur de langue d'index N
- Descripteur de chaine d'index supérieur à 0 :
Champ Taille Description
bLength 1 Taille du descripteur en octets bDescriptorType 1 Type du descripteur = 3
bString X Chaine UNICODE
Descripteur d'interface (valeur 4, 9 octets) :
Champ Taille Description
bLength 1 Taille du descripteur en octets bDescriptorType 1 Type du descripteur = 4
bInterfaceNumber 1 Numéro de cette interface (Base 0) bAlternateSetting 1 Numéro de l'interface alternative
bNumEndpoints 1 Nombre de terminaisons excluant les terminaisons zéro bInterfaceClass 1 Code de classe assigné par l'USB-IF
bInterfaceSubClass 1 Code de sous-classe dépendant de la classe bInterfaceProtocol 1 Code de protocole dépendant de la classe
iInterface 1 Index du descripteur de chaine décrivant cette interface
Descripteur de terminaison (valeur 5, 7 octets) :
Champ Taille Description
bLength 1 Taille du descripteur en octets bDescriptorType 1 Type du descripteur = 4 bEndpointAddress 1
Adresse de cette terminaison Bits 0 à 3 : Numéro de terminaison
Bit 7 : direction (O=OUT, 1=IN) - Ignoré pour canal de contrôle
bmAttributes 1
Propriétés de la terminaison.
Bit 0 et 1 : Type de transfert - 00 Contrôle
- 01 Isochrone - 10 Bloc - 11 Interruption
Bit 2 à 5 : Paramètres pour transfert isochrone wMaxPacketSize 2 Taille maximum des paquets de données en octets
bInterval 1
Intervalle entre chaque demande de données de l'hôte en nombre de trames.
- Transfert isochrone pleine et haute vitesse : 1 à 16 - Transfert par interruption pleine et basse vitesse : 1 à 255 - Transfert par interruption haute vitesse : 1 à 16
- Transfert en bloc OUT haute vitesse : 1 à 255
Composition des PID selon jeton :
Bits (3-0) Nom Type de paquet Description
0001 OUT Jeton Écriture (W) du host pour l'appareil 1001 IN Jeton Lecture (R) du host pour l'appareil 0101 SOF Jeton Début de trame
1101 SETUP Jeton Initialisation pour « transaction control » 0011 DATA0 Données Données paquet pair
1011 DATA1 Données Données paquet impair 0111 DATA2 Données données haute vitesse
1111 MDATA Données données haute vitesse pour transactions « Split » 0010 ACK Acquittement Acquittement positif
1010 NAK Acquittement Acquittement négatif, appareil occupé 1110 STALL Acquittement Terminaison ou canal hors service 0110 NYET Acquittement Acquittement négatif haute vitesse 1100 PREP Jeton Trafic vers un appareil basse vitesse 1100 ERR Acquittement Erreur dans une transaction « Split » 1000 SPLIT Jeton Transaction avec un hub haute vitesse 0100 PING Jeton Vérification de liaison
5. Enumération
Après sa mise sous tension, un appareil ne répond à aucune transaction avant d'avoir reçu un reset du bus.
Après cela l'appareil est adressable à son adresse par défaut. Après raccordement d'un appareil, le système USB procède à « l'énumération » qui réalise les actions suivantes : alimenté / défaut / adressé / configuré
• Le host détecte un périphérique (D+ ou D- change) et sa vitesse. Le host attend au moins 100 ms (temps utile pour : prise complétement inserée et alimentation stabilisée)
• Reset général Fin état alimenté
• Le host effectue une requête (GetDeviceDescriptor) afin de définir la taille max des paquets du endpoint0
• Reset général Fin état défaut
• Le host effectue une requête (SetAddress) afin d’attribuer la nouvelle adresse au périphérique
• Le périphérique est désormais adressé Fin état adressé
• Le host effectue une requête (GetDeviceDescriptor)
• Le host effectue une requête (GetConfigDescriptor)
• Le host effectue une requête (GetConfigDescriptor)
• Le host lit les informations de configuration et assigne à l'appareil l'une de ses configurations. La puissance fournie par Vbus peut alors augmenter; l'appareil est prêt à être utilisé.
Fin état configuré
Tous les appareils supportent un jeu de requêtes communes. A l'exception de la requête "SetAdress" et de certaines requêtes longues, le traitement de la requête doit être terminé avant que l'appareil ne renvoie l'acquittement. Ces requêtes se font par transfert de contrôle sur le canal par défaut; elles sont envoyées dans les 8 octets du paquet de donnée d'une transaction SETUP et doivent en général être terminée en moins de 5 secondes.
Les principales requêtes : Effectuées par le jeton Setup. Les jetons SETUP ont 8 octets de données divisés en 5 champs :
Jeton SETUP (8 octets)
BmRequest
Type bRequest + valeur wValue wIndex wLength Données Nom du champ Taille
(octets) 0x80 GET_CONFIGURATION (8) 0 0 1 Valeur config.
bmRequestType 1 0x80 GET_DESCRIPTOR (6) Type descripteur et index
0 ou Id de langue
Longueur
max desc. Descripteur
bRequest 1 0x81 GET_INTERFACE (10) 0 Interface 1 Configuration
wValue 2 0x00 SET_ADDRESS (5) Adresse 0 0
wIndex 2 0x00 SET_CONFIGURATION (9) Valeur Config. 0 0 wLength 2 0x00 SET_DESCRIPTOR (7) Type descripteur
et index
0 ou Id de langue
Longueur
max desc. Descripteur 0x01 SET_INTERFACE (11) Configuration Interface 0
Logiciel d’acquisition :graphicUSB
boutons
min : seulement événements de niveau haut
Affiche les états électriques du bus USB (vert clair) SOF : Start of Frame
Show Chirps (high speed only)
Show transactions : affiche uniquement les transactions
Show packet : affiche la profondeur maximale de la trame (niveau parquets) Show NAK : affiche les NAK
Show NYET (high speed only) Show Spurious data (optionnel) Max : événements de bas niveau Barre travail : Enregistrement/export
Options d’impressions (choix de la fenêtre à imprimer) et de visualisation : time / bandwidth
Exo 1 : Couche noire et bleu (transferts) - Charger fichier mouse_hid.mqu - Afficher les états (électriques) du bus - A quel instant (en s) se fait la connexion ?
- Comment le host détecte la vitesse du périphérique (ici une souris) ? - Que signifie le « suspend » ?
- Pourquoi le host procède-t-il à 2 reset ?
- A quoi sert la première requête « GetDeviceDescriptor » ?
- A quel instant le périphérique est-il disponible pour utilisation. Comment s’appelle la phase précédente ? A quoi sert-elle ?
- afficher SOF -> commentaires !
- Détailler les différentes étapes de cette phase en explicitant les descripteurs (et le sens des transferts de commande (« control transfert »)
- Pourquoi tous les « control transfert » se font-ils en endpoint 0 et les « interrupt transfert » en endpoint 1 ?
Exo 2 : Couche jaune (transactions) Remarques :
• La réponse à une requête « GetDescriptor » se décompose en plusieurs transactions :
• Setup /Data (IN ou OUT) / Status (OUT ou IN)
• La requête « GetConfig » fournit une réponse de plusieurs descripteurs (config, interface, endpoint, string, autres).
• Afficher NAK : vérifier que la plupart des transferts sont NAK, ce qui ne signifie pas une erreur mais une demande de ré-émission. Par souci de clarté, on affichera uniquement les transferts ACK.
Analyse du transfert de commande n°1 (event #56…83) - GetDeviceDescriptor : Setup / data IN / status OUT - Commenter le sens de chaque transaction
- Pourquoi 3 transactions data IN ?
Analyse du transfert de commande n°2 (event #106…113) - SetAddress : Setup / data IN
- Commenter le sens de chaque transaction - Pourquoi aucune transactions status ? Analyse des autres transferts de commande
- idem
Analyse d’un transfert interrupt (communication avec la souris) - Pas de descripteur : pourquoi?
- Pas de transaction Setup : pourquoi ? - A quoi correspond la transaction IN ? Interprétation des données descripteurs : Device
DATA1 12 01 00 01 00 00 00 08
DATA0 03 06 71 68 00 01 04 22
DATA1 00 01
Config
DATA1 09 02 22 00 01 01 00 A0
Interface
DATA1 09 04 00 00 01 03 01 02
DATA0 00
Endpoint
DATA1 07 05 81 03 08 00 0A
HID : réponse de 4 octets / 10 ms
DATA1 09 21 00 01 00 01 22 32
DATA0 00
String0
DATA1 04 03 09 04
String 34
DATA1 22 03 55 00 53 00 42 00
DATA0 20 00 4D 00 6F 00 75 00
DATA1 73 00 65 00 20 00 53 00
DATA0 54 00 44 00 2E 00 20 00
DATA1 20 00
Vérifier le contenu des rapports de la souris (« input report ») : exemples #5230-5232, #6018-6020, #20892-20894
Exo 3 : Couche blanche (paquet)
Chaque transaction contient une succession de paquets TDH Donner le contenu des champs de chaque paquet
Identifier et vérifier chaque PID (pour chaque paquet)
CORRECTION
Exo 1 : Couche noire et bleu (transferts)
On connecte le périphérique (ici une souris) à partir de 34 secondes. La connexion se fait sur la ligne D- donc le périphérique est basse vitesse (low speed). Ensuite il y a une suspension du bus car il n’y a pas d’activité sur les lignes de données D-/D+ car le host n’est pas encore autorisé. Après sa mise sous tension, un appareil ne répond à aucune transaction avant d'avoir reçu un premier reset du bus (le device est positionné dans l’état défaut, il peut maintenant répondre à l’adresse par défaut 0)
• Fin phase alimentée
Après cela l'appareil est adressable à son adresse par défaut. Il faut au préalable envoyer une requête
« GetDeviceDescriptor » pour définir la taille max des paquets du endpoint 0 (le « chef de table » qui doit échanger principalement les informations de configuration/setup). Un deuxième reset est nécessaire pour pouvoir positionner le device dans l’état adressable (pouvoir lui attribuer son adresse différente de 0).
• Fin phase défaut
« SetAddress » permet d’attribuer une adresse à la souris (ici address = 1).
• Fin phase adressée
Plusieurs requêtes sont alors envoyées par le host afin de récupérer l’ensemble des informations nécessaires à la configuration de l’appareil.
• Fin phase configurée
Le périphérique est prêt pour utilisation (communication par transfert de type interrupt car le volume de données est peu important mais doit être garantit à intervalles réguliers, ici une trame chaque ms).
Plusieurs remarques :
• Si on affiche les SOF (Start Of Frame), on s’aperçoit que de nombreuses trames sont vides (exemple 52 trames de #4 à #55). Par souci de clarté, on fera apparaître uniquement les trames non vides (comprenant des réponses).
• Tous les transferts de commande (« control transfert ») se font en endpoint0 car il est le seul endpoint habilité à échanger ce type d’information (de configuration). Les transferts de communication (ici « interrupt ») se font avec les autres endpoint (ici endpoint 1). Pour rappel, un périphérique basse vitesse comporte seulement 3 endpoint (endpoint0 bidirectionnel IN/OUT, endpoint1 de sens IN et endpoint1 de sens OUT) tandis qu’un pleine ou haute vitesse peut en comporter 31 (endpoint 0 + 15 dans chaque sens)
• Le groupe de requête (GetDevice, GetConfig x2, GetString0, GetString34) se fait 2 fois : une fois par driver chargé dans la pile (ici 2 drivers).
• Pour « monter » un périphérique, le système d’exploitation vérifie que les données (d’usine) situées dans les descripteurs sont en accord avec celles requises par les drivers (exemple Vendor IDentificator, Product IDentificator, etc…). Le cas échéant, l’énumération est refusée.
L’ensemble de ces 4 phases représente l’énumération (qui dure ici environ 4 ms).
Détail de la phase configurée (requêtes et descripteurs en réponse)
• « GetDeviceDescriptor » : information générale sur le périphérique (quel type de périphérique, ici une souris standard USB)
• « GetConfigDescriptor » x 2 : en réponse à cette requête on reçoit plusieurs descripteurs (Config, Interface, HID, Endpoint et éventuellement d’autres). Le host connait uniquement la taille du premier descripteur (Config, 9 octets) mais ne connait pas la taille globale de l’ensemble des descripteurs qui suivent. Il fait une première requête pour obtenir Config dans lequel apparait la taille globale des descripteurs suivants (34). Ensuite, il recommence l’opération pour obtenir l’ensemble des descripteurs.
• « GetString0 » : information sur le langage par défaut (anglais) et la liste des langages.
• « GetString34 » : informations sur le produit (une chaîne de caractères unicode de longueur 34 ici qui décrit le produit).
Plusieurs requêtes terminent la phase d’énumération :
• « SetConfig » : permet la configuration du périphérique en fonction des informations recueillies précédemment.
• « SetIdle » : Le host demande au périphérique de renvoyer un rapport en réponse à chaque transfert de type interrupt sur chaque nouvel événement.
• « GetHIDClassReport » : le host informe le driver qu’il va recevoir un rapport (de la souris) de longueur définie (ici 4 octets) sur endpoint IN (interrupt)
Exo 2 : Couche jaune (transactions)
Un transfert de commande se décompose en 3 transactions (SETUP / Data IN ou OUT / status OUT ou IN inversement) tandis que les autres transferts (bulk, interrupt, isochronous) contiennent uniquement des transactions IN ou OUT
Analyse du transfert de commande n°1 (event #56…83) - GetDeviceDescriptor : Setup / data IN / status OUT
- Le sens de chaque transaction : Setup (Write), 3 transactions IN (Read), status OUT (Write) - Pourquoi 3 transactions data IN ? car descripteur de longueur 18 octets (soit 8 + 8 + 2) Analyse du transfert de commande n°2 (event #106…113)
- SetAddress : Setup / status IN
- Setup (W), Status IN (R, obligatoirement inversé par rapport au précédent)
- Pourquoi aucune transaction data IN/OUT ? optionnel, ici pas de données à transmettre ou bien à lire, opération SetAddress impose uniquement l’adresse.
Analyse d’un transfert interrupt (communication avec la souris)
- Pas de descripteur : Ce n’est pas un transfert de commande (pas un « control transfert »)
- Pas de transaction Setup : Pas besoin (pas d’adresse et de numéro de trame à reconfigurer).
Uniquement besoin de transaction IN ou OUT selon le sens des échanges.
- A quoi correspond la transaction IN ? Une lecture par le host des données souris (en fait : lecture du rapport fourni par la souris).
Interprétation des données descripteurs : les données à interpréter en priorité sont en rouge.
--- Device
DATA1 12 (taille) 01 (type) 00 01 00 00 00 08 (taille max des paquets)
DATA0 03 06 71 68 00 01 04 22
DATA1 00 01
0x08 correspond à la taille max des paquets du endpoint 0
0x0603 correspond au code vendeur de « Novatek » (la marque de la souris) 0X6871 correspond au code produit pour une souris
--- Config
DATA1 09 (taille) 02 (type) 22 00 01 01 00 A0 DATA0 32
0x0022 ≡ 34 correspond à la taille de l’ensemble des descripteurs qui suivent.
0x32 ≡ 50 unités de 2 mA Æ 100 mA d’alimentation pour ce périphérique
--- Interface
DATA1 09 (taille) 04 (type) 00 00 01 03 01 02
DATA0 00
0x01 correspond au numéro du endpoint chargé des échanges (ici endpoint1, voir remarques) --- Endpoint
DATA1 07 (taille) 05 (type) 81 03 08 00 0A
0x81 correspond à l’adresse du endpoint1 (qui sera chargé des échanges) 0x0008 correspond à la taille max des paquets.
0x0A ≡ 10 signifie un rapport de périphérique tous les 10 trames (soit 10 ms)
---
HID : réponse de 4 octets / 10 ms
DATA1 09 (taille) 21 (type) 00 01 00 01 22 32 DATA0 00
0x22 ≡ 34 correspond au type (code 34 pour un rapport) 0x0032 ≡ 50 correspond à la longueur du rapport (50 octets)
--- String0
DATA1 04 (taille) 03 (type) 09 04
0x0409 correspond au code langage pour Anglais String 34
DATA1 22 03 55 00 53 00 42 00
“ U . S . B .
DATA0 20 00 4D 00 6F 00 75 00
. M . o . u .
DATA1 73 00 65 00 20 00 53 00
s . e . . S .
DATA0 54 00 44 00 2E 00 20 00
T . D . ” . .
DATA1 20 00
.
String34 : contient les données descriptives de la souris en unicode (ici « U.S.B. M.o.u.s.e. S.T.D. » --- Le contenu des rapports (envoyé toute les 10 trames) de la souris (« input report ») :
#5230-5232 #6018-6020 #20892-20894
Déplacement d’une déplacement de 5 unités click bouton 2 Unité (droite) selon Y (droite) en X et 3 unités
(gauche) en Y
Exo 3 : Couche blanche (paquet)
Chaque transaction contient une succession de paquets TDH : Token (jeton), Data (données, optionnel, Handshake). Selon le type de transfert, on peut avoir différentes combinaisons : TDH, TH, etc…
• T :Le jeton peut être de différente nature selon l’action à venir : TIN ou TOUT ou TSETUP (voire TSOF). Un jeton SETUP caractérise entièrement la requête (la direction, le type et la source du transfert, suivi du type de requête et du nom du descripteur demandé avec sa longueur reservée).
• D : Le paquet DATA vient immédiatement après un jeton SETUP ou un jeton IN ou OUT.
Pour un périphérique basse vitesse, il y a alternance DATA0/DATA1 (8 octets max)
• H : Ce paquet indique que le paquet de données a été reçu sans erreur (par le host ou le device selon le sens du transfert)
Donner le contenu des champs de chaque paquet : SYNC/PID/SPecific Information/CRC/EOP. Seul le champ SPI est différent (sa structure) : « ADDR + EndP » pour Token (T), Payload pour Data (D), vide pour Handshake (H). Les valeurs des PID sont adaptées selon l’action (voir question suivante)
Identifier et vérifier chaque PID (pour chaque paquet) : les bits 0-3 sont complétés par le complément à 2 pour la détection d’erreur relative au seul PID, on obtient un codage du PID sur 1 octet.
Code PID SETUP : 1101 (≡ D) octet : 0 x 2D Code PID IN : 1001 (≡ 9) octet : 0 x 69 Code PID OUT : 0001 (≡ 1) octet : 0 x E1 Code PID DATA0 : 0011 (≡ 3) octet : 0 x C3 Code PID DATA1 : 1011 (≡ B) octet : 0 x 4B Code PID ACK : 0010 (≡ 2) octet : 0 x D2