Exemple de réalisation USB en mode CDC · communication entre le PIC et un PC via le terminal USB....

16
1 Exemple de réalisation USB en mode CDC Et HID Par Jean Marc Masson Introduction L’USB CDC communication device classe , permet une communication entre le PIC et un PC via le terminal USB. Les périphériques comme l’interface pour appareil audio ou disque dur entrent dans cette catégorie. C’est une communication entre deux machines possédant un microprocesseur. Vous pouvez télécharger le firmwork USB à l’adrees suivante pour obtenir les codes d’exemple CDC et HID étudiés dans cette réalisation. http://www.microchip.com/page/handler/en-us/devtools/mla/

Transcript of Exemple de réalisation USB en mode CDC · communication entre le PIC et un PC via le terminal USB....

  1  

Exemple de réalisation USB en mode CDC

Et HID

Par Jean Marc Masson

Introduction

L’USB CDC communication device classe , permet une communication entre le PIC et un PC via le terminal USB.

Les périphériques comme l’interface pour appareil audio ou disque dur entrent dans cette catégorie.

C’est une communication entre deux machines possédant un microprocesseur.

Vous pouvez télécharger le firmwork USB à l’adrees suivante pour obtenir les codes d’exemple CDC et HID étudiés dans cette réalisation.

http://www.microchip.com/page/handler/en-us/devtools/mla/

  2  

Le fichier utilise sera sélectionné comme dans l’image suivante:

Ordinogramme

  3  

  4  

Nous n’avons pas écrit tout le code, mais seulementque;ques parties. Vous pouvez cependant suivre le déroulement du code via l’ordinogramme.

Fonction main.

La fonction Initializesystem() initialise le périphérique USB. Puis le programme entre dans une boucle infinie. Dans cette boucle, la première chose est de verifier que le périphérique est connecté.

Dans l’affirmative, on enclenche une interruption. Si l’interruption USB est enclenchée, on démarre la fonction USBDeviceTask() qui initialise et configure l’USB détecté. Puis, le programme entre dans la fonction ProcessIO() dont toutes les étapes sont écrites.

  5  

Dès l’entrée dans la fonction ProcessIO(), On vérifie l’état du périphérique USB ( attaché, configure, alimenté etc…). Cet état est affiché sur deux dels RD0 et RD1 .

Dans le cas ou le bouton est appuyé côté PIC, une chaîne de caractères est envoyée au PC .

L’étape suivante se produit si une touche du clavier est enfoncée.

Dans ce cas , le programme incrémente le caractère et le renvoie au PC.

Lors de la reception du caractère envoyé par le PC, le caractère est envoyé dans un tableau. Si le caractère est dans le tableau, le programme lit tous les caractères un par un. À chaque

  6  

caractère, le programme vérifie que le caractère n’apartient pas à une liste d’exception comme ENTRER et RETOUR qui ne sont pas incrémentés. Si le caractère est incrémenté, il est envoyé au PC.

Voici une partie de la fonction BlinkUSBStatus(). Nous pouvons y voir tous les états de l’USB.

  7  

  8  

Le Mode HID ( clavier ou souris)

Introduction

Un dispositif d'interface humaine ou HID est un type de dispositif informatique qui interagit directement avec les humains. Le terme «HID» désigne le plus souvent à l' USB-HID spécification. Ce mode est utilisé pour les souris, claviers et autres périphériques basse vitesse .

Les caratéristiques de fonctionnement d'un périphérique sont définies par ses terminaisons (EP0, EP1, ...), leur sens (IN ou OUT), et leur mode de transfert (Control, Interrupt, Bulk ou Isochrone), et le protocole au niveau de chaque terminaison. On ne peut dialoguer avec un périphérique USB que par l'intermédiaire de l'hôte USB. Comme si les choses n'étaient pas assez compliquées, la norme USB originelle définit deux types d'hôtes USB, les hôtes OHCI et UHCI. L'hôte UHCI privilégie la simplicité du matériel au détriement du logiciel, et l'hôte OHCI fait l'inverse. Les agencements des registres et la manière de communiquer est bien évidemment tout à fait différente pour ces deux hôtes. Une autre raison qui empêche le dialogue direct avec les périphériques USB est que toutes les requêtes doivent passer par l'hôte USB. Il faut donc un arbitrage, pour savoir qui peut utiliser l'hôte USB. Ceci ne peut être fait que par le système d'exploitation.

