Article Linux Mag N2 - Revision history

JulienB: /* keypad */

2008-03-02T21:07:24Z

‎keypad

JulienB: /* Tslib */

2008-03-02T21:05:19Z

‎Tslib

JulienB: /* ALSA Soc */

2008-03-01T17:11:23Z

‎ALSA Soc

JulienB: /* Un peu de soft */

2008-03-01T16:01:54Z

‎Un peu de soft

JulienB: /* Un peu de soft */

2008-03-01T15:56:35Z

‎Un peu de soft

JulienB: /* Le contrôleur "magique" */

2008-03-01T15:55:49Z

‎Le contrôleur "magique"

JulienB: /* Le LCD */

2008-03-01T15:43:54Z

‎Le LCD

JulienB: /* Introduction */

2008-03-01T15:33:40Z

‎Introduction

JulienB at 15:31, 1 March 2008

2008-03-01T15:31:57Z

ChristopheF: corrections mineures (orthographe, fautes de frappe)

2007-09-05T08:42:02Z

corrections mineures (orthographe, fautes de frappe)

← Older revision		Revision as of 21:07, 2 March 2008
Line 51:		Line 51:
	* 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		* 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~~==	+	==Keypad==
		+
		+	===Principe de fonctionnement d'un clavier matriciel===
		+
		+	===Détails du pilote===

@@ Line 39: / Line 39: @@
 ==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.
 ==ALSA Soc==

← Older revision		Revision as of 17:11, 1 March 2008
Line 41:		Line 41:

	==ALSA Soc==		==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==		==keypad==

← Older revision		Revision as of 16:01, 1 March 2008
Line 37:		Line 37:
	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.

		+	==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.		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.
		+
		+	==ALSA Soc==
		+
		+	==keypad==

@@ Line 30: / Line 30: @@
 * 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:

@@ Line 13: / Line 13: @@
 ==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 et de Convertisseur Analogique Numérique (2 entrées).
+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 à:
+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 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.
 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 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
@@ Line 31: / Line 32: @@
 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).
+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.
-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.
+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.

@@ Line 5: / Line 5: @@
 ==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.
+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).
-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é.
+==La dalle tactile==
-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 contrôleur "magique"==
-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 SPI qui permet de le configurer et de lire les valeurs liées au contrôleur de dalle tactile ;

@@ Line 1: / Line 1: @@
 ==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.
+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 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.
+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==