l’hôte et le périphérique - WordPress.comTerme qui décrit les signaux numériques transmis...

1

Version 1.0

par Jean Marc Masson

Généralités

L’USB ou Universal Serial Bus fait appel à des connaissances sur les systèmes de transmission. Les termes utilisés sont spécifiques et sont tirés des réseaux en anneaux “ token ring ”.

Il est bien important de comprendre que toute la subtilité et la complexité de l’USB résident dans les échanges entre deux entités

qui sont :

l’hôte et le périphérique.

Nous ne parlons plus de transmission de données, mais de transmission de paquets dans un système isochrone.

2

Synoptique

Contrôleur d’hôte/hub Hub racine

HUB HUB

3

Les termes transmission asynchrone Terme qui décrit les signaux numériques transmis sans synchronisation précise. En règle générale, ces signaux ont des séquences et des relations de phases différentes. Les transmissions asynchrones encapsulent habituellement des caractères individuels dans des bits de contrôle (appelés bit de départ et bit d'arrêt) qui indiquent le début et la fin d'un caractère. transmission isochrone Transmission asynchrone sur une liaison de données synchrone. Les signaux isochrones exigent un débit constant afin d'assurer une transmission fiable. transmission synchrone Terme désignant les signaux numériques transmis avec un synchronisme précis. Ces signaux ont la même séquence que les caractères encapsulés dans des bits

de contrôle (appelés bits de départ et bits d'arrêt) qui indiquent le début et la fin

Contrairement aux interfaces sérielles classiques où le format des données n’est pas défini, l’USB est composé de plusieurs couches de protocoles ou étapes. Avec l’USB, nous transmettons des paquets dont la longueur varie entre 8 et 1024 octets. L’analogie la plus simple est celle d’un paquet postal. Lorsque vous envoyez un paquet, vous devez remplir un coupon, inscrire l’adresse du destinataire, noter le contenu du paquet, demander un accusé de réception. Dans le cas de l’USB, un paquet est constitué de 3 paquets : Le jeton, la donnée, la poignée de main ou accusé de réception. L’ensemble de 3 paquets doit réponse des règles que l’on nomme protocole.

4

Paquet Suite d'un nombre déterminé de bits comportant des éléments de service (adresses...) et des données. Jeton Trame autorisant à émettre ou à recevoir et circulant entre l’hôte et les périphériques. Le jeton est identifié par son type , il contient des adresses permettant de définir le périphérique déservi ainsi que des zones tampons . Il est contrôlé par un CRC . Donnée Elle fait suite au jeton et peut être de 2 types : Une donnée simple : C’est une valeur exprimée par un certain nombre d’octets La requête ou demande : C’est une demande d’état ou une lecture des caractéristiques. Elle représente la majorité des échanges entre l’hôte et le périphérique La poignée de main C’est un accusé de réception pouvant signifier suivant son contenu : • J’ai bien reçu (ACK • Je suis occupé (NAK) • Je suis bloqué (STALL) Nous verrons plus loin les cas ou il n’y a pas de paquet poignée de main . L’émission d’un paquet vide correspond à une commande achevée. Transaction Une transaction est un échange entre l’hôte et le périphérique . Toute transaction débute par un jeton définissant le sens de celle-ci ainsi que des adresses. Le jeton est suivi par la donnée , puis par la poignée de main La transaction est donc la « partie de ping pong » entre l’hôte et le périphérique Protocole C’est l’ensemble des règles définissant le format et le type des messages de la transaction. Autrement dit nous savons à l’avance ce que l’on est en mesure de recevoir comme réponse en fonction de la question que l’on pose . Transfert C’est le mode par lequel la donnée part d’un point à un autre . Une lettre peut être envoyée par avion , par bateau etc.. Le mode de transfert est défini dans la requête . Il détermine entre autres choses le nombre d’octets à transférer et donc la bande passante.

5

.

constitution

Bus PCI

Contrôleur d ’hôte/hub

Hôte périphérique

Logiciel client

Logiciel système

Adresse terminaisons

Interface fonction

Logiciel périphérique

Interface bus

Terminaison 0

Amont Aval

6


Interface fonction

•Le périphérique est soit un émetteur/récepteur, un circuit intégré, un appareil. La norme parle ainsi de fonction

•Étant donné que c ’est hôte qui gère le bus, la fonction ne peut être ni lue ni écrite directement. Chaque fonction est précédée de 16 interfaces numérotées de 0 à 15. à chaque interface correspond une terminaison. La terminaison 0 est la terminaison par défaut, elle est utilisée pour les commandes d ’état. Les autres terminaisons sont utilisées par la suite par le logiciel. Chaque terminaison comporte un tampon mémoire

Voyons ce qui se passe simplement

Il est à noter que le périphérique ne possède ni zone de mémoire d’entrées/sorties, ni de lignes IRQ, ni de canaux DMA

8

Étape 4

Logiciel client


Interface fonction

•Une fois que les descripteurs sont lus, l ’alimentation appliquée, les descripteurs rangés, la bande passante établie :

•Le logiciel client envoie un jeton contenant : - L ’adresse du périphérique sur 7 bits ( possibilité de connecter 127 appareils) - L ’adresse de la terminaison sur 4 bits (16 terminaisons numérotées de 0 à 15) - Le sens de la transaction

•L ’hôte affecte un numéro de configuration et une adresse unique au périphérique ( le changement d’adresse demande une temporisation de 2 ms)

• Interconnexion entre le logiciel système et le logiciel client

Logiciel client

Logiciel système

10

Hub racine

contrôleur d’hôte Il est ouvert ou universel il est responsable de la génération des transactions programmées par le logiciel hôte. Le pilote contrôleur d’hôte construit une liste de liens de données en mémoire qui défini les transactions programmées et devant être exécutées durant une trame donnée. • Effectue la conversion parallèle - série • Lit les transactions et les envoie au hub racine Hub racine • Contrôle de l’alimentation des ports • validation /inhibition des ports • reconnaissance de périphériques liés aux ports • initilisation et transfert de l’état de chaque événement associé à chaque port contrôleur de hub il contient une interface USB ou interface série . Il contient les descripteurs que le logiciel lit et reçoit les commandes du logiciel hôte le répéteur C’est un aiguilleur dont le rôle est d’aiguiller la donnée suivant le sens du transfert entre l’ hôte et les ports

Jean Marc MassonCommentaire: Le bus PCI •Contrôlé par l’hôte •1 seul hôte par bus (la dernière version USB 2.0 prévoit la possibilité de 2 hôtes) •l’hôte gère les transactions et la programmation de la bande passante •utilisation de hub ( 127 appareils par hub) •plug and play Alimentation Basse puissance Haute puissance auto alimenté 100 mA 500 mA 100 mA 4.4 volts_5.25 volts 4.75 volts_5.25 volts tout le reste est externe Courant de veille •proportionnel à i charge , maximum = 500 mA •veille si pas d’activité bus pendant 3 ms + 7 ms pour éteindre l’appareil avec i minimum = 100 mA •Nous envoyons une trame paquet ou d’entretien toutes les 125 ms en pleine vitesse et toutes les 1 ms en basse vitesse ( évite le mode veille) •Si Vbus est perdue nous avons 10 secondes pour éteindre l’appareil

11

Les descripteurs

Nous les étudierons ne détail plus loin dans le cours Les transferts

12

Nous en distinguons 4 types :: • ceux qui sont destinés à identifier et configurer un périphérique qui vient d'être connecté

(control transfers) . Transfert de contrôle ou de commande • ceux qui sont réservés à certains périphériques d'entrée (interrupt transfers), tels que les

claviers ou la souris . Transfert d’interruption • ceux qui s'effectuent sans confirmation de la réception des paquets (isochronous

transfers), et qui sont destinés au transport de la voix . Transfert isochrone • ceux qui s'effectuent avec confirmation de la réception des paquets (bulk transfers), et qui

concernent la plupart des périphériques . Transfert de bloc ou de masse

13

Partie logicielle

14

Les pilotes Un pilote est un programme qui fait le lien entre un composant matériel et les logiciels qui veulent utiliser ce composant. Généralement, le matériel en question possède des registres adressables pouvant être configurés et lus : le rôle du pilote est d’accéder à ces registres et de fournir au programme appelant une interface facilement exploitable. Deux types d’exécutables les pilotes de bas niveaux, qui sont créés par l'éditeur du système d'exploitation, et permettent à ce dernier de gérer un type particulier de périphérique. Ils font partie du système d'exploitation, ou sont fournis ultérieurement à l'utilisateur à l'occasion d'une mise à jour les pilotes de haut niveau, qui sont fournis par le constructeur du périphérique, et qui tiennent compte des particularités techniques de ce dernier. C'est souvent les pilotes de haut niveau que l'on invoque lorsqu'on parle de "pilotes" sans autre précision Mode utilisateur Il permet l ’interface entre une application Win32 API et les pilotes en mode interne ou les autres composants du système d ’exploitation. Les pilotes en mode utilisateur sont utilisés comme des routines définies dans la programmation de l ’interface API. Le mode utilisateur ne peut accéder aux données systèmes que via l ’appel des routines Win32 API. Mode interne Le mode interne fait parti de la fonction couche, il prend en compte les entrées/sorties, les systèmes plug and play, l ’alimentation, la mémoire etc… Le schéma respecte une hiérarchie :

•Les pilotes au niveau haut reçoivent les données des applications

• filtrent les données

•passent à des pilotes bas niveau qui supportent les fonctionnalités des périphériques

15

USB contient 3 pilotes en mode utilisateur en mémoire • pilote client ou pilote de périphérique • le pilote d’hôte USB ou pilote USB • le pilote contrôleur d’hôte USB

Câble Int cde blocs isochrone

Applications logicielles API Win 32

Pilote d’hôte USB

Pilote contrôleur d’hôte

Contrôleur d’hôte USB

ouvert universel

Hub racine

Hub ctlr de hub

pointeur

pointeur

DT TQ Registre INT

commande

blocs

Int 0

Int 31

Routines de pilotes internes

Système d’exploitation

Registres Contrôleur d’hôte

tampon

ou

Int 1

Périphérique Interface bus

interface

Terminaison 0 Terminaison 0

Pilote client

16

Rôle des élements Pilote contrôleur d’hôte Il est responsable de la gestion des transferts et de la construction des descripteurs de transferts . Ceux-ci peuvent être gérés de 2 façons en fonction du type de contrôleur d’hôte Contrôleur universel Le pilote crée une liste de pointeurs emplilés corrrespondants à la liste des trames et pointant des descripteurs de transferts (DT) en mode isochrone. Chaque pointeur contient l’adresse d’un descripteur de transfert ou de la tête de queue(TQ) ainsi qu’une indication sur la validité du pointeur de lien entre les DT et/ou le TQ. Les transferts sont ensuite placés sous la forme de colonnes par ordre de priorités de transferts( isochrone-interruption – commande - bloc). Chaque colonne de transfert non isochrone est chapeautée par une tête de queue (TQ) donnant le début de la liste d’un transfert donné. Contrôleur d’hôte ouvert Le pilote contrôleur d’hôte contruit les descripteurs et les place dans une zone mémoire dite de communication. Ces descripteurs comprennent les descripteurs de transferts et de terminaux .Le contrôleur d’hôte assigne un descripteur de terminal pour chaque terminal. Le descripteur de terminal contient l’adresse, le nombre de terminaux et l’information nécessaire dont le contrôleur d’hôte a besoin pour communiquer avec le terminal. Les descripteurs de terminaux sont représentés par des points noirs. Une queue de descripteurs de transfert est liée à chaque descripteur de terminal. Les descripteurs de terminaux sont liés par un descripteur de transfert d’interruptions. Il est à noter qu’il existe dans ce type de contrôleur 3 pointeurs . Deux pointeurs pour les transferts non périodiques ( un pour le transfert de commande, un pour le transfert de blocs) et un registre INT qui pointe une liste de liens de transferts isochrones et de 32 transferts d’interruptions possibles .

17

Pilote client Le pilote client initialise un transfert quand il appelle le pilote USB et effectue une demande de transfert par l’intermédiaire d’une IRP (Interrupt Request Paquet ). Le pilote client utilise une mémoire tampon ou tampon client pour les transferts de données entre un terminal d’un périphérique et l’hôte . Il n’a aucune connaissance des mécanismes de transfert Pilote USB Le pilote USB transforme les requêtes du client en transactions individuelles consistant à allouer la bande passante nécessaire et à établir un mécanisme de protocole. Les canaux Canal: c’est l’association entre une terminaison ( terminal) d’un périphérique et le logiciel de l’hôte. Il représente la capacité de déplacer une donnée entre le logiciel de l’hôte via une mémoire tampon et une terminaison . Il existe 2 types de canaux : flux et message . les données des canaux de flux n’ont pas de format définis USB alors que pour les messsages c’est le cas . Canal par défaut Tout périphérique ayant un hub a un canal de contrôle au terminal 0 . Le logiciel hôte a son propre canal par défaut (configuration des contrôleurs et des périphériques) . Ce canal est établi par le pilote USB durant l’initialisation Canal client Nous avons vu que l’hôte alloue une adresse unique et un numéro de terminal . A un numéro de terminal correspond un numéro de canal de communication dit canal client . C’est un canal non géré par le pilote USB . Le pilote client l’utilise pour transférer des informations sur les terminaux .

18

Les terminaisons ou terminaux Chaque périphérique USB est décomposé en plusieurs sous blocs, possédant chacun un rôle différent dans la communication.

Nous pouvons distinguer 3 sous blocs 1. La partie qui décode l’adresse émise par l’hôte dans le paquet jeton 2. La partie terminaison 3. La partie réalisant la fonction USB proprement dit. Les terminaisons peuvent être vues comme des intermédiaires, des tampons entre le bus et la fonction USB. En effet, il n'est pas possible pour le bus d'écrire directement dans la fonction, et pour la fonction d'écrire directement sur le bus. Les données sont donc stockées temporairement (jusqu'à ce que l'hôte ou le périphérique les lisent) dans les terminaisons. C'est donc pour cette raison que dans le paquet Jeton, l'hôte précise la terminaison à laquelle il veut s'adresser. On peut remarquer qu'une même fonction USB peut utiliser plusieurs terminaisons (jusqu’à 16). Dans la spécification USB1.1 le nombre de paires de terminaisons est limité à 2 en basse vitesse, c'est-à-dire que les communications peuvent se faire via EP0 In, EP0 Out, EP1 In et EP1 Out. La paire de terminaisons utilisée par défaut par l'hôte pour dialoguer avec le périphérique est EP0

périphérique

bus

adresse

EP0 OUT

EP0 IN hôte

EP1 IN

EP1 OUT

fonction

19

Le paquet d’installation ou setup Le paquet d’installation détermine :

• le sens du transfert • type de transfert • le destinataire • le type de requête • le nombre d’octets à transférer

Il est utiliser dès le départ pour la demande de configuration, puis pour les différentes requêtes.

Les requêtes

1. appareil standard (8 requêtes) • type d’alimentation • attribution de l’adresse unique • positionner ou demander la configuration

2. interface standard (5 requêtes) • état de l’interface • interface de remplacement

3. terminaison standard(4 requêtes) • état de la terminaison • numéro de trame

Nous les étudierons en détail plus loin dans le cours La trame Le contrôleur d’hôte initialise les transactions via le hub racine . Une trame démarre toutes les 1 ms . Elle débute par un jeton SOF suivi des transferts isochrone , d’interruption , de commande et de bloc ( ordre de priorité) . Descripteurs de base Appreil Configuration interfaces terminaison chaîne Version usb Taille du

paquet Nombre d’interfaces

Adresse de la terminaison

Manufacturier

Taille max du paquet

Nombre d’interfaces

Type de transfert Produit

ID constructeur et produit

État de l’alimentattion

Intervalle de temps pour interroger les transferts

série

Nombre de configurations

La consommation

20

Fonctionnement

1. première étape : la connexion • connexion de l’appareil • détection de présence par la lecture des résistances d’entrée • détection du débit par la résistance de 3.3 K Ω sur D+ ou D- • validation du port de l’hub et de l’appareil • temporisation de 10 ms 2. étape 2 : lecture de la configuration • entrée en fonction du logiciel système et liaison avec le pilote USB et le

pilote client via Win 32 • Le pilote USB établi une interface 0 terminaison 0 ( canal 0 par défaut) C’est commande correspond à un RESET ( lignes D+ et D- à 0

• émission d’un jeton IN vers la terminaison 0 ( début d’une transaction)

• émission de l’adresse du périphérique sur 7 bits ( 127 appareils)

• émission de l’adresse de la terminaison sur 4 bits ( terminaisons de 0 à 15 )

• détection des adresses • validation de l’interface 0 terminaison 0 et de la fonction

liée • le jeton est suivi d’un paquet d’installation • envoie d’une requête de lecture de configuration • copie de la configuration dans le tampon de la terminaison 0 ( c’est la

réponse du périphérique) en provenance de la fonction Nous avons ici un canal de flux , donc un format de message non défini USB car nous sommes dans le périphérique . • transaction et mise en mémoire dans les registres du contrôleur d’hôte

C’est un canal de message au format USB car nous sommes dans l’hôte . • accusé de réception de l’hôte ( poignée de main) • le logiciel système est en interruption

• lecture du contenu du tampon • analyse de la demande

• commutation de l’alimentation suivant que le périphérique est alimenté par le bus ou auto- alimenté .

• temporisation de 100 ms

21

3. étape 3 et 4 : les requêtes • interconnexion entre le logiciel système et le logiciel client via Win32

• Le logiciel système étant lié au logiciel client via Win 32 , informe le pilote client d’attribuer une adresse unique , un numéro d’interface associée à un numéro de terminaison. Le pilote USB n’est plus conserné

• Le pilote client envoie une IRP (Interrupt Request Paquet ) vers le pilote USB.

• Émission d’un jeton OUT • temporisation de 2 ms pour le changement d’adresse • l’hôte affecte un numéro de configuration

Puis nous tournons en boucle jusqu’à ce qu’il n’y ai plus de requêtes . • Le pilote USB transforme les requêtes client en transactions individuelles .

Le paquet d’installation permet entre autres choses de définir le nombre d’octets à transmettre et donc la bande pande .

• Le pilote contrôleur d’hôte crée des descripteurs de transfert qui sont

fonction du type du transfert défini dans la requête. Il crée une liste de liens en mémoire qui définissent les transactions devant être excécutées dans une trame donnée . • Les descripteurs de transfert sont rangés dans le contrôleur d’hôte par ordre

prioriataire et suivant un mécanisme défini dans le protocole dépendant du type de conrôleur d’hôte et du type de transfert .

• Le contrôleur d’hôte confectionne les paquets , puis les range dans des registres pouvant être soit dans le contrôleur d’hôte soit en RAM .

• L’hôte vérifie que les ressources USB nécessaires nécessaires au périphérique sont valides et attribut une bande passante fonction du nombre d’octets à transférer

• Les paquets sont copiés dans les terminaisons appropriées puis traités par le

logiciel système avant d’être envoyé vers l’application. Chaque paquet est terminé par une phase "End Of Packet" de 2 temps-bit et il est suivi d’un délai interpaquet de 2 à 7.5 temps-bit. Plusieurs commandes IN et OUT peuvent être envoyées au sein d’un cycle USB. Le dépassement temps bus défini le nombre maximum de segments de câble en aval de l ’hôte. Pour un câble le délai est de 30ns max, pour un hub il est de 40 nS soit 70 nS par section. En amont, nous comptons 7.5 temps bit entre la transaction de l ’EOP et le SOP Les transferts sont effectués dans l’ordre suivant : isochrone, interruption, contrôle et enfin les blocs de données. Ils sont précédés d’un jeton SOF(start of frame )

22

début transfert Transfert Transfert transfert SOF Isochrone Interruption Contrôle blocs 1 ms ou trame sof J D A J D A 1 ms en jaune la transaction = Jeton+Donnée+Accusé de réception en blanc le EOP de 2 temps bit en gris le EOP+ un certain nombre de temps bit fonctions du temps des transactions d ou D correspondent aux données transférées . le nombre d’octets dépend du mode de transfert et du nombre d’octets définis dans les descripteurs . Les transactions sont regroupées à l’intérieur d’une trame sans se chevaucher. Une trame peut contenir une ou plusieurs transactions destinées à un même périphérique.

5. étape 5 : fin de la transaction • Tant que les requêtes continues la boucle se poursuit

• Requête • Création d’un descripteur de transfert • Mise en place dans le contrôleur d’hôte par ordre prioritaire et

par type • Préparation du paquet • Mise en mémoire • Décodage d’une interface et d’une terminaison unique • Transfert du paquet dans la terminaison

• dès que les requêtes sont terminées le logiciel système en avise le logiciel

client que la transaction est terminée par l’envoie d’un paquet vide. • le périphérique est prêt Il est à noter que le mode de transfert peut très bien être modifié en cours de route . En effet , si nous demandons le descripteur de configuration c’est un transfert de commande car nous voulons un état : qu’elle est ta configuration? Dans cette état figure la valeur de la consommation . Si nous voulons transférer cette valeur , un transfert de bloc est nécéssaire.

23

Le bus PCI ( Peripheral Component Interconnect ) bus 32 bits cadencé à 33 Mhz . Taux de transfert de 130 Mo/s • utilise une topologie en étoile à étages du type Ethernet • contrôlé par l ’hôte ( la version USB2.0 prévoit des hôtes multiples) • un hôte par bus pour l’USB 1.0 • Nous pouvons connecter jusqu ’à 127 appareils sur un port USB.

24

• L ’USB supporte le système «plug & play »soit un branchement à chaud avec des pilotes directement chargeables et déchargeables

Alimentation Bus

Auto-alimenté

Basse vitesse Haute vitesse 100 ma 500 ma 100 ma

4.4 V-5.25 V 4.75 V-5.25 V courant de veille • il est proportionnel à i charge (maximum 500 mA) • veille = pas d’activité bus pendant 3 ms + 7 ms pour éteindre l’appareil soit 10 mS • Nous envoyons une trame paquet toutes les 125 ms en pleine vitesse et toutes les 1 ms en

basse vitesse (évite le mode veille) • Si Vbus est perdue nous avons 10 secondes pour éteindre l’appareil Débits USB

Vitesse Version USB 1.0 Version USB 2.0 Basse vitesse 1.5 Mbits/s 1.5 Mbits/s Pleine vitesse ………………….. 12 Mbits/s Haute vitesse 12 Mbits/s 480 Mbit/s

Environnement Le connecteur Type A : côte hôte en amont 1 2 3 4 mâle :côté câble femelle : côté hôte

Alimenté par le bus Alimenté par le bus

25

type B : côté appareil en aval 2 1 1 rouge +5V

2 blanc D- 3 vert D+

3 4 4 noir masse mâle :côté câble femelle :côte appareil

câble basse vitesse : 3 m max haute vitesse : 5 m max hôte +5V +5V appareil D+ au D+ haute vitesse D- au D- basse vitesse 15K 15K 3.3K 3.3K 3.3V< V<3.6V code NRZI bit de bourrage à 0 après six 1 (évite perte de synchronisation) le périphérique est remis à zéro si D+ et D- = 0 pendant 2.5µs D+ et D- passent à 0 pendant 2 coups d’horloge en fin d’EOP (End Of Paquet) Le codage NRZI Autres dénominations : NRZ-M ( Mark ) Utilisation : Fast Ethernet ( 100BaseFX ), FDDI.USB Le codage NRZI n’utilise pas directement le niveau, mais le changement de niveau.

26

Ce principe, appelé le mode différentiel, convertit une information non plus en un niveau de tension constant, mais en un changement de niveau. Nous appellons « transition » ce changement d’état. La transition correspond au bit 1 pour le codage NRZI ou codage NRZ-Mark (Mark signifie 1) et au bit 0 pour le codage NRZ-Space (Space signifie 0). Lorsque le front montant de l’horloge détecte un 1 en entrée, le signal de sortie est alors inversé (d’où NRZ-Inverted), et lorsque le front montant voit un 0, le signal ne subit aucun changement et garde la valeur précédente.

Etat du bus

NRZ

NRZI

27

Les transferts Transferts isochrones Ce type de transfert est utilisé par les applications en temps réel nécessitant un débit de transfert constant telles que CD audio, haut-parleurs, téléphone numérique. La donnée

1 0

28

isochrone est caractérisée par le fait que celle - ci est autorisée (présente) pendant un temps donné sans même s ’assurer qu ’elle est valide. • Accès garanti à la bande passante USB • Temps d’attente limité • Flux de données unidirectionnel • Détection d’erreur via le CRC, mais sans reprise ni garantie de livraison • Modes pleine et haute vitesse seulement • Pas de donnée de basculement La taille maximum de données «charge utile «est spécifiée dans le descripteur de terminaisons d’une terminaison synchrone. Elle peut être de 1023 octets en pleine vitesse et de 1024 octets en haute vitesse. Les synchronisations peuvent être de 3 types : • Asynchrone : horloge externe • Synchrone : le périphérique est synchronisé • Adaptative : Utilise une gamme de débits pour le transfert Transferts d’interruption Ils sont strictement utilisés pour scruter les périphériques afin de déterminer s’ils ont une donnée à transmettre. Dans le cas de l’USB, si un appareil demande de l’hôte, il doit attendre que l’hôte l’interroge avant de signaler qu’il a besoin d’une attention urgente. Le maximum de données utiles par trame est de 64 octets à pleine vitesse. Les transferts se font toujours avec le maximum de taille spécifiée par le descripteur de terminal sauf pour le dernier transfert où le paquet de données est plus petit. • Temps d’attente garanti • Ligne de flux - unidirectionnel • Détection d’erreur et nouvel essai sur période suivante • Taille maximum du paquet en basse vitesse = 8 octets • Taille maximum du paquet en pleine vitesse = 64 octets • Taille maximum du paquet en haute vitesse = 1023 octets Transferts de contrôle Il permet de configurer un périphérique USB et le contrôle de certains aspects de son fonctionnement. Chaque terminal comporte un contrôle de défaut des périphériques utilisés pour la configuration et le contrôle d ’état des périphériques. Le contrôle répond à une variété de questions spécifiques délivrées via le transfert de contrôles. Par exemple quand un périphérique est détecté sur l ’USB le logiciel système doit accéder aux descripteurs pour déterminer le type de périphériques et les caractéristiques de

29

fonctionnement. La spécification USB définie une variété de demandes de périphériques pour les hubs ou pour les autres périphériques. Etape d ’initialisation : Un transfert de contrôles commence toujours par une étape d ’initialisation pour le transfert d ’informations vers un périphérique cible afin de définir le type de demande pouvant être effectuée par le périphérique. Etape donnée : définie seulement lorsqu ’une demande nécessite un transfert de données Etape d état : Elle a lieu suite à une demande, c ’est le résultat de la demande Transferts de masse ou de blocs • Utilisés pour de grandes quantités de données sporadiques • Détection d’erreurs via le CRC avec la garantie de livraison • Pas de garantie de bande passante ou du temps d’attente minimum • Flux de données – unidirectionnel • Modes pleine et haute vitesse • Paquets de 8, 16, 32, 64 octets • Pour les terminaisons à haute vitesse le paquet est de 512 octets • Transfert complet si :

1. Le transfert correspond à la données demandée 2. La taille du paquet est inférieure à la taille maximale du paquet prévu

dans la terminaison 3. Si le paquet est de longueur nulle

Nota : dans le cas 2 ou la taille du paquet est inférieure à la taille maximale, il n’y a pas de bits d e bourrage à zéro pour combler la taille prévue dans la terminaison.

Les paquets

Jeton données protocole Ie paquet est formé de 3 paquets : le jeton – la donnée – le protocole

30

La synchronisation : C’est un mot binaire constant = 00000001 Le PID : C’est l’identificateur de paquet (Paquet identifier), il est sur 4 bits suivis de 4 autres bits qui sont le complément à 1 des 4 bits précédents. Nous le détaillerons un peu plus bas L’adresse périphérique : C’est l’adresse unique allouée par le pilote d’hôte, elle est sur 7 bits Le numéro de terminal : C’est le numéro de terminal alloué , il est sur 4 bits (terminaux de 0 à 15 ) Le CRC : dans le cas du jeton, il est sur 5 bits, dans le cas de la donnée il est sur 16 bits La donnée : la longueur de la donnée est fonction du type de transfert (voir plus loin)

L’identificateur

Groupe PID identificateur Paquet

synchronisation PID Adresse périphérique Numéro Terminal CRC

PID

PID

Données utiles CRC synchronisation

synchronisation

31

Jeton 0001 jeton OUT 1001 jeton IN 0101 jeton SOF 1101 jeton Setup Données 0011 Data 0 1011 Data 1 0111 Data 2 1111 Mdata poignée de main 0010 ACK

Spécial 1100 préambule 1100 erreur 1000 split (partager, fractionner) 0100 ping (s’assurer d’une bonne réception) • : USB version 2.0

1110 Stall 0110 NYET

Paquet jeton

Il en existe 4 types Indique le début de la prochaine trame, utilisé pour synchroniser les terminaux isochrones.

1010 NAK

32

Paquets de données Data0 et data1

Ils transportent la donnée utile associée à une transaction. Direction des paquets

type direction IN du périphérique USB

OUT vers périphérique USB Setup vers périphérique USB

Les mots binaires sont placés poids forts à droite

33

Data 0 Data 1

Paquets « poignée de main »

Paquet de réception ACK indique que le message a été bien reçu


34

Paquet préambule


35

• connecteur = hub

Les transactions

Définition : Dès qu’un jeton est émis par l’hôte , une transaction démarre. Une transaction est un échange de données entre 2 entités.


36

Si vous dites bonjour à une personne , la politesse veut qu’une réponse soit donnée. Dans le cas de l’USB , ce principe reste valable , nous parlons alors de protocole . Il existe plusieurs cas prévus dans le protocole USB , ils sont tous liés à la constitution du paquet .

Transaction IN sans erreur

Elle permet les transferts d ’interruption, de masse, isochrones, de contrôle. Un protocole ACK est retourné à la cible. Le paquet de données est défini comme un paquet Data 0. Dans le cas de transactions IN multiples, les transactions Data0 et Data1 seront alternées.

synchronisation Jeton IN

synchronisation

synchronisation

64 octets de données EOP

EOP ACK

Paquet In de l ’hôte

Paquet de données du périphérique USB

Paquet accusé de réception de l ’hôte

EOP

Transaction IN avec erreur

Constituée de 2 phases : une phase jeton, une phase données. Le protocole n ’est pas retourné de l ’hôte vers le périphérique cible du fait qu ’une erreur a été détectée par l ’hôte lors de la réception. Le périphérique cible détectera un temps d ’attente (tempo) durant lequel l ’accusé de réception n ’est pas retourné à l ’hôte. L ’hôte est responsable de la reprise d ’une transaction IN un peu plus tard.

37

synchronisation Jeton IN EOP

synchronisation 64 octets de données EOP



Transaction IN sans interruption en cours ou périphérique occupé

38

Le périphérique cible ne peut retourner provisoirement la donnée. Pendant ce temps le périphérique retourne un NAK ( pas d ’accusé de réception). Ceci informe le hub racine et le contrôleur hôte que le périphérique est temporairement invalide. Cette forme de transaction est permise pendant un transfert d ’interruptions à condition qu ’une Interruption ne soit pas en cours ou pour des transferts de masse et de contrôles si il n ’existe pas de condition «occupé ».


synchronisation NAK EOP


Transaction In avec cible bloquée

Le périphérique cible retourne un protocole de blocage au hub racine pour informer le logiciel que la condition erreur doit être effacée avant le retour de la donnée

39


synchronisation STALL EOP


Paquet retour du périphérique USB

Transaction IN pendant un transfert isochrone

Le contrôleur hôte et le périphérique cible «savent » que la transaction est une partie du transfert isochrone. Côté périphérique c ’est l ’adresse terminal qui sélectionne un des points Isochrones. Côté hôte c ’est le logiciel système qui spécifie le type de transfert dans le descripteur de transfert. Ce type de transaction comporte une phase jeton et une phase de données mais pas d’accusé de réception (La donnée n ’est pas garantie)

40




Paquet de données en retour du périphérique USB

41

synchronisation Jeton OUT EOP

synchronisation

synchronisation

64 octets de données EOP

EOP ACK

Paquet OUT de l ’hôte


Paquet protocole du périphérique cible

Transaction OUT avec erreur

Transaction OUT Sans erreur

42


synchronisation paquet de données EOP


Paquet de données de l ’hôte

Transaction OUT La cible ne peut accepter la donnée

43

La cible reçoit la donnée sans erreur mais ne peut l ’accepter (occupée, tampon plein). En réponse, la cible retourne un NAK pendant la phase protocole afin d ’informer l ’hôte que la cible ne peut accepter la donnée et que la transaction doit s ’effectuée plus tard.


synchronisation

synchronisation

>64 octets de données EOP

EOP NAK


Paquet de données vers le périphérique USB

Paquet protocole de la cible

Transaction OUT avec cible bloquée

44


synchronisation

synchronisation

>64 octets de données EOP

EOP STALL


Paquet de données

Paquet STALL

La cible reçoit un jeton Out et reconnaît qu ’elle a été adressée. Toutefois quand l ’hôte envoie le paquet de données, le périphérique cible ne peut accepter la donnée et retourne une information de blocage à l ’hôte pendant la phase protocole. Cette information est envoyée au logiciel hôte qui efface la condition erreur

45

Transferts de contrôles Les transferts de contrôles permettent la configuration, les commandes et les demandes d’états de ou vers les périphériques. Il existe 3 étapes : Une étape donnée paquet d’installation ou étape init Une étape donnée

Transaction OUT pendant un transfert isochrone





46

Une étape état

Etape donnée paquet d ’installation

décalage champ Valeur signification

0 type de demande bitmap - 1 octet D7 direction de la demande 0 hôte vers périphérique 1 périphérique vers höte D6-D5 type de demande 0 standard 1 classe 2 fournisseur 3 réservé D4-0 destinataire 0 périphérique 1 interface 2 terminal 3 autre 4….31 réservé 1 demande valeur - 1 octet demande spécifique 2 valeur valeur- 2 octets taille du mot 4 index index décalage transmet un index ou un 2 octets décalage 6 longueur compte - 2 octets dans une étape de données , c ’est le nombre d ’octets transférés

étape donnée Elle est facultative et consiste en un ou plusieurs transferts In (entrée) ou OUT

47

Étape état

48

Généralités sur la correction des erreurs

La vérification du mécanisme de détection permet :

•les vérifications d ’erreur de paquet 1- les faux EOP 2-les débordements

•La vérifications de l ’erreur de transition de données 1- la diaphonie

49

Paquets d ’erreurs

Les périphériques USB détectent 3 types de paquets d ’erreurs :

•les paquets d ’identification

•Le CRC

•l ’erreur de bit de bourrage Si l ’un de ces cas se présente, le récepteur de paquet doit ignorer le paquet et n ’envoyer aucune réponse. Le type de détection d ’erreur n ’est dépendant ni de l ’hôte ni du périphérique.

Toutefois, le système hôte peut faire une statistique en fonction des paquets défectueux.

Vérification des paquets d ’identification

Chaque paquet transmis sur l ’USB débute avec un paquet d ’identification constitué de 4 bits en tête représentant le type (jeton, donnée, protocole, spécial) suivis de 4 bits de vérification qui sont le complément à 1 des 4 bits précédents. Nous parlons alors de PID ( Packet ID)

50

PID0 PID1 PID2 PID3 PID0 PID1 PID2 PID3

Erreur CRC

Type de paquet champ taille maximum nombre de bit du CRC SOF nombre de trame 11 bits 5 IN périph/adresse terminal 11 bits 5 Out idem idem idem Init idem idem idem Data 0 donnée utile 1023 octets 16 Data 1 idem 1023 octets 16 ACK paquet ID idem idem NACK idem idem idem Stall idem idem idem Préambule idem idem idem CRC 5 bits :champ =00101 - polynôme générateur=X5+X2+1 reste=01100 CrC16bits: champ=100000000000101-polynôme générateur = X16+X15+X2+1 reste=1000000000001101

Erreur Bit de bourrage Le bit de bourrage assure la synchronisation de l ’émission /réception du code NRZI en forçant une transition après détection de 6 bits à 1 consécutifs. Si en réception le récepteur ne déclenche pas de bit de bourrage après 6 bits à 1 il y a erreur. De plus, le récepteur perd la synchronisation si le code NRZI est à 1 pendant 1 seconde. En agissant ainsi, nous évitons la perte de synchronisation du récepteur.

Erreurs du paquet jeton erreur IN

Si une erreur est détectée dans le paquet jeton, elle est ignorée par la cible et aucune réponse n ’est envoyée à l’hôte. L ’hôte accepte soit une donnée soit un paquet protocole en réponse à un jeton IN. Toutefois si la cible ne répond pas, l ’hôte détectera un dépassement de temps et une perte de transaction. L ’hôte est responsable de la reprise de la transaction.

Erreurs du paquet jeton paquet OUT ou initialisation

51

Dépassement temps bus

Si le paquet OUT ou l ’initialisation sont générés par l ’hôte quand l ’erreur est détectée, l ’hôte fera suivre le paquet jeton par le paquet de données. La cible peut décoder le paquet de données sans erreur mais ne peut vérifier ni le but du contenu (erreur adresse CRC), ni sa signification (erreur de vérification PID). Cependant la cible ne répond pas au paquet OUT(initialisation) ni au paquet de données qui suit. Il s ’en suit un dépassement de temps et une perte de transaction.

Erreur de paquet de données Il existe 2 cas :

•pendant une transaction OUT ou initialisation pas de réponse

•pendant une transaction IN La donnée valide est retournée à l ’hôte mais celui-ci reçoit une donnée erronée L ’hôte ne répond pas avec un protocole ACK La cible est informée que l ’hôte ne reçoit plus la donnée l ’hôte doit réessayer la transaction

Erreur de paquet »poignée de main » pendant une transaction OUT Pendant une transaction OUT le jeton et le paquet de données peuvent être reçus sans erreur. La cible accuse réception de la donnée par un protocole ACK. Si des erreurs sont détectées quand le paquet ACK est reçu, le paquet sera ignoré par l ’hôte et le protocole s ’annulera. La cible a en fait reçu la donnée, mais le protocole ayant été corrompu empêche la transaction complète. L ’hôte qui a émis une erreur envoie un nouveau paquet, la cible reconnaît avoir déjà reçu le paquet, ceci entraîne que la donnée a été validée 2 fois et crée des problèmes de synchronisation entre l ’hôte et la cible.

Erreur de paquet « poignée de main » pendant une transaction IN Une circonstance similaire à celle de la transaction OUT peut apparaître avec un transfert entre la cible et l ’hôte. L ’hôte retourne un ACK à la cible, mais le paquet d ’erreur ACK est détectée par la cible. La cible confirme un transfert dégradé, mais l ’hôte a reçu la donnée. L ’hôte reconnaît que le transfert a été complet et demande la prochaine donnée à transférer. Toutefois la cible croit que la transaction a échouée et renvoie la même donnée. Il est possible d ’éliminer ce genre de problème par l ’envoie d ’un mécanisme de basculement de données

L ’émetteur /récepteur impliqué dans une transaction doit connaître le temps d ’attente pour avoir une réponse. Si cette réponse n ’arrive pas dans les délais, une erreur dépassement temps bus est détectée. La non réponse d ’une cible est définie par la spécification comme une méthode permettant d ’indiquer qu ’un paquet envoyé n ’a pas été reçu. Si des erreurs sont détectées à la réception d ’un paquet, il n ’y aura pas de réponse mais la détection d ’un dépassement de temps bus permettra de déterminer la présence d ’erreurs pendant le transfert. Le dépassement temps bus défini le nombre maximum de segments de câble en aval de l ’hôte. Pour un câble le délai est de 30ns max, pour un hub il est de 40 nS soit 70 nS par section.

52

EOP faux Un problème peut apparaître si le récepteur détecte un EOP avant que l ’émetteur ait terminé son transfert, c ’est un EOP faux. Si le récepteur répond à un EOP prématuré par un paquet protocole il y a risque de collision sur le bus. Ceci aura pour effet de corrompre 2 paquets consécutifs. Heureusement les EOP faux peuvent être détectés par une erreur CRC et éviter la collision

EOP faux pendant une transition de l ’hôte

Le périphérique cible USB qui détecte un paquet d ’erreurs ignore simplement le paquet et ne répond pas à l ’hôte. Toutefois si un EOP faux apparaît l ’erreur CRC force la cible a attendre que l ’hôte envoie un autre paquet. Ce comportement passif de la cible évite les collisions. L ’hôte peut continuer à transmettre la donnée après détection d ’un EOP faux. Le périphérique cible ne reconnaît pas le reste du paquet comme valide et détectera le vrai EOP à la fin du paquet .

EOP faux pendant une transition de la cible

Si la cible est en train de transmettre une donnée et que l ’hôte reçoit un EOP faux, l ’erreur CRC fait que l ’hôte ignore le paquet et ne répond pas à la cible évitant ainsi la collision. La cible en attente de protocole « sait » que le paquet n ’a pas été reçu par l ’hôte et attend la prochaine transaction pour être initialisée. L ’hôte dans ce cas a besoin de savoir quand il doit sauvegarder pour transmettre le paquet suivant. Cependant la détection EOP fut prématurée et la cible peut continuer à transmettre. Si l ’hôte ne détecte pas d ’autres transitions sur le bus pendant une période de dépassement temps bus de 16 temps bit, il est assuré qu ’aucune autre donnée n ’est envoyée par la cible. Si les transactions bus continuent l ’hôte doit attendre l ’EOP et 16 temps bit avant de transmettre (ce délai est nécessaire à la cible pour détecter la non réponse de l ’hôte)

Procédure de basculement de données sans erreurs(data0) Le basculement de données est supporté par les transferts de masse, d ’interruptions et de contrôles en implantant des bits de basculement. Les périphériques émission/réception placent leurs bits de basculement dans des états opposés à ceux d ’une transaction sans erreur. Les paquets de données Data0 et Data1 sont transmis alternativement et comparés par le récepteur de paquet pour vérifier que le paquet a été bien reçu. L ’émetteur de paquet utilise le paquet de données en fonction du bit de basculement (bit =0 pour data0). Hôte Cible

53

Émission du jeton OUT réception du jeton sans erreur

Émission de Data 0 réception de data 0, le bit bascule à1

Réception du paquet ACK émission du protocole ACK sans erreur le bit bascule à 1

Procédure de basculement de données sans erreurs(Data1)

Émission du jeton OUT réception du jeton sans erreur

Émission de Data 1 réception de data 1, le bit bascule à 0

Réception du paquet ACK émission du protocole ACK sans erreur le bit bascule à 0

Hôte cible

Procédure de basculement de données avec erreurs(data0)

Il y a 2 tentatives

54

Basculement pendant un transfert de contrôle

Le problème est le suivant : Le transfert de contrôle s’effectue en 3 étapes :

Hôte Cible

Jeton OUT réception sans erreur Data 0 réception avec erreur pas de protocole la cible ignore le paquet ACK après 16 temps pas de protocole ACK Bit, 2ème tentative

Hôte Cible

Jeton OUT réception sans erreur Data 0 réception sans erreur basculement du bit à 1 réception du paquet émission du ACK , basculement protocole ACK du bit à 1

Basculement de donnée avec erreur de paquet «poignée de main » transaction OUT

Il y a 2 tentatives

Hôte Cible

Jeton OUT réception sans erreur Data 0 réception sans erreur basculement du bit à 1 réception du paquet protocole ACK sans erreur ACK avec erreur 2ème tentative

Hôte Cible

Jeton OUT réception sans erreur Data 0 réception sans erreur basculement du bit à 1 réception du paquet émission du ACK sans erreur protocole ACK sans erreur basculement du bit

55

• Étape paquet d’initialisation ou init • Étape donnée • Étape état Etant donné le nombre de possibilités attachées à une donnée, il est difficile de régler le problème simplement en 2 opérations comme précédemment et la solution du bit de basculement n’est plus valable. Le départ est toujours l’étape paquet init, elle est réalisée par l’envoie d’un paquet de données Data 0 suivi de paquets Data1 et Data 0 alternativement. L’hôte peut vouloir soit recevoir une donnée soit émettre une donnée. Afin de s’assurer que tout fonctionne bien, le protocole est le suivant : Écriture de données (OUT) • Étape paquet init • Étape Donnée OUT L’hôte est en droit d’attendre soit : 1. La cible ignore le paquet (mauvais jeton) 2. Réponse ACK (bien reçu) 3. Réponse NAK (occupé) 4. Réponse STALL(bloqué) Afin de connaître l’état de la réponse il doit être en état IN ( je veux recevoir une réponse) . Celle-ci peut être 1. Paquet nul (validation bien reçu) 2. NAK ou STALL (occupé ,bloqué) Lecture de données (IN) • Étape paquet init • Étape Donnée IN L’hôte est en droit d’attendre soit : 1. La cible ignore le paquet ( mauvais jeton) 2. Réponse ACK ( bien reçu) 3. Réponse NAK (occupé) Afin de confirmer la bonne réception il doit être en état OUT (je confirme) Il doit alors envoyer : 1. Paquet nul (validation bien reçu) 2. NAK ou STALL (occupé ,bloqué)

Diaphonie Des pannes de bus peuvent apparaître si un périphérique sur le bus tombe en panne à la fin d ’une transaction créant ainsi de la diaphonie. Ce type de diaphonie peut bloquer complètement le bus. La diaphonie est détectée en fin de trame, toutefois elle est caractérisée par un SOP suivi d ’une activité en fin de trame. Si le bus n ’est pas en état d ’activité et que la fin de trame montre une diaphonie, il doit être isolé en inhibant le hub qui s ’y rattache.

56

Perte d ’activité

C ’est une forme de panne potentielle. Elle est caractérisée par un périphérique démarrant un transfert de paquet suivi d ’un état J ou K constant sur le bus sans EOP. Elle est aussi détectée en fin de trame.

Correction et détection de perte d ’activité/diaphonie Le hub a pour fonction de détecter et de corriger ces erreurs. L ’hôte bloque les transactions et s ’assure qu ’il n ’y a pas d ’activité sur le bus sans fin de trame. Quand tout fonctionne, la dernière transaction se termine par un EOP suivie d ’un état d ’activité.

Séquenceur de trame

Les hubs sont chargés du séquencement de chaque trame et de l ’échantillonnage de l ’activité bus à la fin de chaque trame. Le séquenceur de trame est synchronisé par le paquet SOF et doit pouvoir maintenir la synchronisation en absence de deux jetons SOF consécutifs. Si le hub détecte une diaphonie ou un état d ’activité après un EOF1 il doit terminer le trafic en amont. Tous les hubs en amont devront détecter un état inactif. Si toutefois un hub détecte une activité après un EOF2, il doit inhiber le port auquel le périphérique est attaché.

Conservation /suspension de l ’alimentation

La suspension de l ’alimentation est utilisée pour réduire le surplus de consommation pendant le contrôle logiciel. Il existe 2 types de suspension : globale :tous les périphériques USB sont placés dans un état de suspension sélective :les périphériques sélectionnés sont en état de suspension quand un périphérique entre en état de suspension, il ne doit pas consommer plus de 500 µA. Les périphériques entrent en suspension après 3mS d ’inactivité bus. Les périphériques basse vitesse ne voient pas de paquet SOF ou de transactions pleine vitesse, il s ’en suit que les hubs doivent envoyer un état de transition K à tous les périphériques basse vitesse dans un intervalle inférieur à 3.0 mS afin de les avertir d ’une entrée imminente en état

57

Réponse d ’un périphérique à une suspension

Quand les périphériques entrent en état de suspension, ils doivent conserver cet état et ne pas consommer plus de 500µA. Cette limite inclus le courant qui traverse les résistances liées aux lignes D+ et D-. Certains périphériques comme les modems doivent remettre en route le système suite à un événement externe. Le logiciel système réagit en fonction d ’une demande du périphérique.

Réponse d ’un hub à une suspension Quand le hub détecte une inactivité de plus de 3 mS en amont du port, il doit entrer en état de suspension. Cependant le hub a détecté une inactivité pendant 3 ms , par définition cette inactivité aura été transmise en aval du hub par tous les ports. Tous les ports en aval ainsi que le hub détecteront l ’état de suspension pratiquement en même temps. A la détection de l ’état de suspension le hub entreprend les actions suivantes :

•place ses répéteurs en état d ’attente de départ de paquet (WSOP)

•sauvegarde toutes les sorties des pilotes

•maintient toutes les valeurs statiques des bits de contrôles et d ’états

•préserve l ’information d ’état courant pour tous les ports en aval Cependant, le hub peut très bien envoyer plus de 500µa aux ports an amont afin de permettre une commande de mise en route à distance pendant un état de suspension. Ceci permet à un périphérique de pouvoir piloter le bus pendant un état de suspension et de remettre le système en route

Une suspension globale place tout le réseau USB en suspension. Ceci implique une consommation minimum. L ’hôte initialise une suspension globale en réponse à une période prolongée d ’inactivité sur USB.

Suspension globale

58

Elle est initialisée quand le trafic du hub racine est terminé. Ceci est fait sous contrôle logiciel via une suspension globale suite à une demande du terminal de contrôle du hub racine.

Reprise de suspension globale

Les périphériques se «réveillent » de leur état de suspension quand ils détectent un signal de reprise sur le bus. La reprise peut s ’effectuer de plusieurs façons :

•par le hub racine, celui-ci signalant une reprise en aval

•par le périphérique en aval relié à un port valide

•par la connexion d ’un périphérique

•par la déconnexion d ’un périphérique

•par un reset, ce qui impose une reconfiguration de tous les périphériques

Bus PCI

Contrôleur d’hôte Hub racine

Initialisation de reprise par l ’hôte

Initialisation à une suspension globale

59

« réveil » télécommandé d ’un périphérique Un périphérique en état de reprise peut répondre à un événement externe en signalant un «réveil » au système via l ’USB. Le signal de reprise est initialisé par le périphérique qui envoie un état K sur le bus. Les actions du hub sont :

•signal de reprise sur les ports en amont

•signal de reprise sur tous les ports valides en aval

•retourner un signal de reprise au périphérique source Signal de reprise globale suite à un « réveil » d ’un périphérique cible

Bus PCI •Un état K est signalé sur le port du hub •le port détecte un signal de reprise •le signal de reprise est envoyé par le hub 7 sur tous les ports en amont et en aval pendant les 50µS de réception de la reprise •le hub 2 transmet à tous ces périphériques valides la reprise pendant les 50 µS du signal de reprise du hub7

60


Périphérique 1

Périphérique 3

Périphérique 4

Périphérique 5

Périphérique 6

Périphérique 7

hub

Périphérique 2 hub

Périphérique 8

Suspension sélective

Permet au logiciel de suspendre un périphérique donné ou une partie du bus. La suspension sélective est initialisée par logiciel quand un port hub est placé dans un état de suspension. Les ports en état de suspension bloquent tout le trafic en aval, ceci entraîne que tous les périphériques en aval détectent une inactivité au bout de 3 mS, limitant ainsi leur consommation.

61

Initialisation de Suspension sélective

Le logiciel hôte peut suspendre un périphérique donné ou un groupe de périphériques reliés à un segment donné du bus. La suspension est accomplie via un transfert de contrôles qui envoie une demande SETPORTFEATURE. Le hub qui reçoit cette demande placera le port en état de suspension. Il est à noter que le hub ne peut suspendre un port pendant le transfert d ’un paquet. Dans l ’état de suspension le port n ’envoie aucun trafic en aval au périphérique lié, sauf en cas de demande de RAZ sur le port.

Reprise d ’une suspension sélective

Elle peut être initialisée de 2 façons : l ’hôte initialise la reprise sélective L ’hôte initialise la reprise sélective via une demande CLEARPORTFEATURE au port hub. Ceci entraîne que le port envoie un signal de reprise au port lié pour «réveiller » le périphérique. La suspension doit être signalée durant les dernières 20mS suivies d ’un EOP. Un bit d ’état est initialisé sur le hub pour signaler que la reprise est complète et que le périphérique est maintenant accessible.Ce bit ne doit pas être initialisé pendant 3ms après l ’EOP. Ceci permet au

62

Le périphérique signale une reprise

Suspension sélective quand le hub est suspendu

Après la suspension d ’un port hub. Le logiciel hôte doit suspendre tout le hub. Il faut pour cela 3 conditions :

•le périphérique lié a interrompu la demande de reprise au port

•le périphérique est connecté à un port suspendu de façon sélective

•le périphérique est déconnecté du port suspendu de façon sélective

Si le périphérique lié à un port suspendu signale une reprise («réveil ») les actions du hub sont les suivantes :

•La reprise est signalée à tous les ports en aval qui sont validés en arrière du port suspendu.

•La reprise est signalée en amont sur son port racine pendant les 50 µS de réception de la reprise des périphériques. Elle doit être conservée et la connectivité inversée pendant 10 ms

•Le port amont signale la reprise au hub pendant 20 ms. Le signal est donc réfléchi vers tous les périphériques en aval y compris le périphérique source

•Le port racine envoie un EOP basse vitesse à la fin du signal de reprise et le hub

63

Le port reçoit une connexion/déconnexion

Si le port en suspension sélective reçoit un SE0 (Single -ended zero) d ’une transition active ou inactive, le signal de reprise n ’est pas renvoyé au port suspendu, les tampons de sortie du port sont placés en haute impédance. Le bit d ’état ne sera pas initialisé et le hub indiquera un événement de connexion ou une déconnexion et que le port ne doit pas conserver plus longtemps son état de suspension.

Suspension sélective suivie d ’une suspension globale

Bus PCI

64


Périphérique 1

Périphérique 2 hub

Périphérique 3

Périphérique 4

Périphérique 5

Périphérique 6

Périphérique 7

hub

Périphérique 8

Port inhibé Signal de reprise vers l’aval signal de reprise vers l ’amont

Supposons les ports marqués en noir en suspension sélective avant qu ’une suspension globale arrive. Quand un «réveil »télécommandé est signalé par le périphérique 8 le hub 7 transmet un signal de reprise à ses autres ports et au port racine. Le périphérique 2 reconnaît le signal de reprise et retransmet celui-ci à tous les ports sauf aux périphériques 4 et 3 en suspension sélective. Une fois la suspension globale terminée l ’hôte doit tenir en éveil les périphériques ayant reçu le signal de reprise en priorité sur la suspension globale

Reprise via une remise à zéro

Quand un hub suspendu détecte un reset sur son port amont (SE0>2.5µs), il doit initialiser une séquence de réveil. Le hub doit être «réveillé » et avoir complété son reset 10 mS avant la fin du signal de reset. Le contrôleur de hub doit être dans l ’état suivant :

•adresse 0 par défaut

•bit de contrôle initialisé à la valeur par défaut

•hub répéteur en état WFSOF

•alimentation des ports en aval coupée

•tous les ports en aval en état déconnecté

65

Séquenceur de trame hub après un réveil

Durant leur état de suspension les hubs coupent leurs séquenceurs de trame afin de réduire la consommation. Quand une reprise arrive le séquenceur doit redémarrer et prendre le temps de se synchroniser à l ’hôte après réception d ’un paquet SOF. L ’intervalle de temps entre le retour à l ’état «éveil » et le premier paquet SOF fait que le hub est incapable de détecter la diaphonie d ’un périphérique et la perte d ’activité. Normalement le hub vérifie l ’état du bus en début et en fin de trame pour déterminer si un périphérique est en diaphonie ou maintenu en état d ’inactivité. Toutefois immédiatement après un état de suspension le hub ne peut détecter ce type d ’erreur. Afin de prévenir une diaphonie ou une perte d ’activité, le hub ne doit pas transmettre l ’activité bus en amont jusqu ’à réception d ’un SOF. Le trafic en amont est bloqué par le hub qui est alors en état d ’attente (WFSOF). La transition d ’état WFSOF en WFSOP s ’effectue à la réception du paquet SOF. Il est à noter que le trafic en aval fonctionne quand le hub est en état WFSOF. Si les périphériques en aval sont adressés ils retournent un paquet à l ’hôte afin d ’éviter un dépassement de temps détecté par l ’hôte du fait d ’une non réponse. A cause de ceci, la recommandation spécifie de ne pas adresser ces périphériques.

66

Connexion d ’un nouveau périphérique USB

•L ’hôte attribue sa propre adresse de bus au périphérique

•à cette adresse l ’hôte extrait toutes les informations de configuration de l ’appareil

•l ’hôte attribue à l ’appareil l ’une des configurations possibles.

•Le périphérique est autorisé à drainer le courant défini dans le descripteur de configuration

•Le microcontrôleur de l ’appareil répond aux interrogations de l ’hôte, les données sont stockées dans le FIFO 0.

Configuration du hub racine

Le logiciel hôte commence l ’énumération des périphériques USB par la configuration du hub racine. Rentre alors en scène 2 contrôleurs, le UHC(Universal Controller) et le OHC (Open Host Controller). Ces contrôleurs ont la même fonction de base et accomplissent le même travail mais suivent des chemins différents. Le hub racine comporte un terminal permettant de détecter le changement d ’état de chaque port. Une fois le hub configuré, le logiciel peut scruter l ’état du terminal pour voir si un périphérique a été connecté au port. Les périphériques connectés sont isolés du bus et sont détectés et configurés un par un. Chaque périphérique doit être initialisé à une adresse 0 par défaut. Le logiciel fait une demande de remise à zéro du port sélectionner de sorte que l ’adresse étant à 0 le descripteur de périphérique lit cette adresse. Le logiciel hôte ayant détecté les périphériques détermine si les terminaux ont une bande passante adéquate et si l ’alimentation est correcte. Une fois tous les périphériques inspectés, les configurations non effectuées entraînent que les périphériques liés ne sont pas configurés.

67

Généralités sur la configuration du hub

Les hubs doivent être configurés comme un autre périphérique. Les étapes sont les suivantes :

•lecture des descripteurs de périphériques afin d ’obtenir l ’information nécessaire à leur configuration

•affecter une adresse unique

•alimenter les ports

•vérifier que l ’état du hub change à la détection d ’événements port ( déconnexion-connexion)

•Lecture de l ’information d ’état pour déterminer la nature de l ’événement

•valider le port afin de permettre l ’accès du périphérique lié

68

Gestion du transfert de données.

Chaque canal qui est initialisé pendant la configuration est défini pour un terminal spécifique dans une interface fonctionnelle d ’un périphérique. Un client peut initialiser un canal avant d ’être utilisé, il respecte alors la politique du canal. La politique du canal définie la donnée devant être transférée par IRP. Le client peut aussi demander l ’information d ’état et spécifier l ’adresse du tampon mémoire où la donnée lue/écrite du terminal est stockée. Pour accéder à l ’information du périphérique nous utilisons un canal par défaut, le pilote USB étant responsable de sa gestion et de son initialisation.

Gestion bus

Le pilote doit permettre à un client de devenir un client maître sur l ’USB. Un client maître peut ajuster le temps bit d ’une trame, additionner ou soustraire un temps bit de la trame USB courante pour ajuster l ’intervalle SOF. Quelques terminaux requièrent la synchronisation de leur horloge interne par le SOF (1mS). Toutefois un périphérique ne peut synchroniser son horloge interne sur le SOF.

69

Les descripteurs

Le constructeur de périphérique doit créer des descripteurs reflétant les caractéristiques et le comportement d’un périphérique donné. Les descripteurs standards comprennent : • le descripteur de périphérique : spécifie une ou plusieurs interfaces et les attributs liés à

la configuration • Le descripteur de configuration : défini le nombre de terminaux et les attributs liés à

l’interface • Le descripteur de terminal : il spécifie les attributs liés à un terminal donné ainsi que les

informations nécessaires au pilote d’hôte lui permettant d’accéder au terminal • Le descripteur de chaîne : C’est une chaîne unicode optionnelle pouvant être lue • Le descripteur de classe : Il permet à un descripteur de spécifier une classe particulière

70

Descripteurs d'appareils Le descripteur d'appareil d'un appareil USB représente l'appareil en entier. En conséquence un appareil USB ne peut avoir qu'un seul descripteur d'appareil. Il donne des informations élémentaires et pourtant fondamentales sur l'appareil telles la version USB supporté, la taille maximale de paquet, les IDs constructeur et produits et le nombre de configurations possibles que peut avoir l'appareil. Le format du descripteur d'appareil est montré ci-dessous : 0 bLength 1 Nombre Taille du descripteur en octets(18 octets) 1 bDescriptorType 1 Constan

te Descripteur d'Appareil (0x01)

2 bcdUSB 2 BCD Numéro de spécification USB auquel l'appareil doit aussi se soumettre.

4 bDeviceClass 1 Classe Code classe (class) (Assigné par USB org) si égal à 0, chaque interface précise son propre code classe si égal à 0xFF, le code classe est précisé par le constructeur. Autrement le champ est un code classe valable.

5 bDeviceSubClass 1 Sous Classe

Code sous Classe (Assigné par USB org)

6 bDeviceProtocol 1 Protocole

Code Protocole (Assigné par USB Org)

7 bMaxPacketSize 1 Nombre Taille maximale de paquet pour la terminaison Zéro. Les tailles conformes sont 8, 16, 32, 64

8 idVendor 2 ID IDentification du fournisseur(Assigné par USB Org)

10 idProduct 2 ID IDentification du produit (Assigné par le Fabricant)

12 bcdDevice 2 BCD Numéro de version de l'appareil 14 iManufacturer 1 Index Index de descripteur de chaîne du

fabricant 15 iProduct 1 Index Index de descripteur de chaîne du produit 16 iSerialNumber 1 Index Index de descripteur de chaîne du numéro

de série 17 bNumConfigurations 1 Entier Nombre de configurations possibles

Le champ bcdUSB rapporte la version USB la plus haute que peut supporter l'appareil. La valeur est en binaire codé décimal avec un format de 0xJJMN ou JJ est le numéro de

71

version de poids fort, M le numéro de version de poids faible et N correspond au numéro de sous-version c'est à dire USB 2.0 est inscrit comme 0x0200, USB 1.2 comme 0x0110 et USB 1.0 comme 0x0100. Les bDeviceClass, bDeviceSubClass et bDeviceProtocol sont utilisés par le système d'exploitation pour trouver un pilote logiciel de classe pour votre appareil. Habituellement seul le bdeviceclass est positionné au niveau de l'appareil. La plupart des spécifications de classe choisissent de s'identifier au niveau de l'interface et en conséquence positionnent le bdeviceclass à 0x00. Cela permet à un appareil de supporter plusieurs classes. Le champ bMaxPacketSize rapporte la taille maximale pour la terminaison zéro. Tous les appareils doivent supporter la terminaison zéro. Le champ idVendor et idProduct sont utilisés par le système d'exploitation pour trouver un pilote logiciel pour votre appareil. Le champ bcdDevice a le même format que bcdUSB et est utilisé pour fournir un numéro de version d'appareil. Cette valeur est assignée par le programmeur. 3 descripteurs de chaînes de caractères existent pour fournir des détails du fabriquant, du produit et du numéro de série. Il n'y a pas d'obligation à avoir des descripteurs de chaînes de caractères. Si aucun descripteur de chaînes de caractères n'est présent, il faudrait utiliser un index de zéro. bNumConfigurations définit le nombre de configuration que l'appareil peut supporter et sa vitesse normale d'exécution.

72

Les Descripteurs de Configurations Un appareil USB peut avoir plusieurs configurations différentes alors que la majorité des appareils sont simples et n'en ont qu'une. Le Descripteur de Configuration précise la façon dont l'appareil est alimenté, quelle est sa consommation électrique maximale, le nombre d'interfaces qu'il possède. Il est donc possible d'avoir 2 configurations, quand il est alimenté par le bus et une autre quand il est alimenté par le secteur. Comme ceci est un "en tête " de descripteur d'interface, il est aussi possible d'avoir une configuration utilisant un mode de transfert différent de celui d'une autre configuration. Une fois que toutes les configurations ont été examinées par l'hôte, celui-ci enverra une instruction SetConfiguration avec une valeur différente de Zéro qui correspondra à la valeur bConfiguration de l'une des configurations. Elle est utilisée pour sélectionner la configuration voulue. 0 bLength 1 Nombre Taille du Descripteur en Octets. (9 octets) 1 bDescriptorType 1 Constan

te Descripteur de configuration. (0x02)

2 wTotalLength 2 Nombre Longueur totale en octets de données renvoyées.

4 bNumInterfaces 1 Nombre Nombre d'Interfaces 5 bConfigurationValue 1 Nombre Valeur à utiliser comme argument pour

sélectionner cette configuration. 6 iConfiguration 1 Index Index du Descripteur de chaînes de

caractères décrivant cette configuration. 7 bmAttributes 1 Bitmap D7 réservé, mis à 1 (usb 1.0 alimenté par

le bus ) D6 Auto alimenté D5 Activation d'une station à distance. D4. 0 Réservé. Mis à 0

8 bMaxPower 1 mA Consommation électrique maximale en unités de 2 m A.

Lors de la lecture du descripteur de configuration, il renvoie la hiérarchie ou l'arborescence complète de configuration qui inclut toute interface apparentée et les descripteurs de terminaisons. Le champ wTotalLength indique le nombre d'octets dans la hiérarchie.

Le champ bNumInterfaces indique le nombre d'interface présent pour cette configuration. Le champ bConfigurationValue est utilisé par la demande SetConfiguration pour sélectionner cette configuration.

73

Le champ iConfiguration est un index de descripteur de chaîne de caractère décrivant la configuration dans un format lisible par l'homme. Le champ bmAttributes précise les paramètres d'alimentation pour la configuration. Si un appareil est auto-alimenté, il positionne D6. Le bit D7 était autrefois utilisé par l'USB 1.0 pour indiquer un appareil alimenté par le bus, ceci est maintenant réalisé par le champ bMaxPower. Si un appareil utilise l'énergie du bus, que ce soit un appareil alimenté par le bus ou un appareil auto-alimenté, il doit rapporter sa consommation électrique dans le champ bMaxPower. Les appareils peuvent aussi prendre en charge l'activation d'une station à distance qui permettra à l'appareil de réveiller l'hôte quand celui-ci est en mode veille. Le champ bMaxPower définit la consommation électrique maximale que l'appareil peut prendre du bus. Elle est donnée en unités de 2 mA, jusqu'au chiffre maximum de 500 mA environ. La spécification permet à un appareil alimenté par un bus de forte puissance de ponctionner jusqu'à 500 mA à partir de Vbus. Dans le cas où un appareil perd son alimentation externe, il ne doit pas ponctionner plus que ce qui est indiqué dans bMaxPower. Il devrait échouer sur toutes opérations nécessitant l'alimentation externe.

74

Les Descripteurs d'Interfaces Le Descripteur d'Interface peut être vu comme un " en tête " ou un regroupement de Terminaisons dans un groupe fonctionnel exécutant une simple fonction pour l'appareil. Le Descripteur d'Interface correspond au format suivant :

0 bLength 1 Nombre Taille du descripteur en Octets (9 octets ) 1 bDescriptorType 1 Constan

te Descripteur d'interface (0x04 )

2 bInterfaceNomber 1 Nombre Nombre d'Interfaces 3 bAlternateSetting 1 Nombre Valeur utilisée pour sélectionner une

configuration de remplacement. 4 bNumEndpoints 1 Nombre Nombre de terminaisons utilisées pour

cette interface. 5 bInterfaceClass 1 Class Code Classe (assigné par USB org ) 6 bInterfaceSubClass 1 SubClas

s Code Sous Classe (assigné par USB org )

7 bInterfaceProtocol 1 Protocol Code du Protocole (Assigné par USB org ) 8 iInterface 1 Index Index du descripteur de chaîne décrivant

cette interface.

Le champ bInterfaceNumber indique l'index du descripteur d'interface. Il devait être pointé à Zéro, et incrémenté une fois pour chaque nouveau descripteur d'interface. Le champ bAlternativeSetting peut être utilisé pour préciser les interfaces de remplacement. Ces interfaces alternatives peuvent être sélectionnées par la demande SetInterface. bNumEndpoints indique le nombre de terminaisons utilisé par l'interface. Cette valeur devrait exclure la terminaison Zéro et est utilisée pour indiquer le nombre de Descripteurs de terminaisons à suivre. bInterfaceClass, bInterfaceSubClass et bInterfaceProtocol peuvent être utilisés pour préciser les classes prises en compte (par exemple : HID, Communications, mémoire de masse etc…). Ceci permet à plusieurs appareils d'utiliser des " drivers " (pilote logiciel) de classe évitant le besoin d'écrire des " drivers " spécifiques pour votre appareil. iInterface permet d'avoir une description textuelle de l'interface

75

Les Descripteurs de Terminaisons (ou Terminaux) Les Descripteurs de Terminaison sont utilisés pour décrire les terminaisons autres que la terminaison zéro. La terminaison zéro est toujours censée être une terminaison de commande et est configuré avant que n'importe quel autre descripteur ne soit sollicité. L'Hôte utilisera l'information renvoyée par ces descripteurs pour déterminer les besoins de bande passante du Bus.

0 bLength 1 Nombre Taille du Descripteur en octets (7octets ). 1 bDescriptorType 1 Constan

te Descripteur de Terminaison (0x05)

2 bEndpointAddress 1 Terminaison

Adresse de Terminaison Bits 0. 3b Numéro de terminaison Bits 4. 6b Réservés. Mis à 0 Bits 7 Direction ; 0 = Sortie, 1 = Entrée (Ignoré pour les terminaisons de commandes)

3 bmAttributes 1 Bitmap Bits 0. 1 Type de transfert 00 = 00 Commande 01 = Isochrone 10 = par Bloc 11 = Interruption

Bits 2. 7 sont réservés. Si terminaison isochrone : Bits 3. 2 = Type de synchronisation (Mode Iso)

00 = Pas de synchronisation 01 = Asynchrone 10 = Adaptif 11 = Synchrone

Bits 5. 4 = Type d'utilisation (Mode Iso)

00 = Terminaison de données 01 = Terminaison de retour (FeedBack) 10 = Renvoi explicite de terminaison de données 11 = Réservé

4 wMaxPacketSize 2 Nombre Taille maximale du paquet que cette terminaison est capable d'envoyer ou de recevoir

76

6 bIntervale 1 Nombre Intervalle de temps pour interroger les transferts de données de la terminaison. Valeur en nombre de trames. Ignoré pour les terminaisons par Bloc et de commande. Pour le mode Isochrone il doit être égal à 1 et le champ peut valoir de 1 à 255 pour des terminaisons d'interruptions.

bEndpointAddress indique quelle terminaison ce descripteur décrit. bmAttributes précise le type de transfert. Cela peut être soit des transferts de type Commande, Interruption, Isochrone ou par Blocs. Si une terminaison Isochrone est précisée, des attributs supplémentaires peuvent être sélectionnés tel que la synchronisation et les types d'utilisations. wMaxPacketSize indique la taille maximale de charge utile pour cette terminaison. bInterval est utilisée pour préciser cet intervalle d'interrogation de certains transferts. L'unité est exprimée en trames équivalant ainsi à 1 ms pour des appareils basse / pleine vitesse et 125 µs pour des appareils haute vitesse.

77

Les Descripteurs de chaînes de caractères. Les Descripteurs de chaînes fournissent une information lisible pour l'homme et sont optionnels. S'ils ne sont pas utilisés, tout champ d'index de descripteurs de chaînes doit être mis à zéro indiquant qu'il n'y a pas de descripteur de chaîne disponible. Les chaînes de caractères sont codées au format Unicode et les produits peuvent être prévus pour comprendre les diverses langues. L'index de chaîne zéro devra retourner une liste de langues acceptée. 0 bLength 1 Nombre Taille du descripteur en octets(8 octets) 1 bDescriptorType 1 Constan

te Descripteur de chaîne (0x03)

2 wLANGID[0] 2 Nombre Langue acceptée code zéro (par exemple 0x0409 Anglais, U.S.)

4 wLANGID[1] 2 Nombre Langue acceptée code Un (par exemple 0x0C09 Anglais, australien)

n wLANGID[x] 2 Nombre SLangue acceptée code x (par exemple 0x0407 Allemand - Standard)

Le descripteur de chaînes ci-dessus montre le format du descripteur de chaîne zéro. L'Hôte devra lire ce descripteur pour déterminer quelles langues sont disponibles. Si une langue est acceptée, elle peut être référencée en envoyant l'Identification de la langue dans le champ wIndex à la demande de Get Descriptor(String). Toutes les chaînes de caractères à venir tiennent dans le format ci-dessous :

0 bLength 1 Nombre Taille du descripteur en octets 1 bDescriptorType 1 Constan

te Descripteur de chaînes (0x03)

2 bString n Unicode Textes codés unicode

78

Descripteur de classe hub

Décalage Champ Taille Description 0 Desclenght 1 Nombre d’octets du descripteur 1 DescripteorType 1 Type de descripteur= 00 H 2 Nbrports 1 Nombre de port en aval supporté 3 Hubcaracteristics 2 D1-D0 mode de commutation

de l’alimentation 00 commutation groupée 01 commutation sur 1 port 1X pas de commutation

(port toujours alimenté) D2 identification d’une fonction de

commande 0 le hub n’a pas de fonction de commande 1 le hub a une fonction de commande D4-D3 mode de protection d’intensité 00 globale 01 sélective 1x pas de protection D15-D5 réservé

5 Pwron2PwrGood 1 Intervalle de temps par pas de 2 mS 6 Hubcontrcurrent 1 Maximum de courant nécessaire

au contrôleur de hub, par pas de 2 mA 7 DeviceRemovable Dépend

du nombre de ports

Indique si un périphérique est connecté ou pas au port

0 = connecté 1 = non connecté ceci est un tableau

bit 0 réservé bit 1 port 1

bit 2 port 2 etc…. 8 PortPwrCtrlMask Dépend

du nombre de ports

Indique si un port est affecté par une demande de contrôle en mode global

0= affecté 1 = non affecté

ceci est un tableau bit 0 réservé bit 1 port 1

bit 2 port 2 etc….

Pwron2PwrGood : Le logiciel système utilise cette valeur d’intervalle pour déterminer le temps d’attente avant d’accéder au port PortPwrCtrlMask : Si le port n’est pas affecté par une demande de contrôle en mode global, une commande SETPORTFEATURE est nécessaire pour commuter l’alimentation du port

79

Descripteur de transfert

Il contient : • Le type de transfert • Le type de paquet jeton • La direction du transfert • La taille du paquet de données • Le bit de basculement de données • L’adresse du tampon mémoire • L’état d’achèvement

80

Le descripteur de transfert

• F : drapeau de fin 0 = lien valide 1 = lien non valide • Q : 0 = descripteur 1 = tête de queue • PV : première branche du mécanisme • Pointeur de liens : pointe un autre descripteur ou une tête de queue • Longueur actuelle : longueur du transfert • Int : interruption en fin de trame • Iso : sélectionne le descripteur terminal isochrone • Bv : préambule périphérique basse vitesse • Ecpt : nombre d’erreurs détectées dans le descripteur • Ppd : détection paquet suite à une transaction IN • ID : identification IN-OUT • Terminal : terminal cible • D : type de paquet • R : réservé • Longueur maximum : longueur maximale de la donnée = 1280 octets (4FF H) • Pointeur tampon mémoire : pointe le début de la mémoire utilisée pendant la transaction

81

Tête de queue

Elle définit une liste de liens pour les descripteurs de transfert qui ont été mis en file

d ’attente. La tête de queue contient un pointeur pour le premier descripteur de transferts devant être exécuté (élément de lien) et le pointeur de TQ (pointeur de lien)

La TQ a aussi un bit de fin permettant au logiciel de clôturer les transactions de trame.

F : 0 = dernière tête de queue 1 = pointeur valide Q : 1 = Tête de Queue 0 = descripteur de transfert

Les pointeurs : pointent le prochain descripteur PF : bit ignoré

82

D : direction 00 du descripteur de transfert 01 OUT 10 IN 11 ------

S : sélection de la vitesse 0 pleine vitesse 1 basse vitesse K :saut F : 1 = isochrone 0 = interruption – bloc – commande TMP = taille maximale du paquet R= valeur du bit de basculement H = halte, fin de traitement de queue

Descripteur de terminaux d ’interruption

K S

83

CHO = Contrôleur d’Hôte Ouvert A : temporisation d’interruption NT : compteur de trame EC : code d’erreur

Descripteur de transfert isochrone

84

Les Classes et les Sous classes

L’USB défini 5 classes de base : • Les périphériques de classe Audio : son ou source audio temps réel • Les périphériques de classe de communication : périphériques reliés à une ligne

téléphonique (pas à un réseau local) • Les périphériques de classe d’affichage : utilisés pour configurer les écrans sous contrôle

logiciel • Les périphériques de classe interface homme-machine : périphérique manipulé par

l’utilisateur • Les périphériques de classe de stockage de masse : lecteur de disquettes, disque dur,

magnétophone à celles-ci nous pouvons ajouter 4 classes : • Classe image : permettant de visualiser des images • Classe interface physique : utilisation tactile de l’utilisateur • Classe alimentation : périphériques permettant d’alimenter un système • Classe imprimante : permet de stocker une masse d’informations Certaines classes de base possèdent une sous classe Sous classe Audio Code Nom Code protocole Nom du protocole 01 H MIC 8 bits 01 H

02 H Mono Stéréo

02 H MIC 16 bits 01H 02H 03H 04H

Mono Stéréo Quadro Stéréo & Stéréo

03 H Dolby surround 16 bits 02 H Stéréo 04 H IEC958 05 H

06 H IEC958 consommateur IEC958 professionnel

05 H MPEG1 07 H 08 H

Couche 1 Couche 2

06 H AC3 TBD TBD Sous classe de stockage de masse décalage champ taille valeur description 5 interfaceClass 1 class Code classe = 01 H 6 interfaceSubClass 1 subClass 01 H = stockage de masse général

02 H = CD ROM 03 H = magnétophone 04 H = état solide 05 –FE H= réservé

85

Sous classe communication Code protocole

description norme

00 H Non défini Non défini 01 H Commande AT commune V.225ter 02 H Commande modem PSTN V.25bis 04 H Terminal série ISDN V.120 08 H Contrôle DCE V.ib 10 H Contrôle ISDN TA Q.931 20 H Réservé Non défini 40 H Autre standard DCE Non défini 80 H Manufacturier propriétaire de d’un

protocole DCE Non défini

Sous classe affichage Décalage Champ Taille Valeur Description 4 Deviceclass 1 Class Code classe=04 H 5 DeviceSubClass 1 subclass Code sous classe

01 H = CRT 06 H = écran plat 07 H =affichage 3D

86

Les requêtes

Le Paquet d'installation Tout appareil USB doit répondre aux paquets d'installation sur le canal de communication par défaut. Les paquets d'installation sont utilisés pour la détection et configuration de l'appareil et véhiculent des fonctions courantes telles que la mise en place de l'adresse de l'appareil USB, la demande d'un descripteur d'appareil ou la vérification de l'état d'une terminaison. Un hôte USB conforme s'attend à ce que toutes les requêtes soient traitées dans une période maximale de 5 secondes. Il précise aussi des temps plus stricts pour des requêtes particulières : Les requêtes standards d'appareils sans étage de données doivent être accomplies en 50 ms. Les requêtes standards d'appareils avec un étage de données doivent commencer à renvoyer les données 500 ms après la requête.

• Chaque paquet de données doit être envoyé dans les 500 ms de la transmission réussie du paquet précédent.

• L'étage d'état doit être accompli dans les 50 ms après la transmission du dernier paquet de données.

L'instruction SetAdress (qui contient une phase de données) doit traiter l'instruction et retourner l'état dans ces 50 ms. L'appareil a 2 ms pour changer d'adresse avant que

la prochaine requête ne soit envoyée.

87

0 bmRequestTy

pe

1 Bit-Map D7 Direction de transfert de phase de données 0 = Hôte vers l'appareil 1 = Appareil vers Hôte D6..5 Type 0 =00= Standard 1 =01= Classe 2 =10= Constructeur 3 =11= Réservé D4..0 Destinataire 0 = Appareil 1 = Interface 2 = Terminaison 3 = Autre 4..31 = Réservé

1 bRequest 1 Valeur Requête

2 wValue 2 Valeur Valeur

4 wIndex 2 Index ou Décalage Index

6 wLength 2 Compteur Nombres d'octets à transférer s'il y a une

phase de données

Le champ bmRequestType déterminera le sens de la requête, le type de la requête et le destinataire désigné. Le champ bRequest indique la requête formulée. bmRequestType est généralement analysé et l'exécution est raccordée à un numéro d'identificateurs comme un gestionnaire de requête d'un appareil standard, un gestionnaire de requête d'une interface standard, un gestionnaire de requête de terminaison standard, un gestionnaire de requête d'un appareil de classe, etc…. La façon d'exécuter le paquet d'installation vous appartient. D'autres pourraient choisir d'exécuter en premier bRequest puis de déterminer le type et le destinataire basé sur chaque requête.

Les requêtes standards sont communes à tous les appareils USB et seront détaillés dans les prochaines pages. Les requêtes de classe sont communes aux classes de drivers (pilote logiciel). Par exemple, tout appareil étant conforme à la classe HID aura un ensemble commun de requêtes spécifiques de classe. Ils différeront d'un appareil conforme à la classe communication et différeront encore d'un appareil conforme à la mémoire de masse (de grande capacité de stockage). Et pour finir, les requêtes définies par le constructeur. Ce sont des requêtes que vous pouvez attribuer en tant que concepteur d'appareil USB. Elles sont normalement différentes d'un appareil à un autre, mais dépendent de votre réalisation et de votre imagination.

88

Une requête commune peut être dirigée vers des destinataires différents et basée sur les fonctions différentes exécutée par le destinataire. Par exemple une requête standard GetStatus peut être dirigée sur l'appareil, l'interface ou la terminaison. Quand elle est dirigée sur un appareil, ce dernier retourne des drapeaux (flags) indiquant l'état de la station d'activation et si l'appareil est auto-alimenté. Toutefois si la même requête est dirigée sur l'interface il renvoie toujours Zéro, ou bien, si elle était dirigée sur une terminaison, l'appareil retournerait le drapeau Halt pour la terminaison. Les champs wValue et wIndex permettent le passage de paramètres avec la requête. wLength est utilisé pour préciser le nombre d'octets à transférer au cas où il existerait une phase de donnée.

89

Les Requêtes d'appareil standard Il y a actuellement 8 requêtes d'appareil standard, chacune étant détaillée dans le tableau ci-dessous :

bmRequbmestType

bRequest wValue wIndex wLength Données

1000 0000b GET_STATUS (0x00) Zéro Zéro Deux Etat de

l'appareil

0000 0000b CLEAR_FEATURE (0x01)

Sélecteur de fonction Zéro Zéro Acune

0000 0000b SET_FEATURE (0x03)

Sélecteur de fonction Zéro Zéro Aucune

0000 0000b

SET_ADDRESS (0x05)

Addresse de

l'appareil Zéro Zéro Aucune

1000 0000b GET_DESCRIPTOR (0x06)

Type de Descripteur & Index

Zéro ou ID de

Langues

Longueur du

Descripteur

Descripteur

0000 0000b SET_DESCRIPTOR (0x07)

Type de Descripteur & Index

Zéro ou ID de

Langues

Longueur du

Descripteur

Descripteur

1000 0000b GET_CONFIGURATION (0x08) Zéro Zéro 1

Valeur de Configurati

on

0000 0000b SET_CONFIGURATION (0x09)

Valeur de Configurati

on Zéro Zéro Aucune

La requête GetStatus dirigée vers l'appareil retournera 2 octets pendant l'étage de données suivant le format :

D 15

D 14

D 13

D 12

D 11

D 10

D9 D8 D7 D6 D5 D4 D3 D2 D1 D0

Réservé

Activation à

distance

Auto alimenté

90

Si D0 est à 1, ceci indique que l'appareil est auto alimenté. S'il est à 0, l'appareil est alimenté par le bus. Si D1 est à 1, l'activation à distance de l'appareil est validée et ce dernier peut réveiller l'hôte pendant le mode veille. Le bit d'activation à distance peut être positionné par les requêtes SetFeature et ClearFeature grâce à un sélecteur de fonction de DEVICE_REMOTE_WAKEUP(0x01). Les requêtes Clear Feature et Set Feature peuvent être utilisées pour positionner des fonctions booléennes. Quand le destinataire désigné est l'appareil, les 2 seuls sélecteurs de fonctions disponibles sont DEVICE_REMOTE_WAKEUP et TEST_MODE. Test mode permet à l'appareil de présenter diverses conditions. A leur égard, des précisions supplémentaires sont fournies dans la spécification USB, version 2.0. Set Address est utilisé pendant l'énumération pour attribuer une adresse unique à l'appareil USB. L'adresse est précisée dans wValue et peut valoir au maximum 127. Cette requête est unique dans le sens ou l'appareil ne positionnera pas son adresse tant que la phase d'état ne sera pas achevée (voir transfert de commande). Toutes les autres requêtes doivent être terminées avant la phase d'état. Set Descriptor/Get Descriptor est utilisé pour renvoyer le descripteur indiqué dans wValue. Une requête pour le descripteur de configuration retournera le descripteur d'appareil et, tous les descripteurs d'interfaces et de terminaisons dans la même requête.

• Les descripteurs de terminaisons ne peuvent pas être accessibles directement par une

requête de GetDescriptor / SetDescriptor. • Les descripteurs d'interfaces ne peuvent pas être accessibles directement par une

requête de GetDescriptor / SetDescriptor. • Les descripteurs de chaînes incluent une IDentification de langues dans wIndex pour

autoriser le support de plusieurs langues. Get Configuration/Set Configuration est utilisé pour demander ou positionner la configuration de l'appareil actuel. Dans le cas d'une requête GetConfiguration, un octet sera renvoyé pendant la phase de donnée indiquant l'état de l'appareil. Une valeur zéro signifie que l'appareil n'est pas configuré et une valeur différente de zéro indique que l'appareil est configuré. SetConfiguration est utilisé pour valider un appareil. Il doit contenir la valeur de bConfigurationValue du descripteur de configuration voulu dans l'octet de poids faible de wValue pour sélectionner quelle configuration valider.

91

Les Requêtes d'Interface standard La spécification actuelle définit 5 requêtes d'interface standard qui sont détaillées dans le tableau ci-dessous :

bmRequestType

bRequest wValue wIndex wLength Données

1000 0001b GET_STATUS (0x00) Zéro Interface Deux Etat de

l'Interface


Sélecteur de

Fonction Interface Zéro Aucune


Sélecteur de

Fonction Interface Zéro Aucune

1000 0001b GET_INTERFACE (0x0A) Zéro Interface Un

Interface de

remplacement

0000 0001b SET_INTERFACE (0x11)

Positionnement

alternatif Interface Zéro Aucune

wIndex est normalement utilisé pour préciser l'interface de référence pour des requêtes liées à l'interface. Voir son format dans le schéma ci-dessous.

D 15

D 14

D 13

D 12

D 11

D 10

D9 D8 D7 D6 D5 D4 D3 D2 D1 D0

Réservé Numéro d'Interface

Get Status est utilisé pour retourner l'état de l'interface. Une telle requête à l'interface doit renvoyer 2 octets de valeur 0x00, 0x00. ( Les 2 octets sont réservés pour une utilisation future). Les requêtes ClearFeature et SetFeature peuvent être utilisées pour positionner des fonctions booléennes. Quand le destinataire désigné est l'interface, la spécification USB actuelle révision 2 précise qu'il n'y a pas de fonctions d'interface. Get Interface et Set Interface règle le positionnement de l'interface de remplacement qui est décrit plus en détails dans le descripteur d'interface.

92

Les Requêtes de terminaisons standard Les requêtes de terminaisons standard sont au nombre de 4, listées ci-dessous :

bmRequest

Type bRequest wValue Windex wLength Données

1000 0010b GET_STATUS (0x00) Zéro Terminaiso

n Deux Etat de la

Terminaison


Sélecteur de

Fonction

Terminaison Zéro Aucune


Sélecteur de

Fonction

Terminaison Zéro Aucune

1000 0010b SYNCH_FRAME (0x12) Zéro Terminaiso

n Deux Numéro de Trame

Le champ wIndex est normalement utilisé pour préciser la terminaison de référence et la direction pour les requêtes liées à la terminaison. Voir son format dans le schéma ci-dessous.

D 15

D 14

D 13

D 12

D 11

D 10

D9 D8 D7 D6 D5 D4 D3 D2 D1 D0

Réservé Dir Réservé Numéro de Terminaison

GetStatus renvoie 2 octets indiquant l'état (Arrêté/Bloqué) d'une terminaison. Le format des 2 octets renvoyés est illustré ci-dessous.

D 15

D 14

D 13

D 12

D 11

D 10

D9 D8 D7 D6 D5 D4 D3 D2 D1 D0

Réservé Halt

ClearFeature et SetFeature sont utilisés pour positionner les fonctions de la terminaison. Le standard défini actuellement un sélecteur de fonction de terminaison : ENDPOINT_HALT (0x00) qui permet à l'hôte de bloquer et d'effacer une terminaison. Seules les terminaisons autres que la terminaison par défaut sont conseillées pour avoir cette fonctionnalité. Une requête SynchFrame est utilisée pour rapporter une trame de synchronisation de terminaison.

93

Les champs d ’états du port

4 : 0= pas de raz 1= raz 3: 0= normal 1- une condition de surintensité existe 2: 0= pas interruption 1= interruption 1: 0= port validé 1= port inhibé 0 :0= pas de périphérique 1= périphérique présent 9:0=haute vitesse 1=basse vitesse 8: 0= alimentation coupée 1= alimenté

Les champs de modification des ports

0 : 0= pas de changement 1= modification de l ’état de connexion 1 : 0= port non valide 1= port valide 2: indique une reprise du périph. lié au port . Le connecteur a fait suivre le signal de reprise par une inactivité de 3ms pour permettre au périph. de se synchroniser sur le SOF. 0= pas de modification 1 = reprise complète 3 : 0= pas de modification 1= modification 4: initialisé si la raz a été complète. Entraîne l ’init du bit d ’état du port valide et la modification de l ’état d ’interruption. 0= pas de modification 1= modification

94

L ’énumération sous Windows98-XP-2000

1− 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. 2− 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. 3− L'hôte (sous MS Windows) demande les premiers octets du descripteur de périphérique. 4− Après avoir reçu les premiers octets du descripteur de périphérique, l'hôte émet immédiatement un autre reset sur le bus. 5− L'hôte émet maintenant une commande SetAdress, mettant l'appareil dans l'état adressable. 6− L'hôte demande la totalité des octets du descripteur de périphérique. 7−Puis il demande les octets du descripteur de configuration pour déterminer la taille totale. 8− L'hôte demande les octets du descripteur de configuration. 9− L'hôte demande l'un des descripteurs de chaînes s'ils étaient indiqués. A la fin de l 'étape 9, " Windows " demandera un pilote logiciel pour votre périphérique. Il est alors courant de le voir redemander tous les descripteurs avant d'émettre une requête SetConfiguration.

95

Création des descripteurs • Descripteur de périphérique

• Descripteur de configuration • Descripteur d’interface • Descripteur de terminaison • Descripteur chaîne de langue • Manufacturier

Initialisation • Définition variables et Cst • Initialisation du PDIUSBD11 • Configuration de ADCON1

Configuration du PDIUSBD11 • Validation et adresse • Inintialisation des commandes • Création d’une zone tampon

Lecture du registre d’interruptions • Traitement du jeton

IN • Traitement du jeton

OUT • Blocage des

terminaisons

Traitement des requêtes

• Requêtes appareils standards • Requêtes interfaces standards • Requêtes terminaisons standards • CAN

Lecture/écriture des données

Organigramme de haut niveau du programme

96

Le programme

# include <pic.h> inclure le fichier librairie du PIC # include < stdio.h> inclure le fichier des entrées/sorties # include <string.h> inclure le fichier chaînes de caractères # include < usbfull.h> inclure le fichier usbfull.h

Création du descripteur de périphérique

{ Sizeof (USB_DEVICE_DESCRIPTOR), Taille du descripteur, nombre d’octets=18

TYPE_DEVICE_DESCRIPTOR Type de descripteur, code =0x01 soit descripteur de périphérique 0x0110, numéro de la spécification USB = USB1.2 0, code classe 0, code sous classe 0, code protocole 8, taille maximale du paquet du terminal 0=8 octets 0x04B4, identificateur vendeur 0x0002, identificateur produit (exemple thermomètre) 0x0000, numéro de version du périphérique 1, Index du descripteur de chaîne du fabriquant 0, Index du descripteur de chaîne du produit 0, Index du descripteur de chaîne du numéro de série 1 nombre de configurations = 1 } ;

97

Création du descripteur de configuration

{ Sizeof (USB_CONFIGURATION-DESCRIPTOR), Taille du descripteur en octets =9 octets

TYPE _CONFIGURATION-DESCRIPTOR, Type de descripteur, code=02

SIZEOF (usb_config_data), Longueur totale de la donnée en octets 1, nombre d’interface =1 1, argument de sélection de la configuration 0, index du descripteur de chaîne de caractères

décrivant la configuration

0x80, périphérique alimenté par bus, pas de télécommande 0x32 alimentation maximale =100mA } ;

98

Création du descripteur d’interface

{ Sizeof (USB_INTERFACE_DESCRIPTOR), Taille du descripteur en octets =9 TYPE_INTERFACE_DESCRIPTOR’ Type de descripteur, code = 0x4 0, Nombre d’interfaces =0 0, valeur utilisée pour sélectionner la configuration de remplacement 2, nombre de terminaux =2 0xFF, code classe =FF, c’est un vendeur spécifique 0xFF, code sous classe =FF, c’est une classe spécifique 0xFF, code protocole =FF, c’est un protocole spécifique 0, index du descripteur de chaîne décrivant l’interface };

99

CRÉATION DU DESCRIPTEUR DE TERMINAL

{ SIZEOF (USB_ENDPOINT_DESCRIPTOR) taille du descripteur en octets =7 TYPE_ENDPOINT_DESCRIPTOR type de descripteur, code =0x05 0x01, Terminal 1 en sortie (out) 0x02, transfert par blocs 0x0008, taille maximale du paquet =8 octets 0x00 l’intervalle de temps pour les transferts de bloc est ignoré }, { SIZEOF(USB_ENDPOINT_DESCRIPTOR) taille du descripteur en octets =7 TYPE_ENDPOINT_DESCRIPTOR, type de descripteur, code =0x05 0x81, Terminal 1 en entrée (IN) 0x02, transfert par blocs 0x0008, taille maximale du paquet =8 octets 0x00 l’intervalle de temps pour les transferts de blocs est ignoré }; Nous verrons un peu plus loin, la création d’une mémoire tampon circulaire de 80 octets. Les données lues en sortie sont stockées dans cette mémoire. L’envoi d’un paquet IN au terminal permettra de lire 8 octets dans la mémoire.

100

Descripteur de chaîne de langue

0 blength 1 nombre Taille du descripteur en octets 1 bDescriptor Type 1 constante Descripteur de chaîne (0x03) 2 wLANGID(0) 2 nombre Langue accepte code zéro 4 wLANGID(1) 2 nombre Langue acceptée code Un n wLANGID(x) 2 nombre langue acceptée codex LANGID_DESCRIPTOR LANGID_Descriptor ={ Création du descripteur de chaîne de langue Sizeof (LANGID_DESCRIPTOR), Taille du descripteurde chaîne en octets=8 TYPE_STRING_DESCRIPTOR, Type de descripteur de chaîne, code =0x03 0x0409 langue =anglais }; (voir la documentation sur le CD)

Décalage

Champ Taille Valeur Description

101

Création du descripteur du manufacturier

Const. MANUFACTURER_DESCRIPTOR Manufacturer_Descriptor = { Sizeof (MANUFACTURER_DESCRIPTOR), Taille du descripteur en octets =8 TYPE_STRING_DESCRIPTOR type de descripteur de chaîne, code =03 * B\0e\0y\0o\0n\0d\0 \0L\0o\0g\0i\0c\0* Chaîne de caractères du manufacturier en unicode UNICODE * / };

102

#define MAX_BUFFER_SIZE 80 création du tampon mémoire de 80 octets bank1 unsigned char circularbuffer[MAX_BUFFER_SIZE]; création de unsigned char inpointer; variables et d’un pointeur unsigned char outpointer; unsigned char *pSendBuffer; unsigned char BytesToSend; unsigned char CtlTransferInProgress; unsigned char DeviceAddress; unsigned char DeviceConfigured; #define PROGRESS_IDLE 0 constantes #define PROGRESS_ADDRESS 3 void main (void) { TRISB = 0x03; /* Int & Suspend Inputs */ configuration du port B B0 = entrée d’interruption et B1 = entrée en suspension RB3 = 1; /* Device Not Configured (LED) */la led est bloquée RB2 = 0; /* Reset PDIUSBD11 */ raz du PDIUSBD11 InitUART(); envoie sur C6 le message d’initialisation printf("Initialising\n\r"); et initialisation de l’interface i2C I2C_Init(); RB2 = 1; /* Bring PDIUSBD11 out of reset */ plus de RAZ ADCON1 = 0x80; /* ADC Control - All 8 Channels Enabled, */ /* supporting upgrade to 16F877 */ programmation du registre ADCON1 du pic, ici le convertisseur analogique digital. Nous effectuons une justification à droite USB_Init(); printf("PDIUSBD11 Ready for connection\n\r"); initialisation du circuit et affichage du message prêt pour la connexion while(1) D11GetIRQ(); une fois que tout ceci est configué, nous

utilisons une boucle infinie dans laquelle nous interrogeons D11GetIRQ qui traite les requêtes IRQ

}

103

Dans la suite du programme, nous allons initialiser le PDIUSBD11. ( voir la documentation sur le CD) Celui-ci est vu comme un système à 2 adresses ,une adresse Command/data Et une adresse LSBit spécifiant les opérations de lecture et d’écriture. Afin de respecter la façon dont le circuit est vu, nous allons créer un ensemble de variables permettant d’aller lire/écrire des données dans une mémoire tampon au moyen d’un pointeur. De plus nous allons créer un tableau représentatif des 2 adresses de 8 octets. La partie 0 étant pour l’adresse command/data (octet 1) Et la partie 1 pour le LSBit (octet 2). L’adresse command/data est considérée comme suit : Enable (Validation) 7 6 5 4 3 2 1 0 address (adresse) Si validation =0 le hub du circuit est inibé. Si validation =1 le circuit est vu comme un descripteur La zone adresse permet d’initialiser l’adresse à 0 jusqu’à ce que l’hôte initialise une demande SET ADDRESS DEVICE REQUEST durant l’énumération.

104

La validation de commande est à 0 et l’adresse est à 0 par défaut, Autrement dit nous avons 00 dans la mémoire command/data. Première étape : command SETENDPOINTENABLE Les bits 2 à 7 et 0 sont réservés 7 6 5 4 3 2 1 0 Le bit 1 est le générique du

terminal validé Lorsque command/data est validé seul le canal par défaut est validé, Il correspond aux terminaux 2&3. Durant l’énumération le périphérique enverra à l’hôte un générique sous la forme d’un descripteur de terminal. Par la suite l’hôte enverra une demande SET CONFIGURATION. Pour l’instant voyons le générique : Numéro de terminal

Index terminal

Type de terminal Direction

Direction

0 2-3 Control/défaut Out in

1 5-4 Générique Out In

2 6-7 idem idem Idem

3 8-9 Idem Idem Idem

105

SET MODE (octet 1 configuration) 7 6 5 4 3 2 1 0 Embedded Function Mode

X

X

Soft Connect

Debug Mode

Clock Running

No lazy Clock

Remote Wakeup

Nous verrons dans la suite du logiciel que la valeur placée ici est 97 soit : Mode fonction embedded (mode contrôle), soft connect, pas de debug le reste est à 1. Fonction embedded : Le circuit utilise ce bit pour des fonctions de contrôles multiples. Soft connect : Ceci validera les résistances de pull up sur D+ reliées à Vbus Clock running : Assure que la phase et l’horloge sont verrouillées en mode suspension No lazy clock : Si à 0 assure que l’horloge ne commute pas en mode lazy (- 30Khz) Remote wakeup : Valide le mode réveil distant, une raz bus validera cette fonction Debug mode : à 0 évite la diffusion d ‘erreurs SET MODE (octet 2 clock divider) 7 6 5 4 3 2 1 0 Xxx L’octet 2 initialise la fréquence horloge, celle-ci peut être soit 4 Mhz par défaut Ou nous pouvons souhaiter ne pas utiliser l’horloge en ignorant cet octet. Dans le logiciel la valeur appliquée est 0B soit 00001011. Le bit 3 étant à 1 impose une horloge à 4Mhz.

X

X 0 0 0 0 1 1 X X Clock divider

106

Création de la zone tampon Permettant de configurer le PDIUSBD11

void USB_Init(void) { unsigned char Buffer[2]; création d’un tableau de 2 octets

correspondants aux 2 octets command/data(octet 0)et LSBit du circuit (octet 1)

/* Disable Hub Function in PDIUSBD11 */ Buffer[0] = 0x00; D11CmdDataWrite(D11_SET_HUB_ADDRESS, Buffer, 1); Enable de command/data = 0 soit hub du circuit inhibé Adresse = 0 via le buffer écrit sur un octet /* Set Address to zero (default) and enable function */ Buffer[0] = 0x80; D11CmdDataWrite(D11_SET_ADDRESS_ENABLE, Buffer, 1); Enable de command/data =1 ceci valide l’adresse 0 par défaut et permet La création des descripteurs du circuit Set ADDress Enable du PDIUSBD11 7 6 5 4 3 2 1 0

/* Enable function generic endpoints */ Buffer[0] = 0x02; D11CmdDataWrite(D11_SET_ENDPOINT_ENABLE, Buffer, 1); Validation de la fonction générique du PDIUSBD11 /* Set Mode - Enable SoftConnect */ Buffer[0] = 0x97; /* Embedded Function, SoftConnect, Clk Run, No LazyClk, Remote Wakeup */ Mode fonction embedded , soft connect , pas de mode debug Mise en route de l’horloge,pas de lazy clock , validation du mode réveil distant Buffer[1] = 0x0B; /* CLKOut = 4MHz */ D11CmdDataWrite(D11_SET_MODE, Buffer, 2); Octet 1 du tampon = 00001011 . Le bit 3 étant à 1 impose une horloge à 4 Mhz. Nous écrivons sur SET MODE via le buffer (1) }

Enable address

107

Lecture du registre d’interruptions La suite du programme constiste en la lecture du registre d’interruptions . Il comprend 2 octets : Octet 1 7 6 5 4 3 2 1 0 0 0 0 0 0 0 0 0 Terminal Index 7

Terminal Index 6

Terminal Index 5

Terminal Index 4

Contrôle en entrée

Contrôle En sortie

Réservé réservé

Octet 2 7 6 5 4 3 2 1 0 0 0 0 0 0 0 0 0 réservé Bus reset réservé réservé réservé réservé Terminal

Index 8 Terminal Index 9

La lecture de ce registre entraîne l’exécution d’une interruption correspondant à un bit actif à 1 . Suite à la lecture de la dernière transaction, le registre est remis à zéro. Dans le cas du PDIUSBD11, les lignes d’interruptions sont placées à l’état 0 en cas d’interruption. Elles conservent cet état jusqu’à la raz des interruptions. Dans la suite du programme correspondant à la lecture du registre d’interruptions, nous venons lire les intrruptions de l’octet 2 pour vérifier si il y a un reset bus. Puis, nous venons lire l’octet 1 pour vérifier si le terminal reçoit une interruption IN ou OUT. Si une requête est faite par l’hôte et qu’il veut recevoir une donnée, le pic enverra un paquet de 8 octets au PDI . Comme le bus est contrôlé par l’hôte, le PDI ne peut écrire les données quand il le désire, aussi , il les stocke et attend un jeton IN de l’hôte . C’est le premier if Quand le PDI reçoit un jeton IN, il provoque une interruption. Cela laisse un temps suffisant pour recharger le prochain paquet. C’est le rôle de la fonction WriteBufferToEndPoint . Deuxième if Les terminaux 1 et 2 en IN /OUT sont mis en place pour lire/écrire des données par blocs à destination/provenance du tampon mémoire circulaire de 80 octets occupant toute la banque 1 de la RAM du pic. Afin de parcourir le tampon nous utilisons le pointeur déclaré plus haut et un compteur . L’un pointant les cases et l’autre comptant le nombre d’octets . Quand l’adresse du pointeur correspond au nombre de cases le tampon a fini d’être parcouru.

108

void D11GetIRQ(void) { unsigned short Irq; variable de 1 bit non signée unsigned char Buffer[1]; tableau de 1 octet do { /* Read Interrupt Register to determine source of interrupt */ D11CmdDataRead(D11_READ_INTERRUPT_REGISTER, (unsigned char *)&Irq, 2); lecture du registre d’interruptions afin d’en déterminer la source if (Irq) printf("Irq = 0x%X: ",Irq); si C’est une interruption , l’afficher suivant le format défini La fonction main() continue d'appeler D11GetIRQ en boucle. Cette fonction lit les registres d'interruption du PDIUSBD11 pour établir si des interruptions sont en suspens. Si c'est le cas, elle les traitera, sinon elle continuera sa boucle.

if (Irq & D11_INT_BUS_RESET) { si C’est une interruption reset bus printf("Bus Reset\n\r"); afficher le message et initialiser l’USB USB_Init(); } if (Irq & D11_INT_EP0_OUT) { Si c’est un jeton OUT terminal 0 printf("EP0_Out: "); afficher le message et procéder Process_EP0_OUT_Interrupt(); au traitement } if (Irq & D11_INT_EP0_IN) { si c’est un jeton IN du terminal 0 printf("EP0_In: \n\r"); afficher le message if (CtlTransferInProgress == PROGRESS_ADDRESS) { D11CmdDataWrite(D11_SET_ADDRESS_ENABLE,&DeviceAddress,1); D11CmdDataRead(D11_READ_LAST_TRANSACTION + D11_ENDPOINT_EP0_IN, Buffer, 1); CtlTransferInProgress = PROGRESS_IDLE; } else { D11CmdDataRead(D11_READ_LAST_TRANSACTION + D11_ENDPOINT_EP0_IN, Buffer, 1); WriteBufferToEndPoint(); } } Si un paquet IN est en cours nous envoyons l’adresse du périphérique à la place de l’adresse par défaut et nous lisons la prochaine transaction. Sinon, nous lisons la prochaine transaction et chargeons les 8 premiers octets du tampon.

109

if (Irq & D11_INT_EP1_OUT) si c’est un jeton OUT terminal 1 { printf("EP1_OUT\n\r"); afficher le message D11CmdDataRead(D11_READ_LAST_TRANSACTION + D11_ENDPOINT_EP1_OUT, Buffer, 1); Lecture de la dernière transaction , retour de l’état de la dernière transaction du terminal demandé bytes = D11ReadEndpoint(D11_ENDPOINT_EP1_OUT, Buffer); Lecture des données à transférer à placer dans la mémoire circulaire for (count = 0; count < bytes; count++) { tant que le compteur < nombre de données inc circularbuffer[inpointer++] = Buffer[count]; incrémenter le compteur ainsi que le

pointeur de la mémoire if (inpointer >= MAX_BUFFER_SIZE) inpointer = 0; si le pointeur mémoire arrive à la } fin celle-ci le pointeur = 0 loadfromcircularbuffer(); chargement de la mémoire tampon //Kick Start démarrage } if (Irq & D11_INT_EP1_IN) { si c’est un jeton IN terminal 1 printf("EP1_IN\n\r"); l’afficher D11CmdDataRead(D11_READ_LAST_TRANSACTION + D11_ENDPOINT_EP1_IN, Buffer, 1); Lecture des données à transférer à placer dans la mémoire circulaire loadfromcircularbuffer(); chargement de la mémoire tampon } EP1 OUT et EP1 In sont mis en place pour lire et écrire des données par Blocs à destination et en provenance d'un tampon mémoire circulaire. Le tampon mémoire circulaire a été défini plus haut dans le code comme comportant 80 octets de long et prenant toute la banque1 de la RAM du 16F876.

110

Rappel sur les transferts de blocs

IN : quand l’hôte est prêt à recevoir des données en bloc, il émet un jeton IN. Si la fonction reçoit un jeton IN avec une erreur, il ignore le paquet. Si le jeton est reçu correctement, la fonction peut soit répondre : • un paquet DATA contenant les données en bloc à envoyer • un paquet STALL signalant que que la terminaison a eu une erreur • un paquet NAK signalant à l’hôte que la terminaison travaille, mais provisoirement n’a

pas de données à envoyer OUT : quand l’hôte veut envoyer à la fonction un paquet de données en bloc, il émet un jeton OUT suivi d’un paquet DATA contenant les données en bloc. Si le jeton OUT ou le paquet DATA est altéré, la fonction ignore le paquet. Si le tampon de terminaison est : Vide : la fonction émet un ACK pour prévenir l’hôte qu’il a reçu correctement les données Plein : la fonction re tourne un NAK Si la terminaison a eu une erreur et que son bit d’arrêt a été positionné, elle retourne un STALL

111

if (Irq & D11_INT_EP2_OUT) { vérification si terminal 2 est en sortie printf("EP2_OUT\n\r"); D11CmdDataRead(D11_READ_LAST_TRANSACTION + D11_ENDPOINT_EP2_OUT, Buffer, 1); Lecture de l’état de la dernière transaction et de la sortie du terminal 2 via le buffer Buffer[0] = 0x01; /* Stall Endpoint */ D11CmdDataWrite(D11_SET_ENDPOINT_STATUS + D11_ENDPOINT_EP2_OUT, Buffer, 1); } blocage du terminal 2 en sortie via la commande SET_ENDPOINT_STATUS if (Irq & D11_INT_EP2_IN) { vérification si terminal 2 est en entrée printf("EP2_IN\n\r"); D11CmdDataRead(D11_READ_LAST_TRANSACTION + D11_ENDPOINT_EP2_IN, Buffer, 1); Lecture de l’état de la dernière transaction et de l’entrée du terminal 2 via le buffer Buffer[0] = 0x01;/* Stall Endpoint */ D11CmdDataWrite(D11_SET_ENDPOINT_STATUS + D11_ENDPOINT_EP2_IN, Buffer, 1); } blocage du terminal 2 en entrée via la commande SET_ENDPOINT_STATUS if (Irq & D11_INT_EP3_OUT) { vérification si terminal 3 est en sortie printf("EP3_OUT\n\r"); D11CmdDataRead(D11_READ_LAST_TRANSACTION + D11_ENDPOINT_EP3_OUT, Buffer, 1); Lecture de l’état de la dernière transaction et de la sortie du terminal 2 via le buffer Buffer[0] = 0x01; /* Stall Endpoint */ D11CmdDataWrite(D11_SET_ENDPOINT_STATUS + D11_ENDPOINT_EP3_OUT, Buffer, 1); } blocage du terminal 3 en sortie via la commande SET_ENDPOINT_STATUS if (Irq & D11_INT_EP3_IN) { vérification si terminal 3 est en entrée printf("EP3_IN\n\r"); D11CmdDataRead(D11_READ_LAST_TRANSACTION + D11_ENDPOINT_EP3_IN, Buffer, 1); Lecture de l’état de la dernière transaction et de l’entrée du terminal 3 via le buffer Buffer[0] = 0x01; /* Stall Endpoint */ D11CmdDataWrite(D11_SET_ENDPOINT_STATUS + D11_ENDPOINT_EP3_IN, Buffer, 1); } blocage du terminal 3 en entrée via la commande SET_ENDPOINT_STATUS } while (Irq); boucler tant qu’il y a des IRQ } Les terminaisons 2 et 3 ne sont pas utilisés pour l'instant, aussi nous les bloquons si elles reçoivent une donnée quelconque. Le PDIUSBD11 a une commande SetEndpointEnable qui peut être utilisée pour valider ou dé valider la fonction de terminaison générique (n'importe qu'elle terminaison autre que le canal de communication par défaut).

112

Read Last Transaction Status (PDIUSBD11) 7 6 5 4 3 2 1 0 0 0 0 0 0 0 0 0 Previous Status Not read

Data 0/1 paquet

Setup paquet

Data Receive Transmit sucess

Cette commande retourne un octet montrant la dernière transaction du terminal demandé. Set Endpoint Status (PDIUSBD11) 7 6 5 4 3 2 1 0 0 0 0 0 0 0 0 0 Reserved Reserved Reserved Reserved Reserved Reserved Reserved stalled Cette commande est utilisée pour bloquer les terminaux. Ici nous utilisons un tampon buffer(0) = 0x01 Le bit Stalled est à 1 , cequi entraîne que le terminal appelé est bloqué

Error Code

113

Le Paquet d'installation Tout appareil USB doit répondre aux paquets d'installation sur le canal de communication par défaut. Les paquets d'installation sont utilisés pour la détection et configuration de l'appareil et véhiculent des fonctions courantes telles que la mise en place de l'adresse de l'appareil USB, la demande d'un descripteur d'appareil ou la vérification de l'état d'une terminaison. Un hôte USB conforme s'attend à ce que toutes les requêtes soient traitées dans une période maximale de 5 secondes. Il précise aussi des temps plus stricts pour des requêtes particulières : Les requêtes standards d'appareils sans étage de données doivent être accomplies en 50 ms. Les requêtes standards d'appareils avec un étage de données doivent commencer à renvoyer les données 500 ms après la requête.

• Chaque paquet de données doit être envoyé dans les 500 ms de la transmission réussie du paquet précédent.

• L'étage d'état doit être accompli dans les 50 ms après la transmission du dernier • paquet de données.

L'instruction SetAdress (qui contient une phase de données) doit traiter l'instruction et retourner l'état dans ces 50 ms. L'appareil a donc 2 ms pour changer d'adresse avant que la prochaine requête ne soit envoyée.

Décalage Champ Taill

e Valeur Description

0 bmRequestType 1 Bit-Map D7 Direction de transfert de phase de données 0 = Hôte vers l'appareil 1 = Appareil vers Hôte D6..5 Type 0 =00= Standard 1 =01= Classe 2 =10= Constructeur 3 =11= Réservé D4..0 Destinataire 0 = Appareil 1 = Interface 2 = Terminaison 3 = Autre 4..31 = Reservé

1 bRequest 1 Valeur Requête

2 wValue 2 Valeur Valeur

4 wIndex 2 Index ou Décalage Index

6 wLength 2 Compteur Nombres d'octets à transférer s'il y a une phase de données

114

Le champ bmRequestType déterminera le sens de la requête, le type de la requête et le destinataire désigné. Le champ bRequest indique la requête formulée. bmRequestType est généralement analysé et l'exécution est raccordée à un numéro d'identificateurs comme un gestionnaire de requête d'un appareil standard, un gestionnaire de requête d'une interface standard, un gestionnaire de requête de terminaison standard, un gestionnaire de requête d'un appareil de classe, etc…. La façon d'exécuter le paquet d'installation vous appartient. D'autres pourraient choisir d'exécuter en premier bRequest puis de déterminer le type et le destinataire basé sur chaque requête. Les requêtes standards sont communes à tous les appareils USB . Les requêtes de classe sont communes aux classes de pilote . Par exemple, tout appareil étant conforme à la classe HID aura un ensemble commun de requêtes spécifiques de classe. Ils différeront d'un appareil conforme à la classe communication et différeront encore d'un appareil conforme à la mémoire de masse (de grande capacité de stockage). Et pour finir, les requêtes définies par le constructeur. Ce sont des requêtes que vous pouvez attribuer en tant que concepteur d'appareil USB. Elles sont normalement différentes d'un appareil à un autre, mais dépendent de votre réalisation et de votre imagination. Une requête commune peut être dirigée vers des destinataires différents et basée sur les fonctions différentes exécutée par le destinataire. Par exemple une requête standard GetStatus peut être dirigée sur l'appareil, l'interface ou la terminaison. Quand elle est dirigée sur un appareil, ce dernier retourne des drapeaux (flags) indiquant l'état de la station d'activation et si l'appareil est auto - alimenté. Toutefois si la même requête est dirigée sur l'interface il renvoie toujours Zéro, ou bien si elle était dirigée sur une terminaison, l'appareil retournerait le drapeau Halt pour la terminaison. Les champs wValue et wIndex permettent le passage de paramètres avec la requête. wLength est utilisé pour préciser le nombre d'octets à transférer au cas où il existerait une phase de donnée.

115

La première chose à faire est de déterminer si le paquet reçu sur EP0 est un paquet de données ou un paquet d'installation. Un paquet d'installation contient une requête telle que GetDescriptor, tandis qu'un paquet de données contient des données d'une requête précédente. Cependant, la plupart des requêtes n'envoient pas des paquets de données provenant de l'hôte vers l'appareil. La seule requête qui le réalise est SET_DESCRIPTOR mais elle est rarement mise en œuvre. void Process_EP0_OUT_Interrupt(void) { unsigned long a; définition d’un entier 16 bits non signé unsigned char Buffer[2]; création d’un tableau de 2 octets USB_SETUP_REQUEST SetupPacket; demande du paquet d’installation /* Check if packet received is Setup or Data - Also clears IRQ */ vérifier si le paquet reçu est un paquet d’installation ou un paquet de données et RAZ des IRQ D11CmdDataRead(D11_READ_LAST_TRANSACTION + D11_ENDPOINT_EP0_OUT, &SetupPacket, 1); pour cela nous lisons la dernière

requête et la sortie du terminal 0 if (SetupPacket.bmRequestType & D11_LAST_TRAN_SETUP) { si dans la dernière requête il n’y avait pas de données alors , c’est un paquet d’installation /* This is a setup Packet - Read Packet */ D11ReadEndpoint(D11_ENDPOINT_EP0_OUT, &SetupPacket); Lecture de la sortie du terminal 0 et du paquet d’installation /* Acknowlegde Setup Packet to EP0_OUT & Clear Buffer*/ D11CmdDataWrite(D11_ACK_SETUP, NULL, 0); D11CmdDataWrite(D11_CLEAR_BUFFER, NULL, 0); /* Acknowlegde Setup Packet to EP0_IN */ D11CmdDataWrite(D11_ENDPOINT_EP0_IN, NULL, 0); D11CmdDataWrite(D11_ACK_SETUP, NULL, 0); un paquet d'installation ne peut pas être Non ACQuité(NAKed) ou Bloqué (STALLed). Quand le PDIUSBD11 reçoit un paquet d'installation, il vide le tampon EP0 IN et invalide les commandes du tampon mémoire de validation et celles du tampon mémoire d'effacement. Cela garantit que le paquet d'installation est acquitté par le microcontrôleur en envoyant un acquittement de commande d'installation à EP0 IN et EP0 OUT avant qu'une commande de validation ou d 'effacement de tampon mémoire ne soit effective. La réception d'un paquet d'installation débloquera aussi une terminaison de commande bloquée (STALLed).

116

Une fois le paquet installé dans la mémoire et le paquet d'installation validé, nous allons analyser la requête en commençant par son type. A ce moment nous ne nous intéressons pas à la direction, aussi nous masquons ce bit. Les 3 requêtes que tout appareil doit traiter sont la requête standard d'appareil, la requête standard d'interface et les requêtes standard de terminaisons. Nous fournissons notre fonctionnalité (lecture des entrées analogiques) par la requête constructeur, aussi nous ajoutons un type d'instruction pour les requêtes standard de constructeur. Si votre appareil supporte une spécification de classe USB, alors vous pouvez aussi avoir besoin d'ajouter des cas pour la requête de classe d'appareil, la requête de classe d'interface et/ou de la requête de classe de terminaison. Les Requêtes d'appareil standard

bmRequestType bRequest wValue wIndex wLength Données

1000 0000b GET_STATUS (0x00) Zéro Zéro Deux Etat de l'appareil

0000 0000b CLEAR_FEATURE (0x01) Sélecteur de fonction Zéro Zéro Acune

0000 0000b SET_FEATURE (0x03) Sélecteur de fonction Zéro Zéro Aucune

0000 0000b SET_ADDRESS (0x05) Addresse de

l'appareil Zéro Zéro Aucune

1000 0000b GET_DESCRIPTOR (0x06) Type de

Descripteur & Index

Zéro ou ID de Langues

Longueur du Descripteur Descripteur

0000 0000b SET_DESCRIPTOR (0x07) Type de

Descripteur & Index

Zéro ou ID de Langues

Longueur du Descripteur Descripteur

1000 0000b GET_CONFIGURATION (0x08) Zéro Zéro 1 Valeur de

Configuration

0000 0000b SET_CONFIGURATION (0x09)

Valeur de Configuration Zéro Zéro Aucune

La requête GetStatus dirigée vers l'appareil retournera 2 octets pendant l'étage de données suivant le format :

D15 D14 D13 D12 D11 D10 D9 D8 D7 D6 D5 D4 D3 D2 D1 D0

Réservé

Activation à

distance

Auto

alimenté

117

Cet état est écrit en utilisant la mémoire tampon déclarée un peu plus haut. Ici buffer (0) = 01 et buffer (1) = 00 Buffer (0) pour le premier octet et buffer (1) pour le deuxième octet Nous venons de placer la valeur binaire 1 sur le bit 0 de l’octet 1 et la valeur binaire 0 Sur le bit 1 de l’octet 1.En effet wLenght est sur 2 octets. Ceci implique : appareil auto alimenté et pas de commande à distance Explication :

Si D0 est à 1, ceci indique que l'appareil est auto alimenté. S'il est à 0, l'appareil est alimenté par le bus. Si D1 est à 1, l'activation à distance de l'appareil est validée et ce dernier peut réveiller l'hôte pendant le mode veille. Le bit d'activation à distance peut être positionné par les requêtes SetFeature et ClearFeature grâce à un sélecteur de fonction de DEVICE_REMOTE_WAKEUP(0x01). Les requêtes Clear Feature et Set Feature peuvent être utilisées pour positionner des fonctions booléennes. Quand le destinataire désigné est l'appareil, les 2 seuls sélecteurs de fonctions disponibles sont DEVICE_REMOTE_WAKEUP et TEST_MODE. Test mode permet à l'appareil de présenter diverses conditions. A leur égard, des précisions supplémentaires sont fournies dans la spécification USB, version 2.0. Set Address est utilisé pendant l'énumération pour attribuer une adresse unique à l'appareil USB. L'adresse est précisée dans wValue et peut valoir au maximum 127. Cette requête est unique dans le sens ou l'appareil ne positionnera pas son adresse tant que la phase d'état ne sera pas achevé (voir transfert de commande). Toutes les autres requêtes doivent être terminées avant la phase d'état. Set Descriptor/Get Descriptor est utilisé pour renvoyer le descripteur indiqué dans wValue. Une requête pour le descripteur de configuration retournera le descripteur d'appareil et, tous les descripteurs d'interfaces et de terminaisons dans la même requête.

Les requêtes Clear Feature et Set Feature sont utilisées par la suite afin de positionner les Fonctions DEVICE_REMOTE_WAKEUP et TEST_MODE . Nous signifions qu’il n’y a ni réveil distant ni mode test .

118

/* Parse bmRequestType */ analyse du type de demande switch (SetupPacket.bmRequestType & 0x7F) { selon le type de demande Case Standard_Device-Request cas d’une demande standard Printf (*Standard Device Request *) ; affiche le message Switch (SetupPaquet.bRequest ) { selon le type de requête de la colonne bRequest Case GET_STATUS : cas GET_STATUS /*Get STATUS Request to Device should return*/ la demande Get STATUS au /*Remote Wakeup and self powered status */ périphérique devra retourner le réveil

distant et l’état d’alimentation Buffer (0) = 0x01; nous écrivons la valeur binaire 1 dans le

Buffer(0) Buffer(1) = 0x00; nous écrivons la valeur binaire 0 dans le

Buffer(1) D11WriteEndpoint ( D11_ENDPOINT_EP0_IN, Buffer ,2 ); Nous venons écrire sur le terminal 0 qui est en entrée . Via le tampon et sur 2 octets les Valeurs 01 pour l’octet 1 et 00 pour l’octet 2 . Nous signifions qu’il n’y a pas de réveil distant et que le périphérique est auto alimenté.( Le 2 en fin de ligne est pour indiquer que c’est par rapport aux 2 octets de wLenght) Break ; fin du cas GET_STATUS Case CLEAR_FEATURE cas CLEAR_FEATURE ou Case SET_FEATURE cas SET_FEATURE /*We don’t support DEVICE_REMOTE_WAKEUP OR TEST_MODE*/

pas de réveil distant ni de mode test ErrorsStallControlEndpoint (); en fonction des caractéristiques écrites

plus haut , l’appareil retourne une erreur de requête USB au terminal en envoyant un paquet Stall

Break ; fin des 2 cas Case SET_ADDRESS : cas SET_ADDRESS Printf (« Set ADDress\n\r « ) affiche le message suivant le format Précisé DeviceAddress = SetupPaquet.wValue ⏐0x80;

119

D11WriteEnpoint (D11_EndPoint_EP0_IN,NULL, 0); CtlTranfertInProgress = PROGRESS_ADDRESS; Break ; Set Address est utilisé pendant l'énumération pour attribuer une adresse unique à l'appareil USB. L'adresse est précisée dans wValue et peut valoir au maximum 127 La commande SetAddress est la seule commande qui continue d'être traitée après l'étape d'état. Toutes les autres commandes doivent finir le traitement avant l'étape d'état. L'adresse de l'appareil est lue puis combinée par un OU logique avec 0x80 et ensuite stockée dans une variable DeviceAddress. La combinaison par un OU logique avec 0x80 avec le bit le plus significatif indiquant si l'appareil est validé ou non est spécifique au PDIUSBD11. Un paquet de longueur nul est renvoyé comme état à l'hôte, indiquant que la commande est achevée. Toutefois l'hôte doit envoyer un jeton IN, récupérer le paquet de longueur nul et délivrer un ACK avant que l'on puisse changer d'adresse. Autrement l'appareil ne constatera peut être jamais que le jeton IN a été envoyé à l'adresse par défaut. L'achèvement de l'étape d'état est signalé par une interruption sur EP0 IN. Afin de différencier une réponse à SetAddress et une interruption normale EP0_IN, nous positionnons une variable, CtlTransferInProgress à PROGRESS_ADDRESS. Le programme de traitement de EP0 IN prévoit une vérification de CtlTransfertInProgress. Si elle équivaut à PROGRESS_ADDRESS la commande Set Address Enable est alors délivrée au PDIUSBD11 et CtlTransferInProgress est positionné à PROGRESS_IDLE. L'hôte donne 2ms à l'appareil pour changer d'adresse avant que la prochaine commande ne soit envoyée.

120

case GET_DESCRIPTOR: cas GET_DESCRIPTOR GetDescriptor(&SetupPacket); break; Get Descriptor est utilisé pour renvoyer le descripteur indiqué dans wValue. case GET_CONFIGURATION: cas GET_CONFIGURATION D11WriteEndpoint(D11_ENDPOINT_EP0_IN, &DeviceConfigured, 1); break; wLenght =1 explique le 1 case SET_CONFIGURATION: cas SET_CONFIGURATION printf("Set Configuration\n\r"); DeviceConfigured = SetupPacket.wValue & 0xFF; D11WriteEndpoint(D11_ENDPOINT_EP0_IN, NULL, 0); wLenght =0 explique le 0 Une requête pour le descripteur de configuration retournera le descripteur d'appareil et, tous les descripteurs d'interfaces et de terminaisons dans la même requête. if (DeviceConfigured) si le périphérique est configuré { RB3 = 0; valeur= 0 printf("\n\r *** Device Configured *** \n\r"); afficher le message } else { RB3 = 1; sinon valeur = 1 /* Device Not Configured */ printf("\n\r ** Device Not Configured *** \n\r"); } le périphérique n’est pas configuré break; //case SET_DESCRIPTOR: cas SET_DESCRIPTOR utilisé pour renvoyer le descripteur indiqué dans wValue default: /* Unsupported - Request Error - Stall */ si wValue différent de bConfigurationValue ErrorStallControlEndPoint(); break; } erreur de requête break; GetConfiguration et SetConfiguration sont utilisés pour " valider " l'appareil USB permettant aux données d'être transférées sur les terminaisons autres que la terminaison zéro. SetConfiguration devrait être délivré avec wValue égal à bConfigurationValue de la configuration que vous voulez valider. Dans notre cas, nous n'avons qu'une configuration, la configuration 1. Une configuration de valeur zéro signifie que l'appareil est configuré tandis qu'une configuration de valeur différente de zéro indique que l'appareil n’est pas configuré. Le code ne recopie pas complètement la valeur de configuration, il la recopie seulement dans une variable locale (de stockage) appelée DeviceConfigured. Si la valeur dans wValue ne correspond pas à bConfigurationValue d'une configuration, elle devrait renvoyer le message : Erreur de Requête USB. Il à noter que le wLenght de SetConfiguration est de 0 octet d’ou la fin de ligne après le NULL. Nous écrivons un NULL pour indiquer la fin de la requête. case STANDARD_INTERFACE_REQUEST: cas d’une requête standard

121

printf("Standard Interface Request\n\r"); affiche le message switch (SetupPacket.bRequest) { selon le type de requête case GET_STATUS: cas GET_STATUS /* Get Status Request to Interface should return */ la requête doit retourner un /* Zero, Zero (Reserved for future use) */ message composé de 0 et est réservée pour un usage ultérieur. Buffer[0] = 0x00; Buffer[1] = 0x00; nous utilisons le buffer (0) et buffer(1) pour écrire le D11WriteEndpoint(D11_ENDPOINT_EP0_IN, Buffer, 2); message composé de 0 sur le terminal 0 sur 2 octets. Le terminal est en entrée . break; case SET_INTERFACE: cas SET_INTERFACE et GET_INTERFACE /* Device Only supports default setting, Stall may be */ sont utilisés avec des /* returned in the status stage of the request */ descripteurs alternatifs if (SetupPacket.wIndex == 0 && SetupPacket.wValue == 0) d’interface ( non

définis). /* Interface Zero, Alternative Setting = 0 */ Nous envoyons un 0 et toutes les requêtes pour mettre à 1 une interface autre que l’interface 0 se traduiront par une erreur de requête D11WriteEndpoint(D11_ENDPOINT_EP0_IN, NULL, 0); else ErrorStallControlEndPoint(); break; Fin case GET_INTERFACE: if (SetupPacket.wIndex == 0) { /* Interface Zero */ Buffer[0] = 0; /* Alternative Setting */ D11WriteEndpoint(D11_ENDPOINT_EP0_IN, Buffer, 1); break; Les valeurs 0 et 1 en fin de correspondent à wLenght } /* else fall through as RequestError */ //case CLEAR_FEATURE: cas CLEAR_FEATURE ou //case SET_FEATURE: SET_FEATURE /* Interface has no defined features. Return RequestError */ l’interface de remplacement n’ayant pas été définie nous envoyons une erreur de requête default: ErrorStallControlEndPoint(); break; } break;

122

Les Requêtes d'Interface standard La spécification actuelle définit 5 requêtes d'interface standard qui sont détaillées dans le tableau ci-dessous : Il est intéressant de noter que, seules 2 requêtes donnent quelque chose de compréhensible.

bmRequestTy

pe bRequest wValue wIndex wLength Données

1000 0001b GET_STATUS (0x00) Zéro Interface Deux Etat de l'Interface


Sélecteur de Fonction Interface Zéro Aucune

0000 0001b SET_FEATURE (0x03) Sélecteur de Fonction Interface Zéro Aucune

1000 0001b GET_INTERFACE (0x0A) Zéro Interface Un

Interface de

remplacement

0000 0001b SET_INTERFACE (0x11)

Positionnement alternatif Interface Zéro Aucune

wIndex est normalement utilisé pour préciser l'interface de référence pour des requêtes liées à l'interface. Voir son format dans le schéma ci-dessous.

D15

D14

D13

D12

D11

D10

D9 D8 D7 D6 D5 D4 D3 D2 D1 D0

Réservé Numéro d'Interface

Get Status est utilisé pour retourner l'état de l'interface. Une telle requête à l'interface doit renvoyer 2 octets de valeur 0x00, 0x00. ( Les 2 octets sont réservés pour une utilisation future). Les requêtes ClearFeature et SetFeature peuvent être utilisées pour positionner des fonctions booléennes. Quand le destinataire désigné est l'interface, la spécification USB actuelle révision 2 précise qu'il n'y a pas de fonctions d'interface. Get Interface et Set Interface règle le positionnement de l'interface de remplacement qui est décrit plus en détails dans le descripteur d'interface.

Nous voyons ici que : cas GET_STATUS wLenght = 2 octets cas GET_INTERFACE wLenght = 1 octet cas SET_INTERFACE wLenght = 0 octet

123

Les Requêtes de terminaisons standard Les requêtes de terminaisons standard sont au nombre de 4, listées ci-dessous :

bmRequestTy

pe bRequest wValue Windex wLength Données

1000 0010b GET_STATUS (0x00) Zéro Terminaison Deux Etat de la Terminaison


Sélecteur de Fonction Terminaison Zéro Aucune

0000 0010b SET_FEATURE (0x03) Sélecteur de Fonction Terminaison Zéro Aucune

1000 0010b SYNCH_FRAME (0x12) Zéro Terminaison Deux Numéro de

Trame

Le champ wIndex est normalement utilisé pour préciser la terminaison de référence et la direction pour les requêtes liées à la terminaison. Voir son format dans le schéma ci-dessous.

D15

D14

D13

D12

D11

D10

D9 D8 D7 D6 D5 D4 D3 D2 D1 D0



D15

D14

D13

D12

D11

D10

D9 D8 D7 D6 D5 D4 D3 D2 D1 D0

Réservé Halt

ClearFeature et SetFeature sont utilisés pour positionner les fonctions de la terminaison. Le standard défini actuellement un sélecteur de fonction de terminaison : ENDPOINT_HALT (0x00) qui permet à l'hôte de bloquer et d'effacer une terminaison. Seules les terminaisons autres que la terminaison par défaut sont conseillées pour avoir cette fonctionnalité. Une requête SynchFrame est utilisée pour rapporter une trame de synchronisation de terminaison.

Nous allons utiliser une suite de cas associés à wIndex Exemples : cas 0x01 DIR =0 et D0 = 1 C’est donc le terminal 1 en sortie Cas 0x81 DIR = 1 et D0 = 1 C’est donc le terminal 1 en entrée

D15

D14

D13

D12

D11

D10

D9 D8 D7 D6 D5 D4 D3 D2 D1 D0


124

case STANDARD_ENDPOINT_REQUEST: Cas d’une requête standard printf("Standard Endpoint Request\n\r"); affiche le message switch (SetupPacket.bRequest) { selon le type de requête contenu dans bRequest du paquet d’installation case CLEAR_FEATURE: cas CLEAR_FEATURE ou SET_FEATURE case SET_FEATURE: /* Halt(Stall) feature required to be implemented on all Interrupt and */ /* Bulk Endpoints. It is not required nor recommended on the Default Pipe */ if (SetupPacket.wValue == ENDPOINT_HALT) {

if (SetupPacket.bRequest == CLEAR_FEATURE) Buffer[0] = 0x00; else Buffer[0] = 0x01;

CLEAR_FEATURE et SET_FEATURE sont utilisés pour positionner des fonctions spécifiques de terminal. Le sélecteur ENDPOINT_HALT (0x00) permet à l’hôte de bloquer ou d’effacer un terminal. Seuls les terminaux autres que le terminal 0 est conseillé.

switch (SetupPacket.wIndex & 0xFF) { selon le contenu de wIndex

case 0x01 : D11CmdDataWrite(D11_SET_ENDPOINT_STATUS + \ D11_ENDPOINT_EP1_OUT, Buffer, 1); terminal 1 en sortie écrit dans

break; SET_ENDPOINT_STATUS case 0x81 : D11CmdDataWrite(D11_SET_ENDPOINT_STATUS + \

D11_ENDPOINT_EP1_IN, Buffer, 1); terminal 1 en entrée écrit dans break; SET_ENDPOINT_STATUS case 0x02 : D11CmdDataWrite(D11_SET_ENDPOINT_STATUS + \

D11_ENDPOINT_EP2_OUT, Buffer, 1); terminal 2 en sortie écrit dans break; SET_ENDPOINT_STATUS

case 0x82 : D11CmdDataWrite(D11_SET_ENDPOINT_STATUS + \ D11_ENDPOINT_EP2_IN, Buffer, 1); terminal 2 en entrée écrit dans

break; SET_ENDPOINT_STATUS

case 0x03 : D11CmdDataWrite(D11_SET_ENDPOINT_STATUS + \ D11_ENDPOINT_EP3_OUT, Buffer, 1); terminal 3 en sortie écrit dans

break; SET_ENDPOINT_STATUS

case 0x83 : D11CmdDataWrite(D11_SET_ENDPOINT_STATUS + \ D11_ENDPOINT_EP3_IN, Buffer, 1); terminal 3 en entrée écrit dans

break; SET_ENDPOINT_STATUS default : /* Invalid Endpoint - RequestError */ si la requête est pour

125

ErrorStallControlEndPoint(); un terminal invalide nous break; envoyons une erreur de

} requête D11WriteEndpoint(D11_ENDPOINT_EP0_IN, NULL, 0); une fois terminé nous } else { envoyons un paquet NULL /* No other Features for Endpoint - Request Error */ dans tous les autres cas nous envoyons une erreur de requête ErrorStallControlEndPoint(); } break;


D15

D14

D13

D12

D11

D10

D9 D8 D7 D6 D5 D4 D3 D2 D1 D0

Réservé Halt

case GET_STATUS: cas GET_STATUS /* Get Status Request to Endpoint should return */ retourne l’état Halt de D0 pour les transactions de /* Halt Status in D0 for Interrupt and Bulk */ blocs et d’interruption switch (SetupPacket.wIndex & 0xFF) { selon le type de terminal case 0x01 : D11CmdDataRead(D11_READ_ENDPOINT_STATUS + \ lecture de l’état D11_ENDPOINT_EP1_OUT, Buffer, 1); et report sur le terminal 1 en sortie break; case 0x81 : D11CmdDataRead(D11_READ_ENDPOINT_STATUS + \ lecture de l’état D11_ENDPOINT_EP1_IN, Buffer, 1); et report sur le terminal 1 en entrée break; case 0x02 : D11CmdDataRead(D11_READ_ENDPOINT_STATUS + \ lecture de l’état D11_ENDPOINT_EP2_OUT, Buffer, 1); et report sur le terminal 2 en sortie break; case 0x82 : D11CmdDataRead(D11_READ_ENDPOINT_STATUS + \ lecture de l’état D11_ENDPOINT_EP2_IN, Buffer, 1); et report sur le terminal 2 en entrée break; case 0x03 : D11CmdDataRead(D11_READ_ENDPOINT_STATUS + \ lecture de l’état D11_ENDPOINT_EP3_OUT, Buffer, 1); et report sur le terminal 3 en sortie break; case 0x83 : D11CmdDataRead(D11_READ_ENDPOINT_STATUS + \ lecture de l ‘état D11_ENDPOINT_EP3_IN, Buffer, 1); et report sur le terminal 3 en entrée break;

126

default : /* Invalid Endpoint - RequestError */ ErrorStallControlEndPoint(); envoie une break; erreur de requête pour tout autre terminal } if (Buffer[0] & 0x08) Buffer[0] = 0x01; nous venons positionner/effacer

else Buffer[0] = 0x00; Buffer[1] = 0x00; le bit Halt (octet 2 de GetStatus) D11WriteEndpoint(D11_ENDPOINT_EP0_IN, Buffer, 2); break; default: /* Unsupported - Request Error - Stall */ ErrorStallControlEndPoint(); break; pour toutes les requêtes non définies } erreur de requête break; Les requêtes constructeur peuvent être imaginées par le concepteur. Nous avons imaginé 2 requêtes : VENDOR_GET_ANALOG_VALUE et VENDOR_SET_RB_HIGH_NIBBLE. VENDOR_GET_ANALOG_VALUE lit la valeur analogique de 10 bits du canal x imposé par wIndex. Elle est masquée avec 0x07 pour permettre 8 canaux possibles, supportant le PIC 16F877 plus grand si nécessaire. La valeur analogique est renvoyée dans un paquet de données de 2 octets.

127

Nous utilisons le registre ADCON0 du pic. R/W-0 R/W-0 R/W-0 R/W-0 R/W-0 R/W-0 U-0 R/W-0 ADCS1

ADCS0

CHS2

CHS1

CHS0

GoDone

ADON

Bit 7-6 ADCS1-ADCS0.A/D Conversion Clock Select bits 00 = Fosc/2 01 = Fosc/8

10 = Fosc/32 11 = Frc (Clock derived from an RC Oscillation)

bit 5-3 CHS2 :CHS0 :analog channel select bits 000 = channel 0.(RA0/AN0) 001 = channel 1.(RA1/AN1) 010 = channel 2.(RA2/AN2) 011 = channel 3.(RA3/AN3) 100 = channel 4.(RA5/AN4) 101 = channel 5.(RE0/AN5)*

110 = channel 6.(RE1/AN6)* 111 = channel 7.(RE2/AN6)*

bit 2 GoDone : A/D Conversion Status Bit if ADON =1 1 = A/D conversion in progress (settting this bit starts the A/D conversoion) 0 = A/D conversion not in progress ( this bit is automatically cleared by by the harware when the A/D conversion is complete ) bit 1 unimplemented : Read as « 0 » bit 0 AFDON : A/D on bit 1 = A/D converter module is operating 0 = A/D converter module is shuoff and consumes no operating current note* : there channels are not available on the 28-pin devices R= Readable bit W= writable bit U = unimplemented bit , read as « 0 » n= value at POR reset

128

case VENDOR_DEVICE_REQUEST: dans le cas de l’une ou l’autre des case VENDOR_ENDPOINT_REQUEST: requêtes afficher ainsi le type de requête Les champs wValue et wIndex permettent le passage de paramètres avec la requête printf("Vendor Device bRequest = 0x%X, wValue = 0x%X, wIndex = 0x%X\n\r", \ SetupPacket.bRequest, SetupPacket.wValue, SetupPacket.wIndex); initialisation du type de requête, de wValue et wIndex selon le type de requête lues dans le paquet d’installation switch (SetupPacket.bRequest) { case VENDOR_GET_ANALOG_VALUE: cas VENDOR_GET_ANALOG_VALUE printf("Get Analog Value, Channel %x :",SetupPacket.wIndex & 0x07); afficher

les 8 canaux ADCON0 = 0xC1 | (SetupPacket.wIndex & 0x07) << 3; Frc CH2-CH0 =000 canal0(RA0/AN0) , GoDone=0 , ADON=1 module A/D fonctionnel , garder les 7 MSB /* Wait Acquistion time of Sample and Hold */ attendre le temps d’acquisition for (a = 0; a <= 255; a++); boucle d’attente ADGO = 1; while(ADGO); tant que la conversion s’effectue Buffer[0] = ADRESL; lire le résultat de conversion Buffer[1] = ADRESH; sur 7 bits et stocker dans 2 registres de 8 bits a = (Buffer[1] << 8) + Buffer[0]; mettre le résultat dans la variable 16 a = (a * 500) / 1024; bits définie plus haut le résultat est ramené

par rapport à une échelle de 5 volts printf(" Value = %d.%02d\n\r",(unsigned int)a/100,(unsigned int)a%100); affiche le résultat en volts avec 2 chiffres après le point ainsi que le reste de la division D11WriteEndpoint(D11_ENDPOINT_EP0_IN, Buffer, 2); Le résultat est écrit sur 2 octets sur le terminal 0 en entrée via les 2 octets de buffer break; case VENDOR_SET_RB_HIGH_NIBBLE:cas VENDOR_SET_RB_HIGH_NIBBLE printf("Write High Nibble of PORTB\n\r"); afiicher le message : écriture de la valeur des poids forts du port B PORTB = (PORTB & 0x0F) | (SetupPacket.wIndex & 0xF0); poids forts port B D11WriteEndpoint(D11_ENDPOINT_EP0_IN, NULL, 0);écriture d’un paquet NULL avant de quitter break; default: ErrorStallControlEndPoint(); si erreur nous envoyons une erreur de requête break; } break;

129

VENDOR_SET_RB_HIGH_NIBBLE peut être utilisé pour positionner les bits factices de poids forts du PORTB[3:7].

default: printf("UnSupported Request Type 0x%X\n\r",SetupPacket.bmRequestType); ErrorStallControlEndPoint(); break; } } else { printf("Data Packet?\n\r"); /* This is a Data Packet */ } } Tous les types de requêtes non supportés tels que la requête de classe d'appareil, la requête de classe d'interface, etc. se traduiront par une erreur de requête USB. Sinon , C’est un paquet de données et nous l’affichons.

void GetDescriptor(PUSB_SETUP_REQUEST SetupPacket) { switch((SetupPacket->wValue & 0xFF00) >> 8) { selon les paquets de 8 octets de

wValue case TYPE_DEVICE_DESCRIPTOR: cas TYPE_DEVICE_DESCRIPTOR printf("\n\rDevice Descriptor: Bytes Asked For %d, Size of Descriptor %d\n\r", \ affiche les octets demandés dans le descripteur de périphérique SetupPacket->wLength,DeviceDescriptor.bLength); Longueur du descripteur dans wLengh de l’hôte et longueur du descripteur de Périphérique pSendBuffer = (const unsigned char *)&DeviceDescriptor; charge l’adresse des descripteurs BytesToSend = DeviceDescriptor.bLength; charge la longueur des descripteurs if (BytesToSend > SetupPacket->wLength) vérification de la longueur BytesToSend = SetupPacket->wLength; par rapport à celle de l’hôte et WriteBufferToEndPoint(); ajustement écriture dans le break; le buffer du terminal case TYPE_CONFIGURATION_DESCRIPTOR: cas TYPE_CONFIGURATION_DESCRIPTOR printf("\n\rConfiguration Descriptor: Bytes Asked For %d, Size of Descriptor %d\n\r", \ affiche les octets demandés dans le descripteur de configuration

130

SetupPacket->wLength, sizeof(ConfigurationDescriptor)); Longueur du descripteur dans wLengh de l’hôte et longueur du descripteur de configuration pSendBuffer = (const unsigned char *)&ConfigurationDescriptor; charge l’adresse des descripteurs BytesToSend = sizeof(ConfigurationDescriptor); charge la longueur des descripteurs if (BytesToSend > SetupPacket->wLength) vérification de la longueur BytesToSend = SetupPacket->wLength; par rapport à celle de l’hôte et WriteBufferToEndPoint(); ajustement écriture dans le break; buffer du terminal WriteBufferToEndPoint charge les 8 premiers octets dans le tampon puis le pointeur s’incrémente par la suite . Get Descriptor est utilisé pour renvoyer le descripteur indiqué dans wValue. Une requête pour le descripteur de configuration retournera le descripteur d'appareil , tous les descripteurs d'interfaces et de terminaisons dans la même requête Les requêtes GetDescriptor impliquent des réponses plus grandes que la taille maximale limite du paquet de 8 octets de la terminaison. Par conséquent elles doivent être scindées en morceaux de 8 octets. Les 2 requêtes d'appareil et de configuration chargent l'adresse des descripteurs pertinents dans pSendBuffer et positionnent BytesToSend à la longueur du descripteur. La requête précisera aussi une longueur de descripteur dans wLength indiquant le maximum de données à envoyer. Dans chaque cas nous vérifions la longueur réelle par rapport à celle demandée par l'hôte et ajustons la taille si nécessaire. Ensuite nous appellerons WriteBufferToEndpoint qui charge les 8 premiers octets dans le tampon de terminaison et incrémenterons le pointeur qui sera prêt pour le prochain paquet de 8 octets

Décalage

131

Descripteur de chaîne de langue

Décalage Champ Taille Valeur Description 0 bLength 1 Nombre Taille du descripteur en octets 1 bDescriptorType 1 Constante Descripteur de chaîne (0x03) 2 wLANGID[0] 2 Nombre Langue acceptée code zéro

( par exemple 0x0409 Anglais, U.S.) 4 wLANGID[1] 2 Nombre Langue acceptée code Un

( par exemple 0x0C09 Anglais, Australien)

n wLANGID[x] 2 Nombre SLangue acceptée code x ( par exemple 0x0407 Allemand - Standard)

case TYPE_STRING_DESCRIPTOR: cas TYPE_STRING_DESCRIPTOR printf("\n\rString Descriptor: LANGID = 0x%04x, Index %d\n\r", \ afficher le descripteur

de langue SetupPacket->wIndex, SetupPacket->wValue & 0xFF); récupération de wIndex et wValue dans le paquet d’installation. L’ID de langue est dans wIndex switch (SetupPacket->wValue & 0xFF){ selon les valeurs de wValue case 0 : pSendBuffer = (const unsigned char *)&LANGID_Descriptor; l'adresse du BytesToSend = sizeof(LANGID_Descriptor); descripteur est celle du descripteur

de Chaîne 0 BytesToSend = la longueur du descripteur de langue break; case 1 : pSendBuffer = (const unsigned char *)&Manufacturer_Descriptor; idem pour le BytesToSend = sizeof(Manufacturer_Descriptor); manufacturier BytesToSend = la longueur du descripteur de manufacturier break; default : pSendBuffer = NULL; en cas d’erreur nous envoyons un paquet NULL BytesToSend = 0; longueur descripteur à 0 } if (BytesToSend > SetupPacket->wLength) nous ajustons la longueur du BytesToSend = SetupPacket->wLength; paquet suivant la valeur de wLenght WriteBufferToEndPoint(); break; } } Si des descripteurs de chaînes sont inclus, il doit y avoir la présence d'un descripteur de chaîne zéro qui détaille quelles langues sont supportées par l'appareil. N'importe quelle requête de chaînes différente de zéro a un langage

132

ID spécifié dans wIndex indiquant quelle langue est supportée. Dans notre cas nous trichons quelque peu et ignorons la valeur de wIndex (LANGID) en renvoyant la chaîne, quelle que soit la langue demandée. WriteBufferToEndpoint qui charge les 8 premiers octets dans le tampon de terminaison et incrémenterons le pointeur qui sera prêt pour le prochain paquet de 8 octets. void ErrorStallControlEndPoint(void) { unsigned char Buffer[] = { 0x01 }; /* 9.2.7 RequestError - return STALL PID in response to next DATA Stage Transaction */ D11CmdDataWrite(D11_SET_ENDPOINT_STATUS + D11_ENDPOINT_EP0_IN, Buffer, 1); /* or in the status stage of the message. */ D11CmdDataWrite(D11_SET_ENDPOINT_STATUS + D11_ENDPOINT_EP0_OUT, Buffer, 1); } Quand nous rencontrons une requête invalide, un paramètre invalide ou une requête que l'appareil ne prend pas en charge, nous devons prendre compte d'une erreur de requête. Ceci est défini dans la spécification 9.2.7. Une erreur de requête renverra un STALL PID en réponse à la prochaine transaction d'étape de données ou au cours de l'étape d'état du message.. Toutefois elle note que pour empêcher un trafic inutile sur le bus, l'erreur doit être reportée à la prochaine étape de données plutôt que d'attendre l'étape d'état.

133

La commande de lecture/écriture de données s ’effectue pendant la phase donnée. Le PDIUSBD11 a un segment de RAM dans une zone tampon ENDPOINT. Le format de la donnée dans la zone tampon est : Nous définissons : D11HEADER (2) qui est un tableau de 2 octets et une variable état BufferStatus. Le D11HEADER permet de lire le nombre d ’octets . L e pointeur de tampon est incrémenté à chaque lecture , il est remis à zéro par une commande SELECT ENDPOINT. Nous envoyons un paquet null pour indiquer que la lecture est finie. Dans le cas de l ’écriture , nous spécifions dans l ’octet 1 du tableau le nombre d ’octets à écrire . Puis nous envoyons la commande SELECT ENDPOINT afin de remettre à 0 le pointeur. Nous écrivons le nombre d ’octet sur l ’offset 2 suivi de la donnée en fonction du nombre d ’octets. Une fois l ’écriture terminée , nous envoyons un paquet null pour informer la fin de l ’écriture. unsigned char D11ReadEndpoint(unsigned char Endpoint, unsigned char *Buffer) { unsigned char D11Header[2]; définition du tableau D11Header unsigned char BufferStatus = 0; définition de la variable BufferStatus /* Select Endpoint */ sélection du terminal, vérification de D11CmdDataRead(Endpoint, &BufferStatus, 1); l’état du tampon du terminal. Si le tampon est plein, lecture du paquet d’entête et incrémentation du pointeur du tampon . RAZ du pointeur par Select Endpoint seulement /* Check if Buffer is Full */ if(BufferStatus & 0x01) { /* Read dummy header - D11 buffer pointer is incremented on each read */ /* and is only reset by a Select Endpoint Command */ D11CmdDataRead(D11_READ_BUFFER, D11Header, 2); if(D11Header[1]) D11CmdDataRead(D11_READ_BUFFER, Buffer, D11Header[1]); si le tampon est vide un nouveau paquet peut être accepté. /* Allow new packets to be accepted */ D11CmdDataWrite(D11_CLEAR_BUFFER, NULL, 0); fin d’écriture } return D11Header[1]; retour à l’entête }

Nombre d ’octets

Réservé Octet 1 Octet 8

Offset 0 offset 1 offset 2 offset 9

134

En utilisant la commande Select Enpoint nous avons l’état du buffer du terminal désiré. Le format est le suivant : 7 6 5 4 3 2 1 0 0 0 0 0 0 0 0 0

void D11WriteEndpoint(unsigned char Endpoint, const unsigned char *Buffer, unsigned char Bytes) { unsigned char D11Header[2]; définition du tableau de 2 octets D11Header unsigned char BufferStatus = 0; initialisation de la variable d’état D11Header[0] = 0x00; RAZ du paquet d’entête octet 0 D11Header[1] = Bytes; octet 2 du paquet d’entête = nombre d’octets (1 à 8) /* Select Endpoint */ sélection du terminal D11CmdDataRead(Endpoint, &BufferStatus, 1); lecture de l’état /* Write Header */ D11CmdDataWrite(D11_WRITE_BUFFER, D11Header, 2); écriture des 2 octets d’entête /* Write Packet */ if (Bytes) D11CmdDataWrite(D11_WRITE_BUFFER, Buffer, Bytes); écriture du nombre d’octets /* Validate Buffer */ D11CmdDataWrite(D11_VALIDATE_BUFFER, NULL, 0); écriture de la validation du tampon et fin d’écriture } D11ReadEndpoint et D11WriteEndpoint sont des fonctions spécifiques au PDIUSBD11. Le PDIUSBD11 a 2 octets factices préfixant toute opération de lecture ou écriture de données. Le premier octet est réservé, tandis que le second octet indique le nombre d'octets reçus ou à transmettre. Ces 2 fonctions tiennent compte de cet en-tête.

void WriteBufferToEndPoint(void) { if (BytesToSend == 0) { /* If BytesToSend is Zero and we get called again, assume buffer is smaller */ /* than Setup Request Size and indicate end by sending Zero Lenght packet */ D11WriteEndpoint(D11_ENDPOINT_EP0_IN, NULL, 0); Si le compteur BytesToSend = 0 nous avons un multiple de 8 octets et nous l’indiquons par un paquet NULL } else if (BytesToSend >= 8) { /* Write another 8 Bytes to buffer and send */ D11WriteEndpoint(D11_ENDPOINT_EP0_IN, pSendBuffer, 8); Si BytesToSend est >= 8 nous envoyons les octets en fonction du pointeur

réservé réservé réservé réservé réservé réservé réservé Buffer full

135

pSendBuffer += 8; pointeur = pointeur +8 octetts BytesToSend -= 8; compteur = compteur – 8 octets } else { /* Buffer must have less than 8 bytes left */ D11WriteEndpoint(D11_ENDPOINT_EP0_IN, pSendBuffer, BytesToSend); BytesToSend = 0; } sinon le buffer a moins de 8 octets , nous les envoyons tel quel } et nous remettons le compteur BytesToSend à 0 WriteBufferToEndpoint est responsable du chargement des données dans PDIUSBD11 en morceaux de 8 octets et de l'ajustement de la préparation des pointeurs pour le prochain paquet. Il est appelé une fois par le programme de gestion de la requête pour charger les 8 premiers octets dans le tampon mémoire de la terminaison. L'hôte enverra donc un jeton IN, lira cette donnée et le PDIUSBD11 génèrera une interruption. Le programme de gestion de EP0 IN appellera donc WriteBufferToEndpoint pour charger le prochain paquet qui sera prêt pour le prochain jeton IN provenant de l'hôte. Un transfert est considéré comme complet si tous les octets requis ont été lus, si le paquet est reçu avec une charge utile inférieure à bMaxPacketSize ou si un paquet de longueur nul est renvoyé. Par conséquent si le compteur BytesToSend atteint zéro, nous pouvons présumer que les données à envoyer représentaient un multiple de 8 octets et que nous enverrons un paquet de longueur nul pour indiquer les dernières données. Toutefois, s'il nous reste moins de 8 octets à envoyer, nous enverrons seulement les octets restants. Il n'est pas nécessaire de rembourrer les données avec des zéros.

136

void loadfromcircularbuffer(void) { unsigned char Buffer[10]; longueur du tableau unsigned char count; définition de la variable count // Read Buffer Full Status lecture de l’état du tampon D11CmdDataRead(D11_ENDPOINT_EP1_IN, Buffer, 1); if (Buffer[0] == 0){ si le tableau est vide // Buffer Empty if (inpointer != outpointer){ si outpointer différent de inpointer // We have bytes to send count =0 et nous avons des octets count = 0; à envoyer do { Buffer[count++] = circularbuffer[outpointer++]; incréemntation du pointeur de la Mémoire circulaire et du compteur if (outpointer >= MAX_BUFFER_SIZE) outpointer = 0; si le pointeur est en fin de mémoire nous remettons outpointer à 0 if (outpointer == inpointer) break; // No more data si outpointeur= inpointeur il n’y a plus de données } while (count < 8); // Maximum Buffer Size // Now load it into EP1_In D11WriteEndpoint(D11_ENDPOINT_EP1_IN, Buffer, count); } tant que count < 8 octets qui est la taille maximale du buffer }nous pouvons recharger de nouvelles données dans le tampon mémoire de EP1 IN } La routine loadfromcircularbuffer() gère le chargement de données dans le tampon mémoire de la terminaison EP0 IN. Nous y faisons appel après une interruption EP0 IN pour recharger le tampon mémoire afin d'être prêt pour le prochain jeton IN sur EP1. Cependant afin d'envoyer le premier paquet, nous avons besoin de charger les données avant la réception de l'interruption EP1 IN. Par conséquent nous faisons appel à la routine après que les données soient reçues sur EP1 OUT. En appelant aussi la routine du programme de gestion de EP0 OUT, nous pouvons facilement écraser les données dans le tampon IN sans se préoccuper si elles ont été envoyées ou pas. Pour empêcher ceci, nous déterminons si le tampon mémoire EP1 IN est vide, avant de tenter de le recharger avec de nouvelles données.

137

void D11CmdDataWrite(unsigned char Command, const unsigned char *Buffer, unsigned char Count) { I2C_Write(D11_CMD_ADDR, &Command, 1); if(Count) I2C_Write(D11_DATA_ADDR_WRITE, Buffer, Count); } void D11CmdDataRead(unsigned char Command, unsigned char Buffer[], unsigned char Count) { I2C_Write(D11_CMD_ADDR, &Command, 1); if(Count) I2C_Read(D11_DATA_ADDR_READ, Buffer, Count); } D11CmdDataWrite et D11CmdDataRead sont 2 fonctions spécifiques au PDIUSBD11 qui sont responsables de l'envoi de l'adresse/commande I2C en premier puis de l'envoi ou de la reception des données sur le bus I2C.

l’hôte et le périphérique - WordPress.comTerme qui décrit les signaux numériques transmis...

Documents

Transcript of l’hôte et le périphérique - WordPress.comTerme qui décrit les signaux numériques transmis...