HID norme La norme HID a été adoptée principalement pour permettre l'innovation dans PC de périphériques d'entrée et de simplifier le processus d'installation de tels dispositifs. A l'introduction de la notion HID, les dispositifs définissent des protocoles pour les souris , claviers et manettes de jeu .Toutes les innovations matérielles ont nécessité soit de surcharger l'utilisation des données dans un protocole existant ou la création de pilotes de périphériques personnalisés et un nouveau protocole pour les développeurs. En revanche, tous les périphériques HID définis offrent des forfaits auto-descriptifs qui peuvent contenir n’ importe quel nombre de types et de formats de données. Un pilote HID seul sur un ordinateur traite les données et permet l’association dynamique des données d'E / S avec

  9  

des fonctionnalités de l'application, ce qui a permis l'innovation et le développement rapide et la diversification prolifique de nouveaux dispositifs d'interface humaine. Le protocole HID a ses limites, mais la plupart des systèmes d'exploitation reconnaîtront les appareils standard HID USB, tels que les claviers et les souris, sans avoir besoin d'un pilote spécialisé. Une fois installé, un message disant que le dispositif "A" HID »a été reconnu" apparaît généralement à l'écran. En comparaison, ce message n’apparaît généralement pas pour les périphériques connectés via les PS / 2 6 broches des connecteurs DIN qui ont précédé USB. PS / 2 ne fonctionne généralement pas plug-and-play , ce qui signifie que la connexion d'un clavier PS / 2 ou une souris à l'ordinateur sous tension ne fonctionne pas toujours et peuvent présenter un danger pour la carte mère de l'ordinateur. De même, la norme PS / 2 ne supporte pas le protocole HID. Le humaine classe de périphérique d'interface USB décrit un USB HID. Composants du protocole HID Dans le protocole HID, il ya deux entités: le «hôte» et le «dispositif». Le dispositif est l'entité qui interagit directement avec un être humain, tel qu'un clavier ou une souris. L'hôte communique avec le dispositif d'entrée et reçoit des données à partir du dispositif sur les actions effectuées par l'homme. Les flux de données de sortie de l'hôte vers le périphérique, puis à l'humain. L'exemple le plus courant d'un hôte est un PC mais certains téléphones portables et PDA peuvent aussi être des hôtes. Le protocole HID rend la mise en œuvre de dispositifs très simple. Les Dispositifs définissent leurs paquets de données, puis présentent un «descripteur HID" à l'hôte. Le descripteur HID est un tableau d'octets codé en dur qui décrivent les paquets de données de l'appareil. Cela comprend: le nombre de paquets que l'appareil prend en charge, la taille des paquets, et le but de chaque octet et du bit dans le paquet. Par exemple, un clavier avec une touche de programme de calculatrice peut dire à l'hôte : pressé / état relâché du bouton. Il est stocké comme le 2ème bits dans l'octet 6 en nombre de paquets de données 4 (à noter: ces endroits sont qu'une illustration spécifique à l'appareil ) . Le dispositif stocke généralement le descripteur HID dans la ROM et n'a pas besoin de comprendre ou analyser le descripteur HID. Certaines souris et le clavier matériel sur le marché aujourd'hui sont implémentés en utilisant seulement un CPU 8 bits . L'hôte devrait être une entité plus complexe que l'appareil. L'hôte a besoin de récupérer le descripteur HID de l'appareil et l'analyser avant de pouvoir

  10  

pleinement communiquer avec le périphérique. L’Analyse du descripteur HID peut être compliquée. Le mécanisme décrit ci-dessus ce qui est connu comme HID "protocole de rapport". Parce qu'il a été entendu que tous les hôtes seraient capables de l'analyse de descripteurs HID, HID définit également "protocole de démarrage". Dans le protocole de démarrage, seuls les périphériques spécifiques sont pris en charge avec seulement des particularités car les formats de paquets de données fixes sont utilisés. Le descripteur HID n’est pas utilisé dans ce mode si l'innovation est limité. Cependant, l'avantage est que la fonctionnalité minimale est encore possible sur les hôtes qui, autrement, seraient incapables de soutenir HID. Les seuls périphériques pris en charge dans le protocole de démarrage sont • Clavier – N’importe lequel des 256 premiers codes clés ("Usages") définis

