UNIVERSITE D ANTANANARIVO ECOLE SUPERIEURE POLYTECHNIQUE Polytechnique, Premier Partenaire des Professionnels DEPARTEMENTS : GENIE MECANIQUE ET PRODUCTIQUE GENIE ELECTRIQUE FILIERE GENIE INDUSTRIEL s en vue de l obtention du diplôme d ingénieur en Génie Industriel Numéro d ordre : /2010 Intitulé : ETUDE ET CONCEPTION D UN SYSTEME D INTERFACE DU PORT USB DE L ORDINATEUR Présenté et soutenu le 12 Novembre 2011 par : HERIMAMPIONONA Hasindrainy Florent Directeur de mémoire : Monsieur ANDRIAMANOHISOA Hery Zo, Enseignant chercheur à l ESPA Promotion 2010
UNIVERSITE D ANTANANARIVO ECOLE SUPERIEURE POLYTECHNIQUE Polytechnique, Premier Partenaire des Professionnels DEPARTEMENTS : GENIE MECANIQUE ET PRODUCTIQUE GENIE ELECTRIQUE FILIERE GENIE INDUSTRIEL s en vue de l obtention du diplôme d ingénieur en Génie Industriel Numéro d ordre : /2010 Intitulé : ETUDE ET CONCEPTION D UN SYSTEME D INTERFACE D DU PORT USB DE Présenté et soutenu le 12 Novembre 2011 par : HERIMAMPIONONA Hasindrainy Florent Directeur de mémoire : Monsieur ANDRIAMANOHISOA Hery Zo Zo, Enseignant chercheur à l ESPA Président du Jury : Monsieur RAKOTOMANANA Charles Rodin Rodin, Chef du département Génie Mécanique et productique, Enseignant à l ESPA Examinateurs : Ø Monsieur ANDRIAMANALINA William William,, Enseignant à l ESPA Ø Monsieur RAMELINA Lala Arimonjy Arimonjy, Enseignant à l ESPA Ø Monsieur RAVALOMANANA Olivier Olivier,, Enseignant à l ESPA. Promotion 2010
REMERCIEMENTS REMERCIEMENTS Avant tout, je rends grâce à Dieu pour sa bienveillance, soutien, miséricorde et protection tout au long de notre étude ce qui a conduit à l achèvement de cet ouvrage. Ce présent n a pu être achevé sans l intervention de plusieurs personnes. Ainsi, je tiens à adresser mes sincères remerciements à : Monsieur ANDRIANARY Philippe, Directeur de l Ecole Supérieure Polytechnique d Antananarivo de m avoir laissé soutenir mon mémoire de fin d étude; Monsieur RAKOTOMANANA Charles Rodin, à la fois Chef de Département Génie Mécanique et Productique, et président du jury de ce présent mémoire ; Monsieur RAKOTONIAINA Solofohery, Chef de Département Génie électrique ; Monsieur ANDRIAMANOHISOA Hery Zo, Directeur de ce mémoire qui, malgré ses lourdes responsabilités, a bien voulu partager ses connaissances et m encadrer durant toute l élaboration de cet ouvrage ; Aux membres du jury qui ont pris de leur temps pour ce mémoire : Monsieur ANDRIAMANALINA William, Enseignant à l ESPA ; Monsieur RAMELINA Lala Arimonjy, Enseignant à l ESPA ; Monsieur RAVALOMANANA Olivier, Enseignant à l ESPA. Je ne saurais oublier tous les enseignants à l ESPA, surtout de la filière Génie Industriel qui nous ont instruit durant ces cinq ans d études. Mes remerciements sont aussi adressés à ma famille pour leur soutien et encouragement, ainsi qu à tous mes amis et collègues. Mes vifs remerciements aussi à tous ceux qui, de près ou de loin, ont contribué à la réalisation de cet ouvrage. Merci beaucoup. i
TABLES DES MATIERES TABLES DES MATIERES REMERCIEMENTS... i TABLES DES MATIERES... ii LISTE DES TABLEAUX... vi LISTE DES FIGURES... vii LISTE DES ABREVIATONS... ix INTRODUCTION... 1 PARTIE I : CONTEXTE GENERAL... 2 Chapitre 1 : GENERALITES SUR L USB... 3 1.1 PRESENTATION DE L USB... 3 1.2 HISTORIQUE DE L USB... 3 1.3 AVANTAGES DE L UTILISATION DE L USB... 4 1.4 ARCHITECTURE DU BUS USB... 5 1.5 CARACTERISTIQUES MECANIQUES DU BUS USB... 5 1.5.1 Câble... 5 1.5.2 Connecteur... 6 1.6 CARACTERISTIQUES ELECTRIQUES DU BUS USB... 7 1.6.1 Etats sur les lignes de données... 7 1.6.2 Version d un périphérique... 7 1.6.3 Codage NRZI... 8 1.7 CONCLUSION... 9 Chapitre 2 : COMMUNICATION SUR LE PORT USB... 10 2.1 STRUCTURE D UN DEVICE... 10 2.2 MODELE DE COMMUNICATION... 11 2.3 FLUX DE COMMUNICATION... 11 2.3.1 Pipe... 12 ii
TABLES DES MATIERES 2.3.2 Différents types de transfert... 12 2.3.2.1 Transfert de contrôle (Control)... 12 2.3.2.2 Transfert par interruption (Interrupt)... 12 2.3.2.3 Transfert isochrone (Isochronous)... 13 2.3.2.4 Transfert en masse (Bulk)... 13 2.4 ENUMERATION... 13 2.4.1 Définition de l énumération... 13 2.4.2 Principe de fonctionnement... 13 2.5 PROTOCOLE USB... 14 2.5.1 Différents champs d une trame USB... 14 2.5.2 Types de paquet USB... 15 2.6 DESCRIPTEURS... 16 2.7 CONCLUSION... 17 PARTIE II : METHODOLOGIE... 18 Chapitre 3 : PILOTE DE PERIPHERIQUE POUR WINDOWS NT... 19 3.1 GENERALITES SUR WINDOWS NT... 19 3.1.1 Présentation de Windows NT... 19 3.1.2 Architecture de Windows NT... 19 3.1.3 Registre de Windows NT... 20 3.2 PILOTES DE WINDOWS... 21 3.2.1 Présentation du pilote de Windows... 21 3.2.2 Kernel Mode Drivers... 21 3.2.3 WDM... 22 3.2.3.1 Présentation de WDM... 22 3.2.3.2 Architecture de WDM... 22 3.2.3.3 Routines de support pour les drivers de WDM... 23 3.2.3.4 IRQ Level (IRQL)... 24 3.2.3.5 Paquet de demande d E/S... 25 3.2.3.6 Objet de driver et Objet de dispositif... 27 3.2.3.7 Les routines d entrée... 28 iii
TABLES DES MATIERES 3.3 CONCLUSION... 29 Chapitre 4 : CONTROLEUR D USB... 30 4.1 MICROCONTROLEUR... 30 4.2.1 Présentation du Microcontrôleur... 30 4.2.2 Architecture interne d un microcontrôleur... 30 4.2.2.1 Microprocesseur... 31 4.2.2.2 Mémoire programme... 32 4.2.2.3 Mémoire de Données... 32 4.2.2.4 Interface parallèle... 32 4.2.2.5 Interface série... 33 4.2.2.6 CAN... 33 4.2.2.7 Timer... 33 4.2.2.8 Chien de garde... 33 4.2.2.9 Signal d horloge... 34 4.2 DISPOSITIF D E/S DE L USB... 34 4.2.1 Présentation du dispositif d E/S de l USB... 34 4.2.2 Contrôleur d USB... 35 4.2.2.1 Critères de sélection... 35 4.2.2.2 Quelques types de Contrôleur d USB... 35 4.3 CONCLUSION... 36 PARTIE III : IMPLEMENTATIONS ET RESULTATS... 37 Chapitre 5 : IMPLEMENTATIONS... 38 5.1 LA CARTE D INTERFACE... 38 5.1.1 Présentation du projet... 38 5.1.2 PIC 18F4550... 38 5.1.3 Conception de la carte... 40 5.1.3.1 Représentation schématique de la carte... 40 5.1.3.2 Description des composants... 41 5.2 PROGRAMMATION DU PIC... 42 5.2.1 Présentation du firmware... 42 5.2.2 Outils de développement... 43 iv
TABLES DES MATIERES 5.2.3 Firmware... 43 5.2.3.1 Enumération... 43 5.2.3.2 Communication avec le host... 44 5.2.3.3 Structure du programme... 44 5.2.3.4 Compilation du firmware... 47 5.3 DRIVER... 47 5.3.1 Présentation... 47 5.3.2 WDK... 47 5.3.3 Compilation du driver... 48 5.3.4 Programme du driver... 48 5.3.4.1 Fonctions de contrôle... 48 5.3.4.2 Routines du programme... 49 5.3.5 Paquetage... 49 5.4 CONCLUSION... 49 Chapitre 6 : SIMULATION ET RESULTATS... 50 6.1 LOGICIEL GIUSBInterface... 50 6.1.1 Présentation du logiciel... 50 6.1.2 Mode d utilisation du logiciel... 50 6.2 SIMULATION... 51 6.2.1 Définition de la simulation... 51 6.2.2 Raisons de la simulation... 52 6.2.3 Proteus... 52 6.2.4 Circuits de test... 52 6.3 CONCLUSION... 54 CONCLUSION GENERALE... 55 ANNEXE... I BIBLIOGRAPHIE... VI WEBOGRAPHIE... VII v
LISTE DES TABLEAUX LISTE DES TABLEAUX Tableau 1.1 : Avantages de l USB... 4 Tableau 1.2: Brochage des connecteurs... 7 Tableau 2.1 : Différentes couches de l échange via USB... 11 Tableau 2.2 : Récapitulatifs des différents types de transfert... 13 Tableau 2.3 : Désignation des PID... 15 Tableau 2.4 : Format des paquets et Nombre de bits... 16 Tableau 2.5 : Identification des descripteurs... 16 Tableau 3.1 : Composants du mode noyau exposant des routines de support pour les drivers de WDM... 24 Tableau 3.2 : IRQ Levels pour la plateforme x86... 25 Tableau 4.1 : Contrôleurs d USB compatibles avec les familles populaires de microcontrôleurs.. 36 Tableau 5.1 : Valeurs des LEDs en fonction de l état du dispositif... 42 Tableau 5.2 : Les fonctions de contrôle du driver... 48 Tableau 5.3 : Paquetage du driver... 49 vi
LISTE DES FIGURES LISTE DES FIGURES Figure 1.1 : Topologie du bus USB... 5 Figure 1.2 : Câble USB... 6 Figure 1.3 : Section d un câble USB... 6 Figure 1.4 : Différents types de prises USB... 6 Figure 1.5 : Différents types de connecteurs USB... 6 Figure 1.6 : Connexion Low Speed... 7 Figure 1.7 : Connexion Full Speed... 8 Figure 1.8 : Système de transfert et de Codage des données... 8 Figure 1.9 : Principe du codage NRZI... 8 Figure 2.1 : Eléments d un device... 10 Figure 2.2 : Modèle de couche pour la communication USB... 11 Figure 2.3 : Flux de communication de l USB... 12 Figure 2.4 : Diagramme hiérarchique des descripteurs... 17 Figure 3.1 : Architecture de Windows NT... 20 Figure 3.2 : Architecture des couches de WDM... 22 Figure 3.3 : Structure d un IRP... 25 Figure 3.4 : Structure d IRP concernant les locations de la pile... 26 Figure 3.5 : Structure d un objet de driver... 27 Figure 3.6 : Structure d un objet de dispositif... 27 Figure 4.1 : Système à microcontrôleur... 30 Figure 4.2 : Architecture d un microcontrôleur... 31 Figure 4.3 : Configuration d horloge... 34 Figure 4.4 : Schéma fonctionnel d un dispositif d E/S d USB... 34 Figure 5.1 : Schéma fonctionnel de la carte d interface... 38 Figure 5.2 : Vue d ensemble du PIC18F4550... 39 vii
LISTE DES FIGURES Figure 5.3 : Schéma de montage de la carte d interface... 40 Figure 5.4 :Modélisation3D de la carte d interface... 40 Figure 5.5 : Résumé des étapes d énumération... 44 Figure 5.6 : Relation entre les fichiers et les fonctions principales du programme... 45 Figure 5.7 : Organigramme du programme principal... 46 Figure 5.8 : Contenu d un fichier makefile... 48 Figure 6.1 : Icône du logiciel GIUSBInterface... 50 Figure 6.2 : Message montrant le non connexion de la carte... 50 Figure 6.3 : Interface utilisateur du logiciel GIUSBInterface v1.00... 51 Figure 6.4 : Circuit à 8 LEDs... 53 Figure 6.5 : Circuit à 8 interrupteurs... 53 Figure 6.6 : Circuit à LEDs... 53 Figure 6.7 : Circuit à potentiomètres... 54 viii
LISTE DES ABREVIATIONS LISTE DES ABREVIATONS Abréviation ADDR ALU CAN CISC CNA CPU CRC DDI DMA DOS EEPROM EISA ENDP EOP EPROM E/S: FDO FiDO FIFO FILO HAL HID ICSP IDE IOCTL IRQ IRQL ISA IRP LSB Désignation Address Arithmetical and Logical Unit ou Unité Arithmétique et Logique Convertisseur Analogique Numérique Complex Instruction Set Computer Convertisseur Numérique Analogique Central Processing Unit ou Unité Centrale de Traitement Cyclic Redundancy Check Device Driver Interfaces Direct Memory Access Disk Operating System Electrically EPROM Enhanced Industry Standard Architecture Endpoint End Of Packet Erasable PROM Entrée/Sortie Function Device Object Filter Device Object First In First Out ou Première Entrée Première Sortie First In Last Out ou Première Entrée Dernière Sortie Hardware Abstraction Layer ou Couche d Abstraction Materielle Human Interface Driver In Circuit Serial Programming Integrated Development Environment I/O Control Code Interrupt ReQuest ou Demande d Interruption IRQ Level Industry Standard Architecture I/O Request Packet Least Significant Bit ix
LISTE DES ABREVIATIONS MIDI NT NYET OLE OS PC PCB PCI PDO PID PID PROM PWM RAM RISC ROM SCSI SIE SOF SYNC USB USBD VID WDK WDM Musical Instrument Digital Interface New Technology No response Yet Object Linking and Embedding Operating System ou Système d Exploitation Personal Computer Printed Circuit Board Peripheral Component Interconnect Physical device Object Paquet ID Product ID Programmable ROM Pulse Width Modulation Random Access Memory Reduced Instruction Set Computer Read Only Memory Small Computer System Interface Serial Interface Engine Start Of Frame Synchronisation Universal Serial Bus USB Driver Vendor ID Windows driver Kit Windows Driver Model x
INTRODUCTION INTRODUCTION Depuis l apparition des premiers PC (Personal Computer) ou ordinateurs, la connexion avec les périphériques extérieures s est révélée indispensable. Les connecteurs se sont évolués suivant les besoins des utilisateurs comme : la vitesse de transfert, la longueur et le coût des câblages nécessaires à la communication, la fiabilité et la sécurité, et d autres critères facilitant la communication entre le PC et les dispositifs extérieurs. Actuellement l USB «Universal Serial Bus» a supplanté les anciens ports d interfaçage comme le port parallèle, le port série RS-232, le port PS/2, le port joystick (ou port MIDI : Musical Instrument Digital Interface), le port SCSI (Small Computer System Interface), et même des bus internes comme PCI (Peripheral Component Interconnect) pour la connexion de certains dispositifs (par exemple cartes son ou cartes de réception TV). Ainsi il devient un standard surtout les PC, et aussi il satisfait les besoins des utilisateurs. C est pourquoi, ce présent mémoire intitulé : «Etude et conception d un système d interface du port USB de l ordinateur» a pour objectif d étudier le protocole de communication sur le bus USB afin de développer un système capable de contrôler totalement le transfert et l acquisition de données sur le port USB. Pour se faire, notre étude se subdivisera comme suit en trois grandes parties : La première s intéresse au contexte général s affairant aux généralités sur le bus USB et la communication sur ce bus ; La seconde partie relate les méthodologies, dans laquelle on étudiera le pilote de périphérique pour Windows NT et le contrôleur d USB ; Et enfin, la dernière, implémentation et résultats, qui exposera la réalisation du système et une simulation pour tester notre système. 1
CONTEXTE GENERAL PARTIE I : CONTEXTE GENERAL 2
GENERALITES SUR L USB Chapitre 1 : GENERALITES SUR L USB Actuellement, parmi les divers ports d interfaçage de l ordinateur, l USB est le plus utilisé et même le plus avancé. Il est aussi employé dans plusieurs applications. Ainsi, il est important de connaître les raisons de sa situation actuelle. Ce premier chapitre consiste à donner une aperçue générale de l USB, et de présenter ses avantages, son architecture et ses divers caractéristiques. 1.1 PRESENTATION DE L USB L USB est une norme relative à un bus de transmission, servant à connecter des périphériques informatiques au PC. Le bus USB s'est répandu de façon très significative ces dernières années, que ce soit dans les applications grand public (imprimantes, scanners, appareils photos) ou dans les applications professionnelles (programmateurs, automates, appareils de mesure). Les raisons principales de son architecture série sont : L'interface série permet d'utiliser une cadence d'horloge beaucoup plus élevée qu'une interface parallèle (dans une architecture parallèle à haut débit, les bits circulant sur chaque fil arrivent avec des décalages temporels, provoquant des erreurs). La connexion série est plus économique que la connexion parallèle de part la simplicité des connecteurs et du faible nombre de conducteurs du câble. 1.2 HISTORIQUE DE L USB Au milieu des années 1990, pour remplacer plusieurs ports externes lents et incompatibles du PC, l USB a été conçu. Ensuite au fur à mesure que les technologies s avancent, différentes versions de la norme sont développées. Le standard USB a été élaboré par l alliance de sept partenaires industriels (Compaq, DEC, IBM, Intel, Microsoft, NEC et Northern Telecom). La première version de la norme, l USB 1.0, voit ses spécifications publiées en 1996. Puis la version USB 1.1 lui apporte des corrections en 1998. Dans ces normes, deux vitesses de communication sont possibles : 1,5 Mbit/s (faible vitesse, ou Low Speed), et 12 Mbit/s (soit 1.5 Mo/s, pleine vitesse ou Full Speed). En 2000 sort la version USB 2.0 qui apporte des communications à 480 Mbit/s (60 Mo/s, haute vitesse ou High Speed). En 2005, le Wireless USB Promoter Group publie les spécifications d'une version sans-fil de l'usb : le Wireless USB. En 2008 c'est au tour de l'usb 3.0 de voir ses spécifications publiées. Elle introduit les communications à 4,8 Gbit/s (soit env. 600 Mo/s, vitesse supérieure ou Super Speed). Les nouveaux 3
GENERALITES SUR L USB périphériques disposeront de connexions à 8 contacts au lieu de 4, mais la compatibilité ascendante des prises et des câbles avec les versions précédentes est assurée. L'introduction de l'usb 3.0 dans des produits grand public a commencé en début de l année 2010. 1.3 AVANTAGES DE L UTILISATION DE L USB L utilisation du port USB nous procure plusieurs avantages qui sont résumés dans le tableau 1.1 suivant : Tableau 1.1 : Avantages de l USB Avantage Description Faible coût L USB fournit un faible coût d interfaçage au PC. Branchement et Débranchement à chaud sans arrêter le PC. Hot Plug and Play L USB détecte automatiquement la connexion d un dispositif, le système configure automatiquement ce dernier pour l utilisation immédiat. (PnP) Le PC définit un simple connecteur pour attacher tous les dispositifs. Simple type de Possibilités de connecter un Hub (concentrateur) au port existant, dans le but d y connecteur connecter plus de périphériques USB. 127 périphériques Supportant la connexion jusqu à 127 périphériques sur le bus USB. L USB supporte les vitesses suivantes : Low Speed à 1.5 Mbit/s (USB 1.0); Plusieurs vitesses Full Speed à 12 Mbit/s (USB 1.1); High Speed à 480 Mbit/s (USB 2.0); Super Speed à 4.8 Gbit/s (USB 3.0). Un périphérique peut être alimenté directement par le câble. Cable Power Une tension de 5 VDC est fournie par le PC, le courant est de 100 à 500 ma selon le HUB. Au contraire de ceux d EISA (Enhanced Industry Standard Architecture), ISA Condition de (Industry Standard Architecture), et PCI ; les dispositifs d USB n exigent aucune ressource du adresse mémoire ou adresse E/S (I/O Address) et n ont pas besoin de lignes système éliminée d interruption. Fiabilité et Sécurité les transactions d USB comprennent des mécanismes de détection d erreurs, qui (Détection et sont utilisés pour s assurer la délivrance sans erreur des données, et réessayer les Correction d erreurs) transactions en cas d erreurs. Mode veille : Suspension automatique du périphérique après 3 ms, quand il n est Power conservation plus utilisé, avec réduction à 500 µa de la consommation en courant du composant. L USB définie 4 types de transferts pour supporter les différents caractéristiques Quatre types de de transfert exigés par les dispositifs : mode Contrôle, Interruption, Isochrone, et transferts Transfert en mode Bloque. Capacité de prolonger le bus On peut installer des Concentrateurs d USB pour avoir plus de ports, ainsi permettant d attacher plus de dispositifs. 4
GENERALITES SUR L USB 1.4 ARCHITECTURE DU BUS USB Les connexions sont faites point à point. Tous les appareils ont une connexion amont vers un unique host (hôte) généralement le PC. C est ce dernier qui gère le fonctionnement du bus. Figure 1.1 : Topologie du bus USB L USB utilise une topologie en étoile série (tiered star) : supportant cinq niveaux (tier) de hubs en plus du hub racine qui est implémenté dans l host. Des périphériques au nombre maximum de 127 sont connectés à ces hubs. Les ports dirigés vers les appareils sont appelés ports descendants (Downstream) et ceux dirigés vers l'hôte ports montants (Upstream). Chaque hub contient un contrôleur surveillant les différents ports et qui rend des comptes à l'hôte. Ce dernier interroge les contrôleurs de hubs afin de connaitre les connexions et les déconnexions des périphériques (Function). Lorsqu un appareil est connecté, l'hôte l'identifie et lui assigne une adresse unique : c'est la phase d'énumération. Pour la connexion d'un hub, il y a énumération de tous les appareils en aval. L'hôte attribue également la bande passante en fonction des types de transferts requis par les appareils. Un hub accepte des appareils à basse et pleine vitesse sur ses ports descendants, mais le trafic est celui défini par sa norme (1.1 ou 2.0). La figure 1.1 illustre cette topologie. 1.5 CARACTERISTIQUES MECANIQUES DU BUS USB 1.5.1 Câble Le câble est composé de quatre fils : une paire torsadée (D- et D+) pour les données, elle utilise le principe de transmission différentielle afin de garantir une certaine immunité aux bruits 5
GENERALITES SUR L USB parasites de l environnement physique du périphérique ou de son câble, et une paire électrique (Vbus et GND) pour l alimentation 5 V. Un blindage est indispensable pour une utilisation à haute vitesse. La longueur maximale est 5 m. Ces caractéristiques sont détaillées sur les figures ci-dessous (figure 1.2 et figure 1.3) et le tableau 1.2. Figure 1.2 : Câble USB Figure 1.3 : Section d un câble USB 1.5.2 Connecteur L USB utilise essentiellement deux types de connecteurs : Type A : de forme plate, se trouvant sur les ports montants (host, hubs) ; Type B : de forme carrée, se trouvant sur les ports descendants (appareils). Les câbles de connexion ont toujours une extrémité de type A mâle, et une extrémité de type B mâle, ce qui garantit le respect de la topologie du bus. Au départ, il n existe que quatre connecteurs, pour deux types (A et B) et deux genres. Par la suite, devant le développement d'appareils compacts, des versions miniatures qui sont fonctionnellement équivalente aux connecteurs de base, mais de dimensions réduites ont été spécifiées. Ces différents types de connecteurs sont présentés par les figures ci-dessous (figure 1.4 et figure 1.5). Figure 1.5 : Différents types de connecteurs USB Figure 1.4 : Différents types de prises USB Le brochage de ces connecteurs est décrit par le tableau 1.2 ci-après : 6
GENERALITES SUR L USB Fonction Alimentation +5V (Vbus) 500 ma maximum Tableau 1.2: Brochage des connecteurs Couleur Numéro de broche pour les types A et B Numéro de broche pour les types mini Rouge 1 1 Données (D-) Blanc 2 2 Données (D+) Vert 3 3 Masse (GND) Noir 4 5 1.6 CARACTERISTIQUES ELECTRIQUES DU BUS USB 1.6.1 Etats sur les lignes de données Les lignes de données D+ et D- fonctionnent en mode différentiel. Les circuits doivent avoir un état haut impédance ; les lignes doivent résister à un court-circuit avec Vbus ou la masse (GND). Selon la norme USB, il existe trois états sur les lignes du bus : Etat J : D+ - D- < -200 mv, indiquant un périphérique connecté ou un état inoccupé ; Etat K : D+ - D- > 200 mv, indiquant un périphérique débranché ; Etat SEO : -200mV < D+ - D- < 200 mv, indiquant un reset. 1.6.2 Version d un périphérique Pour utiliser l une des deux versions d USB : Low Speed ou Full Speed, et pour permettre le hub amont à détecter la connexion ou la déconnexion, on doit placer une résistance de tirage (Pull Up de 1.5 kω) sur l interface d entrée (Function ou Hub). Cette résistance est placée soit sur D- pour Low Speed et D+ pour Full Speed. D autre part, il y a une résistance sur chacune des lignes D+ et D- (Pull Down de 15 kω) à la sortie du hub. Ces détails sont éclaircis par les figures suivantes (figure 1.6 et figure 1.7). Figure 1.6 : Connexion Low Speed 7
GENERALITES SUR L USB Figure 1.7 : Connexion Full Speed 1.6.3 Codage NRZI Le codage NRZI «No Return to Zero Inverted» ou Non-Retour à Zéro Inversé est uniqueles bruits et assurer ment utilisé pour le transport à travers le cordon USB dans le but d éliminer l intégrité des données. Le codage est d abord effectué par le codeur, puis les données codées sont envoyées sur le câble USB par le «Differential Driver». Ensuite le «Differential Receveir» amplifie les données différentielles entrantes et les envoie au décodeur. Ces étapes de transfert de données sont décrites par la figure 1.8. Figure 1.8 : Système de transfert et de Codage des données Ce codage a pour principe : un «1» logique est représenté par un nom changement d état et un «0» logique par un changement d état. Pour éviter les pertes de données, le codage utilise le Bit Stuffing en mettant un «0» après 6 «1» logique. La figure 1.9 ci-dessous illustre ce système de codage. Figure 1.9 : Principe du codage NRZI 8
GENERALITES SUR L USB 1.7 CONCLUSION Dans ce chapitre, on a vu la généralité sur l USB comme : les avantages qu il fournit aux utilisateurs, ses divers caractéristiques, et aussi bien son architecture. Cela nous a permis d avoir quelques notions pour commencer avec l USB. Dans le prochain chapitre, on va tenter d approfondir nos connaissances sur la communication avec le port USB. 9
COMMUNICATION SUR LE PORT USB Chapitre 2 : COMMUNICATION SUR LE PORT USB En dépit de tous les avantages qu on avait vu auparavant, la communication avec le port USB est beaucoup plus difficile par rapport aux autres interfaces de communication. L USB est composé de plusieurs couches de protocoles et son format de données à transmettre est bien défini. Ce second chapitre s étalera sur la communication avec le port USB. Il va nous montrer : la structure d un device, le modèle et les flux de communication, l énumération et enfin le protocole USB et les descripteurs. 2.1 STRUCTURE D UN DEVICE Un USB device (dispositif utilisant le port USB) peut avoir plusieurs configurations, mais une dans une période ; et pour changer de configuration, le fonctionnement du device doit être arrêté. On peut employer diverses configurations, par exemple, pour définir les différentes conditions courantes, alors que l actuel nécessaire est défini dans le descripteur de configuration. Cependant, le fait d avoir beaucoup de configuration n est pas courant. Les drivers standards de Windows choisissent toujours la première configuration, donc il n y a pas beaucoup de points. Un dispositif peut avoir une ou plusieurs interfaces, et chacun peut avoir un certain nombre d endpoints (terminaisons) et représente une unité fonctionnelle appartenant à une classe particulière. Chaque endpoint est une source de donnée ; il peut seulement être dans une interface, mais aussi peut être utilisé dans les remplacements multiples dans cette interface. Un appareil basse vitesse est limité à deux endpoints optionnels en plus de l endpoint numéro zéro, qui est obligatoire. A part l endpoint numéro 0, un appareil plein vitesse peut avoir 15 montantes et 15 descendantes. Cette structure est illustrée par la figure 2.1 suivante. DEVICE CONFIGURATION CONFIGURATION Interface Interface Interface Interface Endpoint Endpoint Endpoint Endpoint Endpoint Endpoint Endpoint Endpoint Figure 2.1 : Eléments d un device 10
COMMUNICATION SUR LE PORT USB 2.2 MODELE DE COMMUNICATION On peut représenter les échanges via USB en trois couches bien distinctes chez le host et chez les devices. Le tableau 2.1 ci-après décrit ces différentes couches avec leurs fonctions. Le client driver communique les requêtes de transfert des applications via des IRP (I/O Packet). Puis, l USBD (USB Driver) traduit chaque transfert en une suite de transactions. Ensuite l USB HCD (Host Controller Driver) traduit les transactions en paquets et enchaîne les trames. Tableau 2.1 : Différentes couches de l échange via USB Couche Host Device Fonctions 1 USB Host USB Bus Assure la connexion physique vers le bus arborescent USB. Controller interface 2 USB Réalise l étoile logique entre le maître et les USB device System différents dispositifs, et définit les transactions. 3 Client Function Permet d établir une relation fonctionnelle unique avec le dispositif. La liaison entre ces différentes couches est décrite par la figure 2.2 ci-dessous. Figure 2.2 : Modèle de couche pour la communication USB 2.3 FLUX DE COMMUNICATION Pour les différents flux de communication, le système USB crée des pipes (canaux virtuels). Les pipes de type contrôle sont bidirectionnels, les autres sont unidirectionnels. Chaque canal aboutit au device sur un endpoint. Un device possède plusieurs endpoints, et est toujours relié à l hôte au moins par le canal par défaut aboutissant à l endpoint numéro 0, qui est bidirectionnel. Pour les autres endpoints, il peut y avoir deux pipes : montant et descendant. 11
COMMUNICATION SUR LE PORT USB La figure 2.3 illustre plus de détails sur la circulation des flux, ainsi que sur les éléments mis en jeu dans cette opération. Figure 2.3 : Flux de communication de l USB 2.3.1 Pipe Une pipe est une connexion logique entre le host et les endpoints. Les pipes possèdent plusieurs paramètres comme : le nombre de leur bande passante, le type de transfert, la direction des flux et les tailles maximales des paquets/tampon. L USB définit deux types de pipe tels que : Les flux de données (Stream Pipes) : n ayant pas de format USB défini ; supportant les transferts en bloc, isochrone et par interruption. Ces flux peuvent être contrôlés par le host ou le device. Les canaux de messages (Message Pipes) : ayant un format USB défini, supportant seulement les transferts de commande. Ils sont contrôlés par le host, et initiés par une requête qui y provient. 2.3.2 Différents types de transfert L USB définit quatre types de transfert, qui sont les suivants. 2.3.2.1 Transfert de contrôle (Control) Ce mode de transfert est compatible avec l USB Low et Full Speed, et est employé pour les opérations d initialisations et de configurations. On peut aussi l utiliser pour les transferts standards, pour l obtention d un débit Low Speed acceptable, ou pour utiliser le driver de classe HID (Human Interface Driver) standard. 2.3.2.2 Transfert par interruption (Interrupt) Ce mode de transfert est aussi compatible avec le Low et Full Speed USB. Il est utilisé pour les échanges limités et périodiques, il assure la fréquence de scrutation ainsi que la re- 12
COMMUNICATION SUR LE PORT USB prise sur les erreurs. On l emploie aussi pour des transferts à l initiative du device (asynchrones) et pour des transferts périodiques ou permanents comme les claviers. 2.3.2.3 Transfert isochrone (Isochronous) Ce mode de transfert est particulièrement pour le Full USB. La bande passante est garantie (début, latence), par contre il n y a pas de reprise sur les erreurs. Il est utilisé pour des transferts nécessitant un flux régulier de données (ex : les caméras ou les téléphones, ). La bande passante réclamée et non utilisée est perdue. 2.3.2.4 Transfert en masse (Bulk) Ce mode de transfert est spécialement pour le Full USB. Ce mode est réservé pour les gros transferts de données (ex : imprimantes, ). Le débit est variable et dépend de la disponibilité. Il garantit la reprise sur les erreurs. Le tableau 2.2 suivant résume ces différents modes de transfert avec leurs caractéristiques. Tableau 2.2 : Récapitulatifs des différents types de transfert Type Control Contrainte sur la taille maximale du bloc de données Full speed : 8, 16, 32, 64 octets par trame Low speed : 8 octets par trame Isochronous Full speed : 1023 octets par trame Interrupt Bulk Full speed : 64 octets par trame Low speed : 8 octets pas trame Full speed : 8, 16, 32, 64 octets par trame Accusé de réception et reprise sur erreur OUI NON OUI OUI Bande réservée 10% de la trame «best effort» 90% de la trame «guaranteed» Non «good effort» 2.4 ENUMERATION 2.4.1 Définition de l énumération L énumération est la gestion dynamique de la connexion et de la déconnexion des périphériques reliés à un port USB.C est aussi un processus USB par lequel le système identifie et configure le device en lui donnant une adresse unique. 2.4.2 Principe de fonctionnement La phase d énumération se produit lors d une connexion de périphérique, et elle est complètement transparente. Après la connexion d un périphérique USB, il y a une succession des étapes suivantes : 13
COMMUNICATION SUR LE PORT USB Détection : le host détecte le device par sa vitesse (Section 1.6) grâce au changement de la différence de potentiel entre D+ et D-, et lui fournit du courant grâce aux fils GND et Vbus (jusqu à 100 ma). Ensuite le périphérique récupère l adresse par défaut (adresse 0). Changement d adresse : le host interroge les devices déjà connectés pour connaitre la leur, et en attribue une adresse unique (Unique ID) au nouveau, qui en retour s identifie. Chargement du driver : en possédant toutes les caractéristiques nécessaires par les descripteurs, le host charge le pilote et positionne le périphérique. 2.5 PROTOCOLE USB L USB est constitué de diverses couches de protocole. Elles sont invisibles au constructeur, cette invisibilité est assurée par les microcontrôleurs (s occupant de la couche inférieure) spécifiques à l USB. Toutes les transactions sur le bus USB sont initiées par le host, et commencent par le bit le moins significatif (LSB : Least Significant Bit) en premier. Ces transmissions s accomplissent à l aide des paquets : paquets de jetons, paquets de données et paquets d états. 2.5.1 Différents champs d une trame USB Les paquets USB sont composés des champs suivants : SYNC (Synchronisation) : c est le début de tous les paquets, de longueur 8 bits pour Low USB ou 32 pour Full USB. Il assure la synchronisation de l horloge du récepteur avec celle de l émetteur/récepteur. Ces 2 derniers bits indiquent l'endroit où commence le champ PID. PID (Paquet ID) : utilisé pour l identification du type de paquet envoyé (tableau 2.3). ADDR (Address) : détermine l adresse du périphérique auquel est destiné le paquet, avec une longueur de 7 bits (supportant 127 devices). ENDP (Endpoint) : indique le numéro de l endpoint du device (Section 2.1), composé de 4 bits. CRC (Cyclic Redundancy Check) : Contrôle de Redondance Cyclique, il s agit d une suite de bits permettant de vérifier si les données ont été transférées sans erreur. Tous les paquets de jetons ont un CRC de 5 bits, tandis que les paquets de données en ont un de 16 bits. EOP (End Of Packet) : Fin de Paquet qui est signalé par une sortie unique zéro (SE0) pendant une durée approximative de 2 bits suivie par un «J» d'une durée de 1 bit. 14
COMMUNICATION SUR LE PORT USB Le tableau 2.3 suivant montre ses valeurs des possibles PID et ses désignations. Groupe Token (Jetons) Data (Données) Handshake (Poignée de Main) Special Tableau 2.3 : Désignation des PID Valeur PID Identificateur Paquet Description 0001 OUT Token Données du host pour le device 1001 IN Token Données du device pour le host 0101 SOF Token Start Of Frame, Début de Trame 1101 SETUP Token Installation et Configuration 0011 DATA0 Paquet de données pair 1011 DATA1 Paquet de données impair 0111 DATA2 Paquet de données Full Speed 1111 MDATA Paquet de données Full Speed pour transactions «Split» 0010 ACK Handshake ACKnowledge, Validation 1010 NAK Handshake No ACKnowledge, Pas de Validation, Device occupé 1110 STALL Handshake Bloqué, Endpoint ou Pipe hors service 0110 NYET (No response Yet) Pas de Validation Full Speed 0000 PREamble Synchronisation initiale 1100 ERR Erreur transmisse par un hub haute vitesse dans une transaction «Split» 1000 Split Partager, Transaction avec un hub Full Speed 0100 Ping S'assurer une bonne connexion 2.5.2 Types de paquet USB L USB dispose 4 différents types de paquets : Paquets TOKEN : indiquant le type de la transaction suivante ; Paquets DATA : contenant la charge utile (PAYLOAD) ; Paquets HANDSHAKE : utilisés pour valider les données ou rapporter les erreurs ; Paquets SOF (SOF : Start Of Frame ou début de trame) : indiquant le début d une nouvelle trame. Ces types de paquets sont résumés par le tableau 2.4 avec leurs champs avec ses tailles en bit. 15
COMMUNICATION SUR LE PORT USB Tableau 2.4 : Format des paquets et Nombre de bits Paquets Champs et taille (en bits) TOKEN (IN, OUT, SETUP) SYNC PID (8) ADDR (7) ENDP (4) CRC (5) EOP DATA (Data0, Data1, DATA2, MDATA) SYNC PID (8) DATA (0-8192) CRC (16) EOP HANDSHAKE (ACK, NACK, STALL) SYNC PID (8) EOP SOF SYNC PID (8) Frame Number (11) CRC (5) EOP 2.6 DESCRIPTEURS Les descripteurs sont des blocs d informations pré formatés. Tous les composants USB doivent obligatoirement posséder des descripteurs standards. Ils sont regroupés dans un fichier texte (ex : fichier assembleur), qui est ensuite programmé dans le système USB. Ces informations sont stockées dans la ROM (Read Only Memory) du composant. Ainsi lors de la phase d énumération, le device envoie le fichier pour se faire identifier et se faire configurer. Il existe plusieurs types de descripteurs, dont 4 de ces types sont indispensables (Device, Configuration, Interface, Endpoint).Le tableau 2.5 montre les divers types de descripteurs avec leurs rôles. Tableau 2.5 : Identification des descripteurs Type Valeur Description Device 0x01 Décrit les informations générales sur l USB device. Configuration 0x02 Renseigne sur les divers états de l USB device. Interface 0x03 Communique une information unique à tous ses endpoints. String 0x04 Contient des textes (Unicode string) décrivant le device, la configuration, et l interface ou l endpoint. Endpoint 0x05 Indique la direction et le type de transfert. Device_Qualifier 0x06 Information de Configuration pour Full et High Speed. Other_Speed_Configuration 0x07 Descripteur de Configuration pour Full et High Speed. Interface_Power 0x08 Informations sur la gestion d énergie (pour l USB 2.0). 16
COMMUNICATION SUR LE PORT USB La figure 2.4 suivante décrit la hiérarchie de ces différents descripteurs. Figure 2.4 : Diagramme hiérarchique des descripteurs Remarque : L identification d un nouveau périphérique USB durant la phase d énumération est rendue possible grâce au couple VID (Vendor ID) et PID (Product ID) dont : VID : valeur codée sur 16 bits, qui est donnée par le fabricant du composant ; PID : valeur codée sur 16 bits, qui est faite par le constructeur du dispositif. 2.7 CONCLUSION Nous avons vu dans ce chapitre le protocole USB, quelques étapes de communication et divers éléments nécessaires à ces étapes. Ce chapitre nous a permis de savoir les notions de base sur la communication via USB. Ainsi, dans le prochain chapitre, on essayera d élargir nos connaissances sur le pilote de périphérique de Windows NT. 17
METHODOLOGIE PARTIE II : METHODOLOGIE 18
PILOTE DE PERIPHERIQUE POUR WINDOWS NT Chapitre 3 : PILOTE DE PERIPHERIQUE POUR WINDOWS NT Après avoir étudié ce qu est l USB et son protocole de communication, ce chapitre traitera le pilote de périphérique pour Windows NT. On va commencer par les généralités sur Windows NT, qui se portent sur l architecture et la base de registre de Windows NT. Et enfin, on terminera sur le pilote de Windows, avec le modèle de développement de pilote WDM. 3.1 GENERALITES SUR WINDOWS NT 3.1.1 Présentation de Windows NT Windows NT «New Technology» est un système d exploitation (OS : Operating System) développé par Microsoft indépendamment du système historique MS-DOS (DOS : Disk Operating System, 16 bits). Les OS tels que : Windows 2000, XP, Vista et Windows 7 sont basés sur Windows NT. L OS Windows NT détient les caractéristiques suivantes : Orienté objet : les processus, les threads, et même les fichiers sont tous des objets ; Multitâche préemptif : il est capable d'exécuter plusieurs applications et plusieurs processus sur une même machine; Multiutilisateur : il peut être utilisé par beaucoup d utilisateurs en même temps ; Multiprocesseur : il autorise l utilisation de plusieurs (2 à 32) processeurs en parallèle. 3.1.2 Architecture de Windows NT Le système NT travaille dans deux modes de fonctionnement : Kernel mode (mode noyau) : ou mode système, qui nous permet l exécution de toutes les instructions, même les instructions privilégiées. Et on peut accéder à toutes les ressources de la machine sans restriction; User mode (mode utilisateur) : ou mode application, qui pour des raisons de sécurité, n autorise pas l accès et l utilisation des instructions privilégiées directement à toutes les ressources de la machine. Il est imposé de passer par des appels système qui contrôleront et effectueront les opérations demandées, en particulier tous les accès au matériel. Windows NT est formé par une superposition de couches (figure 3.1), et met à disposition des fonctions pour la communication entre les couches, qui sont : Matériel ; 19
PILOTE DE PERIPHERIQUE POUR WINDOWS NT Couche d abstraction matérielle (HAL : Hardware Abstraction Layer) : fournissant des fonctions pour accéder au matériel (temporisateurs, bus, DMA, contrôleurs d interruption, ) ; Noyau (kernel), le gestionnaire d Entrée/Sortie (I/O Manager) et les pilotes de périphériques (device drivers). Le noyau gère les interruptions et les exceptions, l ordonnancement des threads, les synchronisations entre les processus et la gestion du temps (time keeping ) ; NT Exécutive : qui gère la mémoire virtuelle, les processus, les communications interprocessus, la sécurité, les objets et les entrées-sorties ; Couches tournant en User mode : qui sont des sous-systèmes regroupant diverses interfaces : Win32, OS/2, POSIX et les applications utilisateur. Figure 3.1 : Architecture de Windows NT 3.1.3 Registre de Windows NT Le registre de Windows (ou BDR : Base De registre) est une base de données utilisée par l OS. Il contient les informations et la configuration de tous les matériels, des logiciels, des utilisateurs et de la personnalisation du PC. La BDR est composée par cinq branches principales, dont chacune de ces branches contient une partie spécifique de l information qui y est stockée. Ces éléments sont les suivants : HKEY_CLASSES_ROOT (HKCR) : comporte les mappages d associations de fichiers pour assurer la fonction de glisser-déposer, l information OLE (Object Linking and Embedding), les raccourcis et l aspect cœur de l interface utilisateur Windows ; 20
PILOTE DE PERIPHERIQUE POUR WINDOWS NT HKEY_CURRENT_USER (HKCU) : contient les informations concernant l utilisateur actuellement en session dans le PC. Cette branche est liée à HKEY_USERS; HKEY_LOCAL_MACHINE (HKLM) : renferme les informations qui sont générales à tous les utilisateurs du PC comme : le matériel, la sécurité, le logiciel et le système ; HKEY_USERS (HKU) : comprend les informations spécifiques à chaque utilisateur ; HKEY_CURRENT_CONFIG (HKCC) : contient les informations de la configuration courante. Elle est liée à la branche HKEY_LOCAL_MACHINE. 3.2 PILOTES DE WINDOWS 3.2.1 Présentation du pilote de Windows Un pilote est un programme qui permet à l OS de gérer le matériel, et jouant l'intermédiaire de la communication entre le système et le device. Pour faciliter cette communication, le système d exploitation fournit un support d interface abstrait appelé «driver model» pour les périphériques. Ce support fonctionne comme tous les services fournis par le système. Windows NT possède deux types de drivers : User Mode Drivers : exécutés en user mode, fournissant une interface entre les applications Win32 et les kernel mode drivers ou d autres composants de l OS ; Kernel Mode Drivers : exécutés en kernel mode en tant qu éléments de NT Exécutive. Dans le cadre de notre travail, on va consacrer notre étude sur les kernel mode drivers. 3.2.2 Kernel Mode Drivers Les kernel mode drivers fonctionnent entièrement dans l espace du noyau, et sont capable de communiquer et de transférer des données directement aux éléments du kernel mode. Ce qui veut dire qu ils peuvent dévier les composants intermédiaires entre l utilisateur et l espace du noyau. Les tâches impliquant les éléments du kernel mode sont plus rapide lorsqu ils sont effectués par un kernel mode driver que par un user mode driver. L exécution d un driver dans le noyau est performante. En outre, la panne d un kernel mode driver peut entraîner le plantage du système entier, tandis que celle de l user mode driver entraîne seulement le plantage du processus courant. Les kernel mode drivers partagent plusieurs des objectifs de conception de Windows NT, en particulier ceux de la gestionnaire d Entrée/Sortie (E/S). Ces buts sont les suivants : Portabilité : de plateforme en plateforme ; Configuration : en terme matériel et logiciel, avec le support total pour le bus et les dispositifs PnP ; Préemptible et Interruptible : le code d E/S ne doit jamais être bloqué, et doit toujours être écrit en thread sûr ; 21
PILOTE DE PERIPHERIQUE POUR WINDOWS NT Multiprocesseur assuré : le même code d E/S doit fonctionner sur des configurations de multiprocesseur et d uniprocesseur ; Basé sur des objets : les services fournis par le code d E/S doivent être offerts en structures de données encapsulées avec des opérations autorisées et bien définies ; Packet-driven : les requêtes faites par le sous ensemble d E/S doivent être soumises et dépistées en utilisant le paquet de demande d E /S (IRP : I/O Request Packet) ; Capable de supporter l E/S Asynchrone : les requêtes faites par le sous ensemble d E/S doivent être autorisées à s exécuter en parallèle avec l exécution du demandeur. Quand la demande est finalement accomplie, un mécanisme doit exister pour informer le visiteur de cet accomplissement. 3.2.3 WDM 3.2.3.1 Présentation de WDM Le WDM (Windows Driver Model) est une framework (charpente d une application) pour développer des drivers. Son principal objectif est de fournir une plateforme plus robuste pour les OS de Microsoft Windows et des meilleures expériences d utilisateur avec le nouveau matériel pour Les PC basés sur Windows. Le WDM a été conçu spécialement pour les kernel mode drivers, tournant sur Windows 98, Millenium et NT. Il utilise les interfaces DDI (Device Driver Interfaces), qui sont exportées directement du noyau du système d exploitation pour avoir plus de performance. 3.2.3.2 Architecture de WDM Figure 3.2 : Architecture des couches de WDM 22
PILOTE DE PERIPHERIQUE POUR WINDOWS NT Le WDM est composé de trois types de driver qui sont respectivement présentés par des objets. La communication entre une application et le driver se fait par l IRP. A chaque demande, l I/O Manager construit un IRP, et le passe vers le bas du driver. Le WDM doit aussi supporter : le Plug and Play, le Power Manager, et le Windows Management Instrument (voir section 3.2.3.3). Cette architecture de WDM est illustrée par la figure 3.2, et ce sont ces composants : Bus Drivers : permettant le fonctionnement d un bus particulier (comme le PCI, l USB, IEEE12394 et SCSI, ). Un bus driver est représenté par le PDO (Physical device Object) ou périphérique physique.ils énumèrent et contrôlent les dispositifs qui y sont rattachés ; Function Drivers : mettent en application la fonctionnalité d un dispositif et entretiennent les requêtes d E/S (Read, Write, IoCtl). On n oublie pas aussi qu un function driver est représenté par FDO (Function Device Object) ; Filter Drivers : sont des pilotes facultatifs qui sont situés entre les bus drivers et les function drivers (Lower Filter Drivers), ou au-dessus des function drivers (Upper Function Drivers). Leur fonction de base est de traiter les données échangées entre les couches. Le filter driver est représenté par FiDO (Filter Device Object). Class Driver : est en général donné par Microsoft, il fournit un support exigé par le système, mais qui est indépendant du matériel pour la classe de dispositif. Miniclass Driver : est habituellement fourni par le vendeur de matériel dans le but d intégrer n importe quelle fonctionnalité unique que le device peut avoir ; Port Driver : fournit les opérations d E/S demandées sur le port, le hub, ou d autre dispositif physique sur lequel est attaché un dispositif. Miniport Driver : effectue des opérations spécifiques de périphérique pour le port driver. Il est fourni par le vendeur du dispositif ; Hardware Bus Driver : fournit par Microsoft en tant qu élément de l OS pour chaque bus principal. Ce type de driver ne devra pas être changé. 3.2.3.3 Routines de support pour les drivers de WDM Divers composants du système d exploitation fonctionnant en mode noyau exposent des routines de support pour les drivers de WDM. Le tableau 3.1 ci-après nous résume ces composants. 23
PILOTE DE PERIPHERIQUE POUR WINDOWS NT Tableau 3.1 : Composants du mode noyau exposant des routines de support pour les Composant Kernel Objet Manager Executive I/O Manager Memory Manager Process Service Run-Time Library Power Manager PnP Subsystem WMI Kernel Streaming HAL drivers de WDM Description Primitifs de synchronisation, Compteurs et temporisateurs d exécution, Contrôle d IRQ (Interrupt ReQuest ou Demande d Interruption) et Stall Compteur de reference d objet Allocations en mémoire, Opérations d enclenchement, Opérations de liste Manipulation d IRP, Device Objects, Driver Objects, Articles de Travail, Accès en registre, Notifications d état du système, DMA (Direct Memory Access) ou Accès direct à la mémoire et interruption Mappage de la mémoire virtuelle en mémoire physique, Engagement et Fermeture de la mémoire physique, Fermeture de mémoire de l image du pilote, Espace portable d E/S Création et Suppression de thread du système Mémoire en bloc, Unicode, Conversions de type de données Changement d état de puissance, Manipulation de power IRP, Détection à vide d un device Détection de matériel et Allocation en ressource, Manipulation de PNP IRP, évènements de matériel Ou Windows Management Instrument, Support et Infrastructure pour l exposition de la mesure du dispositif et les données d instrumentation Support et Infrastructure pour les connexions de dispositif de streamingdata Abstraction de plateforme, Accès et Utilisation pour des ports d E/S et des dispositifs de mappage de mémoire 3.2.3.4 IRQ Level (IRQL) A Chaque interruption matérielle et à un peu de sélection d événements de logiciel, Windows assigne un IRQL ou un niveau de demande d interruption. Ce dernier permet l exécution d un code dans un thread (processus léger) par le processeur (CPU: Central Processing Unit), et chaque CPU a son propre IRQL. Il existe des différents niveaux d IRQL dont un nom est attribué à chacun d eux (exemple : PASSIVE_LEVEL, APC_LEVEL, ). Le tableau 3.2 suivant détaille cette gamme d IRQL pour la plateforme x86. La plupart des temps, le PC tourne en mode utilisateur à PASSIVE_LEVEL. Parmi ces IRQLs, ceux que les routines standard de driver utilisent fréquemment sont : PAS- SIVE_LEVEL, APC_LEVEL, DISPATCH_LEVEL, et le DIRQL. 24
PILOTE DE PERIPHERIQUE POUR WINDOWS NT Tableau 3.2 : IRQ Levels pour la plateforme x86 Type Valeur Nom Description 31 HIGH_LEVEL Plus haut niveau, erreur de la machine ou du bus 30 POWER_LEVEL Erreur sur l alimentation électrique 29 IPI_LEVEL Servant à l échange d information dans les systèmes multiprocesseurs Matériel 28 CLOCK2_LEVEL CLOCK1_LEVEL Rythmeur pour x86 27 SYNCH_LEVEL Synchronisation des instructions entre les CPUs 26 3 DIRQL Arrête l interruption, dépendant de la plateforme 2 DISPATCH_LEVEL Planification de thread, Procedure d appel attardée Logiciel 1 APC_LEVEL Procedure d appel asynchrone 0 PASSIVE_LEVEL Exécution normale du programme 3.2.3.5 Paquet de demande d E/S Le cœur d un driver a pour tâche de répondre aux demandes d E/S de l OS ou d une application. La demande est manipulée par le pilote en traitant l IRP. Si le driver ne peut pas traiter ce dernier, alors il le passe vers le pilote en dessous de lui dans la pile. Chaque driver dans la pile doit être prêt à recevoir n importe quel IRP et à manipuler n importe quelle erreur. a) Structure de données Figure 3.3 : Structure d un IRP Les IRPs sont essentiellement des structures de données qui contiennent certains champs, définissant le type d action à exécuter. Chaque IRP a une action définie par un code de fonction. Deux types de codes de fonction sont possibles pour chaque action : Major function (Mj Fnc) : indique l action principale ; Minor function (Mn Fnc): spécifie l action. La figure 3.3 ci-dessus décrit bien cette structure, avec tous ces composants. 25
PILOTE DE PERIPHERIQUE POUR WINDOWS NT b) Pile d E/S (I/O Stack) La création d un IRP est suivie d une création d un tableau de structures d IO_STACK_LOCATION, qui lui est associé (figure 3.4). Chaque emplacement de la pile représente l un des drivers qui traitera l IRP. Ces emplacements définissent la pile du driver. Figure 3.4 : Structure d IRP concernant les locations de la pile Chaque structure contient les codes et les paramètres de la fonction décrivant l action de l IRP. Dans l emplacement de la pile d E/S, on peut aussi sauvegarder des informations contextuelles sur l opération courant du pilote. De cette façon les drivers peuvent agir dans différents niveaux, permettant l accomplissement incrémental de la tâche. c) Queues d IRP (IRP Queues) Depuis que le système supporte les demandes asynchrones dans une situation multitâche et multithread, les drivers peuvent être incapables de finir le traitement de l IRP actuel avant qu un autre arrive. Les pilotes de WDM devraient alors supporter les queues ou les files d attentes (FI- FO : First In First Out ou Première Entrée Première Sortie) du pilote. Les IRPs qui sont en file d attente sont mis à la queue à la routine StartIo ; cette dernière a été fournie par les pilotes de l extrémité inférieure, supportant des opérations d E/S d un device. d) Codes de contrôle d E/S Les codes de contrôle (IOCTL : I/O Control Code) sont un canal de transmission entre les applications de l User mode et les drivers. En général, ces codes sont envoyés aux pilotes par des applications utilisant l appel de DeviceIoControl. Quand cela se produit, l I/O Manager crée un IRP concernant le device ou le contrôle du dispositif interne, y compris l IOCTL code. Ainsi, l IRP est envoyé vers le driver le plus haut niveau dans la pile. Cela va permettre au pilote de répondre à un IOCTL envoyé par une application. 26
PILOTE DE PERIPHERIQUE POUR WINDOWS NT 3.2.3.6 Objet de driver et Objet de dispositif La représentation du cœur de l architecture de WDM pour l OS est formée par ces 2 objets. Ces derniers évoquent le driver et les dispositifs sous le contrôle du driver, et stockent l information applicable à l opération du driver. Ces deux objets sont les suivants. a) Objet de driver L objet de driver (driver object) est créé par l I/O Manager pour chaque pilote qui est chargé et installé. Les objets de driver sont définis en utilisant les structures DRIVER_OBJECT. Il représente le pilote lui-même, et contient une liste de pointeurs vers les device objects des dispositifs sous le contrôle du driver. Figure 3.5 : Structure d un objet de driver Chaque driver qui est actuellement chargé dans l OS, correspond à un unique driver object. Et ce dernier contient un pointeur vers une liste associée aux dispositifs entretenus par ce driver. La figure 3.5 ci-dessus illustre bien cette structure du driver object. b) Objet de dispositif Figure 3.6 : Structure d un objet de dispositif 27
PILOTE DE PERIPHERIQUE POUR WINDOWS NT L objet de dispositif (device object) est attribué à chaque dispositif du système (virtuel, logique, et physique). Les device objects sont définis en utilisant la structure DEVICE_OBJECT qui est contrôlée par le gestionnaire d E/S. Ils conservent l information sur les caractéristiques et l état du dispositif. Ainsi le driver peut savoir à tout moment ce qui se passe avec un dispositif d E/S. La figure 3.6 illustre la structure d un objet de dispositif et de ses rapports avec d autres structures. 3.2.3.7 Les routines d entrée Les routines d entrée sont les points d entrée dans le code du driver. Elles représentent les différentes fonctionnalités du driver en mettant en application des routines standards. Ces dernières sont appelées sous divers circonstances, et sont exigées pour fournir la fonctionnalité dans laquelle elles sont nommées. Ces routines sont détaillées ci-après. a) DriverEntry La routine DriverEntry est celle que l I/O Manager appelle en première lieu, quand le driver est chargé en mémoire et installé par le système. Cette routine prend en compte toute initialisation installant les paramètres exigés. L objectif principal de cette routine est de compléter de divers pointeurs aux fonctions dans le driver object. Ce sont des pointeurs vers les sous-routines du pilote, et ces sous-routines représentent les autres points d entrée. b) DriverUnload Pour que le conducteur soit déchargeable en mémoire, on a besoin de la routine DriverUnload. Cette routine est annoncée durant la routine DriverEntry. Le gestionnaire d E/S appelle cette routine pour décharger le pilote. S il n y a rien à nettoyer, on a besoin d avoir une fonction de DriverUnload pour que l OS soit capable de décharger dynamiquement le driver. c) AddDevice La routine AddDevice assure la création et l initialisation de la représentation du driver de l objet du dispositif pour chaque device énuméré par le PnP Manager. Des routines AddDevice sont appelées durant l initialisation du système, et aussi lors de l énumération d un nouveau dispositif pendant que l OS tourne. Durant la création d un device object, une association entre l objet de dispositif et le nouvel objet de dispositif est aussi créée. Le driver doit fournir un stockage pour les pointeurs vers certains objets obtenus de l I/O Manager ou d autres composants du système, généralement dans l extension de dispositif du device object. 28
PILOTE DE PERIPHERIQUE POUR WINDOWS NT d) StartIo La routine StartIo est employée exclusivement avec l IRP queue, et est appelée en réponse à une IRP étant prêt dans la queue pour leur traitement sériel. Pour les drivers d extrémité inférieure, la routine StartIo est le responsable du début de toute opération d E/S sur un dispositif physique. Pourtant, elle peut devenir un bouchon qui bloquera le traitement des IRPs pour les driver d extrémité supérieure. Ainsi pour résoudre ce problème, on doit utiliser des queues internes. e) Dispatch Routines Le traitement de toute IRP commence dans une dispatch routine (routine d ordonnancement), que le driver enregistre pour manipuler un code de la fonction majeure d IRP (IRP_MJ_Xxx). Les points d entrées des dispatch routines sont exportés par la routine DriverEntry en une table d ordonnancement dans la structure DriverEntry du driver. Ce dernier peut produire une routine d ordonnancement séparée pour chaque code de la fonction majeure d E/S qu il peut manipuler. Alternativement, on peut écrire les dispatch routines dans le but de manipuler les codes multiples de la fonction d E/S. 3.3 CONCLUSION Ainsi, on a étudié l architecture et le registre de Windows NT. On a aussi vu le pilote de Windows, plus particulièrement les kernel mode drivers, ainsi que le modèle WDM. Ce qui nous a permis d avoir de notions pour le développement de notre driver. Maintenant, dans le chapitre quatre, on traitera le contrôleur d USB. 29
CONTROLEUR D USB Chapitre 4 : CONTROLEUR D USB Pour communiquer avec le port USB, on a besoin d un périphérique intelligent supportant le protocole USB, qui est très complexe. Dans ce chapitre, on abordera le contrôleur d USB. En premier lieu, on va présenter des détails sur le microcontrôleur. Et en second lieu, on étudiera le dispositif d E/S d USB, ainsi que le contrôleur d USB. 4.1 MICROCONTROLEUR 4.2.1 Présentation du Microcontrôleur Le microcontrôleur est une puce électronique, doté d un microprocesseur, de mémoires (ROM, RAM), et de différents périphériques. Ces différents éléments sont intégrés dans un même boîtier. Il est programmable, et le programme inscrit dans sa mémoire (ROM) est orienté au traitement d informations (arithmétiques ou logiques) entre plusieurs signaux d entrée permettant de générer des signaux de sortie. Ainsi, on peut réduire tout un circuit électronique en une petite puce. La figure 4.1 suivante illustre l organisation fonctionnelle d un système à microcontrôleur. Figure 4.1 : Système à microcontrôleur 4.2.2 Architecture interne d un microcontrôleur La structure interne d un microcontrôleur est basée sur le modèle de «Von Neumann», où la mémoire programme partage le même bus que la mémoire de donnée. Et parfois, le microcontrôleur utilise l architecture de «Harvard», disposant de bus distincts pour les données et pour le programme. 30
CONTROLEUR D USB Le microcontrôleur réunit tous les éléments d une structure à base de microprocesseur (Figure 4.2). Et même si sa programmation nécessite un matériel adapté et un système de développement couteux, il apporte quelques avantages comme : La diminution de la consommation énergétique ; La simplification du tracé du circuit imprimé ; Et l augmentation de la fiabilité du système, ainsi qu une réduction globale du coût. Figure 4.2 : Architecture d un microcontrôleur 4.2.2.1 Microprocesseur Le microprocesseur (CPU : Central Processing Unit ou Unité Centrale de Traitement) est le cœur du système. Il exécute séquentiellement les instructions stockées dans la mémoire programme. Le CPU est en général constitué des éléments suivants : Registre(s) accumulateur(s) : contenant temporairement les opérandes et les résultats des opérations ; Registres auxiliaires : permettant de relayer les accumulateurs ; Registres d index : pour le mode d adressage indirect ; Compteur programme : pointant l adresse de la prochaine instruction à exécuter ; Unité arithmétique et logique (ALU : Arithmetical and Logical Unit) : permettant d effectuer des opérations entre l accumulateur et l opérande ; Registre code condition : indiquant certaines particularités en ce qui concerne le résultat de la dernière opération (retenu, zéro, interruption...). 31
CONTROLEUR D USB Et aussi, il existe deux types de CPU, qui sont : CISC (Complex Instruction Set Computer) : possédant un nombre important d instructions, dont chacune d elles s exécute en plusieurs périodes d horloges ; RISC (Reduced Instruction Set Computer) : possédant un nombre réduit d instructions et chacune d elles s exécute en une période d horloge. 4.2.2.2 Mémoire programme Le mémoire programme (Program Memory) contient les instructions du programme que doit exécuter le CPU. On peut aussi l appeler mémoire morte, et elle n est accessible en lecture. Sa programmation nécessite une procédure particulière et un matériel adéquat. Selon leur mode de programmation, il en existe divers types : ROM (Read Only Memory) : son contenu est programmé lors de sa fabrication ; PROM (Programmable ROM) : programmable électriquement une seule fois par le développeur (ou OTPROM : On Time PROM) ; EPROM (Erasable PROM) : programmable électriquement et effaçable aux ultraviolets; EEPROM (Electrically EPROM) : programmable et effaçable électriquement. 4.2.2.3 Mémoire de Données Le Mémoire de données (Data Memory) permet la mémorisation temporaire des données générées par le microcontrôleur pendant les diverses phases de traitement numérique. Ce type de mémoire est accessible en écriture et en lecture. Il existe deux types de cette mémoire : RAM (Random Access Memory) : ou mémoire vive, volatile, et ayant un temps de lecture et d écriture assez court (quelques ns) ; EEPROM : ou mémoire morte, non volatile, et avec un temps d écriture et de lecture assez élevé (quelques ms). 4.2.2.4 Interface parallèle Ce type d interface est réparti sur plusieurs ports (8 bits maximum), et permettant la prise en en compte des états logiques appliqués en entrée ou produisant des signaux binaires en sortie. Les broches de ces ports sont configurables en entrée ou en sortie avec différentes options. La configuration et l état logique de ces broches sont obtenus par des opérations d écriture ou de lecture dans différents registres associés à chaque port. On trouve généralement : Registre de direction : pour une configuration en entrée ou en sortie ; Registre de donnée : recopiant les états logiques de chaque broche de port ; Registre d option : permettant plusieurs configurations en entrée ou en sortie. 32
CONTROLEUR D USB 4.2.2.5 Interface série Ce type d interface permet au microcontrôleur de communiquer avec d autres systèmes à base de microprocesseur. Les données envoyées ou reçues se présentent sous la forme d une succession temporelle (sur un seul bit) de valeurs binaires images d un mot. Il existe deux types de liaison série : synchrone et asynchrone. a) Liaison synchrone C est une liaison, dans laquelle l émetteur et le récepteur sont cadencés à la même horloge. Les informations sont transmises de façon continue. Et de plus, pour garantir l absence d erreur au cours d une transmission, des informations supplémentaires sont insérées. b) Liaison asynchrone C est une liaison dans laquelle, les informations peuvent être émises à un intervalle de temps arbitraire. Pour que le récepteur puisse distinguer les mots, chaque mot est précédé d une information indiquant le début de transmission appelée bit START, et terminé par le bit STOP. Et afin de corriger les erreurs, la donnée à transmettre peut contenir un supplémentaire appelé bit de parité. 4.2.2.6 CAN Le CAN (Convertisseur Analogique Numérique) d un microcontrôleur possède plusieurs entrées multiplexées, qui sont accessibles via les broches des ports de l interface parallèle. Et normalement, il possède les deux types de registre suivants : Registre de données : contenant le résultat d une conversion ; Registre de contrôle : permettant le lancement et la surveillance d une conversion. 4.2.2.7 Timer Le timer (temporisateur) assure l accomplissement des fonctions suivantes : Génération d un signal périodique modulé ou non en largeur d impulsion ; Génération d une impulsion calibrée ; Temporisation ; Comptage d'événements. Plusieurs registres sont associés au timer pour configurer les divers modes décrits auparavant. 4.2.2.8 Chien de garde Le chien de garde (Watch Dog) est un système anti-plantage du microcontrôleur. Il assure que l exécution d une même instruction ne soit pas prolongée. Au rythme de la fréquence 33
CONTROLEUR D USB d horloge, un compteur préchargeable se décrémente régulièrement. Avant qu il atteigne «0», et si aucun préchargement n est effectué, un Reset est généré, relançant ainsi le microcontrôleur. 4.2.2.9 Signal d horloge Le signal d horloge permet de cadencer le fonctionnement du microcontrôleur. Pour réaliser un oscillateur, une porte Trigger de Schmitt est intégrée en ce dernier. Pour obtenir le signal, on place un quartz entre les deux broches «OSCIN» et «OS- COUT», comme indiquée par la figure 4.3 ci-dessous. Figure 4.3 : Configuration d horloge 4.2 DISPOSITIF D E/S DE L USB 4.2.1 Présentation du dispositif d E/S de l USB Le dispositif d E/S de l USB est composé de divers éléments assurant toutes les fonctions de communication d USB, ainsi que la gestion des données (stockage, envoi, recherche, ) entre le host et le dispositif. La figure 4.4 suivante illustre ces éléments de base du dispositif d E/S de l USB. Figure 4.4 : Schéma fonctionnel d un dispositif d E/S d USB Le Transceiver (transcripteur) acquiert et adapte les caractéristiques électriques du bus (différentiel, signal bidirectionnel) au niveau de tension TTL/CMOS du SIE (unidirectionnel).le SIE (Serial Interface Engine) reçoit et valide les bits (ou les octets) d USB transceiver, et fournit les bits validés au SIE Interface. De même, les bits qui sont reçus de ce dernier sont transférés en série sur 34
CONTROLEUR D USB l USB. Le SIE doit être capable de synchroniser avec les transitions de paquet SYNC pour récupérer une fréquence d horloge afin d envoyer et de recevoir des paquets ; et il doit aussi contrôler le rejet de bruit. Le SIE Interface peut performer la correction d erreur avant de passer les données vers le Protocol Controller. Ce dernier manipule les conditions d erreurs, il répond aux événements d USB comme la mise en application du protocole d USB handshake, et formate les données entrantes et sortantes pour être compatible avec le protocole de paquets d USB. Le microcontrôleur assure la commande des signaux d entrée et de sortie. Le stockage des données temporaires et le code du programme tournant dans le microcontrôleur est assuré par le RAM et le ROM. 4.2.2 Contrôleur d USB Le contrôleur d USB est un microcontrôleur, qui intègre les éléments de base du dispositif d E/S d USB en un seul composant qui assure les mêmes rôles que le dispositif d E/S. 4.2.2.1 Critères de sélection A part les éléments de base d un microcontrôleur, le contrôleur d USB doit répondre aux critères suivants : Port d USB : le contrôleur d USB doit posséder de l USB transceiver et d un SIE, qui sont intégrés. Le transceiver fournit une interface matérielle au bus. Le SIE manipule l envoi et la réception des données durant les transactions ; Buffers : pour le stockage des données reçues, et celles qui sont prêtes à être envoyées sur le bus. Ils sont associés à des registres qui sont souvent de structure FIFO ; Configuration, Statut, Paramètres : ces informations sont tenues par le contrôleur à l aide de plusieurs registres ; Horloge, CPU, Program Memory, et Data Memory ; Registres : zones de mémoire accédés par le CPU, en utilisant les différentes instructions qu il emploie pour accéder à l autre Data Memory ; Autres E/S : interfaces au monde extérieur du contrôleur à part le port d USB, qui peuvent être reliées à d autres circuits ; Autres particularités : le contrôleur peut avoir des dispositifs additionnels comme : des timers, des compteurs, des convertisseurs (CAN et CNA : Convertisseur Numérique Analogique), et des sorties PWM (Pulse Width Modulation ou Modulation en Largeur d Impulsion). 4.2.2.2 Quelques types de Contrôleur d USB Il existe actuellement plusieurs types de microcontrôleurs compatibles avec l USB. Notre choix dépend de son utilisation, de sa performance, de son prix, et de sa disponibilité sur le marché 35
CONTROLEUR D USB avec ses outils de développement. Le tableau 4.1 ci-après nous donne une aperçue de quelques familles populaires de contrôleurs d USB. Tableau 4.1 : Contrôleurs d USB compatibles avec les familles populaires de microcontrôleurs Compatibilité Fabricant Microcontrôleur Vitesse du bus Atmel AVR Atmel AT43USB35x, AT76C713 Full Freescale/Motorola68HC0tor Freescale Semiconduc- 68HC05JB3/4 Low Freescale/Motorola68HC0tor Freescale Semiconduc- 68HC08JB8 Low Freescale/Motorola Freescale Semiconductor PowerPC MCF5482 Full/High Infineon C166 Infineon C161U Full Intel 80C186 AMD Am186CC Full Atmel AT89C513x Full Cypress EZ-USB, EZ-USB FX Full Semiconductor EZ-USB FX2 Full/High Prolific Technology PL-23xx Full PL-25xx Full/High Intel 8051 Silicon Laboratories C8051F32x Full Standard Microsystems Corporation (SMSC) USB97Cxxx, USB222x Full, Full/High Texas Instruments TUSB3210/3410 Full TUSB6250 Full/High Microchip PIC16 Microchip Technology PIC16C7x5 Low Microchip PIC18 Microchip Technology PIC18F2455/2550/44 55/4550 Full/High STMicroelectronics ST7265X, ST7263, STMicroelectronics ST7, ST9 ST92163 Low, Full 4.3 CONCLUSION L étude du microcontrôleur et du dispositif d E/S d USB dans ce chapitre nous a permis de compléter notre connaissance sur la communication sur le port USB, et aussi de faire face à la complexité du protocole USB. Ainsi, dans le prochain chapitre, on va entamer la conception d un système capable de supporter le protocole USB, et compatible avec l USB. 36
IMPLEMENTATIONS ET RESULTATS PARTIE III : IMPLEMENTATIONS ET RESULTATS 37
IMPLEMENTATIONS Chapitre 5 : IMPLEMENTATIONS Précédemment, nous avons vu le protocole USB, la mise en œuvre d un driver et les microcontrôleurs d USB. Ce nouveau chapitre s étalera sur l implémentation de notre système. En premier lieu, on présentera la mise en œuvre de la carte d interface ; puis en second lieu, on réalisera le programme du microcontrôleur ; et enfin, on va voir comment programmer le driver de notre carte d interface. 5.1 LA CARTE D INTERFACE 5.1.1 Présentation du projet Notre étude est basée sur la conception d une carte électronique capable de recevoir des ordres d un ordinateur via le port USB (comme : allumer une LED, conversion analogique, ), et de transmettre les réponses au PC (l état d une entrée, la valeur d une conversion analogique). Comme l'usb a le désavantage d'obliger l'utilisation de composants particuliers, alors pour notre application, nous aurons recours au microcontrôleur 18F4550 de Microchip, qui est une puce simple à programmer (en C) et munie de tous les composants hardware nécessaires à la communication avec le port USB. La figure 5-1 suivante représente le schéma bloc de notre carte d interface USB. Figure 5.1 : Schéma fonctionnel de la carte d interface 5.1.2 PIC 18F4550 Le PIC18F4550 est un microcontrôleur de Microchip, supportant directement le protocole USB. C est aussi un microcontrôleur à multi-usage, souple, et économique. Il intègre en une seule puce plusieurs modules d USB, ce qui réduit le nombre des composants externes. Pour qu il soit 38
IMPLEMENTATIONS stable durant son utilisation, on a besoin d employer une horloge extérieure conforme avec les caractéristiques : Low Speed et Full Speed, et le PIC doit avoir respectivement une horloge de 6 MHz ou de 48 MHz. Le PIC18F4550 présente aussi quelques caractéristiques, qui le rendent plus approprié pour ce projet : Conformité avec l USB 2.0 ; Operation Full Speed (12 Mbit/s) et Low Speed (1.5 Mb/s); Supporte divers types de transferts : par contrôle, par interruption, en bloque et isochrone ; Supporte jusqu à 32 endpoints (16 bidirectionnels) ; 1 kbyte de RAM (double accès) pour l USB ; Modules d USB regroupés en une seule puce : transceiver, régulateur de tension, résistances pull-up ; Interface pour le transceiver hors de la puce d USB. La figure 5.2 suivante nous donne une aperçue globale du PIC18F4550 avec ses modules d USB internes. Figure 5.2 : Vue d ensemble du PIC18F4550 39
IMPLEMENTATIONS 5.1.3 Conception de la carte 5.1.3.1 Représentation schématique de la carte Figure 5.3 : Schéma de montage de la carte d interface Figure 5.4 :Modélisation3D de la carte d interface 40
IMPLEMENTATIONS Notre montage est architecturé autour du PIC18F455 qui avec sa connectivité USB intégrée le rend plus simple à mettre en œuvre. Les figures ci-dessus (figure 5.3 et figure 5.4) nous donnent plus de détails sur le schéma électronique de la carte, ainsi que son modèle en 3 dimensions. 5.1.3.2 Description des composants a) Connecteur USB Le connecteur USB (J1) de type B est le canal primaire pour commander et communiquer avec la carte d interface. b) Connecteur ICSP L ICSP (J6, In Circuit Serial Programming) permet la programmation de manière simple du microcontrôleur in situ (en circuit). Il permet aussi la mise à jour et le débogage du programme dans la mémoire sans avoir touché au microcontrôleur. c) Connecteurs des données Notre carte d interface possède (Figure 5.1) 4 connecteurs de données (numériques et analogiques), dont chacun dispose une connexion Vbus/GND pour alimenter la carte. Il est important de ne pas dépasser une intensité de courant 100 ma pour chaque connecteur, ainsi qu une de 25 ma en chaque broche. Dans notre cas, on dispose les 4 connecteurs de données qui sont : Sortie numérique (J2) : 8 bits de 0 ou 5 V (TTL), de la broche RD0 à RD7 ; Entrée numérique (J3): 8 bits de 0 ou 5 V (TTL), de la broche RB0 à RB7 ; Sortie analogique (J4) : 2 bornes de sortie avec une plage de tension comprise entre 0 et 5 V, dont : la broche RC1 et RC2, ces sorties ont une résolution de 10 bits travaillant en PWM (Pulse Width Modulation ou MLI : Modulation en Largeur d Impulsion); Entrée analogique (J5) : 8 bornes d entrée une plage de tension comprise entre 0 et 5 V, qui sont les broches AN0/RA0 à AN7/RE2, avec une résolution de 10 bits. d) Connecteur d alimentation 5V Ce connecteur (J7) assure l alimentation de la carte avec ses périphériques. Dans le cas où l intensité fournie par le port USB n est plus suffisante (500 ma max), on utilise le jumper ou le cavalier (JP1) pour sélectionner les types d alimentions (USB/Externe) à employer au montage. e) Oscillateur L oscillateur a pour rôle de fournir une fréquence d horloge de 20 Mhz au PIC. Sa fréquence est définie par le quartz (X1) appuyé par la paire de condensateurs (C3 et C4) classique assurant une charge en mode parallèle, et la résistance (R5) de forte valeur pour la contre réaction. 41
IMPLEMENTATIONS f) LEDs Les 2 LEDs d états (D2, D3) visualisent l état de l USB, et la LED D3 signale la présence de la tension d alimentation quand la carte est connectée au port USB de l ordinateur. Le courant qui circule autour de chaque LED est limité à 3 ma respectivement par les résistances R6, R7, R8.. = \ ED ÒŖȖ EϜ = 5 2 = 1000 Ω ϜŖ 3 10 Les valeurs des LEDs par rapport aux différents états du dispositif sont résumées par le tableau 5.1 ci-après : Tableau 5.1 : Valeurs des LEDs en fonction de l état du dispositif Etat du Dispositif LED D2 LED D3 Détaché OFF OFF Branché ON ON Alimenté ON OFF Défaut OFF ON Adressé Clignotement OFF Configuré Clignotement alternatif Suspendu Clignotement synchrone rapide g) Réinitialisation Le réseau de réinitialisation (reset) est formé par un bouton poussoir (S1) connecté directement à la masse, et pris à l entrée MCLR du PIC. Ce réseau est composé d un condensateur (C1) servant d anti-rebonds à l action mécanique sur le bouton poussoir, et des résistances de protection (R3, R4). 5.2 PROGRAMMATION DU PIC 5.2.1 Présentation du firmware La communication avec le port USB est réalisée au moyen du firmware (ou microprogramme), qui est un programme résidant dans le ROM du PIC. Le firmware fournit plusieurs fonctions visant à réduire la complexité de la communication entre le dispositif et l USB. Il existe actuellement plusieurs langages dédiés aux firmwares (Assembleur, C, Basic, ). Dans notre cas, le programme est écrit en langage C, sous l IDE (Integrated Development Environment ou EDI : Environnement de Développement Intégré) MPLAB. 42
IMPLEMENTATIONS 5.2.2 Outils de développement Pour le développement de notre firmware, on va utiliser le compilateur de MPLAB C18. Le MPLAB C18 est un outil de compilation dédié à la famille PIC18 (PIC 18Fxxx, PIC 18Cxxx), supporté par l IDE MPLAB. L EDI MPLAB est un puissant outil de développement de microprogramme, supportant divers options de compilation et d interfaces de correction, ainsi, il offre un environnement flexible et structural. Cet outil est fourni librement par Microchip. 5.2.3 Firmware Le firmware assure deux fonctions importants dont : l énumération et la communication avec le host. Les étapes d énumération sont assurées par les fonctions dans le fichier «usb9.c», et celles de la communication par les fonctions du fichier «user.c» (spécialement par la fonction ProcessIO ()). 5.2.3.1 Enumération L'énumération est un moyen de déterminer le dispositif qui vient juste d'être branché au bus avec les paramètres dont il a besoin. Les étapes d énumération sous Windows sont (Figure 5.5) : Détection de la connexion d'un nouvel appareil par l hôte via les résistances de rappel du dispositif reliées sur les 2 fils de données ; Emission d une commande «Bus Reset» par l hôte, mettant le dispositif en état «par défaut». Ce dernier peut maintenant répondre à l'adresse zéro par défaut ; L'hôte demande les 64 premiers octets du descripteur d'appareil (dans le fichier «usbdsc.c») ; Envoi de commande «Bus Reset» par l hôte, après la réception des 8 premiers octets ; L'hôte émet maintenant une commande «Set Adress», mettant l'appareil dans l'état adressable ; Demande de la totalité des 18 octets du descripteur d'appareil par l hôte ; Demande des 9 octets du descripteur de configuration (Set Configuration) pour déterminer la taille totale ; Demande des 255 octets du descripteur de configuration ; L'hôte demande l'un des descripteurs de chaînes s'ils étaient indiqués, et demande de driver par le système. 43
IMPLEMENTATIONS Figure 5.5 : Résumé des étapes d énumération 5.2.3.2 Communication avec le host Pour cette étape, chaque communication est identifiée par une commande. Ces commandes sont traitées par la fonction «ProcessIO ()» du fichier «user.c». Ce sont ces commandes : 0x10 (DIGITAL_OUTPUT_BYTE) : pour envoyer 8 bits (1 octet) de données numériques simultanément sur les sorties numériques ; 0x11 (DIGITAL_OUTPUT_BIT) : commande une à une (envoie de 1 bit) de chaque sortie numérique ; 0x12 (DIGITAL_INPUT_BYTE) : lecture simultanément de 8 bits de données venant des entrées numériques ; 0x13 (DIGITAL_INPUT_BIT) : lecture une à une des entrées numériques ; 0x14 (ANALOG_OUTPUT) : commande une par une des 2 sorties analogiques ; 0x15 (ANALOG_INPUT) : lecture une par une des données des entrées analogiques; 0xFF (RESET) : pour réinitialiser le programme du microcontrôleur. 5.2.3.3 Structure du programme La structure de base de notre programme et aussi ses fonctions principales sont résumés par la figure 5.5 ci-après. Chaque fonction assure un rôle important sur le bon fonctionnement du programme du microcontrôleur. Ces fonctions sont les suivants : main () : fonction formée par une boucle infinie «while», assurant diverses tâches (tâches de USB et tâches Utilisateur) ; USBDriverService () : assure la gestion des tâches USB, et les interruptions des matériels de l USB ; USBCtrlEPService () : vérifie le type des transactions après une transaction d endpoints. Le service de branchement est fourni par les fonctions du fichier «usbctrltrf.c» ; USBCheckStdRequest () : entretient une requête standard, et manipule celles qui sont requises; USBStdSetCfgHandler () : manipule la requête SET_CONFIGURATION lors de la phase d énumération. Cette dernière est effectuée principalement dans le fichier «usb9.c» ; 44
IMPLEMENTATIONS ProcessIO () : assure le support des fonctions de l utilisateur (tâches USB et tâches non USB) ; USBGenWrite () et USBGenRead () : assurent la lecture ou l écriture d une transaction d USB. Figure 5.6 : Relation entre les fichiers et les fonctions principales du programme Le programme principal résidant dans le microcontrôleur peut être simplifié par l organigramme de la figure 5.7 suivante : 45
IMPLEMENTATIONS Début Initialisation du programme 1 Traitement des tâches USB Traitement des tâches Utilisateur Figure 5.7 : Organigramme du programme principal a) Initialisation du programme Cette étape consiste à : Initialiser les broches RC6 et RC7 du port C du PIC pour pouvoir commander les LEDs (D2 et D3) en fonction de l état du dispositif (tableau 5.1), en configurant les registres TRISC et LATC ; Configurer en sortie le port D par les registres PORTD, TRISD, et LATD, pour permettre la sortie numérique; Régler en entrée le port B par le registre TRISB et activer les Resistances pull-up pour permettre l entrée numérique ; Paramétrer le temporisateur et les canaux PWM pour permettre la sortie analogique ; Configurer la conversion Analogique/Numérique pour permettre l entrée analogique. b) Traitement des tâches USB Cette étape consiste à gérer les tâches matérielles, c est le cœur de notre microprogramme. Ici, les fonctions assurent la gestion des interruptions comme celles de l activité de l USB, de la réinitialisation du port USB, et l interruption dû à la complétion des transactions d endpoints. Dans notre firmware, ces fonctions sont assurées par la procédure «USBTasks ()». 46
IMPLEMENTATIONS c) Traitement des tâches Utilisateur Cette étape permet à l utilisateur de traiter les données reçues et d envoyer des données. Ces tâches sont constituées de diverses commandes (Section 5.2.4.2), que le firmware doit exécuter. C est aussi dans cette routine qu on traite la commande des LEDs d états en fonction de l état du dispositif (figure 5.5). Elle est assurée par la routine le «ProcessIO ()» du fichier «user.c». 5.2.3.4 Compilation du firmware Pour construire le programme, il existe différentes étapes, d abord l EDI compile respectivement les fichiers d extension «*.c» et «*.asm» avec MCC18 et MPASMWIN. Les fichiers objets (*.o) obtenus sont ensuite sont archivés avec MPLIB si nécessaire, et on obtient des bibliothèques statiques «*.lib». L éditeur de lien MPLINK combine les objets, les bibliothèques et aussi des fichiers «*.lkr» (linker), pour obtenir des fichiers «*.cof» (COFF : Common Object File Format), «*.map», et «*.hex» (hexadécimale). 5.3 DRIVER 5.3.1 Présentation Pour permettre la communication au dispositif via USB, on a besoin d un driver spécifique au dispositif pour le port USB. Notre pilote de dispositif USB est un kernel mode driver, conforme au modèle de développement WDM, cela vise à la performance et à la rapidité de notre driver. Pour élaborer le pilote, on va utiliser le langage C, et des outils (compilateur de C, linkeur, utilitaires de construction,...) et les bibliothèques du kit de driver de Windows (WDK : Windows driver Kit). 5.3.2 WDK Le WDK est un ensemble d éléments comme : des outils, des extraits de codes, de la documentation, des compilateurs, des headers (ou en-têtes) et des bibliothèques qui sont nécessaires au développement des pilotes de Windows. Il fournit aussi une plateforme sur laquelle on peut développer, compiler et examiner les pilotes. Pour créer une pilote par WDK, on utilise l utilitaire «build». Ce dernier appelle des outils conformes avec les options appropriées à la construction du pilote. Il est aussi un wrapper (programme enveloppant l exécution d un autre programme) autour de l utilitaire NMAKE de Microsoft, ainsi il manipule des issues comme la vérification des dépendances pour s assurer que les fichiers appropriés sont reconstruits après un changement. 47
IMPLEMENTATIONS 5.3.3 Compilation du driver Pour compiler un driver, on a besoin de l utilitaire «build». Il peut générer deux versions de driver : l une avec des informations pour le débogage (checked ), et l autre optimisée pour la version définitive (free ). Le répertoire de travail doit contenir un fichier «makefile» renfichier permettant la génération automatique du driver. La figure 5.8 représente les voyant au codes d un fichier makefile. Figure 5.8 : Contenu d un fichier makefile Un autre fichier appelé «sources» est nécessaire ; il contient le nom du fichier source, le nom qui sera donné au driver compilé, le type de fichier généré (driver, DLL...), le chemin pour ranger les fichiers générés, les localisations des différentes bibliothèques iothèques du DDK et du SDK. Pour lancer la compilation, il suffit alors d aller au menu «Démarrer», puis dans le programme WDK, et dans la version checked ou free ; une fenêtre DOS est alors ouverte. Il faut maintenant retourner dans le répertoire rtoire où se trouve notre driver et lancer la commande «build». Si tout se passe bien, le driver (fichier «*.sys») est généré. 5.3.4 Programme du driver 5.3.4.1 Fonctions de contrôle Les fonctions de contrôle ou IOCTLs sont définies grâce à la macro du DDK : CTL_CODE. Ces fonctions établissent la liaison du programme hôte avec le programme du driver. Dans notre cas, elles sont résumées dans le tableau ci-après : Tableau 5.2 : Les fonctions de contrôle du driver Code d IoCtl Description IOCTL_GIUSB_GET_DEVICE_DESCRIPTOR Retourne les descripteurs du dispositif IOCTL_GIUSB_GET_CONFIGURATION_DESCRIPTOR Retourne les descripteurs de la configuration IOCTL_GIUSB_GET_STRING_DESCRIPTOR Retourne les descripteurs de string du dispositif IOCTL_GIUSB_GET_CURRENT_FRAME_NUMBER Retourne le nombre de frames courants IOCTL_GIUSB_WRITE Ecrire une valeur au dispositif IOCTL_GIUSB_READ Lire une valeur du dispositif IOCTL_GIUSB_RESET_PIPE Réinitialiser le pipe IOCTL_GIUSB_ABORT_PIPE Abandoner l e pipe 48
IMPLEMENTATIONS 5.3.4.2 Routines du programme Notre driver possède plusieurs routines. Elles sont initialisées à partir des pointeurs par le point d entré de l initialisation «DriverEntry ()». Ces routines sont les suivantes : GIUSBCreate () : c est le point d entrée des appels de CreateFile du programme d application. Ici, on crée les liens symboliques entre les endpoints ; GIUSBClose () : c est le point d entrée de la fonction CloseHandle du programme d application ; GIUSBUnload () : libère tous les ressources allouées ; GIUSBIoctl () : manipule tous les codes de DeviceIoControl (fonctions de contrôle) ; GIUSBAddDevice () : assure la création de nouvelle instance pour le dispositif ; GIUSBPnpIrp () : manipule tous les IRPs PNP ; GIUSBPwrIrp () : traite les IRPs envoyés au dispositif. 5.3.5 Paquetage Le paquetage du driver est composé des fichiers du driver et des fichiers d installation. Ces fichiers sont détaillés par le tableau suivant. Nom Fichier «*.inf» Co-installer Fichier «*.cat» Tableau 5.3 : Paquetage du driver Description Fichier d information de l installation du pilote, comportant une part de l information d entrée dans le registre du pilote Fichier «*.dll», qui assiste l installation de driver de NT Fichier catalogue, contenant un hachage cryptographique de chaque fichier dans le paquetage, pour vérifier que le paquetage n a pas été changé après qu il ait été édité 5.4 CONCLUSION Dans ce chapitre, nous avons détaillé la conception électronique de la carte d interface, la programmation du firmware et du driver. Ce qui nous a permis d entrer dans le cas réel de notre étude. Dans le chapitre suivant, on va entamer une simulation dans le but de prévoir les résultats de notre étude. 49
SIMULATION ET RESULTATS Chapitre 6 : SIMULATION ET RESULTATS Pour bien comprendre le fonctionnement de notre système d interface, et aussi d envisager les résultats de notre étude, on a recours à la simulation. Ainsi dans ce chapitre, nous présenterons d abord le logiciel d interface GIUSBInterface, puis, nous allons simuler le fonctionnement du système d interface. 6.1 LOGICIEL GIUSBInterface 6.1.1 Présentation du logiciel GIUSBInterface est un logiciel pour l OS Windows. Il est capable de gérer la communication avec la carte d interface via port USB, en utilisant notre driver «giusbdriver.sys». Notre logiciel a pour tâche de manager l acquisition et la transmission des données (numériques et analogiques) du port USB vers la carte d interface qu on a conçu précédemment. 6.1.2 Mode d utilisation du logiciel Pour lancer le logiciel, il faut cliquer deux fois sur l icône GIUSBInterface v1.00, et la fenêtre principale de la figure 6.1 apparaîtra. Figure 6.1 : Icône du logiciel GIUSBInterface Remarque : Avant de lancer le logiciel, il faut s assurer que le dispositif USB est prêt à être utiliser, sinon la boîte de dialogue de la figure 5.10 ci-joint apparaît. Figure 6.2 : Message montrant le non connexion de la carte 50
SIMULATION ET RESULTATS Explication de la fonction de chaque panneau: Panneau «DIGITAL INPUTS» : visualise les états des entrées numériques, la couleur rouge signale la présence de signal sur le broche, et la couleur gris pour le cas contraire ; Panneau «ANALOG INPUTS» : montre la variation de tension de chaque sortie analogique ; Panneau «DIGITAL OUTPUTS» : avec les «checkbutton», on peut facilement choisir sur quel broche des sorties veut-on envoyer de donnée, en cochant sur la cage ; Panneau «ANALOG OUTPUTS» : permet de varier le signal analogique (travaillant en PWM) de chaque sortie envoyé au dispositif extérieur au carte d interface. Figure 6.3 : Interface utilisateur du logiciel GIUSBInterface v1.00 6.2 SIMULATION 6.2.1 Définition de la simulation La simulation est la reproduction artificielle et aussi réaliste que possible (d un processus complexe) à des fins scientifiques, ludiques ou de formation. C est aussi une représentation de la réelle assise sur un modèle théorique sous-jacent (ou caché), et elle dépend du modèle. La simulation est applicable sur divers modèles théoriques comme : le physique, la chimie, la biologie, et aussi sur les systèmes humaines (économie et sciences sociales). 51
SIMULATION ET RESULTATS 6.2.2 Raisons de la simulation Il existe diverses raisons qui nous poussent à simuler un système (électronique, électrique, ).Ces raisons sont : Pour comprendre : le désir de comprendre le fonctionnement d un système (montage électrique) ; Pour prévoir et prévenir : anticipation de l expérimentation, afin de la faciliter (choix des composants), et de la sécuriser ; Pour comparer : si la simulation est faite après une expérimentation, pour valider un modèle par exemple ; Pour des raisons économiques : notamment dans l enseignement, pour certains montages gourmands en composants, alimentations, charges (onduleur, ). La simulation est alors nécessaire, et permet une économie surtout avec les logiciels gratuits. Dans le cadre de notre étude, l inaccessibilité aux composants électroniques, ainsi que les prix de certains composants sont les raisons qui nous poussent à simuler notre système (simulation électronique). 6.2.3 Proteus La simulation de la carte d interface USB a besoin d un logiciel capable de simuler l interface USB. Dans cet ouvrage, on a choisi d utiliser le Proteus de Labcenter. Ce dernier dispose deux applications dont : ARES pour le traçage des circuits imprimés et ISIS pour la simulation des composantes électroniques, et c est ce dernier qui nous intéresse. ISIS fournit l environnement de développement pour Proteus VSM, qui est notre simulateur interactif évolutionnaire au niveau du système. Il permet de concevoir et de simuler les circuits par l utilisation de ses environnements graphiques (symboles représentatifs des composants), et aussi de visualiser les graphes des signaux obtenus en simulation. ISIS est aussi capable de simuler convenablement le fonctionnement des microcontrôleurs populaires (PIC, ATMEL-AVR, MOTOROLA, 8051, ) 6.2.4 Circuits de test Pour permettre le test de la carte d interface et du logiciel d interface, on va utiliser les divers circuits suivants : Circuit à 8 LEDs : pour visualiser le transfert de données sur les lignes de sortie numérique ; 52
SIMULATION ET RESULTATS Figure 6.4 : Circuit à 8 LEDs Circuit à 8 interrupteurs : pour tester les 8 entrées numériques ; Figure 6.5 : Circuit à 8 interrupteurs Circuit à 2 LEDs : pour visualiser la variation d intensité des 2 sorties analogiques ; Figure 6.6 : Circuit à LEDs 53
SIMULATION ET RESULTATS Circuit à 8 potentiomètres : pour tester le fonctionnement des 8 entrées analogiques. Figure 6.7 : Circuit à potentiomètres 6.3 CONCLUSION Ce dernier chapitre nous a permis de voir la communication entre le dispositif et le logiciel d interface du port USB. Ainsi, nous avons pu étudier la transmission et l acquisition de données via USB, grâce au logiciel PROTEUS de Microchip. 54
CONCLUSION GENERALE CONCLUSION GENERALE L utilisation du port USB de l ordinateur devient actuellement incontournable au niveau de transmission de données. Et presque la totalité des anciens ports commence à disparaître. Or, ce nouveau technologie requiert plusieurs domaines de compétences et difficile à mettre en œuvre. Notre ouvrage sur l étude et la conception d un système d interface du port USB est basé sur la communication de données à un dispositif extérieur via USB. L utilisation de ce système d interface permet de gérer l acquisition de données sur le bus, de minimiser nos dépenses sur l interfaçage avec les anciens ports, d avoir une vitesse de transfert plus rapide, et un dispositif moins encombrant. Au terme de cette étude, nous avons pu acquérir des connaissances sur le protocole USB, la programmation d un pilote de Windows, le dispositif basé sur un microcontrôleur ainsi que sa programmation, et le développement d une application capable de gérer l acquisition de données via USB. Le transfert de données sur USB est applicable sur plusieurs domaines comme la commande des moteurs (moteur pas à pas, moteur à courant continu), l acquisition de données des instrumentations (oscilloscope, thermomètre, ). Ainsi, dans un projet avenir, l application de ce projet sur un dispositif utilisant la technologie sans fil pourrait être envisageable. 55
ANNEXE ANNEXE Annexe 1 : Brochage du PIC18F4550 I
ANNEXE Annexe 2: Spécificité du PIC18F4550 II
ANNEXE Annexe 3 : Schéma électronique de la carte d interface III
ANNEXE Annexe 4 : Liste des composants de la carte d interface Type Resistances Condensateurs Semi-conducteurs Autres Quantité Références Valeur Remarque 2 R1, R2 27 Ω 1 R3 470 Ω 1 R4 10 kω 1/4 W 1 R5 10 MΩ 3 R6, R7, R8 1 kω 2 C1, C2 100 nf 2 C3, C4 22 pf Céramique 1 IC1 PIC18F4550 D1 Rouge 3 D2 LED Vert D3 Bleu 1 X1 Crystal 20 MHz 1 J1 USB CONN USB Type B 4 J2, J3, J4, J5 CONN-DIL 10 1 J6 SIL-100-06 1 J7 TBLOCK-I2 1 JP1 JUMPER2 Annexe 5 : Tracés des circuits imprimés et Implantation des composants PCB bottom (dessous) IV
ANNEXE PCB top (dessus) Implantation des composantes V
BIBLIOGRAPHIE BIBLIOGRAPHIE [1]: Compaq, Hewlett-Packard, Intel, Lucent, Microsoft, NEC, Philips, Usb specification, 2000, 662p [2]: Dogan Ibrahim, Advanced PIC Microcontroller Projects in C, 2009, 539p [3]: Don Anderson, USB System Architecture (USB 2.0), 2002, 506p [4]: Jan Axelson, USB COMPLETE, Troisième edition, 2005, 572p [5]: Labcenter, ISIS Help, 2010 [6]: Labcenter, ARES Help, 2010 [7]: Microchip Technology, MPLAB C18 C Compiler Getting Started, 2004, 124p [8]: Microchip Technology, MPLAB C18 Users Guide, 2004, 128p [9]: Microchip Technology, PIC18F2455/2550/4455/4550 Data Sheet, 2004, 428p [10]: Microsoft Corporation, MSDN Library, 1995-2000 [11]: Microsoft Corporation, MSDN 2008 Library [WDK], 2009 [12]: Microsoft Corporation, WDK Documentation, 2009 [13]: Walter Oney, Programming the Microsoft Windows Driver Model 2nd Edition, 2003, 448p VI
WEBOGRAPHIE Mémoire de fin WEBOGRAPHIE [14] : http://www.abcelectronique.com/bigonoff [15] : http://www.beyondlogic.org [16] : http://www.codeproject.com/kb/system/wdm_driver_development [17] : http://www6.conestogac.on.ca/%7eset/courses/year3/drivers [18] : http://ww.datasheetcatalog.com [19] : http://www.intel-u-press.com/usb_dbe [20] : http://www.lvr.com [21] : http://membres.lycos.fr/grandzebu/electronique/usb [22]: http://www.microchip.com [23] : http://www.microchip.com/downloads/en/appnotes [24]: http://www.microchip.com/downloads/en/devicedoc [25]: http://www.microsoft.com/whdc/ddk [26]: http://msdn.microsoft.com [27]: http://www.newsnespress.com [28]: http://www.osr.com [29]: http://pic18fusb.online.fr [30]: http://www.pulsewan.com/data101/usb_basics.htm [31]: http://www.usb.org [32]: http://ww.usb-by-example.com [33]: http://www.usbman.com [34]: http://www.usb.org/developers/ [35]: http://u.s.b.free.fr/pdf/l_usb_et_sa_norme_v1.pdf [36]: http://www.wikipedia.org/wiki/usb_cours.html VII
TITRE : Nombre de pages : 55 Nombre de figures : 38 Nombre de tableaux : 13 RESUME Ce travail permet l étude et la conception d un système électronique et informatique, capable de gérer le transfert et l acquisition de données sur le port USB de l ordinateur. Dans ce mémoire, on a utilisé le modèle WDM pour élaborer du pilote. Et on a choisi le microcontrôleur PIC 18F4550 pour la réalisation de la carte d interface. ABSTRACT This work allows the study and the design of an electronic and informatics system, able to manage the transfer and the data acquisition on the USB port of the computer. In this dissertation, we used the WDM model for the elaboration of the driver. And we have chosen the PIC 18F4550 chip for the realization of the interface card. Rubrique : Informatique Mots clés: USB, WDM, driver, microcontrôleur Auteur : HERIMAMPIONONA Hasindrainy Florent Email : hasindrainymail@yahoo.fr Contact : +261 (0) 32 41 454 06 +261 (0) 33 24 717 41 +261 (0) 34 39 207 30 Directeur de mémoire : Mr ANDRIAMANOHISOA Hery Zo