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 Enginee- ring. 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 AMO- LED 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 5
4.1 Historique . . . 5
4.2 Le groupe Technology & Strategy . . . 5
4.3 Quelques chiffres . . . 6
4.3.1 Particularité de la division Engineering . . . 6
5 Présentation du sujet 7 5.1 Le laboratoire de R & D . . . 7
5.2 Projet Combi instrument & plateforme linux . . . 7
5.2.1 Cahiers des charges . . . 7
5.3 Cycle de développement et organisation dans le temps . . . 8
5.4 Outils mis à disposition . . . 8
6 Du processeur au noyau 11 6.1 Rôle d’un système d’exploitation . . . 11
6.2 Adressage mémoire . . . 13
6.2.1 Représentation . . . 13
6.2.2 Mode réel . . . 13
6.2.3 Mode protégé et segmentation . . . 13
6.2.4 Pagination . . . 15
6.2.5 Le mode noyau et le mode utilisateur . . . 16
6.3 Lancement d’un système . . . 16
6.4 Présentation de GNU . . . 17
6.5 Présentation de Linux . . . 18
6.5.1 Développement . . . 18
6.6 Un couple gagnant . . . 19
6.7 Linux et la mémoire . . . 19
6.8 Naviguer dans les sources du Noyau . . . 20
6.9 Les pilotes sous Linux 2.6 . . . 22
6.10 Le framebuffer . . . 22
7 Réalisation 23 7.1 Choix de la plateforme GNU/Linux . . . 23
7.1.1 Carte retenue . . . 23
7.2 Présentation de l’architecture ARM (32 bits) . . . 26
7.3 Composants logiciels . . . 26
7.3.1 Sur l’ordinateur . . . 26 1
1. CAHIERS DES CHARGES
7.3.2 Buildroot . . . 27
7.3.3 Sur la carte . . . 27
7.4 Interfaces avec la carte . . . 28
7.5 Écran AMOLED Tactile . . . 28
7.5.1 Interface RGB Parallèle . . . 30
7.5.2 Interface SPI "3-wire" . . . 31
7.5.3 Écriture du pilote . . . 31
7.5.4 Alimentation . . . 39
7.6 Conception de la carte . . . 40
7.6.1 Contraintes de routage . . . 40
7.6.2 Schéma . . . 41
7.6.3 Routage . . . 41
7.6.4 Soudure . . . 41
8 Conclusion 45 A The GNU General Public Licence 51 A.1 Preamble . . . 51
A.2 Terms and conditions for copying, distribution and modification . . . 51
A.3 Appendix : How to Apply These Terms to Your New Programs . . . 54
B Code sources 56 B.1 Module Noyau . . . 56
B.2 Code d’essai SDL - Fractale de MandelBrot . . . 58
B.3 Ajout de la librairie CWIID dans buildroot . . . 60
B.3.1 libcwiid.mk . . . 60
B.3.2 configure_.patch . . . 61
B.3.3 makefile_in.patch . . . 61
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 embar- qué 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 embar- qué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’ali- mentation, 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. PRÉSENTATION DE L’ENTREPRISE
4 Présentation de l’entreprise
4.1 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 Engineeringcentré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 Technologiesfocalisé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 Holdingqui assure les fonctions de gestions pour les deux autres sociétés (ressources hu- maines, administration centralisée, aspects financiers et gestion du personnel).
FIGURE1 – 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éeRheinBrücke Consultingconcentrée sur le conseil en milieu franco-allemand. Elle recherche des compétences bilingues par approche directe.
FIGURE2 – 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 éga- lement la plus grande en termes de création de valeurs et du nombre de collaborateurs.
FIGURE3 – 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.
5. PRÉSENTATION DU SUJET
5 Présentation du sujet
5.1 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).
FIGURE4 – 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 me- sures 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 :
FIGURE5 – 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.
!!"
!
" # $ %&
' ( '
# )*
)$+, ( (
# $ )-
%. #
! ($
/ 0
12324'1 12324'5
(6 7 76 8
% & '
&( % ) ) &) & ' ) * +, )- ( *. ' /01
3 #)'2! 3245 !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
1 #)'2! '67 "63 "83 5 2
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
5 #)'2! '45 " 3 " 3 5 2
563 #)'2! '45 " 3 " 3 5 2
56363 !!" #)'2! '45 " 3 " 3 5 2
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
9 # '68 !! !53 83 5 2
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
> / (63 (65 57 31;7 2 2
; 0 (63 7652 3527 2 2
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.
FIGURE6 – 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 proces- sus 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
FIGURE7 – L’ordonnanceur d’un noyau -Source : wikipédia
FIGURE8 – La gestion de la mémoire au sein d’un noyauSource : 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.
6.2. ADRESSAGE MÉMOIRE 6. DU PROCESSEUR AU NOYAU
6.2 Adressage mémoire
6.2.1 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).
FIGURE9 – 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 lec- ture/é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
FIGURE10 – Adressage en mode protégé
FIGURE11 – Représentation de la mémoire
6.2. ADRESSAGE MÉMOIRE 6. DU PROCESSEUR AU NOYAU 6.2.4 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 segmen- tation 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.
FIGURE12 – 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é.
FIGURE13 – 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 6. DU PROCESSEUR AU NOYAU tour stockée dans le swap.
6.2.5 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 pagina- tion 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.
FIGURE14 – 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.
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
FIGURE15 – 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éalisa- tion 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.
FIGURE16 – 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.
FIGURE17 – 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.
6.6. UN COUPLE GAGNANT 6. DU PROCESSEUR AU NOYAU
FIGURE18 – 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 minori- taire (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
FIGURE19 – Segmentation sous Linux
FIGURE20 – 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 I2C 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.
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
FIGURE21 – Les différents dossiers du noyau et le type de code qu’ils contiennent
FIGURE22 – Taille des différents répertoires -Source : Association Free Electrons
21
6.9. LES PILOTES SOUS LINUX 2.6 6. DU PROCESSEUR AU NOYAU
6.9 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 dy- namiquement 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éri- phé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.
FIGURE23 – Démarrage de knoppix avec framebuffer -Source : Wikipédia [6]
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 Choix de la plateforme GNU/Linux
7.1.1 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.
FIGURE24 – 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 processeurapf27et la carte de développementAPF27DevFull. 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
FIGURE25 – Les cartes de développement de l’APF27 et APF27Dev
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,256MB
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
FIGURE26 – 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. RÉALISATION
7.2 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’ins- tructions 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, STMi- croelectronics, 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, PTX- dist,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 OpenEmbedded Openwrt
Avantages Évolutif,puissant, configuration graphique,Géneraliste
Géneraliste Création de paquets
Inconvénients Gourmand en ressources, pas de paquets
Lourd, configuration avec des fi- chiers textes
Lourd, orienté IAD
7.3. COMPOSANTS LOGICIELS 7. RÉALISATION 7.3.2 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.
FIGURE27 – 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 automa- tiquement 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
FIGURE28 – 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 ap- pels 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
FIGURE29 – 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 écono- miser 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 cel- lules 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 Type
0x00000000 - 0x0009FFFF (640KB, incluant la NAND SPL et 384KB d’économie de mémoire pour les bloc défectueux)
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
FIGURE30 – 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 configuration115200 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
7.5. ÉCRAN AMOLED TACTILE 7. RÉALISATION
FIGURE31 – Liens entre les différentes mémoires
FIGURE32 – Utilisation de la carte sur le réseau
FIGURE33 – É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.
FIGURE34 – 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é.
FIGURE35 – 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).
7.5. ÉCRAN AMOLED TACTILE 7. RÉALISATION
FIGURE36 – 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
FIGURE37 – Chronogrammes des différents signaux de l’écran
7.5. ÉCRAN AMOLED TACTILE 7. RÉALISATION
FIGURE38 – SPI 3 wire
(a) Connexion des bus MOSI et MISO ensemble
(b) Émission de de 0xFF sur le bus pendant l’envoie
FIGURE39 – 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 7. RÉALISATION
12 .platform_data = &apf27_lcd_ts_config,
13 },
14 #endif /* LCD T&S */
15 };
16
17 /* .... */
18 #ifdef CONFIG_LCD_TS_MODULE 19
20 #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).
7.5. ÉCRAN AMOLED TACTILE 7. RÉALISATION – max_speed_hz : vitesse maximale du bus.
– 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 es- clave.
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 :
FIGURE40 – 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
