Forum Linux.embarqué Dalle tactile i2c, driver et linux sur mini6410: comment l'utiliser?

Posté par totolito le 17 octobre 2011 à 10:53.

Étiquettes :

-2

oct.

2011

Bonjour à tous,

Je développe actuellement une application sur la plateforme mini6410 de friendlyARM équipée d'un ARM11 de Samsung et d'un écran 7" tactile, le tout tourne sur emdebian avec le framework Qt + QML :ccool:

Je souhaite changer la dalle tactile résistive actuelle par une dalle tactile capacitive projetée. La dalle actuellement est possède un driver développé par friendlyARM et je peux l'utiliser avec la tslib.

La dalle que je souhaite utilisée possède un chip atmel mXT pilotable en i2c. J'ai trouvé le driver ad-hoc dans le noyau linux 2.6.39 dans /drivers/input/touchscreen/atme_mxt_ts.c.

J'ai backporté ce driver dans mon noyau tuné 2.6.36 sous forme de module que j'ai pu charger avec insmod dans la cible. Jusque là, tout va bien ;)

Avec i2cdetect, j'ai bien trouvé ma dalle sur le bus i2C. :mouarf:

Mais maintenant, je ne sais plus quoi faire!!! Je pensais devoir faire un mknod afin de le linker sur la tslib, mais pas de trace de major/minor dans le driver qui semble utiliser le périphérique i2c (logique) mais je n'ai aucune idée de la procédure à faire ensuite :?

Si une bonne âme peut me donner quelques info sur la manière de procéder :oops:

J'ajoute que la dalle a aussi un contrôleur USB qui m'a permis de la tester sur Ubuntu avec succès, détection et utilisation au poil :D

# si je ne me trompe pas

Posté par NeoX le 17 octobre 2011 à 12:01. Évalué à 2.

i2C, c'est un bus de communication

quand tu utilises ta dalle, tu dois y voir passer des trames, et tu dois pouvoir en generer pour envoyer des infos à la dalle.

il te faut donc la documentation de la dalle et de i2C pour voir comment communiquer avec ce materiel (pour simuler la souris par exemple)
# Le multi post c'est pas bien

Posté par bibitte le 17 octobre 2011 à 14:24. Évalué à 2.

un seul post suffit pour avoir un réponse.
En général le multi postage est mal vue et tu risque de froisser certaines personnes qui du coup ne vont pas te répondre.

Sinon pour ta question je suis désolé je n'ai pas les compétence pour te répondre.
- [^] # Re: Le multi post c'est pas bien
  
  Posté par BAud (site web personnel) le 17 octobre 2011 à 16:08. Évalué à 2.
  
  il s'agit de cross-posting :-) il y avait l'air d'y avoir les mêmes infos, dans ce cas, je ne garde que celui qui a des commentaires. NeoX< avait réécrit peu ou prou la même réponse sur l'autre.
  - [^] # Re: Le multi post c'est pas bien
    
    Posté par NeoX le 17 octobre 2011 à 20:38. Évalué à 2.
    
    j'avais d'abord posté dans celui là
    
    puis j'ai vu celui de linux.embarqué qui me semblait mieux placé
    donc j'avais moinsé les deux autres et pertinenté celui de linux embarqué
    - [^] # Re: Le multi post c'est pas bien
      
      Posté par BAud (site web personnel) le 17 octobre 2011 à 21:55. Évalué à 2.
      
      bin, j'ai replacé celui-ci dans linux.embarqué :) bonne remarque (mais peu de retours de l'auteur :/)
# Des nouvelles...

Posté par totolito le 17 octobre 2011 à 16:37. Évalué à 3. Dernière modification le 17 octobre 2011 à 21:56.
Flute j'ai perdu mon post!

Je disais donc que je suis désolé pour le multiposte, mais j'ai trop hésité entre les deux sections -.-

Sinon j'ai recompiilé le noyau pour y intégrer le driver atmel.

Voilà aussi le résultat d'une commande :
```
# ls /sys/bus/i2c/drivers/atmel_mxt_ts
bind  uevent  unbind
```
Je suppose que le driver est bien "chargé". Je cherche maintenant à comprendre à quoi sert bind, uevent et ubind..
Merci à vous
- [^] # Re: Des nouvelles...
  
  Posté par NeoX le 17 octobre 2011 à 20:41. Évalué à 2.
  je dirais logiquement :
  - bind : c'est pour se connecter à la dalle
  - unbind : pour se deconnecter
  - uevent : c'est la qu'il lire/ecrire pour recevoir/envoyer des evenements à ta dalle
  apres, soit ce sont des scripts (mais je ne penses pas)
  soit ce sont de simple fichier plat dans lesquels tu ecrit
