Article Linux Mag N2 - Revision history

JulienB: /* keypad */

2008-03-02T21:07:24Z

keypad

← Older revision		Revision as of 23: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===

JulienB: /* Tslib */

2008-03-02T21:05:19Z

Tslib

← Older revision		Revision as of 23:05, 2 March 2008
Line 39:		Line 39:
	==Tslib==		==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.
			===Configuration===

			===Utilisation===

	==ALSA Soc==		==ALSA Soc==

JulienB: /* ALSA Soc */

2008-03-01T17:11:23Z

ALSA Soc

← Older revision		Revision as of 19: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==

JulienB: /* Un peu de soft */

2008-03-01T16:01:54Z

Un peu de soft

← Older revision		Revision as of 18: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==

JulienB: /* Un peu de soft */

2008-03-01T15:56:35Z

Un peu de soft

← Older revision		Revision as of 17:56, 1 March 2008
Line 30:		Line 30:
	* 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:

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

2008-03-01T15:55:49Z

Le contrôleur "magique"

JulienB: /* Le LCD */

2008-03-01T15:43:54Z

Le LCD

← Older revision		Revision as of 17:43, 1 March 2008
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 ~~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.		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).

	~~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==
			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é à ~~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"==
			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).

	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 ;

JulienB: /* Introduction */

2008-03-01T15:33:40Z

Introduction

← Older revision		Revision as of 17:33, 1 March 2008
Line 1:		Line 1:
	==Introduction==		==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==		==Le LCD==

JulienB at 15:31, 1 March 2008

2008-03-01T15:31:57Z

← Older revision		Revision as of 17:31, 1 March 2008
Line 1:		Line 1:
	Je vous avais quitté la dernière ~~fois~~ avec un prototype de console de jeu 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.		==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.

	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'~~un autre LCD~~ plus compact (nnn x yyy mm) qu'elle propose à ses membres et qui ressemble beaucoup à ce que l'on peut trouver sur ~~une~~ Nintendo DS: résolution de 320x240 pixels, dalle tactile intégrée, bonne luminosité et bon contraste.		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.
	Ce LCD se connecte ~~de la même manière~~ au processeur i.MXL que le LCD du précédent article à savoir ~~toujours~~ une connection directe des signaux de composante couleur et de contrôle (l'électronique interne de l'i.MXL et du LCD ~~fonctionne les deux en 3~~,3V). 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 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é.		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é.

ChristopheF: corrections mineures (orthographe, fautes de frappe)

2007-09-05T08:42:02Z

corrections mineures (orthographe, fautes de frappe)

← Older revision		Revision as of 17:55, 1 March 2008
Line 13:		Line 13:

	==Le contrôleur "magique"==		==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 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 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 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
Line 31:		Line 32:

	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 ~~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.		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.

← Older revision		Revision as of 10:42, 5 September 2007
Line 10:		Line 10:

	Le TSC2102 s'interface facilement à des microprocesseurs 32 bits récents grâce à:		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 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.

	Maintenant que la bête est ~~cablé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 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 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 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)
Line 25:		Line 25:

	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 ~~convertion~~ 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'~~envoie~~ 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 ou 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. 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 ~~envoies~~ à la couche supérieure qui fait interface avec le système d'entrée/sortie de Linux. Un ~~evénement~~ touchscreen est généré et devra être récupéré au niveau de l'~~espaces~~ utilisateur. Pour cela il existe une librairie Tslib ~~developpée~~ par Russell King himself qui permet de standardiser la ~~ménière~~ de gérer les ~~événement~~ 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.		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.