dans les tableaux d'utilisation HID, Usage Page 7 peut être signalé par un clavier en utilisant le protocole de démarrage, mais la plupart des systèmes ne gèrent qu'un sous-ensemble de ces touches. La plupart des systèmes prennent en charge tous les 104 touches sur l' IBM AT-101 mise en page, ainsi que les trois touches supplémentaires conçus pour Microsoft Windows 95 . De nombreux systèmes supportent également des touches supplémentaires sur Europe occidentale base 105-, 106- coréenne, brésilienne ABNT 107- et japonais DOS / V-109 dispositions clés. Boutons, boutons et les touches qui ne sont pas déclarés sur l'utilisation Page 7 ne sont pas disponibles. Par exemple, les touches QWERTY d'un clavier US notamment fonctionneront mais les touches déconnexion Calculatrice et ne seront pas parce qu'ils sont définis sur l'utilisation Page 12 et ne peuvent être signalés dans le protocole de démarrage.

• Souris - Seulement l'axe X, l'axe Y, et les trois premiers boutons seront disponibles. Les fonctionnalités supplémentaires sur la souris ne fonctionneront pas.

Une utilisation commune du mode de démarrage est pendant les premiers moments de la séquence de démarrage d'un ordinateur. Directement configuration d'un ordinateur le BIOS se fait souvent en utilisant le mode de démarrage uniquement. Parfois, un message se affiche informant l'utilisateur que le dispositif a installé le pilote approprié et est maintenant utilisable.

Nous ne traiterons ici que le clavier.

  11  

Fonctionnement d’un clavier “classique”

Lorsqu’un utilisateur appuie sur une touche, le code de celle-ci est envoyé dans une pile de type LIFO ou FIFO en général située dans un système de DMA.

Et ainsi de suite pour les autres touches.

Lorsque la pile est presque pleine, une interruption est envoyée au processeur.

Durant cette interruption la pile est vidée dans une RAM.

Le processeur reprend la main et est chargé du traitement des données entrées dans la RAM.

Puis le cycle recommence.

La zone de pile contenant les codes de touches est appelée un vecteur d’interruption.

Le cycle est particulièrement rapide afin de de permettre au processeur de ne pas rester trop longtemps en interruption.

Nous sommes habitués à représenter une letter par un code ASCII. Un “a” est code 97 en décimal et un “A” par 65. Pour le clavier USB, il en est tout autre, un “a” et un “A” sont codés par 4 .

Pour différencier un “a” d’un “A” l’ordinateur “regarde” les autres touches appuyées. Ainsi, si la touché “SHIFT” est enfoncée, on saura que c’est “A”.

On peut ainsi représenter chaque touche du clavier par une valeur

Spécifique, ce qui est impossible en ASCII.

Voir les valeurs dans:

www.freebsdiary.org/APS/usb_hid_usages.php

  12  

Dans Keyboard.c, la fonction principale est très simple, il s’agit d’appel de fonction permettant l’initialisation par interruption ou séquentiellement et par la suite l’appel de la fonction ProcessIO().

Dans la fonction ProcessIO() deux fonctions importtantes sont appelées:

BlinkUSBStatus() : permet les états USB sur les leds

Keyboard() : qui permet d’envoyer le code de touché appuyée

  13  

Void ProcessIO()

{

if ( BlinkStatusValid == TRUE)

{

BlinkUSBStatus();// contrôle les leds suivant l’état USB

}

else

{

CountdownTimerToShowUSBStatusOnLEDs--;

If

(CountdownTimerToShowUSBStatusOnLEDs==0)

{

BlinkStatusValid == TRUE;

}

}

// appelle la fonction qui permet d’envoyer des infos de touché

appuyée

Keyboard();

}// fin ProcessIO()

  14  

La fonction Keyboard() nous permet de visualiser un report descriptor .

  15  

  16