# L'auteur prend peur \o/

Posté par totolito le 18 octobre 2011 à 09:31. Évalué à 2.

Salut par ici!

Tout d'abord, merci de votre participation, je n'ai que très peu de réponse ailleurs pour mon souci.

Il faut dire pour motiver les foules que je viens de loin: Jamais fait de linux embarqué, j'ai réussi grâce au net à mettre sur pied un environnement de cross-compilation, personnalisation, compilation et installation de u-boot, kernel, rootfs, lib Qt, puis développement d'une IHM avec ce nouveau framework, superbe interface graphique avec QML !! J'adore !

Le plus difficile arrive donc avec le changement de l'écran (pas assez lumineux) et de la dalle tactile (plus résistante face aux utilisateurs). C'est là où je m'attendais à avoir le plus de problème !!!

Bon, aujourd'hui je creuse cette histoire de bind, qui visiblement permet de lier un driver à un device...

Ensuite je vais trouver un bon cours sur le fonctionnement détaillé de /dev/input. J'ai encore des flous à ce sujet. En effet, mon ancien touchscreen était accessible en faisant un cat /dev/touchscreen, et je ne visualise pas très bien où-comment le /dev/input intervient...

Et pour finir, je déboulotterai le fichier /drivers/input/touchscreen/atmel_mxt_ts.c afin de mieux comprendre comment il fonctionne. J'y ai déjà jeté un coup d'oeil et les différences avec mon ancien driver de dalle (via une communication série propriétaire) sont nombreuses:
- L'ancien fonctionnait de manière un peu bâtard il me semble, car il y avait deux drivers, un pour gérer la liaison série et qui routait ça par un copy_to_user dans /dev/touchscreen-1wire, et un autre fichier qui utilisait les possibilités de /dev/input via des input_report_abs(). Par contre je n'ai pas trouvé le lien entre les deux :-(

Merci de votre attention ;-)
# Des niouz...

Posté par totolito le 18 octobre 2011 à 15:33. Évalué à 3.

Voici des infos complémentaires, qui m'ont permis de mettre en oeuvre le driver !

Après avoir compilé mon driver, j'ai vu qu'il était bien chargé, mais aucun device n'y était attaché.

J'ai fini par comprendre qu'il fallait indiqué quel device (et à quelle adresse) était connecté à notre plateforme. En fonction du nom de ce device, linux cherche un driver associé. Dans mon driver, j'ai une liste (d'alias) de nom de devices supportés. Les deux doivent matcher pour que le driver probe le device

J'ai recompilé une première fois et le driver m'a gratifié d'un "not enough params". Après recherche, j'ai trouvé que le driver avait besoins d'infos spécifiques à ma plateforme, en l'occurence, à quelle dalle le mXT224 était connecté (taille, nombre de lignes X/Y, orientation, etc). J'en ai profité pour lui coller une IRQ,

Recompile, lancement, et là, le driver trouve mon device et créer un /dev/input/qlq chose

Ça sent bon, je remets en ordre mon rootfs pour jouer avec et je reviens!
- [^] # Suite et fin
  
  Posté par totolito le 21 octobre 2011 à 15:50. Évalué à 2.
  
  Oyé!
  
  Suite et fin de mon aventure avec mon touchscreen:
  
  Donc, je me retrouve avec un /dev/input/event0. Que faire maintenant?
  
  Avant, avec le touchscreen d'origine, j'avais un /dev/touchscreen. En faisant un cat dessus, je voyais un paquet de data passer lorsque je touchais le TS. Je tente un cat /dev/input/event0, qui ne marche pas.
  
  En fouinant, je trouve un soft qui s'appelle evtest et qui permet justement de tester "brut" les événements de type input. Compilation, et lancement, bingo, le driver mXT envoi bien des événements!!!
  
  On continu en configurant la tslib sur /dev/input/event0: touchscreen non supporté! :-/
  
  Du coup je jette un oeil aux sources, et me rend compte que mon TS est multitouch, alors que la tslib ne le supporte pas :-S
  
  Heureusement, tslib fonctionne avec des "modules", ici, le fichier de conf de tslib est configuré ainsi: module_raw input
  Houra! Je trouve quelqu'un qui a codé un module compatible multitouch, recompile et test:
  Ca tourne !!!!!!
  
  Malheureusement, ça tourne pendant un certain temps pluis plus rien. Après analyse, la ligne IRQ (faling edge) reste en bas -> Une IT loupée par le driver :-/
  
  Pas le coeur à trouver où le driver des ITs foire, j'ajoute un schedule_delayed_work à la fin de l'ISR afin de lire le mXT 100ms plus tard, ainsi la ligne IRQ remonte toujours après 100ms. Ok, pas très propre mais 3 lignes en plus et un polling différé seulement après l'IT, j'ai vu pire ;-)
  
  Donc tout roule !!!!
  
  Merci de votre soutien.
  
  Pour info: totolito@gmail.com
  - [^] # Re: Suite et fin
    
    Posté par Mali (site web personnel) le 24 octobre 2011 à 09:40. Évalué à 1.
    
    Félicitations pour t'être sorti de ton problème, et merci de nous avoir tenu au courant du dénouement final.
