Difference between revisions of "Article Linux Mag N2"

Revision as of 16:31, 1 March 2008

Introduction

Je vous avais quitté l'année dernière avec un prototype de console de jeu portable qui pouvait encore prêter à moquerie du fait de ses faibles capacités sonores et du besoin de connecter un clavier PS/2 afin de l'utiliser. Nous allons cette fois voir comment parfaire notre prototype afin de lui ajouter les fonctionnalités manquantes afin de lui faire rejoindre la catégories des consoles "nextgen": écran tactile, sortie son stéréo 16bit qualité CD, gamepad.

Bien que applicables à toute plateforme Linux embarqué supportant un noyau Linux récent et Buildroot, mes essais ont été conduits sur les cartes proposées aux membres de l'association Armadeus Project et désormais distribuées par la société armadeus systems.

Le LCD

Dans mon précédent article [1] j'avais utilisé un LCD qui était plutôt destiné à des applications industrielles et pas vraiment à de l'embarqué. Depuis, l'association Armadeus Project s'est doté d'autres types de LCDs plus compact (nnn x yyy mm) qu'elle propose à ses membres et qui ressemble beaucoup à ce que l'on peut trouver sur les consoles à la mode: Nintendo DS (résolution de 320x240 pixels) et Sony PSP (résolution 480x272) tous les 2 avec dalle tactile intégrée, bonne luminosité et bon contraste. Pour mon exemple, j'utiliserai celui de la PSP. Ce LCD se connecte au processeur ARM9/i.MXL de la même manière que le LCD du précédent article à savoir une connection directe des signaux de composante couleur et de contrôle (l'électronique interne de l'i.MXL et du LCD étant électriquement compatible (2,8V)). Cette fois-ci le LCD peut afficher des couleurs sur 24bits et certaines doivent être "sacrifiées" car le contrôlleur LCD de l'i.MXL ne gère au maximum que des couleurs 16 bits. Le rétroéclairage du LCD nécessite par contre des tensions particulières et nous avons donc été obligé de réaliser une petite carte d'adaptation qui permet de convertir le 3,3V fournit par la carte d'accueil (DevLight) en +/-20V. Cette carte permet aussi de brancher plus facilement la nappe du LCD qui est de type Flex et qui requiert donc un connecteur particulier (cf photos).

Comme je l'ai dit le LCD possède une dalle tactile intégrée. Le principe de cette dalle est de faire varier une résistance suivant l'abscisse et l'ordonnée de l'endroit de l'écran qui est appuyé. Le LCD a donc 4 sorties qui permettent de faire cette mesure X+/X- et Y+/Y-. Pour mesurer la résistance il suffit d'envoyer un courant constant sur les sorties et de mesurer la tension au niveau de chaque paire. Ensuite on peut en déduire le X et le Y du point appuyé.

Nous avons choisi de faire remplir cette fonctionnalité à un petit composant externe de chez Texas Instruments le TSC2102. Facilement disponible ce composant sera aisément rajouté à une DevLight par un bon électronicien. Ce composant est en plus d'un contrôleur de dalle tactile un CODEC audio de bonne facture ce qui n'est pas pour nous déplaire: en intégrant ce composant nous rajoutons donc d'un coup à notre prototype l'écran tactile et la sortie audio. En bonus on peut noter que ce composant fait aussi office de capteur de température et de CAN.

Le TSC2102 s'interface facilement à des microprocesseurs 32 bits récents grâce à:

• une liaison série type I2S qui permet de lui envoyer sous forme de trame les données audio à reproduire ;
• une liaison série type SPI qui permet de le configurer et de lire les valeurs liées au contrôleur de dalle tactile ;
• une ligne d'interruption qui signale au microprocesseur que des données sont disponibles.

(Mettre schéma)

Le TSC2102 fonctionnant en 3,3V, les entrées/sorties se câblent directement sur les pattes correspondantes de l'i.MXL de l'APF.

Maintenant que la bête est câblée, prenons-en le contrôle depuis Linux. Comme le TSC regroupe plusieurs fonctionnalités les pilotes Linux nécessaires à son utilisation seront divisés en plusieurs couches/classes:

• une couche bas niveau qui s'occupe de la configuration et de la récupération des données par SPI. Cette couche utilise l'API Linux SPI et fournit aux autres couches/classes des méthodes d'accès. C'est un peu la base sur laquelle reposeront les autres classes.
• une classe permettant de faire le lien entre les données touchscreen fournit par l'écran et les système d'entrées/sorties de Linux (Input Event)
• une couche bas niveau qui s'occupe de l'envoie des données audio sur le bus I2S
• une classe permettant de faire le lien avec l'API ALSA du noyau afin de pouvoir jouer les sons de manière standard.

Détaillons tout d'abord la partie écran tactile: Lorsque l'utilisateur appuie sur l'écran le contrôleur du TSC2102 le détecte et lance une conversion analogique/numérique permettant de récupérer X,Y,Z. Une fois cette conversion effectuée il avertit l'i.MXL au moyen du signal d'interruption que des données sont disponibles. Le driver Linux averti construit alors les trames SPI permettant de récupérer ces informations et confie à l'API SPI Linux l'envoi de ces trames. Notre driver est notifié par callback lorsque les trames ont été traitées et les données recues (Le bus SPI étant synchrone, les données sont reçues au moment où les trames les demandant sont envoyées). Ayant reçu les données le driver les envoie à la couche supérieure qui fait interface avec le système d'entrée/sortie de Linux. Un événement touchscreen est généré et devra être récupéré au niveau de l'espace utilisateur. Pour cela il existe une librairie Tslib développée par Russell King himself qui permet de standardiser la manière de gérer les événements touchscreen et même de leur appliquer des filtres.

Si l'on veut pouvoir récupérer les informations touchscreen au niveau de librairies graphiques comme s'il s'agissait d'événements souris il faut compiler ces dites librairies avec le support Tslib. Ainsi SDL et Qt pour ne citer qu'elles proposent cette option à la compilation.