Projet de fin d`études - Bienvenue sur Catalogue des mémoires de

Projet de fin d’études
Technology & Strategy Engineering
Sujet : Plateforme Linux & Combi Instrument.
1 Février 2010 - 3 Juillet 2010
Société :
Technology & Strategy Engineering
4 avenue de la Paix
67000 Strasbourg
Établissement :
INSA Strasbourg
24 Boulevard de la Victoire
67000 Strasbourg
Professeur référent : M. Boyer Bertrand
Responsable :
M. Roth Matthieu
Étudiant :
M. Heinrich Yannick
1. CAHIERS DES CHARGES
1
–
–
–
–
–
–
–
–
Cahiers des charges
Recherche et étude des différentes plate-formes Linux existantes sur le marché.
Connexion d’un écran tactile à la plate-forme Linux choisie.
Ajout d’une connexion CAN à la plate-forme.
Réalisation éventuelle d’une carte regroupant l’ensemble des composants.
Développement du software nécessaire en langage C.
Connexion de la plate-forme au système lève-vitres rétroviseurs de T&S.
Archivage des différentes versions de SW dans un logiciel de gestion de configuration de type SVN.
Possibilité d’ajout d’un chip GPS ou d’autres fonctionnalités si le temps restant le permet.
1
Résumé
Le stage s’est déroulé au sein du laboratoire de recherche et développement de la société Technology & Strategy Engineering. Le sujet portait sur la réalisation d’une plate-forme d’instrumentation à l’aide d’une carte embarquée GNU/Linux et
un écran AMOLED tactile. Le développement incluait la réalisation du pilote pour le noyau Linux et le développement
d’un PCB pouvant accueillir l’écran et son alimentation. La carte principale provient de la société ARMADEUS Systems
et est articulée autour d’un processeur Freescale iMX27 avec une architecture ARM9. L’intégration d’un noyau Linux de
génération 2.6 et d’un shell BusyBox s’est réalisé avec la suite Buildroot et les sources fournies. La conception du PCB a
été réalisé sous le logiciel KICAD. Le développement des applicatifs s’est basé sur la librairie SDL et a été programmer en C.
My training session took place in the research & development laboratory of the Technology & Strategy Engineering society.
The subject dealed with the conception of an instrumentation platform with an GNU/Linux embedded board and an AMOLED touchscreen. The development covered the software part by the conception of a Linux driver and the hardware part by
the design of an PCB hosting the screen and its power supply. The main board was bought to the ARMADEUS Systems
society and is based on a iMX27 Freescale processor with an ARM9 architecture. The integration of a 2.6 Linux kernel and
a Busybox shell was made with the Buildroot toolchain and the source codes provided by the supplyer. The PCB design was
made with KICAD. The applications was developed using the SDL library in the C language.
1. CAHIERS DES CHARGES
Table des matières
1
Cahiers des charges
1
2
Introduction
3
3
Remerciements
4
4
Présentation de l’entreprise
4.1 Historique . . . . . . . . . . . . . . . . . . . .
4.2 Le groupe Technology & Strategy . . . . . . .
4.3 Quelques chiffres . . . . . . . . . . . . . . . .
4.3.1 Particularité de la division Engineering
5
6
7
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
5
6
6
Présentation du sujet
5.1 Le laboratoire de R & D . . . . . . . . . . . . . . . .
5.2 Projet Combi instrument & plateforme linux . . . . . .
5.2.1 Cahiers des charges . . . . . . . . . . . . . . .
5.3 Cycle de développement et organisation dans le temps
5.4 Outils mis à disposition . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
7
7
8
8
Du processeur au noyau
6.1 Rôle d’un système d’exploitation . . . . . . .
6.2 Adressage mémoire . . . . . . . . . . . . . .
6.2.1 Représentation . . . . . . . . . . . .
6.2.2 Mode réel . . . . . . . . . . . . . . .
6.2.3 Mode protégé et segmentation . . . .
6.2.4 Pagination . . . . . . . . . . . . . .
6.2.5 Le mode noyau et le mode utilisateur
6.3 Lancement d’un système . . . . . . . . . . .
6.4 Présentation de GNU . . . . . . . . . . . . .
6.5 Présentation de Linux . . . . . . . . . . . . .
6.5.1 Développement . . . . . . . . . . . .
6.6 Un couple gagnant . . . . . . . . . . . . . .
6.7 Linux et la mémoire . . . . . . . . . . . . . .
6.8 Naviguer dans les sources du Noyau . . . . .
6.9 Les pilotes sous Linux 2.6 . . . . . . . . . .
6.10 Le framebuffer . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
13
13
13
13
15
16
16
17
18
18
19
19
20
22
22
Réalisation
7.1 Choix de la plateforme GNU/Linux . . . .
7.1.1 Carte retenue . . . . . . . . . . . .
7.2 Présentation de l’architecture ARM (32 bits)
7.3 Composants logiciels . . . . . . . . . . . .
7.3.1 Sur l’ordinateur . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
23
23
26
26
26
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
7.4
7.5
7.6
8
7.3.2 Buildroot . . . . . . . .
7.3.3 Sur la carte . . . . . . .
Interfaces avec la carte . . . . .
Écran AMOLED Tactile . . . .
7.5.1 Interface RGB Parallèle
7.5.2 Interface SPI "3-wire" .
7.5.3 Écriture du pilote . . . .
7.5.4 Alimentation . . . . . .
Conception de la carte . . . . .
7.6.1 Contraintes de routage .
7.6.2 Schéma . . . . . . . . .
7.6.3 Routage . . . . . . . . .
7.6.4 Soudure . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1. CAHIERS DES CHARGES
. . . . . . . . . . . . . . 27
. . . . . . . . . . . . . . 27
. . . . . . . . . . . . . . 28
. . . . . . . . . . . . . . 28
. . . . . . . . . . . . . . 30
. . . . . . . . . . . . . . 31
. . . . . . . . . . . . . . 31
. . . . . . . . . . . . . . 39
. . . . . . . . . . . . . . 40
. . . . . . . . . . . . . . 40
. . . . . . . . . . . . . . 41
. . . . . . . . . . . . . . 41
. . . . . . . . . . . . . . 41
Conclusion
45
A The GNU General Public Licence
A.1 Preamble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2 Terms and conditions for copying, distribution and modification . . . . . . . . . . . . . . . . . . . . . . .
A.3 Appendix : How to Apply These Terms to Your New Programs . . . . . . . . . . . . . . . . . . . . . . . .
51
51
51
54
B Code sources
B.1 Module Noyau . . . . . . . . . . . . . . .
B.2 Code d’essai SDL - Fractale de MandelBrot
B.3 Ajout de la librairie CWIID dans buildroot .
B.3.1 libcwiid.mk . . . . . . . . . . . . .
B.3.2 configure_.patch . . . . . . . . . .
B.3.3 makefile_in.patch . . . . . . . . . .
56
56
58
60
60
61
61
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
2. INTRODUCTION
2
Introduction
Le monde de l’électronique ne cesse d’envahir notre quotidien : récepteurs GPS dans nos voitures, baladeurs audio et
vidéo de dernières générations, appareils photos numériques, robots Wi-fi[1][2]... un trait d’union relie tout ce petit monde :
l’univers des systèmes embarqués.
Depuis l’AGC[3] du programme Apollo à l’hélicoptère télécommandé de la société Parot [4], 40 ans se sont écoulés et ont
permis une véritable démocratisation des systèmes intelligents.
Ce déploiement fut possible grâce à l’intégration constante des puces électroniques et l’évolution en parallèle des concepts
et des langages informatiques. On peut s’abstenir de coder en assembleur pour gérer la pagination et passer à des langages
haut - niveau comme le Pascal, Ada voire même C++ pour réaliser ses propres noyaux et systèmes d’exploitation.
L’arrivée d’outils libres de droits comme GNU, BSD ou Linux ont offert à tous la possibilité de développer des systèmes
autonomes à moindres frais sans s’écarter des standards de l’industrie.
De nombreuses entreprises de différents secteur basent leur travail sur ces outils : des lecteurs DVD, des baladeurs, des
robots domestiques, des motos, des voitures, des routeurs ... tous ces produits sont susceptibles de contenir un noyau embarqué du type Linux ou un mini système GNU.
De nos jours, il n’est plus nécessaire d’être un génie de l’électronique et de l’informatique pour utiliser une caméra sur
son ordinateur, il suffit de disposer du pilote adéquat. Mais comment ce pilote est il réalisé et comment est il intégrer au
coeur du système d’exploitation de nos machines ?
Ces deux questions nous amène au sujet de mon projet de fin d’étude : Comment relier le monde de l’électronique et de
l’informatique au coeur d’un système d’exploitation existant ?
J’ai été amener à couvrir de nombreuses thématiques pour la réalisation de ce projet. Du côté de l’informatique embarquée, la recherche partait de la préemption au protocole VGA en passant par les nombreux outils de compilation et gestions
de dépendances utilisés dans le monde libre. Pour la partie électronique, j’ai été confronté aux problèmes de routage, d’alimentation, de connexion de bus dont les solutions nécessitaient de nombreuses investigations.
C’est avec un très grand intérêt que j’ai mené ce projet et c’est avec plaisir que je vous présente le résultat de mon travail.
3
3. REMERCIEMENTS
3
Remerciements
Je voudrais tout d’abord remercier l’équipe enseignante de l’INSA Strasbourg de m’avoir transmis le bagage nécessaire
à la réalisation d’un projet comme celui-ci et pour l’encadrement de tous les sujets proposés durant cette dernière année.
Je remercie M. Mathieu Roth, responsable du laboratoire R & D, pour son aide, son encadrement et pour l’expérience qu’il
a volontièrement partagée.
Je remercie ensuite M. Jérémie Huss, responsable du département Engineering et M. Frédéric Bonnet, responsable du département Holding, de la confiance et de la liberté de travail qu’ils m’ont accordées pendant tout la durée de mon PFE.
Je souhaite remercier M. Pascal Tourenne,M. Pascal Prim et M. Patrice Paulus pour le temps qu’ils m’ont accordé et leur
intérêt à mon sujet.
Je voudrais également saluer M. Thomas Caucigh, Mlle Élodie Poulain, M. Alexandre Carrier, M. Vercruysse Pierre-Alain,
M. Johan Clauss et M. Loïc Bailleau, stagiaires au laboratoire R & D pour leur aide volontaire et leur amitié qu’ils ont
exprimée pendant ces six mois.
Je suis également reconnaissant du travail réalisé à notre égard par Mme Sylvia Pradillon lors des cours d’Allemand du
mardi et du jeudi matin.
Je remercie également tous les employés de TS Engineering, TS Holding, TS Informations Technologies pour leur accueil
chaleureux et leur sympathie lors de mon passage au sein du groupe TS.
4
4. PRÉSENTATION DE L’ENTREPRISE
4
4.1
Présentation de l’entreprise
Historique
Une première société,Beratta, avait été fondée par les dirigeants de chacune des entités avant d’être rachetée par un des
leaders du conseil : le groupe Altran.
Préférant une indépendance financière et décisionnelle, ils créent la société Technology & Strategy en 2008 avec une équipe
issue à la fois d’Altran et de Beratta. La société retrouve une structure plus "familiale" et sa division en trois parties répartie
au mieux les compétences.
La maison mère de la société se situe sur l’avenue de la paix à Strasbourg et depuis peu une filiale s’est crée dans la région
parisienne.
4.2
Le groupe Technology & Strategy
Le nom "Technology & Strategy" regroupe implicitement trois entités distinctes (cf Fig. 1) :
– Technology & Strategy Engineering centrée sur les métiers de l’ingénierie des systèmes embarqués majoritairement
dans le monde des transports (automobile, ferroviaire, aéronautique) et aussi le domaine de l’énergie.
– Technology & Strategy Information Technologies focalisée sur les technologies de l’information dans les solutions
collaboratives sur le Web (organisation de projets, aide à la décision, plate-forme de gestions de contenus).
– Technology & Strategy Holding qui assure les fonctions de gestions pour les deux autres sociétés (ressources humaines, administration centralisée, aspects financiers et gestion du personnel).
F IGURE 1 – Le groupe Technology & Strategy
5
4.3. QUELQUES CHIFFRES
4. PRÉSENTATION DE L’ENTREPRISE
La famille TS compte depuis peu une nouvelle division nommée RheinBrücke Consulting concentrée sur le conseil en
milieu franco-allemand. Elle recherche des compétences bilingues par approche directe.
F IGURE 2 – Logos de la société RheinBrucke Consulting.
4.3
Quelques chiffres
Le groupe Technology & Strategy représente aujourd’hui [5] :
– plus d’une centaine de collaborateurs avec l’objectif de doubler l’effectif fin 2011.
– un groupe solide avec 3 entités bien distinctes.
– une croissance régulière du nombre de clients depuis 2008.
– un chiffre d’affaire cumulé de 6,5 M d’euros en 2009.
4.3.1
Particularité de la division Engineering
Cette division est une société sur le Rhin : elle réalise 80% de son activité outre Rhin et travaille pour des grands noms
de l’industrie automobile comme l’équipementier Bosch ou divers constructeur comme BMW. L’entité engineering est également la plus grande en termes de création de valeurs et du nombre de collaborateurs.
F IGURE 3 – La zone d’activité vue par la société
Elle possède également un laboratoire de recherche et développement qui permet à l’entreprise d’acquérir des compétences
sur des projets d’actualités, offrir une vitrine des savoirs faires à l’entreprise et former ses futurs collaborateurs.
6
5. PRÉSENTATION DU SUJET
5
5.1
Présentation du sujet
Le laboratoire de R & D
Le laboratoire de la société comptait 5 projets technologiques et un projet de d’étude de marché durant le même laps
de temps. Ils s’organisait autour d’un thème commun : l’automobile.Ils devaient se rencontrer lors des phases terminales (cf
Fig. 4).
F IGURE 4 – Les projets du laboratoire en 2010
5.2
Projet Combi instrument & plateforme linux
L’intitulé officiel du sujet est le suivant :
Afin de continuer son développement dans le secteur des Systèmes Embarqués Automobiles, le laboratoire Engineering
de T&S souhaite développer un tableau de bord tactile sur une plate-forme Linux embarqué.
Outre la possibilité d’afficher la vitesse sous différentes formes, le combi tactile devra également permettre d’enregistrer
et de représenter différentes mesures comme l’accélération, la distance de freinage ou le temps au tour dans le cas de mesures sur circuit.
De plus, des fonctions de diagnostique embarquées doivent également être possible.
5.2.1
Cahiers des charges
Le cahier des charges se décompose comme suit :
– Recherche et étude des différentes plate-formes Linux existantes sur le marché.
– Connexion d’un écran tactile à la plate-forme Linux choisie.
7
5.3. CYCLE DE DÉVELOPPEMENT ET ORGANISATION DANS LE TEMPS
5. PRÉSENTATION DU SUJET
– Ajout d’une connexion CAN à la plate-forme.
– Réalisation éventuelle d’une carte regroupant l’ensemble des composants.
– Développement du software nécessaire en langage C.
– Connexion de la plate-forme au système lève-vitres rétroviseurs de T&S.
– Archivage des différentes versions de SW dans un logiciel de gestion de configuration de type SVN.
– Possibilité d’ajout d’un chip GPS ou d’autres fonctionnalités si le temps restant le permet.
5.3
Cycle de développement et organisation dans le temps
Le processus de développement devait suivre le processus du cycle en V :
F IGURE 5 – Le cycle en V
Ce cycle hiérarchisé minimise la perte de temps et les erreurs de conceptions en fin de projet. Dans notre cas, le cahier des
charges répondait largement à l’analyse des besoins et la partie spécifications correspondait à une recherche documentaire.
La majeur partie du travail s’est située sur les phases de spécifications et de conceptions.
J’étais responsable de la planification des tâches sur l’ensemble du stage et de l’organisation de mon temps sur la semaine.
De même, le choix des outils de travail et les orientations techniques relevaient de ma propre responsabilité. J’ai pu ainsi
m’immerger plus rapidement sur le fond de ma problématique sans me heurter d’emblée à un environnement inconnu.
Le projet nécessitait plusieurs travaux distincts en informatique, électronique et en recherche documentaire. Le travail a
été réparti sur les 6 mois de stage à l’aide d’un diagramme de Gantt. (cf. pages suivantes)
5.4
Outils mis à disposition
Mon principal environnement de travail comportait les éléments suivants :
–
–
–
–
–
Station de travail sous environnement GNU/Linux > 2.6.
Un dépôt subversion sur un serveur de l’entreprise accessible en dehors du réseau interne.
Une station de soudure, 3 alimentations stabilisées, un oscilloscope et un multimètre.
Possibilité de commande de composants auprès des entreprises Farnell, Dahms et Radio Spare.
Accès à internet et à IRC.
8
%
12324'1
&'
(6
!!"
!
"#
$%&
'(
'
#
)*
)$+,(
(
#$
)-
%.#
!($
/
0
12324'5
7
76
8
&(
%
)) &
)
)- (*.'/01
#)'2!
3
245
!453
5
2
363
(63
7652
3527
2
2
361
(63
7652
3527
2
2
365
(63
7652
3527
2
2
369
(63
7652
3527
2
2
#)'2!
'
67
"63
"83
5
2
3
1
&'
) * +,
163
(63
5
157
:;7
2
2
161
9
<
57
:<7
2
2
165
=
<
157
:>7
2
2
169
=
31
17
:<7
2
2
16:
35
13
;7
:;7
2
2
16>
11
1>
57
:<7
2
2
16;
1;
1;
37
:<7
2
2
#)'2!
'
45
" 3
" 3
5
2
#)'2!
'
45
" 3
" 3
5
2
#)'2!
'
45
" 3
" 3
5
2
5
563
56363
!!"
5636363
!
(63
9
197
32>7
2
2
5636361
"#
1<
52
57
>:7
2
2
56361
$%&
(63
(65
57
31;7
2
2
56365
'(
(63
(61
17
31<7
2
2
56369
'
(63
(69
97
31>7
2
2
'
68
!!
!53
83
5
2
9
#
963
)*
1<
1<
37
:;7
2
2
961
)$+,(
1=
52
17
:>7
2
2
965
(
5
33
;7
:<7
2
2
#)'2!
#)'2!!
93
!6!3
5
2
:
#$
:63
)-
(63
(63
37
3137
2
2
:61
%.#
(61
(61
37
3137
2
2
:65
!($
(65
(633
;7
3137
2
2
31;7
2
2
2
2
>
/
(63
(65
57
;
0
(63
7652
3527
6. DU PROCESSEUR AU NOYAU
6
Du processeur au noyau
Cette partie se veut être une transition avant d’entrer techniquement dans le sujet. Elle résume les notions nécessaires à
la compréhension de la problématique et à la justification des différents choix techniques. L’évolution des architectures de
ces puces a façonné les méthodes de conception des systèmes d’exploitations et des noyaux informatiques concernant les
fonctions vitales (gestion de la mémoire, commutation de contexte pour des systèmes multi-tâches,...). Les différences aux
niveaux supérieurs ne relèvent que de choix stratégiques moins dépendants de l’électronique et du processeur (organisation
des pilotes de périphériques, systèmes de fichiers, ...).
6.1
Rôle d’un système d’exploitation
Que ce soit au travail, dans notre voiture ou sur notre téléphone portable, nous sommes tous les jours confrontés à des
systèmes d’exploitations. Ils réalisent le lien entre l’utilisateur et la partie électronique du système.
F IGURE 6 – Rôle d’un système d’exploitation - Source : wikipédia
Son rôle est en règle générale de garantir un environnement multi-tâches, préemptible (il existe des exceptions dans le
monde de l’embarqué) et stable pour l’utilisateur. On peut le décomposer en différents éléments :
– Le noyau : C’est la partie centrale du système qui fait le lien avec les composants électroniques. Il est composé de
plusieurs sous parties :
– L’ordonnanceur (cf Fig. 7) : Ce composant gère la préemption et la partie multi-tâches. À l’aide d’un algorithme
d’ordonnancement (Round Robin, Dead Monotics Analysis,etc..) il attribut un temps d’exécution à chaque processus au détriment de tous les autres. Sa vitesse d’exécution donne l’illusion que tous les processus fonctionnent en
même temps.
– La gestion de la mémoire vive/virtuelle (cf Fig. 8) : La mémoire est le second élément le plus important après le
processeur. Chaque programme y est chargé puis exécuté à des adresses bien précises. Cette partie veille à ce que
aucun processus n’empiète sur une zone non permise ou déjà utilisée. Elle se charge également de sauvegarder des
données non utilisées en zone d’échange si le système manque de mémoire vive.
Ce composant est lié à un composant matériel le gestionnaire de mémoire virtuelle (MMU en anglais) et n’est pas
toujours présent dans certains systèmes embarqués.
– Gestion des pilotes : il offre une architecture et une API pour organiser les pilotes de périphériques.
– Le système de fichier : il sert à organiser les fichiers et dossiers sur les disques de masses.
– Gestion du réseau : permet de gérer les protocoles réseau et de communications.
– Le shell (interface utilisateur) : Il correspond à la frontière sur laquelle l’utilisateur peut communiquer ses instructions
au noyau. Dans les systèmes actuels, on n’accèdent plus directement au shell, une interface graphique se charge de
11
6.1. RÔLE D’UN SYSTÈME D’EXPLOITATION
6. DU PROCESSEUR AU NOYAU
F IGURE 7 – L’ordonnanceur d’un noyau - Source : wikipédia
F IGURE 8 – La gestion de la mémoire au sein d’un noyau Source : wikipédia
faire la liaison.
La conception d’un programme de gestion des ressources est intimement liée à l’architecture et outils proposés par les
processeurs. Les puces des premiers ordinateurs ne proposaient pas de systèmes de protection de la mémoire ou des niveaux
de privilèges. C’est l’évolution du matériel qui a permit l’apparition de programmes plus stables et qui a tracé la voie au
développement de systèmes d’exploitation. L’évolution la plus importante concerne la gestion de la mémoire vive.
12
6.2. ADRESSAGE MÉMOIRE
6.2
6.2.1
6. DU PROCESSEUR AU NOYAU
Adressage mémoire
Représentation
La mémoire peut être souvent représentée avec par un empilement d’octets formant une zone rectangulaire. Chacun de
ses octets est adressé depuis une origine correspondant à l’une des extrémités (cf Fig. 9).
F IGURE 9 – Représentation de la mémoire
6.2.2
Mode réel
Avec les premiers processeurs, on pouvait adresser au maximum 64 Ko de mémoire. On se servait d’adresses de 16 bits
pour organiser les programmes dans la mémoire : chaque adresse logique (une adresse manipulée par le programmeur et par
les registres du processeurs) correspondait à une adresse physique (adresse réelle d’une cellule mémoire dans la RAM). Il
fallait allouer la bonne zone à chaque variable utilisée en se souciant de ne pas grignoter une partie déjà occupée.
Il faut attendre l’apparition des premières puces dédiées à la gestion de la mémoire (MMU) pour améliorer la stabilité et la
puissance des systèmes.
6.2.3
Mode protégé et segmentation
La segmentation est le premier système de protection mémoire activable dès que le processeur passe en mode protégé.
On divise la RAM en différentes cloisons nommées segments auxquelles on attribut un type (code, segment, pile en lecture/écriture/exécution) et un niveau de privilèges. Si on se penche sur la famille x86, on retrouve dès le 386 des registres
dédiés à la navigation dans les segments de code, de pile et de données.
On se sert d’un registre de 16 bits appelé sélecteur que l’on multiplie par 16 pour pointer un segment et d’un autre registre
appelé offset pour se déplacer l’intérieur de celui-ci. Ce mécanisme permet une traduction d’adresse logique en adresse
physique.
Les informations de chacun des segments sont stockées dans un descripteur et chaque descripteur est stocké en mémoire
dans la table des descripteurs.
Les niveaux de privilèges permettent d’instaurer une hiérarchie empêchant un segment de faible privilège d’accéder à
des segments de plus haut privilège.
13
6.2. ADRESSAGE MÉMOIRE
6. DU PROCESSEUR AU NOYAU
F IGURE 10 – Adressage en mode protégé
F IGURE 11 – Représentation de la mémoire
14
6.2. ADRESSAGE MÉMOIRE
6.2.4
6. DU PROCESSEUR AU NOYAU
Pagination
Elle permet l’utilisation d’une mémoire virtuelle qui offre les avantages suivants :
– Utilisation d’une zone de swap sur le disque dur lorsque la limite de la Mémoire est atteinte.
– Associer à chaque processus son propre espace d’adressage.
– Facilite l’allocation ou la désallocation.
Ce mécanisme de protection s’ajoute juste après celui de la segmentation : l’adresse obtenue en sortie de l’unité de segmentation n’est plus une adresse physique mais un adresse linéaire (virtuelle). On navigue alors dans deux espaces mémoires
séparés par la MMU, un virtuel et un réel. Chacun de ces espaces est découpé en zones (soit de 4ko ou de 4Mo) appelées
page pour l’espace virtuel et cadre pour l’espace physique. La MMU fait correspondre les pages et les cadres entre eux.
F IGURE 12 – Représentation de la mémoire paginée
Le mécanisme de traduction se base sur des tables de pages, stockées dans un répertoire de page, un peu comme l’on
stocke des numéros de téléphone dans un répertoire téléphonique. Chaque répertoire peut adresser au maximum 4 Go de
RAM. Ces structures sont stockées en mémoire physique. De même, on peut attribuer des privilèges pour gérer la sécurité.
F IGURE 13 – Mécanisme simplifié de la pagination
Il arrive que la translation d’adresse échoue et la MMU lève alors une interruption pour signaler un défaut de page. Cela
peut se manifester également par une adresse physique sur le zone d’échange du disque dur et il faut demander au processeur
de recopier cette page dans la RAM si il reste de la place. Dans le cas échéant, une page victime sera choisie pour être à son
15
6.3. LANCEMENT D’UN SYSTÈME
tour stockée dans le swap.
6.2.5
6. DU PROCESSEUR AU NOYAU
Le mode noyau et le mode utilisateur
Chaque tâche exécutée par le processeur possède également des niveaux de privilèges qui sont analysés pour savoir à
quelles zones mémoires elle peut accéder. C’est à l’OS de définir les structures nécessaires à la segmentation et à la pagination pour séparer la RAM en deux zones distinctes : l’espace noyau et l’espace utilisateurs.
Dans l’espace noyau, nous allons trouver les codes permettant d’écrire sur un disque, de communiquer avec un périphérique,
de tuer une tâche, d’afficher un pixel à l’écran,etc ... Ces tâches doivent avoir accès à toute la mémoire pour gérer l’ensemble
du système. À l’inverse, nous ne souhaitons pas que les tâches provenant de l’espace utilisateur puissent corrompre une
zone mémoire utilisée pour écrire sur un disque ou pour gérer un niveau de tension d’un périphérique. Cependant, on peut
communiquer d’un espace à l’autre via les appels systèmes, un mécanisme qui permet, via une interruption de passer d’un
code utilisateur à un code noyau.
F IGURE 14 – Vision schématique d’un noyau monolithique modulaire - Source : wikipédia
6.3
Lancement d’un système
Le noyau et le shell ne sont pas les deux seuls composants logiciels nécessaires l’utilisation d’un système. On peut
prendre l’exemple d’un ordinateur pour comprendre. Le noyau de votre système d’exploitation est le plus souvent un fichier
stocké sur votre disque dur. Mais c’est également le noyau qui permet à votre système de lire et d’exécuter un fichier sur
un disque dur. On se retrouve devant le problème de l’oeuf et de la poule. Il nous faut donc un composant intermédiaire qui
charge le noyau en mémoire, l’exécute et qui lui passe la main.
Sur nos ordinateurs personnels, le démarrage du système suit l’ordre suivant :
1. On alimente l’ordinateur
2. Un programme POST s’exécute (Power On Self Test) et vérifie qu’il n’y a pas de problème d’alimentation électrique.
3. Le BIOS met en place un système minimal d’entrées sorties vers les différents périphériques et cherche un secteur de
démarrage valide, le charge en mémoire et l’exécute.
4. Le segment de démarrage contient un bootloader qui charge et exécute le noyau en mémoire.
À une certaine époque, il était nécessaire d’insérer une disquette pour démarrer un système. Sur le premier secteur de
disque du support se trouvait ce fameux bout de code qui chargeait le système en mémoire à l’aide de routines fournis par le
BIOS.
16
6.4. PRÉSENTATION DE GNU
6. DU PROCESSEUR AU NOYAU
Sur des plate-formes embarquées, on retrouve le plus souvent le bootloader ou encore appelé bootstrap. Le terme désigne
littéralement un chausse-pied ou l’anneau situé en haut des bottes permettant de les chausser plus facilement.
L’écriture d’un chargeur de démarrage est relative au processeur (la première adresse exécutée au démarrage varie selon les
puces). Sur les PC x86, on peut citer les plus usités dans le monde de GNU comme Lilo, Grub ou SysLinux.
(a) Grub
(b) Lilo
(c) SysLinux
F IGURE 15 – Différents chargeurs de démarrage sous GNU/BSD
6.4
Présentation de GNU
En 1984, en chercheur en intelligence du laboratoire du MIT, Richard Matthew Stallman (RMS), se lance dans la réalisation d’un système d’exploitation libre de droits. Son initiative cherche à faire renaître la philosophie des premiers instants de
l’informatique où le logiciel n’était que la cerise sur le gâteau offert par les industriels après l’acquisition de leurs machines
onéreuses. GNU est un anagramme récursif signifiant "Gnu’s Not Unix" pour rappeler qu’il est un système très proche de
Unix et en même temps un système indépendant de toute pression industrielle de la part de AT&T, société créatrice de UNIX.
F IGURE 16 – Logo de GNU - Source : wikipédia
17
6.5. PRÉSENTATION DE LINUX
6. DU PROCESSEUR AU NOYAU
RMS est aussi à l’origine de la licence public générale (GPL) qui interdit toute fermeture de code source d’un logiciel
ou d’un dérivé publié sous GPL. Cette notion est également appelée "gauche d’auteur" ou "copyleft" en référence au "droit
d’auteur" ou copyright.
En 1990, le devient suffisamment abouti mais il manque une pièce essentielle au puzzle : le noyau. C’est à ce moment
qu’intervient un jeune étudiant finlandais.
6.5
Présentation de Linux
En 1991, Linus Torvalds, élève en informatique à l’université de Helsinki, travaillait à gérer la commutation des tâches
en mode protégé sur son PC compatible 80386. Il se met en tête de créer un véritable système d’exploitation et un noyau
plus performants que ceux qu’il étudie en classe (Minix). Le 5 octobre 1991, il publie sur le serveur Usenet dédié à Minix
la version 0.0.1 de Linux. Convaincu par RMS de publier son code sous la licence GPL, Linus permit au monde entier de
disposer de son travail et d’y contribuer. Le noyau Linux devient le noyau le plus utilisé avec GNU.
F IGURE 17 – Tux la mascotte de Linux - Source : wikipédia
Depuis sa version 1.2, (la version actuelle en développement est la 2.6.) Linux est un noyau monolithique modulaire,
entièrement paramétrable et ouvert sur les standards industriels. Le code est entièrement codé en C (aucune partie en C++).
Il a été conçu pour utilisé le compilateur GCC dont il utilise beaucoup de macros non standards. Le noyau ne compilera pas
avec un n’importe quel compilateur ANSI C.
Le minimum nécessaire pour le faire fonctionner est un processeur 32 bits avec ou sans bloc MMU.
6.5.1
Développement
Le développement de Linux est supervisé par une hiérarchie précise au sein de la communauté, le haut de celle - ci étant
toujours représenté par Linus Torvalds.
Les publications de codes se font au travers des branches de développement qui intègrent les changements majeurs et les
nouvelles fonctionnalités. Au bout d’un certain temps, si une branche de développement est assez mature (cf Fig. 18), elle
devient une base pour la prochaine version stable. Une branche stable du noyau est publiée tous les deux ou trois ans. Les
branches peuvent être identifiées par leur numéro de version :
– Le numéro de branche est pair pour les versions stables. Exemple : 1.0, 2.0, 2.4.
– Il est impair pour les branches de développement. Exemple : 2.1 , 2.5.
– Les publications mineurs se voient attribuer un ou des numéros supplémentaires. Exemple : 2.2.22, 2.5.9.
18
6.6. UN COUPLE GAGNANT
6. DU PROCESSEUR AU NOYAU
F IGURE 18 – Cycle de développement - Source : Association Free-Electrons
6.6
Un couple gagnant
Les parts de marché de GNU/Linux ne cessent de monter en tant qu’ OS de station de travail, mais reste encore minoritaire (0,80 % en avril 2010). Cependant, il est de plus en plus utilisé dans le monde de l’embarqué (26 % en 2008).
Le succès dans le monde des systèmes intelligents peut s’expliquer d’un point de vue marketing :
– Le code de GNU et de Linux sont mis à disposition sans frais.
– Les outils nécessaires à leur mise en place et utilisation sont également libres de droits.
– Une communauté bénévole et gigantesque, toujours en activité autour d’ Internet. (Le développement de Fedora 9 est
estimé à 10,2 milliards de dollars de $)
Les avantages sont avant tout techniques :
–
–
–
–
–
Linux est certifié POSIX.
Linux fonctionne sur plus de 20 architectures différentes.
Un grand nombre de librairies et de composants compatibles GNU existent sur la toile avec un code ouvert.
La similarité du système avec UNIX est un atout pour les développeurs.
Des versions allégées permettent de l’utiliser sur des systèmes non dotés de MMU (µCLinux) (Un seul processus est
lancé sans commutation de contexte).
– La modularité du noyau permet de l’adapter au ressources de la machine. On peut faire tourner un noyau, GNU et un
serveur graphique sur des machines avec 8 Mo de mémoire vive et 50 Mo de capacité de disque.
– Possibilité de support Temps Réel.
– Existence de distributions prêtes à l’emploi suivant l’usage : Téléphone, serveur, routeur ...
6.7
Linux et la mémoire
Les mécanismes de segmentation et de pagination peuvent se retrouver difficile à gérer d’une architecture à une autre. Le
support de la segmentation sur une architecture RISC est limité, contrairement à la pagination. Ces deux mécanismes offrent
des possibilités similaires, Linux ne supporte donc que la segmentation au minimum. Tous les processeurs auront le même
adressage logique avec un nombre limité de segments uniquement enregistré dans la table globale des segments. On aura :
– Les segments du Noyau (Code et Données en Ring 0)
– Les segments de données utilisateurs (Code et Données en Ring 3)
– Un TSS par coeur. Le TSS (Task Segment State) est une structure qui permet de sauvegarder le contexte lors des
interruptions ou des commutations de tâches
– Un segment pour une table locale des descripteurs de segments. Cette LDT ne contiendra qu’un descripteur nul et est
commune à tous les processus
– 4 Segments pour le code et les données du BIOS (ou chargeur de démarrage).
La pagination est implémentée avec un répertoire principale contenant les autres répertoires de pages.
19
6.8. NAVIGUER DANS LES SOURCES DU NOYAU
6. DU PROCESSEUR AU NOYAU
F IGURE 19 – Segmentation sous Linux
F IGURE 20 – Pagination sous Linux
6.8
Naviguer dans les sources du Noyau
Les différents répertoires du noyau sont répertoriés dans le tableau de la figure 21.
Le répertoire contenant la documentation se révèle très important dans le cadre de l’embarqué puisqu’il n’existe aucune
documentation spécialisée pour une autre architecture que x86. L’ensemble des procédures pour initialiser les ports SPI ou
I2 C restent des spécificités du monde de l’embarqué et les seules informations se trouvent le dossier source du noyau.
En dehors du dossier /arch, relatif à l’architecture du CPU, le reste du code doit être portable. Cette compatibilité se base sur
des macros et des fonctions qui crée une interface pour les parties propres au processeur :
– Problème d’endianness
– Accès aux ports E/S en mémoire
– L’API pour le DMA
L’API interne du noyau est en constante évolution et il n’est pas rare qu’un pilote nécessite une réécriture après la
publication d’une nouvelle version non majeure. La partie suivante parle de ce point plus en détail.
20
6.8. NAVIGUER DANS LES SOURCES DU NOYAU
6. DU PROCESSEUR AU NOYAU
arch/
Code dépendant de l’architecture
COPYING
Conditions de copie de Linux (GNU GPL)
CREDITS
Contributeurs principaux de Linux
crypto/
Bibliothèques de cryptographie
Documentation/
Documentation du noyau.
drivers/
Pilotes de périphériques (drivers/usb/, etc.)
fs/
Systèmes de fichier (fs/ext3/, etc.)
include/
Entêtes du noyau
include/asm<arch>
Entêtes dépendant de l’architecture
include/linux
Entêtes du coeur du noyau Linux
init/
Initialisation de Linux (contient main.c)
ipc/
Code utilisé pour la communication entre processus
kernel/
Coeur du noyau Linux
lib/
Bibliothèques diverses (zlib, crc32...)
MAINTAINERS
Responsables de parties du noyau
Makefile
Makefile principal (définit arch et version)
mm/
Code de la gestion mémoire
net/
Support réseau (protocole uniquement)
README
Introduction et instructions de compilation
REPORTINGBUGS Instructions pour le rapport de bogues
scripts/
Scripts utilisés en interne ou en externe
security/
Implémentations du modèle de sécurité (selinux...)
sound/
Support du son et pilotes
usr/
Utilitaires
F IGURE 21 – Les différents dossiers du noyau et le type de code qu’ils contiennent
F IGURE 22 – Taille des différents répertoires - Source : Association Free Electrons
21
6.9. LES PILOTES SOUS LINUX 2.6
6.9
6. DU PROCESSEUR AU NOYAU
Les pilotes sous Linux 2.6
Les pilotes sont le plus souvent écrit sous forme de modules. Ce sont des petits bout de code que l’on peut charger dynamiquement pendant l’exécution du système ou compiler statiquement dans le noyau. Pour chacun de ses modules, il faut
définir une licence pour son code : GPL, Dual BSD/GPL, DUAL MPL/GPL ou Propriétaire. Cette licence va déterminer le
comportement de son code avec les autre modules disponibles. Si un module est propriétaire, il n’aura pas le droit d’interagir
avec un autre module. C’est pourquoi la plupart des modules et des pilotes sont publiés sous licence libre ou open source.
La gestion des périphériques a grandement évoluée depuis les premières versions. Cette politique oblige souvent le code à
être réécrit, mais du fait de l’ouverture du code, il est assez aisé de faire la transition. Si l’on prends l’exemple de l’API USB,
elle a changé trois fois et est devenue l’ implémentation la plus rapide du protocole. Sous Windows XP, elle a également
changé trois fois, mais du fait de la fermeture du code, il a été nécessaire de garder une rétro compatibilité pour les pilotes
binaires. Ces opérations sont un coût en développement, sécurité, stabilité et performance.
On peut également écrire un pilote en espace utilisateur. Cela présente l’avantage de pouvoir utiliser n’importe quel langage
et assure de ne pas créer d’erreur critique dans la mémoire noyau. Il n’est pas rare de voir des système de gestions de périphériques utiliser les deux espaces : une partie noyau et une partie utilisateur qui communiquent entre eux (On peut citer le
fameux serveur graphique X Window)
Il existe 3 types de pilotes différents :
–
–
–
–
Pilotes de caractères : communication avec le matériel via un flux de caractère. (Clavier, souris, port série, consoles)
Pilotes de blocs : communication avec le matériel via des blocs de données. (Disques durs, système de fichiers, etc...)
Pilotes Réseaux : communication avec le matériel via un protocole de communication
Des pilotes utilisant le modèle unifié.
Chacun de ses périphériques se trouve en espace noyau. Il est courant de créer un lien avec l’espace utilisateur ( au moyen
des dossier /proc et /sys). Il apparaît comme un fichier dans l’arborescence sur lequel les opérations d’écriture et de lecture
se font comme avec n’importe qu’elle autre fichier. Ces actions sont définies dans le module à l’aide d’une structure et de
pointeurs de fonctions.
6.10
Le framebuffer
Ce composant permet de dialoguer directement avec la mémoire vidéo. Il permet de s’affranchir de système de fenêtrage plus lourd comme le serveur X. C’est un atout majeur dans le monde de l’embarqué puisque l’on peut intégrer un
véritable système graphique avec une consommation de ressources amoindrie. C’est ce composant que l’on peut retrouver
au démarrage de la plupart des "Live CD" GNU/Linux.
F IGURE 23 – Démarrage de knoppix avec framebuffer - Source : Wikipédia [6]
22
7. RÉALISATION
7
Réalisation
Cette partie présente les différents choix techniques et les outils qui ont été nécessaires à la réalisation du projet.
7.1
7.1.1
Choix de la plateforme GNU/Linux
Carte retenue
La solution retenue était une carte proposée conjointement par l’association française et l’entreprise ARMADEUS. Les
raisons de ce choix sont les suivantes :
– Un support gratuit en français par mail ou sur IRC [7] en contact direct avec les développeurs.
– Une base de données techniques complête basée sur le moteur de Wikipédia [8].
– Schémas des cartes disponibles en open source.
– Une utilisation à 100% d’outils de développement libres.
– Un système avec MMU et FPGA pour une stabilitée accrue et évolution facilitée vers de nouveaux projets.
– Un prix inférieur par rapport aux cartes de mêmes caractéristiques.
Ces points constituent un réel avantage, car il n’existe actuellement aucun ouvrage traitant directement de la réalisation
de pilotes ou de l’implémentation de GNU/Linux sur une carte embarquée. Les seuls ouvrages existants concernent les
plateformes x86 des PC actuels. La seule manière de se documenter restent les sources de Linux et les codes sources
disponibles sur internet.
Association et compagnie Armadeus
L’association ARMADEUS Project est une organisation à but non lucrative proposant des solutions embarquées basées
sur des logiciels libres conçues via l’entreprise ARMADEUS Systems. Elle propose des kits de développement à bats coûts
comprenant :
– Une carte "processeur" comprenant :
– Un processeur de chez Freescale.
– Une mémoire volatile.
– Une mémoire non volatile.
– Un FPGA de chez Xilinx.
– Une carte de développement comprenant divers périphériques connectés aux blocs fonctionnels du processeur.
F IGURE 24 – Logo de l’entreprise Armadeus
23
7.1. CHOIX DE LA PLATEFORME GNU/LINUX
7. RÉALISATION
Le prix de la carte processeur varie en fonction de la quantité de mémoire et la puissance du processeur. Celui de la carte
de développement change en suivant le nombre de périphériques de communication déjà soudés et configurés.
Les cartes choisies furent la carte processeur apf27 et la carte de développement APF27DevFull. Les caractéristiques sont
présentées à la figure 26.
(a) La carte processeur APF27
(b) La carte processeur APF27DevFull
(c) Les deux cartes assemblées
F IGURE 25 – Les cartes de développement de l’APF27 et APF27Dev
24
7.1. CHOIX DE LA PLATEFORME GNU/LINUX
7. RÉALISATION
Carte processeur APF27 [9]
Processeur
Freescale i.MX27 (ARM9 @ 400MHz)
FPGA
Xilinx Sparant 3A XC3S200A
RAM
Mobile DDR, 2 × 64 MB
FLASH
Mobile NAND, 256 MB
Module Processeur [10]
6 x RS232
2 x I2C
3 x SPI
2 x SSI (High speed synchronous serial port)
1 x USB OTG Hi-Speed host
1 x USB Host (Hi-Speed)
1 x USB Host (Full-Speed)
1 x 10/100Mbits Ethernet MAC
2 x SD/MMC
1 x RTC (no battery)
1 x PWM 16bits resolution
6 x Timer 32 bits with input capture/output compare
1 x adjustable Watchdog
1 x LCD controller STN / TFT interface resolution up to 800 x 600 px, 18 bits
1 x MPEG/H.264 codec
1 x CSI (CMOS sensor interface)
Up to 107 total I/O pins multiplexed with most dedicated functions for pin efficiency (GPIO)
Carte de développement APF27Dev [10]
One high speed and one full speed USB 2.0 port
Touchscreen controller
One microSD
Audio in/Stereo audio out controller (TSC2101 codec)
2 user leds : one connected to the i.MX27 microprocessor and the other to the FPGA
2 user switches : one connected to the i.MX27 microprocessor and the other to the FPGA
CAN(1) controller
ADC (7 channels, 10 bits) type MAX1027(1)
DAC (2 channels, 10 bits) type MAX5821(1)
RTC with backup battery(1)
HDMI/DVI controller.(1) For DVI usage, an additional HDMI/DVI cable is required
Reset switch
F IGURE 26 – Caractéristiques de l’APF27 et APF27Dev chez T & S - Le nombre de I/O est relatif au nombre de module activés.
25
7.2. PRÉSENTATION DE L’ARCHITECTURE ARM (32 BITS)
7.2
7. RÉALISATION
Présentation de l’architecture ARM (32 bits)
ARM est l’abbréviation de Advanced Risc Machine. Cette architecture a été développée à l’origine pour un ordinateur
de la société ACORN puis est devenue une offre de coeur à part entière. La spécificité de l’entreprise ARM Ltd est de ne
vendre aucune puce physique mais uniquement les IPs aux différents fondeurs ou développeurs.
Les coeurs ARM ont inondé le marché, notamment dans le domaine de la téléphonie mobile qui utilise de plus en plus
des systèmes d’exploitations semblables à ceux de nos ordinateurs. Nous pouvons citer les dérivés de Linux avec Maemo,
Symbian de Nokia ou Android sur le Nexus One de Google/HTC ou dans un autre registre l’iPhone OS de la marque à la
pomme.
L’IP la plus connue est l’ARM7TDI comportant un niveau de pipeline sur 3 étages et une possibilité de basculé le jeu d’instructions de 32 à 16 bits (Mode THUMB), mode utilse pour une économie de mémoire dans le monde de l’embarqué. Son
successeur, le ARM9, passe sur 5 niveaux de pipeline.
ARM Ltd. propose les blocs logiques suivants dans ses processeurs :
– MMU : disponible sur les ARM710 et ARM9.
– DSP
– FPU
– Jazelle : une machine virtuelle cablée dans le processeur
La majorité des fondeurs proposent des coeurs ARM aujourd’hui (Fresscale,Qualcomm,Marvell, Cypress, NXP, STMicroelectronics, TI, Samsung, Toshiba..).
7.3
Composants logiciels
Tous les composants cités dans cette partie sont publiés sous une licence libre de type GPLv2 ou BSD.
7.3.1
Sur l’ordinateur
Pour créer des binaires exécutables ARM sans utiliser la plateforme (compiler sur la carte prendrait énormément de
temps), il faut utiliser une chaîne de compilation croisée. La démarche à suivre pour la construire est la suivante :
1. Récupérer les entêtes du noyau.
2. Récupérer, configurer et compiler les outils pour la manipulation des binaires de l’architecture embarquée (assembleur,
éditeur de lien, inspecteur de code et archiveur de code au minimum) et les installer sur la machine.
3. Installer une première version du compilateur pour "cross compiler" les librairies standards (uClibc).
4. Reconfigurer et recompiler une version de compilateur avec les librairies créées.
5. Récupérer les sources du noyau, les configurer et les recompiler.
6. Compiler chaque programme ou librairies avec ses dépendances et les intégrer au futur système de fichiers de la carte.
Ces étapes peuvent se réveler complexe : un simple programme peut recquérir 10 dépendances qui dépendent elles
mêmes d’autres codes .... Heureusement, il existe des outils spécialisés permettant la géneration de la chaîne de compilation
croisée, mais aussi de modifier la plupart des composants du système final. Nous pouvons cité LTIB, OpenEmbedded, PTXdist,Openwrt ou Buildroot. C’est ce dernier qu’a choisi ARMADEUS pour travailler sur ses cartes et elle n’est pas la seule :
THALES, ATMEL, GUMSTIX s’en servent depuis de nombreuses années, bien avant la sortie d’une version stable.
Buildroot
Avantages
OpenEmbedded
Évolutif,puissant, configuration Géneraliste
graphique,Géneraliste
Openwrt
Création de paquets
Inconvénients Gourmand en ressources, pas de Lourd, configuration avec des fi- Lourd, orienté IAD
paquets
chiers textes
26
7.3. COMPOSANTS LOGICIELS
7.3.2
7. RÉALISATION
Buildroot
À l’origine, cet outil n’était utilisé qu’en interne par les développeur de la librairie uClibc. Depuis 2009, il est devenu
un outil à part entière. Sa relative simplicité d’utilisation vient du fait qu’il utilise des outils bien connus de la part de la
communauté GNU et des développeurs du noyau Linux.
F IGURE 27 – Interface buildroot sous ncurses.
Il est constitué d’un ensemble de Makefile et de script shell qui téléchargent, configurent, compilent et intègrent automatiquement les programmes souhaités. Il est assez facile d’intégrer ses propres patchs ou librairies en ajoutant ses fichiers de
configuration type Makefile dans la gestion des dépendances et de la construction.
Une fois la phase de compilation terminée, on obtient 3 fichiers :
1. Un noyau Linux bootable
2. Une image du système de fichier jffs2
3. Un binaire U-Boot
7.3.3
Sur la carte
Les composants utilisés sur la plateforme sont répertoriés dans le tableau suivant :
Bootloader
U-Boot
Noyau
Linux
Librarie
uClibc
Shell
Busybox
Compilateur
GCC
Système de fichier
jffs2
F IGURE 28 – Composants logiciels utilisés sur la carte.
– U-Boot : Ce bootloader possède une pile TCP/IP et une couche permettant de flasher la mémoire vive. Passer par le
réseau ethernet pour charger les composants représente un gain de temps non négligeable.
– Linux : Sa configuration passe par de nombreux patchs mais des modules sont déja présents pour chaque plate-forme.
27
7.4. INTERFACES AVEC LA CARTE
7. RÉALISATION
– uClibc : C’est une librairie statique fournit pour l’utilisateur du système, lui permettant d’utiliser simplement les appels systèmes définis dans le noyau. Elle présente l’avantage d’être réduite par rapport à sa grande soeur la glibc et
suffisante pour les sytèmes embarqués.
glibc uClibc
"hello world" 475k 25k
busybox
843k 311k
F IGURE 29 – Comparaison de la taille de la glibc et la uClibc en compilation statique
– Busybox : Ce programme réimplémente toutes les commandes du système GNU dans un seul exécutable pour économiser de la RAM. Il est très répendu dans les produits grands publics (Freebox par exemple).
– GCC : (Gnu Compiler Collection ) La collection officielle de compilateur GNU. Elle supporte un grand nombre de
langages pour une multitude de plate-formes (dont ARM).
– jffs2 : (Journaling Flash File System) Un système de fichier journalisé qui répartie l’écriture sur l’ensemble des cellules de la mémoire flash pour économiser le matériel. Une compression est réalisée pour stocker autant de données
que possible.
NAND flash address range
0x00000000 - 0x0009FFFF (640KB, incluant la NAND SPL et 384KB
d’économie de mémoire pour les bloc défectueux)
Type
U-Boot
0x000A0000 - 0x000FFFFF (384KB)
Variables d’environnement U-BOOT
0x00100000 - 0x0017FFFF (512KB)
FPGA bitfile
0x00180000 - 0x0067FFFF (5MB)
Image du noyau Linux
0x00680000 - Limite de la FLASH
Système de fichiers racine
F IGURE 30 – Répartition des différents composants au sein de la RAM de l’APF27
7.4
Interfaces avec la carte
L’entrée et la sortie standards de la carte correspondent à la liaison série (ce qui corresponds respectivement au clavier
et à l’écran sur un ordinateur). La carte émule un terminal à la manière d’un modem auquel on peut envoyer des ordres via
un cable Null-Modem (Rx Tx croisé) avec une configuration 115200 bauds 8N1.
Le transfert de fichiers se fait via un protocole dérivé de FTP depuis le PC jusqu’en RAM de la carte qui copie les fichiers
de manière résidente sur la mémoire flash.
La communication depuis la machine hôte se fera depuis un logiciel de communication vers des modems. Sous Linux,
les plus connus restent Minicom, Kermit et GtkTerm.
7.5
Écran AMOLED Tactile
L’écran utilisé est un écran P0430WQLB-T de la société Densitron avec une résolution en RGB de 480 x 272. Il possède
en plus une interface tactile résistive déjà posée sur l’écran :
28
7.5. ÉCRAN AMOLED TACTILE
7. RÉALISATION
F IGURE 31 – Liens entre les différentes mémoires
F IGURE 32 – Utilisation de la carte sur le réseau
F IGURE 33 – Écran P0430WQLB-T de la société Densitron
29
7.5. ÉCRAN AMOLED TACTILE
7. RÉALISATION
L’avantage par rapport aux technologies à matrices actives est un contraste de couleur beaucoup plus nette et , dans la
plupart des cas, une puissance consommée beaucoup plus faible.
Les écrans AMOLED possèdent comme leurs cousins alphanumériques, une interface de communication standardisée avec
laquelle. La puce utilisée est un HX5116.
F IGURE 34 – Interface de la puce HX5116
7.5.1
Interface RGB Parallèle
Cette interface est héritée des premiers moniteurs VGA que les générations suivantes n’ont pas fait disparaître. Ces
appareils utilisaient un canon à électrons qui balayait une grille tricolore afin de faire apparaitre les pixels. La projection
partait du bord haut gauche de l’écran et descendait ligne par ligne avant de retourner à son point de départ. On se servait de
3 signaux pour gérer ces évenènements dans le temps et trois signaux analogiques codant la valeur du pixel affiché.
F IGURE 35 – Les premiers moniteurs RGB
Dans notre écran, on garde le même principe en ajoutant les éléments communs à la majorité des composants numériques : une horloge, une entrèe de validation et un bus de données parrallèle de 24 bits (il est possible d’utiliser un bus
série).
30
7.5. ÉCRAN AMOLED TACTILE
7. RÉALISATION
F IGURE 36 – Interface parallèle 480x212 RGB
Le contrôleur LCD du microprocesseur ne peut contrôler que des écrans dont la résolution RGB est inférieure ou égale
à 18 bits. Nous relierons les 2 bits de poids faible de chaque couleur à la masse, nous laissant encore largement assez de
couleurs pour notre projet.
7.5.2
Interface SPI "3-wire"
Cette interface permet la configuration de l’écran et lui spécifie l’interface à utiliser. La particularité de cette interface
est qu’elle n’utilise qu’un seul fil, contrairement à la carte embarquée qui utilise un bus de deux fils. Aucun problème de
connexion ne se pose si l’on ne souhaite communiquer que dans un seul sens. On a trois fils : une horloge, un bus de donnés
et une entrée d’activation.
L’initialisation de l’écran en mode 480 x 272 en mode RGB requiert une trame spécifique à la mise sous tension de
l’écran. Si l’on souhaite lire des données présentes en mémoire du contrôleur, il faut user d’une petite astuce à la conception
et à la programmation sur le seul bus de communication.
Pour permettre au contrôleur de l’écran de prendre la main sur le bus, il faut forcer l’état de la pin MOSI à l’état haut en
envoyant constamment 0xFF pendant la procédure de réception.
7.5.3
Écriture du pilote
Choix de la connexion sur la carte
Il faut un bus SPI libre sur la carte pour communiquer avec l’écran. D’après la documentation, la carte possède trois bus
SPI. Nous souhaitions préservez les ports USB et nous avons sacrifié l’un des deux bus gérant la connexion à une carte MMC
en se basant sur le bus 3. Les informations nécessaires pour configurer les différents éléments se trouvent dans le dossier
documentation du noyau. Dans notre cas, c’est le fichier Documentation/spi/spi-summary qui fut d’une grande aide.
La procédure est la suivante :
1. Déclarer les ports SPI présents sur la carte (cette partie était déjà présente dans les sources fournit par ARMADEUS).
2. Déclarer les périphériques utilisés sur les ports.
3. Indiquer le pilote utiliser.
31
7.5. ÉCRAN AMOLED TACTILE
7. RÉALISATION
(a) Format des données verticale
(b) Format des données horizontales
(c) Forme de l’horloge et des donnés sur le bus
F IGURE 37 – Chronogrammes des différents signaux de l’écran
32
7.5. ÉCRAN AMOLED TACTILE
7. RÉALISATION
F IGURE 38 – SPI 3 wire
(a) Connexion des bus MOSI et MISO ensemble
(b) Émission de de 0xFF sur le bus pendant l’envoie
F IGURE 39 – Connexion d’un bus SPI 3-wire vers un bus half duplex
Déclaration du périphérique
On déclare le périphérique avec le bout de code suivant :
1
2 static struct spi_board_info spi_board_info[] __initdata = {
3 /* .... */
4
5 #ifdef CONFIG_LCD_TS_MODULE
6
{
7
.modalias
= " l c d _ t s ",
8
.controller_data
= &lcd_ts_hw,
9
.max_speed_hz
= 8000000, /* 8MHz */
10
.bus_num
= 2, /* SPI3 */
11
.chip_select
= 0,
33
7.5. ÉCRAN AMOLED TACTILE
12
13
14
15
16
17
18
19
20
.platform_data
7. RÉALISATION
= &apf27_lcd_ts_config,
},
#endif /* LCD T&S */
};
/* .... */
#ifdef CONFIG_LCD_TS_MODULE
#define NCSPIN (GPIO_PORTE | 21) /* Adresse des PINS utilisees. On se sert des headers
fournit par Motorola */
21 #define RESETPIN (GPIO_PORTE | 19)
22
23
24
25 static int lcd_ts_pins [] ={ /* Pins en sortie */
26
(NCSPIN | GPIO_GPIO | GPIO_OUT),
27
(RESETPIN | GPIO_GPIO | GPIO_OUT),
28
29 };
30
31 static int lcd_ts_init(struct spi_device *spi){
32
33
gpio_set_value(RESETPIN,1); /* Les fonctions gpio_set_value et
mxc_gpio_setup_multiple_pins sont relatif a la pateforme MXC */
34
gpio_set_value(NCSPIN,1);
35
return mxc_gpio_setup_multiple_pins(lcd_ts_pins, ARRAY_SIZE(lcd_ts_pins), "LCD_TS"
);
36
37 }
38
39 static int lcd_ts_exit(struct spi_device *spi){
40
41
gpio_set_value(NCSPIN,1);
42
gpio_set_value(RESETPIN,0);
43
mxc_gpio_release_multiple_pins(lcd_ts_pins, ARRAY_SIZE(lcd_ts_pins));
44
return 0;
45
46
47
48 }
49 static int lcd_ts_reset (int value){
50
gpio_set_value(RESETPIN,value);
51
return 0;
52
53
54 }
55 static void lcd_ts_cs(u32 command)
56 {
57
if (command == SPI_CS_DEASSERT)
58
gpio_set_value(NCSPIN, 1);
59
else
60
gpio_set_value(NCSPIN, 0);
61 }
62
63 static struct spi_imx_chip lcd_ts_hw = {
64
.cs_control = lcd_ts_cs,
65 };
66
67 static struct lcd_ts apf27_lcd_ts_config = {
68
69
.init = lcd_ts_init,
70
.exit = lcd_ts_exit,
71
.reset = lcd_ts_reset,
72
.ncspin = (int) NCSPIN,
73
.resetpin = (int) RESETPIN,
74
75 };
76 #endif
Les arguments sont les suivants :
– modalias : le nom du module correspondant au pilote.
– controller_data : un pointeur vers une structure de contrôl propre à la plateforme (Chip Select).
34
7.5. ÉCRAN AMOLED TACTILE
– max_speed_hz : vitesse maximale du bus.
7. RÉALISATION
– bus_num : bus de communication du processeur (SPI3).
– chip_select : présence d’une pin CS.
– platform_data : un pointeur sur une structure contenant les adresses des fonctions d’initialisation du périphérique esclave.
Ces fonctions d’initialisation se trouvent plus bas dans le code. Elles sont écrites suivants les procédures de démarrage de
l’écran trouvées dans la datasheet :
F IGURE 40 – Séquence d’allumage de l’écran
Écriture du pilote
Cette section de code se situe au niveau de la communication SPI à proprement parlé, il n’y a plus de configuration
matériel.
Le pilote prend la forme d’un module que l’on peut appeler et qui est relié au bon périphérique SPI via la structure vue dans
la partie précédente. On reprends les informations de la plate-forme via une structure :
1
2 struct lcd_ts {
35
7.5. ÉCRAN AMOLED TACTILE
3
4
5
6
7
8
9
10 };
7. RÉALISATION
struct display_device * display_dev;
struct spi_device *spi ;/* SPI BUS */
int (*init)(struct spi_device *spi);
int (*exit)(struct spi_device *spi);
int (*reset)(int value);
int ncspin;
int resetpin;
Puis on définit un driver SPI via une nouvelle structure :
1 static struct spi_driver lcd_ts_driver = {
2
.probe
= lcd_ts_probe,
3
.remove
= lcd_ts_remove,
4
.shutdown
= lcd_ts_shutdown,
5
.suspend
= lcd_ts_suspend,
6
.resume
= lcd_ts_resume,
7
.driver
= {
8
.name
= DRIVER_NAME,
9
.owner = THIS_MODULE,
10
},
11 };
Chacun des éléments est un pointeur sur une fonction de configuration du périphérique. Toutes les références doivent être
définies. Les fonctions shutdown, suspend et resume ne seront pas utilisées et ne renverront que 0.
La fonction probe correspond à l’initialisation du périphérique sur le bus.
1 static int lcd_ts_probe (struct spi_device *spi_device){
2
3
printk("LCD SPI Bus R e g i s t r a t i o n \ n ");
4
struct lcd_ts *lcd_data;
5
int err = -EINVAL;
6
lcd_data = (struct lcd_ts *)(spi_device->dev.platform_data);
7
lcd_data->init(spi_device); /* Initialise GPIO */
8
9
lcd_data->spi = spi_device;
10
11
lcd_data->spi->mode = SPI_MODE_0;
12
lcd_data->spi->bits_per_word = 8;
13
lcd_data->spi->dev.power.power_state = PMSG_ON;
14
err = spi_setup(lcd_data->spi);
15
printk(" R e n v o i e du s e t u p %i \ n ",err);
16
17
lcd_ts_init_screen(lcd_data);
18 return 0;
19
20 }
Cette fonction appelle la fonction lcd_ts_init_screen qui va transmettre la trame de configuration de l’écran conformément à
la datasheet (cf Fig.41) :
1 static int lcd_ts_init_screen( struct lcd_ts * lcd_ts_dev){
2
3
/* gpio_set_value(lcd_ts_dev->resetpin,1); */
4
5
/* initial procedure for 24-bit parallel RGB (DE) */
6
lcd_ts_write (lcd_ts_dev, 0x04, 0x23); /*set display mode 24-bit parallel RGB (DE)*/
7
lcd_ts_write (lcd_ts_dev, 0x05, 0x82); /*set display mode*/
8
lcd_ts_write (lcd_ts_dev, 0x07, 0x0F); /*set driver capability*/
9
lcd_ts_write (lcd_ts_dev, 0x34, 0x18); /*set display timing*/
10
lcd_ts_write (lcd_ts_dev, 0x35, 0x28); /*set display timing*/
11
lcd_ts_write (lcd_ts_dev, 0x36, 0x16); /*set display timing*/
12
lcd_ts_write (lcd_ts_dev, 0x37, 0x01); /*set display timing*/
13
lcd_ts_write (lcd_ts_dev, 0x02, 0x02); /*OTP On*/
14
lcd_ts_write (lcd_ts_dev, 0x0A, 0x79); /*VGHVGL=+/-6V*/
15
lcd_ts_write (lcd_ts_dev, 0x09, 0x20); /*VGAM1OUT=4.85V*/
16
lcd_ts_write (lcd_ts_dev, 0x10, 0x6A); /*set R slop*/
17
lcd_ts_write (lcd_ts_dev, 0x11, 0x6A); /*set G slop*/
18
lcd_ts_write (lcd_ts_dev, 0x12, 0x68); /*set B slop*/
19
lcd_ts_write (lcd_ts_dev, 0x13, 0x00); /*set R_0*/
20
lcd_ts_write (lcd_ts_dev, 0x14, 0x04); /*set R_10*/
36
7.5. ÉCRAN AMOLED TACTILE
7. RÉALISATION
F IGURE 41 – Initialisation de l’écran dans la documentation
37
7.5. ÉCRAN AMOLED TACTILE
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46 }
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
7. RÉALISATION
0x15,
0x16,
0x17,
0x18,
0x19,
0x1A,
0x1B,
0x1C,
0x1D,
0x1E,
0x1F,
0x20,
0x21,
0x22,
0x23,
0x24,
0x25,
0x26,
0x27,
0x28,
0x29,
0x2A,
0x06,
0x05);
0x05);
0x04);
0x03);
0x02);
0x02);
0x00);
0x06);
0x05);
0x06);
0x06);
0x05);
0x05);
0x07);
0x00);
0x07);
0x06);
0x07);
0x07);
0x06);
0x04);
0x07);
0x03);
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
R_36*/
R_80*/
R_124*/
R_168*/
R_212*/
R_255*/
G_0*/
G_10*/
G_36*/
G_80*/
G_124*/
G_168*/
G_212*/
G_255*/
G_0*/
B_10*/
B_36*/
B_80*/
B_124*/
B_168*/
B_212*/
B_255*/
display on*/
/* gpio_set_value(lcd_ts_dev->resetpin,1);*/
Une fois la communication terminée, il faut terminer libérer les ressources. C’est le but de la fonction resume :
1 static int lcd_ts_remove(struct spi_device *spi_device){
2
3
struct lcd_ts * lcd_data ;
4
lcd_data = (struct lcd_ts * )(spi_device->dev.platform_data);
5
6
lcd_data->exit(spi_device); /* Free GPIO */
7
/* Init Sequence */
8
lcd_data->reset(0);
9
10
return 0;
11 }
Nous devons ouvrir notre module à l’extérieur et proposer des fonctions d’initialisation et de désallocation du pilote dans
le système.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
static int __init lcd_ts_init(void)
{
printk(" L o a d i n g LCD D r i v e r module \ n ");
int i;
i = spi_register_driver(&lcd_ts_driver);
printk(" R e n v o i e : %i \ n ",i);
return i;
}
static void __exit lcd_ts_exit(void)
{
printk(" U n l o a d i n g LCD D r i v e r module \ n ");
spi_unregister_driver(&lcd_ts_driver);
}
module_init(lcd_ts_init);
module_exit(lcd_ts_exit);
MODULE_AUTHOR("HEINRICH Y a n n i c k < y a g e e k @ f r e e . f r > ");
MODULE_DESCRIPTION(" HX5116 AMOLED D r i v e r ");
MODULE_LICENSE("GPL");
Toutes les fonctions sont déclarées statiques de manière à cloisonner la compilation et l’édition de liens aux références de ce
fichier.
Le pilote devra être lancé manuellement dès l’identification sur le shell. On pourra par la suite rendre automatiquement le
lancement du module. La commande pour lancer le module sera : modprobe lcd_ts.
38
7.5. ÉCRAN AMOLED TACTILE
7. RÉALISATION
Programme Mandel sous SDL
La SDL est une librarie libre très utilisée pour créer des jeux vidéos 2D. Son aptitude à dialoguer directement avec le
framebuffer linux la rende très rapide.
Le programme Mandel affiche une réprésentation de l’ensemble de Mandelbrot dans le plan d’Argand-Gauss. Son programme est détaillé dans les annexes.
F IGURE 42 – La fractale de Mandelbrot sur PC avec la librarie SDL
7.5.4
Alimentation
L’écran AMOLED requiert un grand nombre de condensateurs et une alimentation symétrique proche de plus et moins
5V. Il existe des circuits dédiés à l’alimentation de ces écrans, basés la plupart du temps sur des pompes de charges, courantes
dans l’alimentation de petite puissance. Notre choix s’est porté sur un contrôleur de ON-Semiconductors : le NCP5810D.
Il permet d’obtenir une tension symétrique à partir d’une tension au maximum de 7 V et peut fournir jusqu’à 1 W de
puissance. La seule complication est liée à l’unique package proposé qui se révèle très difficile à manipuler et à souder. Il est
également prévu de pouvoir se connecter à une alimentation extérieure.
39
7.6. CONCEPTION DE LA CARTE
7. RÉALISATION
F IGURE 43 – Présentation du NCP5810
7.6
Conception de la carte
La conception de la carte s’est faite sous deux logiciels différents : une première version fut réalisée sur le logiciel Eagle
racheté depuis peu par Farnell (anciennement CADSOFT) et la version finale de la carte fut réalisée sous le logiciel libre
Kicad. Ce dernier présentait l’avantage de ne pas avoir de fonctionnalité réduite et la licence d’utilisation qui, contrairement
à Eagle, permettait de concevoir un produit à but commercial.
7.6.1
Contraintes de routage
La carte a été commandée auprès de la société PCB-Pool qui imposait les contraintes de conceptions suivantes en double
face 1 :
– Pad/Via Restring 0.2mm
– Via/Drill Restring 0.15mm (taille de pastille moins le diamètre de perçage), au moins taille de bande de cuivre/taille
entrefer
– Vernis épargne 0.075mm (taille de pastille sur couche soudée moins taille de pastille sur cs/ss)
– Ouvertures (antipads) Multicouches 0.35mm (taille de pastille sur couche interne négative moins perçage)
1. http://www.pcb-pool.com/ppfr/info_technique.html
40
7.6. CONCEPTION DE LA CARTE
7. RÉALISATION
(a) Logo de eagle
(b) Logo de Kicad
F IGURE 44 – Les deux logiciels de CAO utilisés
– Diamètre minimal des trous : Diamètre de foret = 0.2 mm (8mil)
7.6.2
Schéma
Le schématique de la carte n’as pas changé entre les deux versions (cf Fig.45.
7.6.3
Routage
La carte est destinée à se poser au dessus de la carte de développement à l’aide d’entretoises. La conception à pris en
compte l’emplacement des différents connecteurs sur la carte mère.
La première version de la carte a été réalisée sous eagle.
Cette version n’as pas été conservée suite à un changement de disposition sur la carte GNU/Linux.
La seconde version fut réalisée sous Kicad.
7.6.4
Soudure
Le choix de la soudure s’est dirigé vers les fours à refusion du fait de la petite taille des composants utilisés, notamment
le NCP5810 et le connecteur HIROSE pour l’écran AMOLED.Le projet arrivant à son terme ,je n’ai pas pu terminer les
vérifications et les soudures de la carte, au profit de la partie logicielle qui est totalement achevée.
41
7.6. CONCEPTION DE LA CARTE
7. RÉALISATION
F IGURE 45 – Schématique de la carte
42
7.6. CONCEPTION DE LA CARTE
7. RÉALISATION
F IGURE 46 – Première version de la carte
43
7.6. CONCEPTION DE LA CARTE
7. RÉALISATION
(a) 2D
(b) 3D
F IGURE 47 – Seconde version de la carte
44
8. CONCLUSION
8
Conclusion
Ce projet fut une véritable opportunité pour appliquer toutes les connaissances acquises au cours de ma formation à
l’école et mes connaissances en informatique. J’ai pu comprendre l’ensemble des concepts utilisés dans les systèmes intelligents et étudier cette frontière qui existe entre le monde des informaticiens et celui des électroniciens. Partir de la réalisation
d’une carte et arriver à l’écriture de son pilote regroupe toutes les notions que l’informatique, l’électronique et les mathématiques ont engendrés depuis la création des premiers ordinateurs.
C’est également un sujet qui me tenait à coeur, étant un utilisateur de logiciels issus de la communauté libre et open-source.
La démocratisation des outils libres dans le monde de l’embarqué ne cessent de croître. Cet engouement s’explique par
des coûts logicielles quasiment nulles et de la disposition de milliers d’utilitaires pour traiter tous les domaines technologiques actuelles : géomatique, traitement d’image, codeur multimédia, asservissement ,etc. C’est autant de communautés
qui soutiennent et qui développent activement ces programmes, leur garantissant une performance et une fiabilité proches
voir meilleurs que leur équivalent propriétaires. L’investissement réside uniquement dans la formation et l’acquisition des
connaissances nécessaires au développement.
Le succès de GNU/Linux dans l’embarqué n’est plus à démontrer, en démontre la multiplication et le succès des entreprisesassociations dispensant des formations ou proposant des cartes électroniques à bas coûts (Armadeus, Free-Electrons). Ces
solutions présentent des réels avantages pour les petites entreprises et les pays en voie de développement. Ce projet fut une
véritable expérience dans la recherche et le développement que j’ai eu un très grand plaisir à mener.
45
TABLE DES FIGURES
TABLE DES FIGURES
Table des figures
1
2
3
Le groupe Technology & Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logos de la société RheinBrucke Consulting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
La zone d’activité vue par la société . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
6
6
4
5
Les projets du laboratoire en 2010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Le cycle en V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
8
6
7
8
9
10
11
12
13
14
15
Rôle d’un système d’exploitation - Source : wikipédia . . . . . . . . . . . .
L’ordonnanceur d’un noyau - Source : wikipédia . . . . . . . . . . . . . . .
La gestion de la mémoire au sein d’un noyau Source : wikipédia . . . . . . .
Représentation de la mémoire . . . . . . . . . . . . . . . . . . . .
Adressage en mode protégé . . . . . . . . . . . . . . . . . . . . . .
Représentation de la mémoire . . . . . . . . . . . . . . . . . . . .
Représentation de la mémoire paginée . . . . . . . . . . . . . . . .
Mécanisme simplifié de la pagination . . . . . . . . . . . . . . . .
Vision schématique d’un noyau monolithique modulaire - Source : wikipédia
Différents chargeurs de démarrage sous GNU/BSD . . . . . . . . .
(a)
Grub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
(b)
Lilo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
(c)
SysLinux . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logo de GNU - Source : wikipédia . . . . . . . . . . . . . . . . . . . . . .
Tux la mascotte de Linux - Source : wikipédia . . . . . . . . . . . . . . . .
Cycle de développement - Source : Association Free-Electrons . . . . . . . . . . . .
Segmentation sous Linux . . . . . . . . . . . . . . . . . . . . . . .
Pagination sous Linux . . . . . . . . . . . . . . . . . . . . . . . . .
Les différents dossiers du noyau et le type de code qu’ils contiennent
Taille des différents répertoires - Source : Association Free Electrons . . . . . . . .
Démarrage de knoppix avec framebuffer - Source : Wikipédia [6] . . . . . . .
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
12
12
13
14
14
15
15
16
17
17
17
17
17
18
19
20
20
21
21
22
Logo de l’entreprise Armadeus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Les cartes de développement de l’APF27 et APF27Dev . . . . . . . . . . . . . . . . . .
(a) La carte processeur APF27 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
(b) La carte processeur APF27DevFull . . . . . . . . . . . . . . . . . . . . . . . . .
(c) Les deux cartes assemblées . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Caractéristiques de l’APF27 et APF27Dev chez T & S - Le nombre de I/O est relatif au nombre de module activés.
Interface buildroot sous ncurses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Composants logiciels utilisés sur la carte. . . . . . . . . . . . . . . . . . . . . . . . . .
Comparaison de la taille de la glibc et la uClibc en compilation statique . . . . . . . . .
Répartition des différents composants au sein de la RAM de l’APF27 . . . . . . . . . .
Liens entre les différentes mémoires . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Utilisation de la carte sur le réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Écran P0430WQLB-T de la société Densitron . . . . . . . . . . . . . . . . . . . . . . .
Interface de la puce HX5116 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
24
24
24
24
25
27
27
28
28
29
29
29
30
46
TABLE DES FIGURES
35 Les premiers moniteurs RGB . . . . . . . . . . . . . .
36 Interface parallèle 480x212 RGB . . . . . . . . . . .
37 Chronogrammes des différents signaux de l’écran . . .
(a) Format des données verticale . . . . . . . . . . .
(b) Format des données horizontales . . . . . . . . .
(c) Forme de l’horloge et des donnés sur le bus . . .
38 SPI 3 wire . . . . . . . . . . . . . . . . . . . . . . . .
39 Connexion d’un bus SPI 3-wire vers un bus half duplex
(a) Connexion des bus MOSI et MISO ensemble . .
(b) Émission de de 0xFF sur le bus pendant l’envoie
40 Séquence d’allumage de l’écran . . . . . . . . . . . .
41 Initialisation de l’écran dans la documentation . . . .
42 La fractale de Mandelbrot sur PC avec la librarie SDL .
43 Présentation du NCP5810 . . . . . . . . . . . . . . .
44 Les deux logiciels de CAO utilisés . . . . . . . . . . .
(a) Logo de eagle . . . . . . . . . . . . . . . . . . .
(b) Logo de Kicad . . . . . . . . . . . . . . . . . .
45 Schématique de la carte . . . . . . . . . . . . . . . . .
46 Première version de la carte . . . . . . . . . . . . . . .
47 Seconde version de la carte . . . . . . . . . . . . . . .
(a) 2D . . . . . . . . . . . . . . . . . . . . . . . .
(b) 3D . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
TABLE DES FIGURES
. . . . . . . . . . 30
. . . . . . . . . . 31
. . . . . . . . . . 32
. . . . . . . . . . 32
. . . . . . . . . . 32
. . . . . . . . . . 32
. . . . . . . . . . 33
. . . . . . . . . . 33
. . . . . . . . . . 33
. . . . . . . . . . 33
. . . . . . . . . . 35
. . . . . . . . . . 37
. . . . . . . . . . 39
. . . . . . . . . . 40
. . . . . . . . . . 41
. . . . . . . . . . 41
. . . . . . . . . . 41
. . . . . . . . . . 42
. . . . . . . . . . 43
. . . . . . . . . . 44
. . . . . . . . . . 44
. . . . . . . . . . 44
47
BIBLIOGRAPHIE
BIBLIOGRAPHIE
Bibliographie
[1] Nabaztag. http://www.nabaztag.com/fr/index.html.
[2] Tux droïd. http://tuxisalive.com/.
[3] W IKIPÉDIA : Système embarqué — wikipédia, l’encyclopédie libre, 2010. [En ligne ; Page disponible le 18-mai-2010].
[4] PARROT : Ar drone. http://ardrone.parrot.com/parrot-ar-drone/fr/comment-ca-marche/
#start.
[5] Site internet de la société.
aspx, 2010.
http://technologyandstrategy.com/fr/groupe/Pages/chiffres.
[6] W IKIPÉDIA : Framebuffer linux — wikipédia, l’encyclopédie libre, 2010. [En ligne ; Page disponible le 15-septembre2010].
[7] Amadeus P ROJECT : Canal irc de l’association amadeus project - irc://irc.rezosup.org/#Armadeus.
[8] Association ARMADEUS : Wiki de l’association armadeus - http://www.armadeus.org/.
[9] Armadeus P ROJECT : Caractéristiques de apf27 - http://www.armadeus.com/wiki/index.php?title=
APF27.
[10] Armadeus
SYSTEMS
:
boards-apf27.html.
boards-apf27.html.
http://www.armadeus.com/english/products-processor_
http://www.armadeus.com/english/products-processor_
[11] W IKIPÉDIA : Liste des noyaux de systèmes d’exploitation — wikipédia, l’encyclopédie libre, 2009. [En ligne ; Page
disponible le 4-février-2010].
[12] Julien B OIBESSOT : Linux embarqué pour tous - http://www.unixgarden.com/index.php/embarque/
perles-de-mongueurs-analyse-de-logs-2. Linux Magazine 92, 2009.
[13] Julien B OIBESSOT : Rmll 2008 - système embarqué avec ajout de périphériques à la demande - http://2008.
rmll.info/Systeme-embarque-avec-ajout-de.html. 2008.
[14] Fleur B ROSSEAU :
Les modules du noyau linux.
comprendre/les-modules-du-noyau-linux.
http://www.unixgarden.com/index.php/
[15] CORBET : Porting device drivers to the 2.6 kernel. http://lwn.net/Articles/driver-porting/.
[16] Pierre-Yves D UVAL : Linux embarqué sur apf27. Rapport technique, Centre de physique des particules de Marseille,
2009.
[17] Jean-Michel F RIEDT : Programmation et interfaçage d’un microcontrôleur par usb sous linux : le 68hc908jb8.
http://www.unixgarden.com/index.php/embarque/programmation-et-interfacage-d%
e2%80%99un-microcontroleur-par-usb-sous-linux%c2%a0-le-68hc908jb8.
[18] Xavier G ARREAU : Bluetooth, installation et utilisation. http://www.unixgarden.com/index.php/
comprendre/bluetooth-installation-et-utilisation, 2008.
[19] Matthieu K ACZMAREK : Elf et virologie informatique. http://vxheavens.com/lib/vmk00.html.
[20] L33 CKMA : Le format elf : approche du point de vue d’un infecteur. http://l33ckma.tuxfamily.org/?p=
15.
[21] Lycée Henri L ORITZ : Les diodes. http://www.ac-nancy-metz.fr/pres-etab/loritz/pre_bac/
ssi/cours/electronique/Diodes/diode.htm.
48
BIBLIOGRAPHIE
BIBLIOGRAPHIE
[22] Frédéric
M ORAIN -N ICOLIER
:
Détection
de
motifs
:
exploitation
de
la
phase
(suite
de
l’inter-corrélation).
http://pixel-shaker.fr/fr/2008/12/
detection-de-motifs-exploitation-de-la-phase-suite-de-linter-correlation/
#toc-localisation-du-motif-dans-limage.
[23] Adaptateur VGA "S YNC -O N -G REEN ".
[24] Pier Luc P ETITCLERC : Gnu diff & gnu patch : How to apply product patches.
[25] Benjamin ROUX : Ecriture de driver sous linux grâce au langage c. http://broux.developpez.com/
articles/c/driver-c-linux/.
[26] Jean-Michel Friedt S IMON G UINOT : réception d’images satellites : utilisation d’un système embarqué. http:
//www.unixgarden.com/index.php/embarque/reception-d%E2%80%99images-satellites%
C2%A0-utilisation-d%E2%80%99un-systeme-embarque.
[27] Javier VALCARCE : Tv video signal generator with arduino. http://www.javiervalcarce.eu/wiki/TV_
Video_Signal_Generator_with_Arduino, April 2009.
[28] W IKIPEDIA : Video graphics array — wikipedia, the free encyclopedia, 2010. [Online ; accessed 5-February-2010].
[29] W IKIPEDIA : Gerber file — wikipedia, the free encyclopedia, 2010. [Online ; accessed 9-February-2010].
[30] W IKIPEDIA : Flash memory — wikipedia, the free encyclopedia, 2010. [Online ; accessed 15-February-2010].
[31] W IKIPEDIA : Types of capacitor — wikipedia, the free encyclopedia, 2010. [Online ; accessed 10-February-2010].
[32] W IKIPEDIA : Organic led — wikipedia, the free encyclopedia, 2010. [Online ; accessed 26-February-2010].
[33] W IKIPEDIA : Block (data storage) — wikipedia, the free encyclopedia, 2009. [Online ; accessed 15-February-2010].
[34] W IKIPÉDIA : Processeur arm — wikipédia, l’encyclopédie libre, 2010. [En ligne ; Page disponible le 07-avril-2010].
[35] W IKIPÉDIA : Noyau de système d’exploitation — wikipédia, l’encyclopédie libre, 2010. [En ligne ; Page disponible
le 4-février-2010].
[36] W IKIPÉDIA : Serial peripheral interface — wikipédia, l’encyclopédie libre, 2010. [En ligne ; Page disponible le
5-février-2010].
[37] W IKIPÉDIA : Multitâche préemptif — wikipédia, l’encyclopédie libre, 2010. [En ligne ; Page disponible le 11-février2010].
[38] W IKIPÉDIA : Grep — wikipédia, l’encyclopédie libre, 2010. [En ligne ; Page disponible le 17-février-2010].
[39] W IKIPÉDIA : Polarisation (optique) — wikipédia, l’encyclopédie libre, 2010. [En ligne ; Page disponible le 26-février2010].
[40] W IKIPÉDIA : Phase (onde) — wikipédia, l’encyclopédie libre, 2010. [En ligne ; Page disponible le 26-février-2010].
[41] W IKIPÉDIA : Champ électrique — wikipédia, l’encyclopédie libre, 2010. [En ligne ; Page disponible le 26-février2010].
[42] W IKIPÉDIA : Diode électroluminescente organique — wikipédia, l’encyclopédie libre, 2010. [En ligne ; Page disponible le 26-février-2010].
[43] W IKIPÉDIA : Écran à cristaux liquides — wikipédia, l’encyclopédie libre, 2010. [En ligne ; Page disponible le 26février-2010].
[44] W IKIPÉDIA : Ordonnancement dans les systèmes d’exploitation — wikipédia, l’encyclopédie libre, 2010. [En ligne ;
Page disponible le 17-mars-2010].
[45] Lcd controller & driver ics. http://www.tstonramp.com/~pddwebacc/lcd_ics.htm.
[46] Arduino wire library. http://arduino.cc/en/Reference/Wire, 2010.
[47] Le format elf. http://asm-x86.fr/le-format-elf_a8.
[48] Créer un fichier elf sans même gnu/ld. http://www.les-ziboux.rasama.org/elf-without-ld.html.
[49] La gestion de la mémoire. http://www.commentcamarche.net/contents/systemes/memoire.php3.
[50] La mémoire virtuelle. http://cui.unige.ch/~billard/systemeII/cours6.html.
[51] Platform devices and drivers. http://www.mjmwired.net/kernel/Documentation/driver-model/
platform.txt.
49
BIBLIOGRAPHIE
[52] Overview of linux kernel spi support.
spi-summary.
BIBLIOGRAPHIE
http://www.mjmwired.net/kernel/Documentation/spi/
[53] The linux kernel api. http://www.kernel.org/doc/htmldocs/kernel-api/index.html.
[54] Rgb video out. http://www.eecg.toronto.edu/~tm4/rgbout.html.
[55] Mx2 framebuffer driver. http://www.linux-fbdev.org/HOWTO/index.html.
[56] Le logiciel buildroot. http://buildroot.uclibc.org/.
[57] Créer et lancer une application au format elf à partir du système de fichier. http://a.michelizza.free.fr/
pmwiki.php?n=TutoOS.Elf.
[58] Eagle 3d. http://www.matwei.de/doku.php?id=en:eagle3d:eagle3d, 2010.
50
ANNEXE A. THE GNU GENERAL PUBLIC LICENCE
A
The GNU General Public Licence
The following is the text of the GNU General Public Licence, under the terms of which this software is distrubuted.
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
675 Mass Ave, Cambridge, MA 02139, USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
A.1
Preamble
The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU
General Public License is intended to guarantee your freedom to share and change free software—to make sure the software
is free for all its users. This General Public License applies to most of the Free Software Foundation’s software and to any
other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU
Library General Public License instead.) You can apply it to your programs, too.
When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to
make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you
receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs ;
and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender
the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you
modify it.
For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the
rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these
terms so they know their rights.
We protect your rights with two steps : (1) copyright the software, and (2) offer you this license which gives you legal
permission to copy, distribute and/or modify the software.
Also, for each author’s protection and ours, we want to make certain that everyone understands that there is no warranty
for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what
they have is not the original, so that any problems introduced by others will not reflect on the original authors’ reputations.
Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of
a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have
made it clear that any patent must be licensed for everyone’s free use or not licensed at all.
The precise terms and conditions for copying, distribution and modification follow.
A.2
Terms and conditions for copying, distribution and modification
0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may
be distributed under the terms of this General Public License. The “Program”, below, refers to any such program or
work, and a “work based on the Program” means either the Program or any derivative work under copyright law : that
is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into
another language. (Hereinafter, translation is included without limitation in the term “modification”.) Each licensee is
addressed as “you”.
Activities other than copying, distribution and modification are not covered by this License ; they are outside its scope.
The act of running the Program is not restricted, and the output from the Program is covered only if its contents
51
A.2. TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION
ANNEXE
AND
A.MODIFICATION
THE GNU GENERAL PUBLIC LICENCE
constitute a work based on the Program (independent of having been made by running the Program). Whether that is
true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program’s source code as you receive it, in any medium, provided
that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of
warranty ; keep intact all the notices that refer to this License and to the absence of any warranty ; and give any other
recipients of the Program a copy of this License along with the Program.
You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection
in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program,
and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet
all of these conditions :
(a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of
any change.
(b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the
Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this
License.
(c) If the modified program normally reads commands interactively when run, you must cause it, when started
running for such interactive use in the most ordinary way, to print or display an announcement including an
appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty)
and that users may redistribute the program under these conditions, and telling the user how to view a copy of
this License. (Exception : if the Program itself is interactive but does not normally print such an announcement,
your work based on the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from
the Program, and can be reasonably considered independent and separate works in themselves, then this License, and
its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same
sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms
of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part
regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you ; rather,
the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on
the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this
License.
3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form
under the terms of Sections 1 and 2 above provided that you also do one of the following :
(a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under
the terms of Sections 1 and 2 above on a medium customarily used for software interchange ; or,
(b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than
your cost of physically performing source distribution, a complete machine-readable copy of the corresponding
source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for
software interchange ; or,
(c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This
alternative is allowed only for noncommercial distribution and only if you received the program in object code
or executable form with such an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for making modifications to it. For an executable
work, complete source code means all the source code for all modules it contains, plus any associated interface
definition files, plus the scripts used to control compilation and installation of the executable. However, as a special
exception, the source code distributed need not include anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs,
unless that component itself accompanies the executable.
52
A.2. TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION
ANNEXE
AND
A.MODIFICATION
THE GNU GENERAL PUBLIC LICENCE
If distribution of executable or object code is made by offering access to copy from a designated place, then offering
equivalent access to copy the source code from the same place counts as distribution of the source code, even though
third parties are not compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any
attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your
rights under this License. However, parties who have received copies, or rights, from you under this License will not
have their licenses terminated so long as such parties remain in full compliance.
5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission
to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept
this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate
your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the
Program or works based on it.
6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a
license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You
may not impose any further restrictions on the recipients’ exercise of the rights granted herein. You are not responsible
for enforcing compliance by third parties to this License.
7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to
patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the
conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to
satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence
you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution
of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy
both it and this License would be to refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the
section is intended to apply and the section as a whole is intended to apply in other circumstances.
It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest
validity of any such claims ; this section has the sole purpose of protecting the integrity of the free software distribution
system, which is implemented by public license practices. Many people have made generous contributions to the wide
range of software distributed through that system in reliance on consistent application of that system ; it is up to the
author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot
impose that choice.
This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted
interfaces, the original copyright holder who places the Program under this License may add an explicit geographical
distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus
excluded. In such case, this License incorporates the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to
time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems
or concerns.
Each version is given a distinguishing version number. If the Program specifies a version number of this License which
applies to it and “any later version”, you have the option of following the terms and conditions either of that version
or of any later version published by the Free Software Foundation. If the Program does not specify a version number
of this License, you may choose any version ever published by the Free Software Foundation.
10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different,
write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to
the Free Software Foundation ; we sometimes make exceptions for this. Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software
generally.
NO WARRANTY
11. Because the Program is licensed free of charge, there is no warranty for the Program, to the extent permitted
by applicable law. except when otherwise stated in writing the copyright holders and/or other parties provide
53
A.3. APPENDIX : HOW TO APPLY THESE TERMS TO YOUR
ANNEXE
NEW PROGRAMS
A. THE GNU GENERAL PUBLIC LICENCE
the program “as is” without warranty of any kind, either expressed or implied, including, but not limited to,
the implied warranties of merchantability and fitness for a particular purpose. The entire risk as to the quality
and performance of the Program is with you. Should the Program prove defective, you assume the cost of all
necessary servicing, repair or correction.
12. In no event unless required by applicable law or agreed to in writing will any copyright holder, or any other
party who may modify and/or redistribute the program as permitted above, be liable to you for damages,
including any general, special, incidental or consequential damages arising out of the use or inability to use the
program (including but not limited to loss of data or data being rendered inaccurate or losses sustained by you
or third parties or a failure of the Program to operate with any other programs), even if such holder or other
party has been advised of the possibility of such damages.
END OF TERMS AND CONDITIONS
A.3
Appendix : How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve
this is to make it free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most
effectively convey the exclusion of warranty ; and each file should have at least the “copyright” line and a pointer to where
the full notice is found.
<one line to give the program’s name and a brief idea of what it does.>
Copyright (C) 19yy <name of author>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this when it starts in an interactive mode :
Gnomovision version 69, Copyright (C) 19yy name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type ‘show w’.
This is free software, and you are welcome to redistribute it
under certain conditions; type ‘show c’ for details.
The hypothetical commands ‘show w’ and ‘show c’ should show the appropriate parts of the General Public License. Of
course, the commands you use may be called something other than ‘show w’ and ‘show c’ ; they could even be mouse-clicks
or menu items–whatever suits your program.
You should also get your employer (if you work as a programmer) or your school, if any, to sign a “copyright disclaimer”
for the program, if necessary. Here is a sample ; alter the names :
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
‘Gnomovision’ (which makes passes at compilers) written by James Hacker.
54
A.3. APPENDIX : HOW TO APPLY THESE TERMS TO YOUR
ANNEXE
NEW PROGRAMS
A. THE GNU GENERAL PUBLIC LICENCE
<signature of Ty Coon>, 1 April 1989
Ty Coon, President of Vice
This General Public License does not permit incorporating your program into proprietary programs. If your program is a
subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what
you want to do, use the GNU Library General Public License instead of this License.
55
ANNEXE B. CODE SOURCES
B
B.1
Code sources
Module Noyau
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
/*
*
*
*
*
*
*
*
*
*/
Display Driver for hx5116 controler for AMOLED
Copyright (c) 2009 Fabien Marteau - ARMadeus Systems
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License version 2 as
published by the Free Software Foundation.
#include
#include
#include
#include
#include
#include
#include
<linux/module.h>
<linux/kernel.h>
<linux/init.h>
<linux/platform_device.h>
<linux/mutex.h>
<linux/fb.h>
<linux/delay.h>
#include <linux/display.h>
#include <linux/spi/spi.h>
#include
#include
#include
#include
<linux/version.h>
<mach/imxfb.h>
<mach/hardware.h>
<mach/gpio.h>
/* Backlight machinfo struct is defined here */
#include <video/LCD_TS.h>
#define DRIVER_NAME
" lcd_ts "
#define DRIVER_VERSION " 0 . 1 "
static int lcd_ts_write(struct lcd_ts * lcd_ts_dev,u8 address, u16 data){
u8 command[2];
int ret;
/* Address */
command[0] = (address << 1) | HX5116_SPI_WRITE;
command[1] = data;
ret = spi_write(lcd_ts_dev->spi, command, 2);
if (ret < 0)
printk("ERROR : c a n ’ t w r i t e on hx5116 \ n ");
}
static int lcd_ts_init_screen( struct lcd_ts * lcd_ts_dev){
/* gpio_set_value(lcd_ts_dev->resetpin,1); */
/* initial procedure for 24-bit
lcd_ts_write (lcd_ts_dev, 0x04,
lcd_ts_write (lcd_ts_dev, 0x05,
lcd_ts_write (lcd_ts_dev, 0x07,
lcd_ts_write (lcd_ts_dev, 0x34,
lcd_ts_write (lcd_ts_dev, 0x35,
lcd_ts_write (lcd_ts_dev, 0x36,
lcd_ts_write (lcd_ts_dev, 0x37,
lcd_ts_write (lcd_ts_dev, 0x02,
lcd_ts_write (lcd_ts_dev, 0x0A,
lcd_ts_write (lcd_ts_dev, 0x09,
lcd_ts_write (lcd_ts_dev, 0x10,
lcd_ts_write (lcd_ts_dev, 0x11,
lcd_ts_write (lcd_ts_dev, 0x12,
lcd_ts_write (lcd_ts_dev, 0x13,
lcd_ts_write (lcd_ts_dev, 0x14,
parallel RGB (DE) */
0x23); /*set display mode 24-bit parallel RGB (DE)*/
0x82); /*set display mode*/
0x0F); /*set driver capability*/
0x18); /*set display timing*/
0x28); /*set display timing*/
0x16); /*set display timing*/
0x01); /*set display timing*/
0x02); /*OTP On*/
0x79); /*VGHVGL=+/-6V*/
0x20); /*VGAM1OUT=4.85V*/
0x6A); /*set R slop*/
0x6A); /*set G slop*/
0x68); /*set B slop*/
0x00); /*set R_0*/
0x04); /*set R_10*/
56
B.1. MODULE NOYAU
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
lcd_ts_write
ANNEXE B. CODE SOURCES
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
(lcd_ts_dev,
0x15,
0x16,
0x17,
0x18,
0x19,
0x1A,
0x1B,
0x1C,
0x1D,
0x1E,
0x1F,
0x20,
0x21,
0x22,
0x23,
0x24,
0x25,
0x26,
0x27,
0x28,
0x29,
0x2A,
0x06,
0x05);
0x05);
0x04);
0x03);
0x02);
0x02);
0x00);
0x06);
0x05);
0x06);
0x06);
0x05);
0x05);
0x07);
0x00);
0x07);
0x06);
0x07);
0x07);
0x06);
0x04);
0x07);
0x03);
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
/*set
R_36*/
R_80*/
R_124*/
R_168*/
R_212*/
R_255*/
G_0*/
G_10*/
G_36*/
G_80*/
G_124*/
G_168*/
G_212*/
G_255*/
G_0*/
B_10*/
B_36*/
B_80*/
B_124*/
B_168*/
B_212*/
B_255*/
display on*/
/* gpio_set_value(lcd_ts_dev->resetpin,1);*/
}
static int lcd_ts_probe (struct spi_device *spi_device){
printk("LCD SPI Bus R e g i s t r a t i o n \ n ");
struct lcd_ts *lcd_data;
int err = -EINVAL;
lcd_data = (struct lcd_ts *)(spi_device->dev.platform_data);
lcd_data->init(spi_device); /* Initialise GPIO */
lcd_data->spi = spi_device;
lcd_data->spi->mode = SPI_MODE_0;
lcd_data->spi->bits_per_word = 8;
lcd_data->spi->dev.power.power_state = PMSG_ON;
err = spi_setup(lcd_data->spi);
printk(" R e n v o i e du s e t u p %i \ n ",err);
lcd_ts_init_screen(lcd_data);
return 0;
}
static int lcd_ts_remove(struct spi_device *spi_device){
struct lcd_ts * lcd_data ;
lcd_data = (struct lcd_ts * )(spi_device->dev.platform_data);
lcd_data->exit(spi_device); /* Free GPIO */
/* Init Sequence */
lcd_data->reset(0);
return 0;
}
static int lcd_ts_shutdown(struct spi_device *spi_device){
return 0;
}
static int lcd_ts_suspend(struct spi_device *spi_device){
return 0;
}
static int lcd_ts_resume(struct spi_device *spi_device){
return 0;
}
static struct spi_driver lcd_ts_driver = {
57
B.2. CODE D’ESSAI SDL - FRACTALE DE MANDELBROT
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
B.2
.probe
.remove
.shutdown
.suspend
.resume
.driver
.name
.owner
},
=
=
=
=
=
=
=
=
ANNEXE B. CODE SOURCES
lcd_ts_probe,
lcd_ts_remove,
lcd_ts_shutdown,
lcd_ts_suspend,
lcd_ts_resume,
{
DRIVER_NAME,
THIS_MODULE,
};
static int __init lcd_ts_init(void)
{
printk(" L o a d i n g LCD D r i v e r module \ n ");
int i;
i = spi_register_driver(&lcd_ts_driver);
printk(" R e n v o i e : %i \ n ",i);
return i;
}
static void __exit lcd_ts_exit(void)
{
printk(" U n l o a d i n g LCD D r i v e r module \ n ");
spi_unregister_driver(&lcd_ts_driver);
}
module_init(lcd_ts_init);
module_exit(lcd_ts_exit);
MODULE_AUTHOR("HEINRICH Y a n n i c k < y a g e e k @ f r e e . f r > ");
MODULE_DESCRIPTION(" HX5116 AMOLED D r i v e r ");
MODULE_LICENSE("GPL");
Code d’essai SDL - Fractale de MandelBrot
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
/*
============================================================================
Name
: Mandel.c
Author
: HEINRICH Yannick
Version
: 1
Copyright
: GPL
Description : Mandelbrot elements C, Ansi-style
============================================================================
*/
#include <stdio.h>
#include <stdlib.h>
#include<SDL/SDL.h>
/*
* DEFINE
*/
#define MAX_ITER 1000
#define WIDTH 1024
#define HEIGHT 768
#define XORIGIN WIDTH/2
#define YORIGIN HEIGHT/2
/*
* Variables
*/
SDL_Surface *ecran;
void pause()
{
int continuer = 1;
SDL_Event event;
while (continuer)
{
SDL_WaitEvent(&event);
switch(event.type)
58
B.2. CODE D’ESSAI SDL - FRACTALE DE MANDELBROT
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
ANNEXE B. CODE SOURCES
{
case SDL_QUIT:
continuer = 0;
}
}
}
void affAxis(SDL_Surface * ecran){
SDL_Rect rect;
rect.w = 1;
rect.h = 1;
int i;
/*
* Vertical AXIS
*/
rect.y = YORIGIN;
for(i=0;i< WIDTH;i++){
rect.x = i;
SDL_FillRect(ecran,&rect,SDL_MapRGB(ecran->format,255,0,0));
}
/*
* HORIZONTAL AXIS
*/
rect.x = XORIGIN;
for(i=0;i < HEIGHT;i++){
rect.y = i;
SDL_FillRect(ecran,&rect,SDL_MapRGB(ecran->format,255,0,0));
}
}
int main(void) {
/*
* SDL INIT
*/
if (SDL_Init(SDL_INIT_VIDEO) == -1) // Demarrage de la SDL. Si erreur alors...
{
fprintf(stderr, " E r r e u r d ’ i n i t i a l i s a t i o n de l a SDL : %s \ n ", SDL_GetError());
// Ecriture de l’erreur
75
exit(EXIT_FAILURE); // On quitte le programme
76
}
77
78
ecran = SDL_SetVideoMode(WIDTH, HEIGHT, 32, SDL_HWSURFACE);
79
SDL_WM_SetCaption(" Mandel v0 . 1 ",NULL);
80
81
/*
82
* SDL Color
83
*/
84
Uint32 blackcolor = SDL_MapRGB(ecran->format,0,0,0);
85
Uint32 itercolor;
86
SDL_Rect rect;
87
rect.h = 1;
88
rect.w = 1;
89
90
/*
91
* Mandelbrot program
92
*/
93
double xtemp,x,y,xp,yp,factor;
94
int i,j,iter;
95
96
/*
97
* Scale Factor
98
*/
99
factor = 200.0;
100
for(i=0; i< WIDTH;i++){
101
for(j=0;j< HEIGHT;j++){
102
//Start with 0;
103
x=0;
104
y=0;
105
iter=0;
106
xp = (i - XORIGIN)/factor;
107
yp = (j - YORIGIN)/factor;
108
while((x*x + y*y <= 4) && iter < MAX_ITER){
109
xtemp = x*x - y*y +xp;
110
y = 2*x*y + yp;
111
x = xtemp;
59
B.3. AJOUT DE LA LIBRAIRIE CWIID DANS BUILDROOT
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132 }
B.3
ANNEXE B. CODE SOURCES
iter++;
}
//printf("Point (%i,%i) - Iterations %i\n",i,j,iter);
rect.x = i;
rect.y = j;
if(iter == MAX_ITER) SDL_FillRect(ecran,&rect,blackcolor);
else{
itercolor = SDL_MapRGB(ecran->format,0,0,iter*30);
SDL_FillRect(ecran,&rect,itercolor);
}
}
}
//affAxis(ecran);
SDL_Flip(ecran);
pause();
SDL_Quit();
return EXIT_SUCCESS;
Ajout de la librairie CWIID dans buildroot
Le code suivant présente le fichier makefile nécessaire au rajout de la librarie CWIID au sein de la carte embarquée, ainsi
que les patchs nécessaires. Elle se base sur la pile officiel de Linux pour la gestion des protocoles Buettoth (BlueZ).
B.3.1
libcwiid.mk
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
#############################################################
#
# libcwiid
#
#############################################################
CWIID_VERSION:=0.6.00
CWIID_SOURCE:=cwiid-$(CWIID_VERSION).tgz
CWIID_SITE:=http://abstrakraft.org/cwiid/downloads
CWIID_DIR:=$(BUILD_DIR)/cwiid-$(CWIID_VERSION)
$(DL_DIR)/$(CWIID_SOURCE):
$(call DOWNLOAD,$(CWIID_SITE),$(CWIID_SOURCE))
$(CWIID_DIR)/.source: $(DL_DIR)/$(CWIID_SOURCE)
$(ZCAT) $(DL_DIR)/$(CWIID_SOURCE) | tar -C $(BUILD_DIR) $(TAR_OPTIONS) touch $@
$(CWIID_DIR)/.patched: $(CWIID_DIR)/.source
toolchain/patch-kernel.sh $(CWIID_DIR) package/libcwiid *.patch
#
$(CONFIG_UPDATE) $(CWIID_DIR)
touch $@
$(CWIID_DIR)/.configured: $(CWIID_DIR)/.patched
(cd $(CWIID_DIR); rm -rf config.cache;autoconf; \
$(TARGET_CONFIGURE_OPTS) \
$(TARGET_CONFIGURE_ARGS) \
./configure \
--target=$(GNU_TARGET_NAME)\
--host=$(GNU_TARGET_NAME) \
--build=$(GNU_HOST_NAME)\
--prefix=$(STAGING_DIR)/usr \
--sysconfdir=$(STAGING_DIR)/etc \
--disable-ldconfig\
--without-python ;\
)
touch $@
$(CWIID_DIR)/.compiled: $(CWIID_DIR)/.configured
$(MAKE1) CC=$(TARGET_CC) CC_FOR_BUILD=" $ (HOSTCC) " -C $(CWIID_DIR)
touch $@
60
B.3. AJOUT DE LA LIBRAIRIE CWIID DANS BUILDROOT
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
B.3.2
libcwiid cwiid: uclibc $(STAGING-DIR)/usr/lib/libcwiid.so
libcwiid-clean cwiid-clean:
$(MAKE) DESTDIR=$(TARGET_DIR) CC=$(TARGET_CC) -C $(CWIID_DIR) uninstall
-$(MAKE) -C $(SDL_DIR) clean
libcwiid-dirclean cwiid-dirclean:
rm -rf $(CWIID_DIR)
#############################################################
#
# Toplevel Makefile options
#
#############################################################
ifeq ($(strip $(BR2_PACKAGE_LIBCWIID)),y)
TARGETS+=cwiid
endif
configure_.patch
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
B.3.3
ANNEXE B. CODE SOURCES
$(STAGING-DIR)/usr/lib/libcwiid.so: $(CWIID_DIR)/.compiled
$(MAKE) -C $(CWIID_DIR) install
cp -dpf $(STAGING_DIR)/usr/lib/libcwiid*.so* $(TARGET_DIR)/usr/lib/
--- cwiid-0.6.00.org/configure.ac
2007-08-27 02:27:58.000000000 +0200
+++ cwiid-0.6.00/configure.ac
2010-03-01 17:28:00.425401362 +0100
@@ -124,11 +124,6 @@ else
fi
AC_SUBST(LDCONFIG)
-pkg_modules=" g t k + −2.0 >= 2 . 0 . 0 g t h r e a d −2.0 "
-PKG_CHECK_MODULES([GTK], [$pkg_modules])
-AC_SUBST(GTK_CFLAGS)
-AC_SUBST(GTK_LIBS)
AC_OUTPUT(
[Makefile]
[defs.mak]
@@ -137,7 +132,6 @@ AC_OUTPUT(
[man/Makefile]
[libcwiid/Makefile]
[wmdemo/Makefile]
[wmgui/Makefile]
[wminput/Makefile]
[wminput/plugins/Makefile]
[wminput/plugins/ir_ptr/Makefile]
makefile_in.patch
1
2
3
4
5
6
7
8
9
10
11
--- cwiid-0.6.00.org/Makefile.in
2007-07-28 20:47:03.000000000 +0200
+++ cwiid-0.6.00/Makefile.in
2010-03-01 17:28:08.337399709 +0100
@@ -3,7 +3,7 @@
include @top_builddir@/defs.mak
LIB_DIRS = libcwiid
-BIN_DIRS = wmgui wminput lswm
+BIN_DIRS = wminput lswm
DOC_DIRS = man doc
ifdef PYTHON
BIND_DIRS = python
61