# Cool

Posté par Mali (site web personnel) le 18 octobre 2011 à 16:50. Évalué à 2.

Au moins on sent que tu t'éclates sur ton projet çà fait plaisir,
- [^] # Re: Cool
  
  Posté par NeoX le 18 octobre 2011 à 20:23. Évalué à 3.
  
  yep, on voit qu'il avance bien sur son projet.
  
  Merci à lui de nous tenir au courant ;)
# Même galère

Posté par agaves2 le 24 novembre 2011 à 16:49. Évalué à 0.

Bonjour à tous,

Je suis confronté au même souci que toi, je développe une application sur une PHYCARD-L de PHYTEC OMAP 3530 et d'un écran 7" tactile en linux OSELAS 2.6.33.7. .

J'essaye de faire fonctionner le système avec une dalle tactile capacitive projetée. J'ai réalisé un premier essai avec une dalle avec un driver EGALAX en USB le problème est que le driver fourni à besoin du server X11 et que je n'utilise pas celui-ci.

Je me suis orienté vers OCULAR qui propose des dalles avec contrôleur atmel mxt224 soit en USB soit en I2C. Je dois recevoir une dalle capable de faire les deux aujourd'hui ou demain.

J'aimerais faire comme toi, mais je ne suis pas encore assez doué pour m'en sortir tout seul.

J'ai récupéré les fichiers atmel_mxt_ts.c et atmel_mxt_ts.h créé un Makefile pour cross compilé le driver sous forme de module .

Je lance le make en rajoutant les paramètres pour être certains qu'ils soient pris en compte.

[code]make SUBARCH=arm CROSS_COMPILE=/opt/OSELAS.Toolchain-1.99.3/arm-cortexa8-linux-gnueabi/gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/bin/arm-cortexa8-linux-gnueabi-[/code]

