Difference between revisions of "Article Linux Mag N2"
(→Introduction) |
(→keypad) |
||
| (6 intermediate revisions by the same user not shown) | |||
| Line 5: | Line 5: | ||
==Le LCD== | ==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 | + | 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 ressemblent 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, l'écran 320x240 étant de moins en moins facilement approvisionnable. |
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. | 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). | 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). | ||
| − | + | ==La dalle tactile== | |
| + | Le LCD PSP n'étant pas équipée par défaut d'une dalle tactile intégrée, nous en avons rajouté une de taille compatible. 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é. La dalle a donc 4 "connections" (X+/X- et Y+/Y-) qui permettent de faire cette mesure de résistance. Pour cela il suffit d'envoyer un courant constant sur ces connections 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é à | + | ==Le contrôleur "magique"== |
| + | 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é à la carte d'adaptation du LCD 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 (précision de xx°C) et de Convertisseur Analogique Numérique (2 entrées). | ||
| − | Le TSC2102 s'interface facilement à des microprocesseurs 32 bits récents grâce à: | + | Le TSC2102 s'interface facilement à des microprocesseurs 32 bits récents, et donc à notre ARM9, 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 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 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. | * une ligne d'interruption qui signale au microprocesseur que des données sont disponibles. | ||
| − | (Mettre schéma) | + | (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. | 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. | ||
| + | ==Un peu de soft== | ||
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: | 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 | + | * 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 SPI de Linux et fournit aux autres couches/classes des méthodes d'accès aux registres de contrôle du TSC. 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 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 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. | * une classe permettant de faire le lien avec l'API ALSA du noyau afin de pouvoir jouer les sons de manière standard. | ||
| + | |||
| + | (Mettre schéma) | ||
Détaillons tout d'abord la partie écran tactile: | 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 | + | 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 du point appuyé (Z=pression). 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 dans la même trame qui les demandent). |
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. | 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. | + | ==Tslib== |
| + | 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. | ||
| + | ===Configuration=== | ||
| + | |||
| + | ===Utilisation=== | ||
| + | |||
| + | ==ALSA Soc== | ||
| + | ALSA System on Chip (ASoc / ALSA SoC) est une partie du projet ALSA visant à rendre son utilisation sur les systèmes embarqués plus portable et plus au fait des contraintes de ces derniers: pour cela il essaie de rendre les pilotes pour les CODECs les plus réutilisables et donc indépendants du système possible, il facilite l'échange des flux audio entre le processeur et le CODEC et il garantie une adaptation optimum de la consommation du système audio. | ||
| + | |||
| + | ASoC divise un système audio en 3 parties: | ||
| + | * une partie qui gère le CODEC et qui est indépendante du système auquel il est connecté | ||
| + | * une partie "plateforme" qui gère le flux de donnée (I2S/PCM/AC97) entre le CODEC et le processeur | ||
| + | * une partie "machine" qui gère les configurations spécifiques telles que le configuration des amplis et la détection d'événenements type insertion de casque | ||
| + | |||
| + | ==Keypad== | ||
| + | |||
| + | ===Principe de fonctionnement d'un clavier matriciel=== | ||
| + | |||
| + | ===Détails du pilote=== | ||
Latest revision as of 22:07, 2 March 2008
Contents
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 pour lui faire rejoindre la catégories des consoles "nextgen": écran tactile, sortie son stéréo 16bits qualité CD, gamepad.
Bien que applicables à toute plateforme Linux embarqué supportant un noyau 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 ressemblent 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, l'écran 320x240 étant de moins en moins facilement approvisionnable. 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).
La dalle tactile
Le LCD PSP n'étant pas équipée par défaut d'une dalle tactile intégrée, nous en avons rajouté une de taille compatible. 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é. La dalle a donc 4 "connections" (X+/X- et Y+/Y-) qui permettent de faire cette mesure de résistance. Pour cela il suffit d'envoyer un courant constant sur ces connections et de mesurer la tension au niveau de chaque paire. Ensuite on peut en déduire le X et le Y du point appuyé.
Le contrôleur "magique"
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é à la carte d'adaptation du LCD 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 (précision de xx°C) et de Convertisseur Analogique Numérique (2 entrées).
Le TSC2102 s'interface facilement à des microprocesseurs 32 bits récents, et donc à notre ARM9, 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.
Un peu de soft
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 SPI de Linux et fournit aux autres couches/classes des méthodes d'accès aux registres de contrôle du TSC. 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.
(Mettre schéma)
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 du point appuyé (Z=pression). 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 dans la même trame qui les demandent). 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.
Tslib
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.
Configuration
Utilisation
ALSA Soc
ALSA System on Chip (ASoc / ALSA SoC) est une partie du projet ALSA visant à rendre son utilisation sur les systèmes embarqués plus portable et plus au fait des contraintes de ces derniers: pour cela il essaie de rendre les pilotes pour les CODECs les plus réutilisables et donc indépendants du système possible, il facilite l'échange des flux audio entre le processeur et le CODEC et il garantie une adaptation optimum de la consommation du système audio.
ASoC divise un système audio en 3 parties:
- une partie qui gère le CODEC et qui est indépendante du système auquel il est connecté
- une partie "plateforme" qui gère le flux de donnée (I2S/PCM/AC97) entre le CODEC et le processeur
- une partie "machine" qui gère les configurations spécifiques telles que le configuration des amplis et la détection d'événenements type insertion de casque
