Projet de deuxième année

Institut Supérieur
Laboratoire d'Informatique,
d'Informatique de
Modélisation et de
de Modélisation et leurs Applications
d'Optimisation des Systèmes
Complexe des Cézeaux
BP 125 ­ 63173 Aubière Cedex
Complexe des Cézeaux
63173 Aubière Cedex
Rapport d'ingénieur
projet de 2ème année
Filière F1 : Informatique des Systèmes Embarqués
Implémentation du protocole USB
sur la carte AT91SAM7S256
Avec la participation du CEMAGREF
Présenté par : Sylvain Chalmin
Bacem El­Idilbi
Durée : 100h
Soutenu publiquement le 26 mars 2009 à 8h
Responsable ISIMA – LIMOS : Aurélien Jacquot
octobre 2008 ­ mars 2009
Remerciements
Nous tenons à remercier les chercheurs du LIMOS, pour la patience dont ils ont su faire preuve lors de nos fréquentes visites à M. Jacquot.
Nous voulons aussi remercier notre professeur, M. Hou, pour nous avoir conseillé lors de la programmation de la carte.
Enfin, nous tenons particulièrement à remercier M. Jacquot pour son inépuisable talent de pédagogue et son incroyable disponibilité.
CHALMIN & EL­IDILBI
­ III ­
Projet de deuxième année
Table des figures
Figure 1 : Descriptions des différentes classes.....................................................................2
Figure 2 : Logo officiel USB...................................................................................................3
Figure 3 : Vue de la carte AT91SAM7S256...........................................................................4
Figure 4 : Architecture simplifiée de la carte AT91SAM7S256..............................................5
Figure 5 : Architecture simplifiée du port USB.......................................................................7
Figure 6 : Automate des différents états de l'USB.................................................................9
Figure 7 : Chronogramme de traitement d'un paquet de commande..................................11
Figure 8 : Chronogramme du traitement de données entrantes..........................................12
Figure 9 : Chronogramme du traitement de données sortantes..........................................13
Figure 10: Chronogramme d'une poignée de mains bloquante avec données entrantes. . .14
Figure 11 : Chronogramme d'une poignée de mains bloquante avec données sortantes...14
Figure 12 : Schéma synoptique de l'interfaçage du capteur de température......................15
CHALMIN & EL­IDILBI
­ IV ­
Projet de deuxième année
Résumé
Beaucoup de systèmes embarqués utilisent encore le port série (ou RS­232) pour communiquer alors que ce port est en train de disparaitre des ordinateurs. La majorité des micro­contrôleurs intègrent pourtant un module USB qui est le port le plus présent dans les machines actuelles, donc le passage du RS­232 à l'USB semble pertinent. Cette transition a d'ailleurs été prévue par les développeurs de l'USB qui ont mis en place différentes classes dont la CDC (Communication Device Class). Il y a deux raisons à la lente adoption de l'USB : les développeurs se sont dans leur majorité habitués au port RS­
232 (et aux bibliothèques connexes) et la complexité de l'USB rend plus difficile la réalisation de solutions équivalentes à celles existantes déjà pour le RS­232.
Il nous a donc été demandé de réaliser une bibliothèque en langage C facilitant l'implémentation de l'USB. Pour cela, M. Jacquot nous a fourni la carte de développement AT91SAM7S256 du fabriquant Atmel, carte actuellement utilisée pour les études de projet du LIMOS. Mots clés : AT91SAM7S256, Atmel, CDC, RS­232, système embarqué, USB
CHALMIN & EL­IDILBI
­ V ­
Projet de deuxième année
Abstract
A lot of embedded systems still work on serial port (RS­232) for communicating with other devices whereas this port is going to disappear from computers. Nowadays most of micro­controllers integrate an USB port, the most world­spread communication port on today computers. So the transition from RS­232 to USB seems pertinent.
This transition have been prepared by the developers of USB: they integrate different classes of devices in the USB specification, and specifically the CDC (Communication Device Class). But there is two reasons for the low speed of USB adoption by developers: they are used to RS­232 port (and they already have developed all the libraries they need with this port) and the USB complexity do not make it easy to create such libraries for USB.
Our work was to develop a C library implementing a USB interface to facilitate the integration of USB in new or existent projects. In this context, Mr Jacquot provide us a development card AT91SAM7S256 from Atmel, the same used for the LIMOS projects.
Keywords: AT91SAM7S256, Atmel, CDC, embedded systems, RS­232, USB
CHALMIN & EL­IDILBI
­ VI ­
Projet de deuxième année
Table des matières
Remerciements.........................................................................................................III
Table des figures.......................................................................................................IV
Résumé.....................................................................................................................V
Abstract.....................................................................................................................VI
Introduction................................................................................................................1
1.USB........................................................................................................................2
1.1.Présentation de l'USB..................................................................................................2
1.2.Pourquoi le CDC.........................................................................................................3
2.Présentation de la carte AT91SAM7S256..............................................................4
2.1.Caractéristiques..........................................................................................................4
2.2.Les composants..........................................................................................................6
3.Implémentation de la bibliothèque.........................................................................7
3.1.Les différents registres USB........................................................................................8
3.2.Les différents états de l'USB......................................................................................9
3.3.Les transactions entre l'hôte et le périphérique........................................................10
a)Transaction de commande......................................................................................11
b)Transaction de données entrantes..........................................................................12
c)Transaction de données sortantes..........................................................................13
d)Poignée de mains bloquante...................................................................................14
4.Réalisation et résultats.........................................................................................15
Conclusion................................................................................................................16
Références bibliographiques.....................................................................................A
Glossaire....................................................................................................................B
CHALMIN & EL­IDILBI
­ VII ­
Projet de deuxième année
Introduction
Dans le cadre de ses nombreuses réalisations et prototypages, le laboratoire LIMOS utilise depuis quelques temps déjà la carte AT91SAM7S256 des entreprises ATMEL. Cette carte est très utile pour la réalisation des pré­tests et des études de faisabilités. Cependant, du fait de ses nombreuses capacités, il est aussi difficile de faire le tour de ses fonctionnalités.
C'est pourquoi, dans le cadre de notre projet de deuxième année, il nous a été demandé de réaliser une petite bibliothèque pour faciliter l'utilisation du port USB de la carte.
Cette bibliothèque devait permettre d'échanger aisément des données via le port USB de la carte, sans pour autant nécessiter de complexes initialisations des périphériques ou de lourdes fonctions de lectures­écritures. Il devait, si possible, n'y avoir que trois fonctions visibles pour l'utilisateur de la bibliothèque : une fonction d'initialisation, une fonction de lecture, une fonction d'écriture. Une autre fonctionnalité intéressante à développer serait l'activation de la lecture par interruption et non par scrutation, même si cela devait compliquer l'utilisation de notre bibliothèque.
Une bibliothèque USB pour la carte AT91SAM7S256 existe déjà, développée par les ingénieurs d'ATMEL. Cependant, c'est une bibliothèque très générique, et donc très compliquée et peu optimisée, ce qui rend son utilité plus que limité pour les chercheurs du LIMOS.
Pour réaliser notre propre bibliothèque, nous avions prévu de prendre en main la carte avec un projet plus simple que l'USB, comme par exemple la communication RS­232, et d'essayer de remplacer le RS­232 par de l'USB (grâce aux fonctions de base de la bibliothèque déjà existante).
Une fois notre projet fonctionnel, nous aurions ainsi toutes les fonctions et toute la structure nécessaire à la conception de notre bibliothèque USB.
Afin de mieux présenter notre démarche, nous allons en premier lieu présenter sommairement l'USB et expliciter notre choix concernant la classe de périphérique que nous avons utilisée. Nous allons ensuite décrire la carte AT91SAM7S256, et nous attarder quelque peu sur certains périphériques qu'il est nécessaire de connaître pour utiliser au mieux l'USB. Ce n'est que là que nous pourrons entrer plus en détails dans le fonctionnement du périphérique USB de la carte, en présentant en premier lieu les différents registres utilisés, ainsi que les différents états qu'ils peuvent prendre, sans oublier de dérouler les communications types entre la machine hôte et le périphérique USB. Nous terminerons par une présentation du résultat de l'intégration de la bibliothèque.
CHALMIN & EL­IDILBI
­ 1 ­
ISIMA
1.
USB
1.1.
Présentation de l'USB
Universal Serial Bus, ou USB, est un bus inventé en janvier 1996 par un consortium dans le but de connecter de nombreux périphériques en utilisant une connectique standardisée, d'améliorer les capacité de plug­and­play des machines en permettant la connexion / déconnexion à chaud et l'alimentation automatique des périphériques peu gourmands en énergie.
Grâce à ces qualités et à son faible coût, ce bus s'est rapidement répandu et est devenu aujourd'hui incontournable.
Cependant, le nombre important de périphériques divers et variés qu'il accepte font qu'il est nécessaire de trier ceux­ci dans différentes catégories, ou classes (cf. figure 1).
Classe Utilisation
Description
Exemples
00h
périphérique non défini
­
01h
interface
audio
microphone, haut­parleurs
02h
les deux
communication, cdc
modem, adaptateur ethernet
03h
interface
interface homme­machine
clavier, souris
05h
interface
interface physique
joystick avec retour de force
06h
interface
image
webcam
07h
interface
impression
imprimante
08h
interface
stockage de masse
disque dur, clé USB
09h
périphérique hub
hub USB
0Ah interface
données CDC
(classe utilisée avec la classe 02h)
0Bh
carte à puce
lecteur de cartes
0Dh interface
sécurité
­
0Eh
interface
vidéo
webcam
0Fh
interface
médical et santé
­
DCh les deux
périphérique de tests
­
E0h
interface
contrôleur sans fil
Wi­Fi, BlueTooth
EFh
les deux
divers
périphérique ActiveSync
FEh
interface
applications spécifiques
infrarouge
FFh
les deux
interface
constructeurs spécifiques
­
Figure 1 : Descriptions des différentes classes
CHALMIN & EL­IDILBI
­ 2 ­
ISIMA
1.2.
Pourquoi le CDC
Face aux différents types de périphériques que nous propose la norme USB, il nous fallait choisir celui qui correspondait le mieux à nos besoins.
Nous devions développer une bibliothèque permettant à n'importe quel programmeur de communiquer avec sa carte en toute simplicité. L'idée nous est venue d'utiliser la classe FFh (constructeur spécifique). Cela impliquait de développer aussi les drivers sur la machine hôte (l'ordinateur à laquelle la carte allait être reliée), et augmentait de manière exponentielle la difficulté de notre projet. Nous abandonnâmes donc cette solution.
Nous avons donc étudié toutes les possibilités qu'offrait chacune des classes, avant d'en trouver une qui servait à interconnecter les ordinateurs entre eux : la classe CDC ou Communication Device Class. De plus, en cherchant dans les exemples de codes fournis avec la carte, nous avons trouvé un exemple de code USB utilisant cette classe, ce qui nous libérait de la contrainte de devoir implémenter nous­même des drivers.
Un avantage de plus de la classe CDC : elle fonctionnait à l'aide d'un port COM virtuel sur la machine hôte. Hors, que ce soit sous Windows, Mac ou GNU/Linux, il est très aisé de discuter via un port COM à l'aide de petit programmes inclus de base (hypertrm sous Windows, ou la commande echo sous GNU/Linux), et permettait ainsi une plus grande interopérabilité de notre bibliothèque avec n'importe quel système d'exploitation présent sur le marché.
Figure 2 : Logo officiel USB
CHALMIN & EL­IDILBI
­ 3 ­
ISIMA
2.
Présentation de la carte AT91SAM7S256
2.1.
Caractéristiques
La carte pour laquelle nous devions développer la bibliothèque USB est une carte produite par IAR et est basée sur un processeur ARM7 de marque ATMEL. Elle embarque de nombreux périphériques, rendant ses capacités innombrables. connecteur J-TAG
connecteur USB
bouttons
alimentatio
n
micro-contrôleur
CAN
connecteurs RS232
connecteurs
d'extensions
zone de prototypage
Figure 3 : Vue de la carte AT91SAM7S256
Comme on peut le voir sur la figure 3, la carte possède (entre autre) 2 ports USART (RS232), un convertisseur analogique­numérique (CAN), un port USB, et une zone de prototypage avec des connecteurs d'extensions, ce qui en fait une carte très polyvalente.
Tout ces périphériques sont articulés autour d'un processeur RISC 32bits, le ARM7TDMI. Ce processeur réussi le tour de force de ne consommer que 50mA à pleine puissance. On obtient ainsi une carte qui au final peut être alimentée par un port USB.
Le cœur ARM7TDMI est capable d'interpréter à la fois les jeux d'instructions 32bits ARM et 16bits Thumb, autorisant le choix entre de hautes performances et du code à haute densité d'instructions. CHALMIN & EL­IDILBI
­ 4 ­
ISIMA
Le processeur utilise l'architecture de Von Neuman, avec un pipeline à trois étages : Fetch (récupération de l'instruction), Decode (décodage de l'instruction et récupération des paramètres) et Execute (exécution de l'instruction et enregistrement du résultat). L'utilisation du pipeline permet de traiter trois instructions simultanément, et ainsi d'obtenir une accélération sensible des performances.
Seul point noir : la carte n'est pas directement programmable. Il est nécessaire d'avoir un boitier entre la machine hôte et la carte. Ce boitier, nommé J­LINK, se branche via un port spécifique : le port J­TAG.
La figure 4 représente un schéma simplifié de la structure de la carte.
port J-TAG
Processeur ARM7TDMI
SRAM
---------Flash
contrôleur
mémoire
Contrôleur mémoires périphériques
Contrôleurs
Système
AIC
USART 1
USART 2
Autres
périphériques
USB
PMC
PIO
...
Figure 4 : Architecture simplifiée de la carte AT91SAM7S256
Comme on peut le voir, la plupart des entrées/sorties de la carte ne sont pas directement accessibles : elles passent par le PIO, ou Parallel Input/Output Controller (contrôleur des entrées/sorties parallèles).
CHALMIN & EL­IDILBI
­ 5 ­
ISIMA
2.2.
Les composants
Pour une carte ne mesurant que 10 centimètres de côté, avoir un aussi grand nombre de composants pose de nombreux problèmes d'intégration. L'un de ces problèmes est le câblage des entrées/sorties : il est impossible d'affecter une patte à chacune des lignes de chaque composant, la carte ne pouvant pas supporter un tel nombre de pattes. Les ingénieurs ATMEL ont répondu à ce problème avec le PIO.
Le Parallel Input/Output Controller (ou PIO, contrôleur d'entrées/sorties parallèles) est un composant capable de gérer jusqu'à 32 lignes d'entrées/sorties programmables. Chaque ligne d'entrées/sorties peut être laissée comme une ligne générique ou être affectée à une fonctionnalité d'un autre composant embarqué. Cela assure une optimisation du nombre de pins effectifs sur la carte.
Côté programmeur, chaque ligne d'entrées/sorties est associée à un numéro de bit dans tous les registres 32 bits de l'interface utilisateur du PIO, ce qui permet aisément de choisir, au moment de la réalisation d'un programme, comment affecter chacune des pins nécessaires.
Comme nous l'avons vu précédemment, la carte ne consomme que très peu de courant. Afin de toujours minimiser les dépenses énergétiques, ses concepteurs lui ont ajouté une unité de gestion d'énergie, ou PMC (Power Management Controller). Le travail de cette unité est de générer chacune des horloges nécessaires à la carte et à ses composants pour fonctionner. En éteignant une horloge, le PMC force l'arrêt des composants dépendant de cette horloge, les empêchant ainsi de consommer de l'énergie. Pour gérer au mieux ses composants, la carte dispose d'une unité de contrôle d'interruptions avancée, ou AIC (Advanced Interrupt Controller). L'AIC autorise la gestion de 32 sources d'interruptions différentes. Avec cette unité, les développeur peuvent activer (masquer) les interruptions séparément et leur attribuer un niveau de priorité (sur 8 niveaux existants). Les 8 niveaux de priorités permettent aux développeurs de définir une priorité pour chaque interruption, rendant ainsi possible le traitement d'interruptions même si d'autres interruptions avec un niveau de priorité inférieur sont déjà actives.
CHALMIN & EL­IDILBI
­ 6 ­
ISIMA
3.
Implémentation de la bibliothèque
UDPCK
MCK
ASB
Interface utilisateur
Mémoire FIFO
Terminaison 0
T0
Terminaison 1
T1
Terminaison 2
T2
Terminaison 3
T3
Registres globaux
DP
Interface
série
Transducteur
DM
Unité de veille
Figure 5 : Architecture simplifiée du port USB
Un périphérique USB est composé de différentes terminaisons (ou endpoint en anglais). L'AT91SAM7S256 en compte 4 (cf. figure 5), mais certains appareils peuvent en compter jusqu'à 8. Ces terminaisons servent à paralléliser les échanges sur le bus USB. En fonction de la configuration choisie, chaque terminaison aura un rôle différent. Par exemple, la terminaison 0 est toujours associée aux échanges de commandes, alors que les terminaisons 1 et 2 servent généralement à l'émission ou à la réception de données.
Il existe plusieurs sorte d'échanges entre le périphérique USB et la machine hôte. Notre travail ayant principalement consisté en la gestion de ces échanges, nous allons les décrire plus en détails.
Cependant, pour faciliter la compréhension de ces échanges de données, voici une petite présentation des différents registres du périphérique USB ainsi que la machine d'états qui lui est associée.
CHALMIN & EL­IDILBI
­ 7 ­
ISIMA
3.1.
Les différents registres USB
L'utilisation du périphérique USB se fait par l'intermédiaire de différents registres. UDP_FRM_NUM : Frame Number Register (numéro de trame) Ce registre contient le numéro de trame qui est géré par l'hôte. Il contient également les bits de contrôles qui permettent de savoir si la dernière trame a été envoyée correctement ou non.
UDP_GLB_STAT : Global State Register ( état global)
Ce registre est utilisé pour obtenir et fixer l'état du périphérique (se reporter à la section suivante : Les différents états de l'USB).
UDP_FADDR : Fonction Address Register (adresse de la fonction)
Ce registre contient l'adresse du périphérique lorsque celui­ci est passé en mode adressé.
UDP_IER, UDP_IDR, UDP_IMR, UDP_ISR, UDP_ICR : Interrupt Enable / Disable / Mask/Status / Clear Register (activation/désactivation/masquage/statut/vider des interruptions)
Ces registres servent à manipuler les interruptions de l'USB.
UDP_RST_EP : Reset Endpoint Register (Ré­initialisation des terminaisons)
Ce registre permet de remettre à zéro les files mémoire associées à chaque terminaison.
UDP_CSR : Endpoint Control and Status Register ( statu et contrôle des terminaisons)
Il y a un de ces registre pour chaque terminaison. Ils permettent d'activer la terminaison et de savoir dans quelle état elle est précisément.
UDP_FDR : FIFO Data Value (Donnée de la file)
Il y a un de ces registres pour chaque terminaison, il contient les données reçues ou à émettre. Après une réception, le nombre d'octets à lire dans la file d'une terminaison est donné par le champs RXBYTECNT du registre UDP_CSR correspondant a la même terminaison.
UDP_TXVC : Transceiver Control Register (contrôle du transcepteur)
Ce registre ne contient qu'un bit utile : TXVDIS. Ce bit permet de désactiver le transcepteur en le mettant à 1 et de l'activer en le mettant à zéro.
CHALMIN & EL­IDILBI
­ 8 ­
ISIMA
3.2.
Les différents états de l'USB
Un appareil USB a plusieurs états possible, comme le montre la figure 6.
Figure 6 : Automate des différents états de l'USB
Les changements d'états dépendent de l'état du bus ou des requêtes standards émises par la terminaison de contrôle. Après une période d'inactivité du bus, le périphérique entre en veille. Il est alors obligé d'accepter les requêtes suspend/resume venant de l'hôte. Les contraintes dans le mode veille sont strictes pour les appareils alimentés par le bus USB : ils ne peuvent pas consommer plus de 500µA.
Quand il n'y a pas d'appareils connectés, les câbles DP et DM sont maintenus à la masse par des résistances de pull­down de 15kΩ. Lorsqu'un appareil se connecte, il rajoute sur le câble DP une résistance de pull­up de 1,5kΩ. Le port USB passe en veille (état idle), le signal DP est forcé a 3,3V grâce à la résistance de pull­up et le câble DM est à la masse car il y a toujours la résistance de pull­
down. Si cette transaction s'est déroulée correctement, le périphérique entre dans le mode alimenté. Dans cet état, les deux domaines d'horloge du périphérique USB doivent être activés dans le gestionnaire CHALMIN & EL­IDILBI
­ 9 ­
ISIMA
d'alimentation : 12MHz pour la connectique USB et 48MHz pour l'interface utilisateur.
Après s'être connecté à l'hôte, le périphérique attend un signal reset de fin de bus. Une fois que cette interruption a été levée, le périphérique passe dans l'état normal : il doit activer la terminaison par défaut et activer ses interruptions si nécessaire, puis reconfigurer le masque d'interruptions car celui­ci a été remis a zéro lors du reset de l'USB. Enfin, il faut activer le transcepteur.
Après une requête de configuration d'adresse émise par l'hôte, le périphérique entre dans le mode adresse. Une fois que toutes les requêtes de configuration standard se sont bien déroulées, le périphérique active toutes les terminaisons et leurs interruptions conformément à la configuration. Lorsque une longue inactivité sur le bus est détectée et si l'interruption suspend n'est pas masqué, le périphérique rentre en sommeil. Dans ce mode, le micro­contrôleur doit drainer moins de 500µA du bus USB. Cela implique qu'il baisse sa fréquence, qu'il désactive toutes ses fonctions, voir même qu'il désactive d'autres composants de la carte.
L'ordre de réveil peut être détecté même si le transcepteur et les horloges sont désactivées (toutefois, la résistance de pull­up ne doit pas être retirée). Dès que l'ordre de réveille est perçu, l'interruption de réveil est déclenché. Cette interruption doit réactiver toutes les fonctions qui avaient été désactivées avant l'état de sommeil.
3.3.
Les transactions entre l'hôte et le périphérique
La machine hôte et le périphérique USB échangent plusieurs types de paquets pour pouvoir communiquer. Certains de ces paquets sont générés et/ou traités directement par le port (au niveau électronique) comme le paquet d'acquittement.
Nous allons ici dérouler l'échange de plusieurs paquets, du point de vue de la machine hôte. Ces échanges, ou transactions, sont au nombres de trois : les transactions de commandes, les transactions de données entrantes (du périphérique vers la machine hôte) et les transactions de données sortantes (de la machine hôte vers le périphérique). Il existe aussi une procédure de "poignée de main" bloquante (stall handshake en anglais) que nous détaillerons par la suite.
Toutes les actions logicielles seront traitées par notre bibliothèque. Les actions mises en place par le contrôleur correspondent quand à elles aux actions effectuées matériellement.
CHALMIN & EL­IDILBI
­ 10 ­
ISIMA
a) Transaction de commande
Un échange de commande est une transaction spéciale de la machine hôte vers le périphérique, utilisée lors des contrôles de transferts. Une transaction de commande doit être traitée le plus rapidement possible par le logiciel. Elle est utilisée pour transmettre des requêtes de la machine hôte vers le périphérique. Ces requêtes sont ensuite réceptionnées par le périphérique USB et peuvent nécessiter plus d'arguments. Les arguments sont envoyés au périphérique par une transaction de données sortantes qui suit la transaction de commande. Ces requêtes peuvent renvoyer des données. Les données sont transmises à la machine hôte par la transaction de données entrantes qui suit la transaction de commande. Quand le périphérique reçoit une transaction de commande (cf. figure 7) : ­ le contrôleur USB accuse automatiquement la réception du paquet de commande
­ le bit RXSETUP est mis à 1 dans le registre UDP_CSRx (où x correspond au numéro de la terminaison)
­ une interruption de terminaison est générée tant que le bit RXSETUP n'est pas remis à 0. Si les interruptions pour cette terminaison sont activées, alors l'interruption est transmise au micro­
contrôleur. Ainsi, la bibliothèque doit détecter la présence du bit RXSETUP en interrogeant le registre UDP_CSRx ou en activant les interruptions, lire le paquet dans la file mémoire, et remettre à zéro le bit RXSETUP. Il ne doit en aucun cas être remis à zéro avant la lecture de la file mémoire, autrement le contrôleur USB risquerait d'accepter le paquet de données sortantes suivant et d'écraser le paquet d'initialisation présent dans la mémoire.
Traitement par le logiciel
Réception du paquet
paquet d'init. données d'init.
BUS USB
RXSETUP
ACQ.
Réception des données sortantes
pqt d'envoi envoi de données NACQ.
pqt d'envoi
envoi de données ACQ.
Interruption levée
activé
matériellement
RX_DATA_BK0
Mémoire FIFO
XX
données d'init.
mise à zéro
logiciellement
activé
matériellement
XX
envoi de données
Figure 7 : Chronogramme de traitement d'un paquet de commande
CHALMIN & EL­IDILBI
­ 11 ­
ISIMA
b) Transaction de données entrantes
Les échanges de données entrantes sont utilisés pour transférer des données du périphérique vers la machine hôte. Ces échanges se déroulent en 6 étapes (cf. figure 8) : ­ l'application teste s'il est possible d'écrire dans la file mémoire en vérifiant que le bit TXPKTRDY
est à 1 dans le registre UDP_CSRx (où x est le numéro de la terminaison) de la terminaison correspondante. (le bit TXPKTRDY doit être remis à 0 par la suite)
­ l'application écrit le premier des paquets de données dans la file mémoire de la terminaison (registre UDP_FDRx)
­ l'application signifie qu'elle a finie d'écrire en passant le bit TXPKTRDY à 1 dans le registre UDP_CSRx (x numéro de la terminaison).
­ l'application est prévenue que la file mémoire a été libérée quand le bit TXCOMP du registre UDP_CSRx passe à 1. Une interruption est lancée sur la terminaison tant que TXCOMP reste à 1.
­ l'application écrit le second paquet à envoyer dans la file mémoire de la terminaison via le registre UDP_FDRx
­ l'application signale au contrôleur USB qu'elle a finie d'écrire en passant à 1 le bit TXPKTRDY
dans le registre UDP_CSRx de la terminaison.
­ l'application remet à 0 le bit TXCOMP du registre UDP_CSRx (qui est automatiquement passé à 1 )
Le bit TXCOMP est automatiquement passé à 1 par le port USB lorsqu'il reçoit un acquittement du paquet de données entrantes envoyées. Une interruption est levée tant que le bit TXCOMP est à 1.
Données précédentes
Transfert des données dans la mémoire FIFO
pqt d'envoi données entrantes ACQ.
BUS USB
pqt d'envoi
NACQ.
pqt d'envoi
Données envoyées sur le bus USB
données entrantes 2
ACQ.
TXPKTRDY
mise à zéro
materiellement
activé
logiciellement
mise à zéro
materiellement
activé
logiciellement
Interruption activée
Interruption activée
RX_DATA_BK0
mise à zéro
logiciellement
Mémoire FIFO
données entrantes
chargement en cours
mise à zéro
logiciellement
données entrantes 2
Figure 8 : Chronogramme du traitement de données entrantes
CHALMIN & EL­IDILBI
­ 12 ­
ISIMA
c) Transaction de données sortantes.
Les transactions de données sortantes gèrent la transmission de données de la machine hôte vers le périphérique USB. Ces transactions ont lieu en 6 étapes (cf. figure 9) :
­ la machine hôte génère un paquet de données sortantes
­ lors de la réception du paquet, si la file mémoire de la terminaison est déjà prise, le contrôleur génère un paquet de non­acquittement. Dès que la file mémoire est libre, le contrôleur y écrit les données et envoie un paquet d'acquittement
­ le logiciel est prévenu de l'arrivée de données sur le bus USB par le bit RX_DATA_BK0 dans le registre UDP_CSRx (x numéro de terminaison). Une interruption est levée tant que le bit RX_DATA_BK0 est à 1.
­ le nombre de bits de données disponible dans la file mémoire est lue par le logiciel au travers du bit RXBYTECNT dans le registre UDP_CSRx de la terminaison correspondante.
­ le logiciel lit les données au travers du registre UDP_FDRx
­ le logiciel signifie au contrôleur qu'il a lue les données en re­initialisant le bit RX_DATA_BK0
du registre UDP_CSRx à 0 : le contrôleur peut alors accepter un nouveau paquet.
L'hôte envoie des données
Transfert des données dans la mémoire FIFO
L'hôte envoie d'autres données
pqt d'envoi données sortantes
Bus USB
ACQ.
pqt d'envoi 2
données
sortantes 2
NACQ. pqt d'envoi 2
données sortantes 2
ACQ.
Interruption activée
RX_DATA_BK0
mise à zéro
logiciellement
activation
materielle
Mémoire FIFO
L'hôte renvoie les données
données sortantes
données sortantes
données sortantes 2
écrites par le périphérique USB
lues par le logiciel
écrites par le périphérique USB
Figure 9 : Chronogramme du traitement de données sortantes
CHALMIN & EL­IDILBI
­ 13 ­
ISIMA
d) Poignée de mains bloquante
Il existe deux cas où on peut vouloir mettre fin à une communication USB : lors de la fermeture d'une terminaison ou lorsqu'on veut annuler une requête en cours. Dans ces deux cas, on utilise une "poignée de mains bloquante", ou stall handshake.
Voici les différentes étapes d'un envoi d'une poignée de main bloquante : ­ activation du bit FORCESTALL dans le registre UDP_CSRx de la terminaison
­ la machine hôte reçoit le paquet de poignée de mains ­ le logiciel est averti de l'envoie du paquet par le bit STALLSENT (même registre que FORCESTALL). Une interruption étant liée à ce bit, il faut le remettre à 0. Les figures 10 et 11 représentent la réception d'une poignée de main bloquante interrompant un échange de données entrantes (respectivement sortantes) sur la terminaison 0.
Bus USB
pqt d'envoi données entrantes
pqt bloquant
mise à zéro
logiciellement
activation
logicielle
RX_DATA_BK0
Interruption
activée
Mémoire FIFO
mise à zéro
logiciellement
activation
materielle
Figure 10: Chronogramme d'une poignée de mains bloquante avec données entrantes
Bus USB
pqt d'envoi
données
sortantes
pqt bloquant
activation
logicielle
RX_DATA_BK0
Interruption
activée
Mémoire FIFO
mise à zéro
logiciellement
activation
materielle
Figure 11 : Chronogramme d'une poignée de mains bloquante avec données sortantes
CHALMIN & EL­IDILBI
­ 14 ­
ISIMA
4.
Réalisation et résultats
Figure 12 : Schéma synoptique de l'interfaçage du capteur de température
Pour tester l'USB dans des conditions réelles, nous avons choisi de faire un capteur de température qui renvoi les données à un ordinateur pour que celui­ci affiche une courbe. Nous avons utilisé une application conçu lors de travaux pratiques d'Interfaçage Numérique qui communique avec l'ordinateur grâce à une liaison RS­232. Cette application correspond donc parfaitement au but du projet qui est de faire évoluer le RS­232 vers l'USB.
La première étape a été de modifier les primitives d'envoi pour qu'elles émettent également sur le port USB, pour obtenir une configuration semblable à la figure 12. Pour cela, nous avons regardé le code fournit par le constructeur, code tout à fait opérationnel lorsqu'il est seul, mais qui a eu un comportement erratique lorsque nous avons essayé de l'intégrer à notre projet. Après quelque temps passé à chercher la source du dysfonctionnement, M. Jacquot nous a conseillé d'utiliser une ancienne version de ce code d'exemple, code qui possède l'avantage d'être plus simple que la version actuelle. Après l'intégration de la routine d'initialisation, de la fonction d'écriture et la correction de quelques erreurs d'exécution, le système fonctionnait correctement. Nous avons ensuite testé la lecture par scrutation, ce qui ne nous a pas posé de problèmes particuliers.
CHALMIN & EL­IDILBI
­ 15 ­
ISIMA
Conclusion
Ce projet avait pour but l'implémentation d'une bibliothèque USB pour la carte AT91SAM7S256. Comme vu au chapitre 4, nous avons réalisé une bibliothèque basée sur la méthode de scrutation. Cependant ce type d'utilisation ne répondait pas entièrement au exigences de M. Jacquot qui voulait nous faire utiliser les interruptions pour la lecture des données. Nous avons donc essayé de mettre en place une interruption sur la réception des données, mais malgré tous nos essais, et après plusieurs relectures attentives de la documentation, nous n'avons pas réussi.
Il est à noter que la carte AT91SAM7S256 est relativement récente, et que la documentation change fréquemment (4 versions différentes en moins de 5 mois, chacune ajoutant de nouvelles descriptions et corrigeant les erreurs d'impression de la version précédente).
Nous devons admettre avoir sous­estimé la charge de travail de notre second semestre, ainsi que la complexité de la tâche demandée, complexité que nous n'avons découverte qu'au fur et à mesure des erreurs rencontrées.
Ce projet nous a néanmoins appris à nous plonger dans une documentation imposante, et à en extraire que la partie ciblée sans nous perdre dans la masse d'informations. Il nous a aussi appris à ne pas nous fier à notre matériel, les configurations déjà mises en place pouvant empêcher purement et simplement l'affichage d'un quelconque message d'erreur.
La bibliothèque est néanmoins fonctionnelle en scrutation, et pourra ainsi servir aux chercheurs du LIMOS le temps que quelqu'un d'autre se penche sur le problème.
CHALMIN & EL­IDILBI
­ 16 ­
ISIMA
Références bibliographiques
[1] Atmel Corp., AT91SAM7S Datasheet,
http://www.atmel.com/dyn/resources/prod_documents/doc6175.pdf
[2] Atmel Corp., AT91 USB Framework,
http://www.atmel.com/dyn/resources/prod_documents/doc6263.pdf
[3] Atmel Corp., AT91 USB CDC Driver Implementation,
http://www.atmel.com/dyn/resources/prod_documents/doc6269.pdf
CHALMIN & EL­IDILBI
­ A ­
ISIMA
Glossaire
FIFO (First In First Out) Structure de données où les valeurs stockées sortent dans le même ordre que celui avec lequel elles sont entrées.
Firmware Micrologiciel en français. Logiciel qui est intégré dans un composant matériel pour le contrôler à bas­niveaux.
Interruption Commande indiquant au processeur d'interrompre le programme en cours au profit d'une fonction à exécuter.
JTAG (Joint Test Action Group) Protocole utilisé pour programmer et pour pouvoir dérouler l'exécution du programme pas à pas.
LIMOS (Laboratoire d'informatique, de modélisation et d'optimisation des système) Laboratoire inter­universitaire situé à Clermont­Ferrand.
Pipeline Technique de conception de processeur qui permet d'augmenter le nombre d'instructions traitées par seconde.
Pull­down Résistance reliée entre la masse et un fil imposant le niveaux bas à ce fil.
Pull­up Résistance reliée entre la source de tension et un fil imposant le niveaux haut à ce fil. Registre Zone de mémoire vive interne contenue dans le microprocesseur et affectée au stockage temporaire d'un certain nombre d'informations.
Scrutation Méthode pour interroger un périphérique en regardant périodiquement si il n'a pas de données à transmettre.
Transcepteur Équipement électronique combinant un récepteur et un émetteur qui partagent des circuits communs.
UDP (USB Device Port) Contrôleur USB.
CHALMIN & EL­IDILBI
­ B ­
ISIMA