Développement linux sous ARM

**monnoliv** · 03/03/2011, 23h12

Hello,
Y a t-il quelqu'un qui développe en système embarqué ARM sous Linux? J'utilise une distribution Angstrom sur un processeur OMAP3530 et je vais bientôt avoir besoin d'utiliser l'affichage LCD. Le driver matériel est bien installé mais je ne sais pas encore comment accéder à l'affichage.
:-)

**Aquanum** · 04/03/2011, 16h33

Envoyé par monnoliv

Hello,
Y a t-il quelqu'un qui développe en système embarqué ARM sous Linux?
:-)

Oui

C'est quoi comme type d'écran LCD ?
T'es plutôt parti pour gérer un affichage complexe du type QT ou X11 ? Ou assez simple basé sur le driver de ton LCD ?

**monnoliv** · 04/03/2011, 23h17

Enfin quelqu'un!
Mon LCD est un type NEC 4.3' avec 6bit par couleur en 640x480.
La distribution Angstrom pré-installée a déjà une sorte d'interface graphique (X11 je crois mais pas encore sûr) dont j'aimerais me passer pour l'instant. J'aimerais attaquer directement le frame buffer (par /dev/fb ou par une librairie opengl) mais je n'ai pas encore assez fouillé pour y parvenir. J'ai U-Boot comme bootloader.
Si tu as un tuyau je suis preneur :-)

**Aquanum** · 05/03/2011, 00h37

J'ai une Angström sur une de mes cartes ARM avec un écran tactile qui ne fait qu'afficher le programme de test de QT). Je peux éventuellement regarder plus en détail comment c'est géré au niveau de l'appel à l'écran.

C'est une BeagleBoard ta carte ?

**monnoliv** · 05/03/2011, 10h13

Oui, si tu as le temps ça m'intéresserait.
J'ai aussi une BeagleBoard avec laquelle j'avais commencé à me faire la main, c'est une superbe carte de développement. J'ai pas mal chipoté avec le X-loader (OMAP3530)-UBoot-SDCard pour bien comprendre les étapes de boot.
Maintenant je travaille en développement sur un projet concret qui a besoin d'un LCD (en fait on m'impose le choix du LCD) et après une analyse des cartes existantes (susceptibles de faire de la production) j'ai choisi de développer sur GUMSTIX (ma carte est ici: http://www.gumstix.com/store/catalog...roducts_id=256).
Je travaille seul, j'avance pas à pas (je suis relativement nouveau sur Linux) et mon étape suivante c'est la gestion graphique via le driver fourni dans la distribution. Je ne connais pas encore comment fonctionne QT ou X11 mais pour ma comprenette personnelle et pour être plus efficace niveau gestion temps réel, j'aimerais attaquer directement l'affichage.
Voilà voilà :-)

**monnoliv** · 05/03/2011, 10h16

Et toi, qu'as-tu comme carte?

**Aquanum** · 05/03/2011, 21h36

J'ai une carte Eukréa CPUIMX25. Celle-ci est sous Angström en l'occurrence.
J'ai plusieurs modèles de Carte Fox (LX/G20) mais sous emdebian.
Et actuellement pour le boulot je travaille sur processeur arm920t

Faudrait que je me trouve une BeagleBoard

J'ai bien envie de tester héhé.
Depuis quelques mois il y a tellement de nouvelles cartes de dev !

Déjà je vais jeter un coup d'oeil à mes bouquins, je suis quoi qu'il en soit curieux de savoir comment fonctionnent les LCD.
Je n'ai jamais travaillé sur des systèmes embarqués avec écran (ça viendra)

Mais ça ne doit pas être bien compliqué.

**ArKam** · 06/03/2011, 19h32

Pour ce qui est du fonctionnement des LCD et de l'affichage sous Linux plus globalement, le FrameBuffer ne sert que pour l'affichage monochrome.

Si tu veux écrire du texte ou des choses en noir et blanc c'est bon.

Par contre, si tu veux afficher une application graphique il te faut passer par un environnement X-Window System ou autrement nommé X11 qui vas lui même gérer la façon dont les informations sont envoyés au kernel, qui vas lui même renvoyer celles-ci à l’unité graphique.

On parle d'affichage X11, mais l'on devrait plutôt parler de protocole X11, tous simplement parce que le X11 ça fonctionne sous forme de Serveur<->Client.

Par exemple, sous linux, la plupart du temps tu as un serveur X11 appelé X.ORG ou XFree86 pour les plus connus.

Ensuite tu as des Gestionnaires de bureau Gnome/KDE/Xfce/Enlightment etc qui sont eux des clients X11.

Ces clients sont écrits grâce à des frameworks tels que QT ou GTK+ qui eux même se basent sur la librairie XLib.

Un petit schéma ne fait pas de mal:
http://upload.wikimedia.org/wikipedi...raries.svg.png

Et une page wikipedia non plus:
http://fr.wikipedia.org/wiki/X_Window_System

J’espère que ça aura pu t'aider

PS: J'oublié un ou deux trucs, si tu veux développer des interfaces sans passer par tout ça, tu peut utiliser directement OpenVG et/ou OpenGL|ES qui sont des standards supportés par toutes les Cartes graphiques.

**monnoliv** · 07/03/2011, 15h19

Depuis quelques mois il y a tellement de nouvelles cartes de dev !