Cela génère bien le fichier .ko , par contre je suis bloqué pour la modification du driver pour lui indiquer le mXT224 ainsi que la taille, le nombre de ligne, l'orientation et l'IRQ (au passage est-il possible de ne pas utiliser d'IRQ?).

J'ai bien vu qu'il fallait définir une structure struct mxt_platform_data mais où la définir. J'ai comparé avec le driver d'un MCP2515 qui est déjà implémenté sur ma plateforme et c'est un fichier mcp251x_plat.c qui fait cela. Ensuite, je fais un modprobe mcp251x_plat expansion_slot=1. Dois-je poursuivre sur cette piste?

Pour anticiper les problèmes est-il possible de me dire où trouver le module multitouch de la TSLIB?

Merci
- [^] # Re: Même galère
  
  Posté par totolito le 22 décembre 2011 à 16:25. Évalué à 0.
  Désolé pour la réponse tardive mais je n'en ai pas été notifié...
  
  Pour le module multitouch, la dernière release de tslib intègre le support multitouch.
  
  Source ici:
  https://github.com/kergoth/tslib/downloads
  
  Pour définir ma plateforme, j'ai tapé dans ce fichier:
  /arch/arm/mach-s3c64xx/mach-mini6410.c
  
  A toi de trouver le tiens...
  
  Pour info dans mon mach-mini6410:
```
static struct mxt_platform_data mxt_platform_data __initdata = {
.config = NULL,
.config_length = 0,
.x_line = 18, 
.y_line  = 12,
.x_size  = 800,
.y_size  = 480,
.blen    = 0x1,
.threshold  = 0x28,
.voltage    = 3300000,
.orient  = MXT_DIAGONAL,
.irqflags = IRQF_TRIGGER_FALLING
};

static struct i2c_board_info i2c_devs0[] __initdata = {
[...]
{ I2C_BOARD_INFO("mXT224", 0x4b),
.platform_data = &mxt_platform_data,
.irq     = IRQ_EINT(16),
}
[...]
};
```
  Pour l'IRQ il est fortement déconseillé de s'en passer !! Sinon tu es obligé de poller en permanence le mxt224, pas bon pour pleins de raisons...
  Attention, j'ai patché le driver mxt224 afin de faire une petit lecture i2c d'un registre de temps en temps car parfois l'IRQ n'est pas relâché...
  
  bonne chance...

# Micro-tuto dalle tactile mxt224

Posté par totolito le 23 décembre 2011 à 13:05. Évalué à 1.

Connecter la dalle tactile
Tester la liaison i2c (et surtout retrouver l'adresse de la dalle - normalement 0x4b ou 0x4c - à faire dalle déconnectée puis connecté)
Cross compiler i2c-tools et lancer un i2cdetect sur le bus i2c

A partir des sources du noyau 3.0, récupérer et coller dans voss sources les fichiers suivants:
/drivers/input/touchscreen/atmel_mxt_ts.c
/include/linux/i2c/atmel_mxt_ts.h

Ajouter les lignes suivantes au fichier /drivers/input/touchscreen/atmel/KConfig

config TOUCHSCREEN_ATMEL_MXT
tristate "Atmel mXT I2C Touchscreen"
depends on I2C
help
  Say Y here if you have Atmel mXT series I2C touchscreen,
  such as AT42QT602240/ATMXT224, connected to your system.

  If unsure, say N.

  To compile this driver as a module, choose M here: the
  module will be called atmel_mxt_ts.

Ajouter les lignes suivantes au fichier /drivers/input/touchscreen/atmel/Makefile

obj-$(CONFIG_TOUCHSCREEN_ATMEL_MXT) += atmel_mxt_ts.o

Editer votre fichier décrivant votre plateforme (mach-xxx.c)

static struct mxt_platform_data mxt_platform_data __initdata = {
        .config         = NULL,
        .config_length  = 0,
    .x_line     = 18, 
    .y_line     = 12,
    .x_size     = 800,
    .y_size     = 480,
    .blen       = 0x1,
    .threshold  = 0x28,
    .voltage    = 3300000,
    .orient     = MXT_DIAGONAL,
    .irqflags   = IRQF_TRIGGER_FALLING
};

static struct i2c_board_info i2c_devs0[] __initdata = {
[...]
    { I2C_BOARD_INFO("mXT224", 0x4b),
      .platform_data    = &mxt_platform_data,
      .irq          = IRQ_EINT(16),
    },
[...] }

Note: On suppose q'un bus i2c est déjà présent et configuré...
Ici l'id de l'irq câblée est 16... A adapter.

Lancer la configuration du noyau

make menuconfig

Activer la compilation du driver en mode noyau:
Device Driver -> Input Device Support -> Touchscreen -> Atmel mXT I2C Touchscreen.

Désactiver les drivers de la dalle actuelle si nécessaire
Device Driver -> Input Device Support à Touchscreen -> Votre dalle

cross-compiler (ex avc un arm)

make CROSS_COMPILE=/chemin vers compilo/preefix_compil-

Reflasher le noyau puis démarrer

Un dmesg | grep mxt doit vous lister ce type de lignes (ici addr i2c = 0x4b)

atmel_mxt_ts 0-004b: Family ID: 128 Variant ID: 1 Version: 22 Build: 171
atmel_mxt_ts 0-004b: Matrix X Size: 18 Matrix Y Size: 12 Object Num: 17

Ce qui signifie que le driver a bien détecté le mXT!

Tester le /dev/input/event0 à l’aide du programme evtest:

evtest

ou sur un event précis:
evtest /dev/input/event0

Récuperer et extraire la tslib

Pré-Configurer

cd tslib
./autogen.sh

Configurer (ex avec un arm11)

./configure                       \
--host=arm-linux --target=arm  --prefix=/chemin_tslib/output \
CFLAGS="-march=armv6 -mtune=arm1176jzf-s -mfloat-abi=softfp" \
CXXFLAGS="-march=armv6 -mtune=arm1176jzf-s -mfloat-abi=softfp" \
--enable-static --enable-shared

cross-Compiler et récupérer les libs dans --prefix

make
make install

Tester le fonctionnement avec un ts_calibrate puis ts_test

Note: Après installation sur la cible, éditer ts.conf afin d’utiliser le module input:
module_raw input. Faire un fichier de conf de la tslib. ex:

export TSLIB_TSEVENTTYPE=INPUT
export TSLIB_CONSOLEDEVICE=none
export TSLIB_FBDEVICE=/dev/fb0
export TSLIB_TSDEVICE=/dev/input/event0
export TSLIB_CALIBFILE=/etc/pointercal
export TSLIB_CONFFILE=/etc/ts.conf
export TSLIB_PLUGINDIR=/lib/ts

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.