Les processeurs architecturés ARM sont en pleine expansion, on assiste à une petite révolution.
Pour les LCD, j'avais d'abord évalué comment les attaquer directement sans OS sur l'OMAP3530. Si on a les "drivers", ce n'est pas difficile. Maintenant que j'ai décidé d'utiliser Linux, je dois faire avec "toutes ces couches" que je ne connais pas encore. Sinon question matériel si le processeur gère nativement le LCD graphique (l'interface est standardisée), le fabriquant du uP fournit les infos nécessaires.

Merci pour ces explications,

Pour ce qui est du fonctionnement des LCD et de l'affichage sous Linux plus globalement, le FrameBuffer ne sert que pour l'affichage monochrome.

Ah bon? Comment fait la couche supérieure (xlib) pour accéder au matériel avec la couleur?

Sinon, pour mon application je n'ai pas besoin de fenêtre, juste une librairie qui me permet d'afficher directement du texte et du graphique. Je n'ai pas besoin d'interaction avec l'utilisateur style touch screen ou souris. Je sais que OpenGL est supporté par le uP (accélération hardware), est-ce que ce serait mieux d'utiliser OpenGL dans mon cas? Ou une autre librairie? Je n'ai pas trop envie de dessiner les caractères

Au fait, est-ce que Qt est gratuit? Est-ce que je peux développer avec et faire un produit propriétaire sans verser de royalties?

Pour revenir à OpenGL (ou même Qt), je n'ai aucune idée où commencer

Si quelqu'un a un tuyau

**ArKam** · 07/03/2011, 17h34

Envoyé par monnoliv

Ah bon? Comment fait la couche supérieure (xlib) pour accéder au matériel avec la couleur?

Alors, après recherche, apparemment, effectivement, le framebuffer peux prendre en compte des infos de couleurs et d'alpha.

Cependant, Xlib ne l'utilise pas directement, car apparemment la librairie utilise les drivers systèmes (le noyau quoi) pour parler à la CG.

Par contre, je me suis jamais servi de celui-ci directement.

Perso, j'envoie tout en OpenGL ou CUDA ou OpenCL.

Pour ce qui est de linux / QT

Oui tu peut t'en servir gratuitement pour un produit commercial, lie juste la licence, ils t'obligent peut-etre à dire que c'est fait en QT.

Pour l'OpenGL, le site de Khronos (les developpeurs de OpenGL) est un bon début, sinon, j'ai trouvé des sites sur OpenGL je te mettrais les liens des que je les retrouvent.

Pour ce qui est de framebuffer:

http://www.tldp.org/HOWTO/Framebuffer-HOWTO/x134.html

Sinon sous google:

http://www.google.fr/search?aq=f&sou...84ce993236eef5

Bref, sujet dés plus vastes et intéressant.

DONC dans ton cas, le plus facile pour afficher quelque chose sur le LCD c'est d'utiliser X11 (Xorg) et le developpement en XWindows.

http://pficheux.free.fr/articles/lmf/xlib/

Voili voilou, si tu as plus d'infos, n'hésite pas à nous tenir au jus.
Sur tes avancés non plus n'hésite pas.

**monnoliv** · 07/03/2011, 23h30

Ok et merci beaucoup pour tes liens

, je vous tiens au courant

**cs_ntd** · 10/03/2011, 22h50

Un lien que je n'ai pas vu, et qui pourrait être interessant :

http://processors.wiki.ti.com/index....SP_03.00.00.05

Je m'en sert pour une carte AM3517, mais il est précisé que celà est aussi valable pour les OMAP3x, donc je pense que ça pourrait t'aider...

Ca présente comment utilise le frame buffer, video4linux...

Sinon, si tu veux faire des choses plus évoluée et plus rapidement, Qt Embedded Linux est parfait...

Il existe une version gratuite de Qt, mais je crois que la license demande de publier les codes sources avec ton application... La version payante elle, te permet de faire ce que tu veux...

**monnoliv** · 11/03/2011, 08h52

Très intéressant ton lien. Ca semble être tout à fait ce qu'il me faut (TI cache ses bons documents ou je cherche mal).
Je préfère effectivement commencer par du bas niveau quitte après à remonter sur Qt,
Merci

**ArKam** · 11/03/2011, 10h23

Envoyé par cs_ntd

Un lien que je n'ai pas vu, et qui pourrait être interessant :

http://processors.wiki.ti.com/index....SP_03.00.00.05

Je m'en sert pour une carte AM3517, mais il est précisé que celà est aussi valable pour les OMAP3x, donc je pense que ça pourrait t'aider...

Ca présente comment utilise le frame buffer, video4linux...

Sinon, si tu veux faire des choses plus évoluée et plus rapidement, Qt Embedded Linux est parfait...

Il existe une version gratuite de Qt, mais je crois que la license demande de publier les codes sources avec ton application... La version payante elle, te permet de faire ce que tu veux...

-Pour ce qui est de ton doc, il est encore d'actualité sur les OMAP4x tels que ceux de la pandaboard.

-Pour la doc complète sur les processeurs OMAP4x je vous la met à disposition sur mon espace ftp free:

OMAP4430

Envoyé par monnoliv

Très intéressant ton lien. Ca semble être tout à fait ce qu'il me faut (TI cache ses bons documents ou je cherche mal).
Je préfère effectivement commencer par du bas niveau quitte après à remonter sur Qt,
Merci

Pour ton truc, j'ai regardé dans le document ci-dessus, et notamment la partie GPU PowerVR GSX540 qui permet de passer par les framebuffer pour toutes les opérations apparemment.