Projet de fin d études Technology & Strategy Engineering

Transcription

1 Projet de fin d études Technology & Strategy Engineering Sujet : Plateforme Linux & Combi Instrument. 1 Février Juillet 2010 Société : Technology & Strategy Engineering 4 avenue de la Paix Strasbourg Établissement : INSA Strasbourg 24 Boulevard de la Victoire Strasbourg Professeur référent : M. Boyer Bertrand Responsable : M. Roth Matthieu Étudiant : M. Heinrich Yannick

2 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

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

4 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 Historique Le groupe Technology & Strategy Quelques chiffres Particularité de la division Engineering Présentation du sujet Le laboratoire de R & D Projet Combi instrument & plateforme linux Cahiers des charges Cycle de développement et organisation dans le temps Outils mis à disposition Du processeur au noyau Rôle d un système d exploitation Adressage mémoire Représentation Mode réel Mode protégé et segmentation Pagination Le mode noyau et le mode utilisateur Lancement d un système Présentation de GNU Présentation de Linux Développement Un couple gagnant Linux et la mémoire Naviguer dans les sources du Noyau Les pilotes sous Linux Le framebuffer Réalisation Choix de la plateforme GNU/Linux Carte retenue Présentation de l architecture ARM (32 bits) Composants logiciels Sur l ordinateur

5 1. CAHIERS DES CHARGES Buildroot Sur la carte Interfaces avec la carte Écran AMOLED Tactile Interface RGB Parallèle Interface SPI "3-wire" Écriture du pilote Alimentation Conception de la carte Contraintes de routage Schéma Routage Soudure Conclusion 45 A The GNU General Public Licence 51 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 B Code sources 56 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

6 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

7 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

8 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 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). FIGURE 1 Le groupe Technology & Strategy 5

9 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 un groupe solide avec 3 entités bien distinctes. une croissance régulière du nombre de clients depuis un chiffre d affaire cumulé de 6,5 M d euros en 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

10 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). FIGURE 4 Les projets du laboratoire en 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 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

11 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 : FIGURE 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

12

13

14 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. FIGURE 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

15 6.1. RÔLE D UN SYSTÈME D EXPLOITATION 6. DU PROCESSEUR AU NOYAU FIGURE 7 L ordonnanceur d un noyau - Source : wikipédia FIGURE 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

16 6.2. ADRESSAGE MÉMOIRE 6. DU PROCESSEUR AU NOYAU 6.2 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). FIGURE 9 Représentation de la mémoire 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 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

17 6.2. ADRESSAGE MÉMOIRE 6. DU PROCESSEUR AU NOYAU FIGURE 10 Adressage en mode protégé FIGURE 11 Représentation de la mémoire 14

18 6.2. ADRESSAGE MÉMOIRE 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. FIGURE 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é. FIGURE 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

19 6.3. LANCEMENT D UN SYSTÈME 6. DU PROCESSEUR AU NOYAU tour stockée dans le swap 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. FIGURE 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

20 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 FIGURE 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. FIGURE 16 Logo de GNU - Source : wikipédia 17

21 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 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 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. FIGURE 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 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 : ,

22 6.6. UN COUPLE GAGNANT 6. DU PROCESSEUR AU NOYAU FIGURE 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 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

23 6.8. NAVIGUER DANS LES SOURCES DU NOYAU 6. DU PROCESSEUR AU NOYAU FIGURE 19 Segmentation sous Linux FIGURE 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 I 2 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

24 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 FIGURE 21 Les différents dossiers du noyau et le type de code qu ils contiennent FIGURE 22 Taille des différents répertoires - Source : Association Free Electrons 21

25 6.9. LES PILOTES SOUS LINUX 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 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 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. FIGURE 23 Démarrage de knoppix avec framebuffer - Source : Wikipédia [6] 22

26 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 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. FIGURE 24 Logo de l entreprise Armadeus 23

27 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 FIGURE 25 Les cartes de développement de l APF27 et APF27Dev 24

28 7.1. CHOIX DE LA PLATEFORME GNU/LINUX 7. RÉALISATION Carte processeur APF27 [9] Processeur Freescale i.mx27 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 FIGURE 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

29 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 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 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. Avantages Buildroot OpenEmbedded Openwrt Évolutif,puissant, configuration graphique,géneraliste Inconvénients Gourmand en ressources, pas de paquets Géneraliste Lourd, configuration avec des fichiers textes Création de paquets Lourd, orienté IAD 26

30 7.3. COMPOSANTS LOGICIELS 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. FIGURE 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 Sur la carte Les composants utilisés sur la plateforme sont répertoriés dans le tableau suivant : Bootloader Noyau Librarie Shell Compilateur Système de fichier U-Boot Linux uclibc Busybox GCC jffs2 FIGURE 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

31 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 FIGURE 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 0x x0009FFFF (640KB, incluant la NAND SPL et 384KB d économie de mémoire pour les bloc défectueux) 0x000A0000-0x000FFFFF (384KB) 0x x0017FFFF (512KB) 0x x0067FFFF (5MB) 0x Limite de la FLASH Type U-Boot Variables d environnement U-BOOT FPGA bitfile Image du noyau Linux Système de fichiers racine FIGURE 30 Répartition des différents composants au sein de la RAM de l APF 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 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

32 7.5. ÉCRAN AMOLED TACTILE 7. RÉALISATION FIGURE 31 Liens entre les différentes mémoires FIGURE 32 Utilisation de la carte sur le réseau FIGURE 33 Écran P0430WQLB-T de la société Densitron 29

33 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. FIGURE 34 Interface de la puce HX 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é. FIGURE 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

34 7.5. ÉCRAN AMOLED TACTILE 7. RÉALISATION FIGURE 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 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 É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

35 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 FIGURE 37 Chronogrammes des différents signaux de l écran 32

36 7.5. ÉCRAN AMOLED TACTILE 7. RÉALISATION FIGURE 38 SPI 3 wire (a) Connexion des bus MOSI et MISO ensemble (b) Émission de de 0xFF sur le bus pendant l envoie FIGURE 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 = , /* 8MHz */ 10.bus_num = 2, /* SPI3 */ 11.chip_select = 0, 33

37 7.5. ÉCRAN AMOLED TACTILE 7. RÉALISATION 12.platform_data = &apf27_lcd_ts_config, 13 }, 14 #endif /* LCD T&S */ 15 }; /*... */ 18 #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) static int lcd_ts_pins [] ={ /* Pins en sortie */ 26 (NCSPIN GPIO_GPIO GPIO_OUT), 27 (RESETPIN GPIO_GPIO GPIO_OUT), }; static int lcd_ts_init(struct spi_device *spi){ 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" ); } static int lcd_ts_exit(struct spi_device *spi){ 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; } 49 static int lcd_ts_reset (int value){ 50 gpio_set_value(resetpin,value); 51 return 0; } 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 } static struct spi_imx_chip lcd_ts_hw = { 64.cs_control = lcd_ts_cs, 65 }; static struct lcd_ts apf27_lcd_ts_config = { init = lcd_ts_init, 70.exit = lcd_ts_exit, 71.reset = lcd_ts_reset, 72.ncspin = (int) NCSPIN, 73.resetpin = (int) RESETPIN, }; 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

38 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 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 : FIGURE 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

39 7.5. ÉCRAN AMOLED TACTILE 7. RÉALISATION 3 struct display_device * display_dev; 4 struct spi_device *spi ;/* SPI BUS */ 5 int (*init)(struct spi_device *spi); 6 int (*exit)(struct spi_device *spi); 7 int (*reset)(int value); 8 int ncspin; 9 int resetpin; 10 }; 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; 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(" Renvoie du s e t u p %i \ n ",err); lcd_ts_init_screen(lcd_data); 18 return 0; } 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

40 7.5. ÉCRAN AMOLED TACTILE 7. RÉALISATION FIGURE 41 Initialisation de l écran dans la documentation 37

41 7.5. ÉCRAN AMOLED TACTILE 7. RÉALISATION 21 lcd_ts_write (lcd_ts_dev, 0x15, 0x05); /*set R_36*/ 22 lcd_ts_write (lcd_ts_dev, 0x16, 0x05); /*set R_80*/ 23 lcd_ts_write (lcd_ts_dev, 0x17, 0x04); /*set R_124*/ 24 lcd_ts_write (lcd_ts_dev, 0x18, 0x03); /*set R_168*/ 25 lcd_ts_write (lcd_ts_dev, 0x19, 0x02); /*set R_212*/ 26 lcd_ts_write (lcd_ts_dev, 0x1A, 0x02); /*set R_255*/ 27 lcd_ts_write (lcd_ts_dev, 0x1B, 0x00); /*set G_0*/ 28 lcd_ts_write (lcd_ts_dev, 0x1C, 0x06); /*set G_10*/ 29 lcd_ts_write (lcd_ts_dev, 0x1D, 0x05); /*set G_36*/ 30 lcd_ts_write (lcd_ts_dev, 0x1E, 0x06); /*set G_80*/ 31 lcd_ts_write (lcd_ts_dev, 0x1F, 0x06); /*set G_124*/ 32 lcd_ts_write (lcd_ts_dev, 0x20, 0x05); /*set G_168*/ 33 lcd_ts_write (lcd_ts_dev, 0x21, 0x05); /*set G_212*/ 34 lcd_ts_write (lcd_ts_dev, 0x22, 0x07); /*set G_255*/ 35 lcd_ts_write (lcd_ts_dev, 0x23, 0x00); /*set G_0*/ 36 lcd_ts_write (lcd_ts_dev, 0x24, 0x07); /*set B_10*/ 37 lcd_ts_write (lcd_ts_dev, 0x25, 0x06); /*set B_36*/ 38 lcd_ts_write (lcd_ts_dev, 0x26, 0x07); /*set B_80*/ 39 lcd_ts_write (lcd_ts_dev, 0x27, 0x07); /*set B_124*/ 40 lcd_ts_write (lcd_ts_dev, 0x28, 0x06); /*set B_168*/ 41 lcd_ts_write (lcd_ts_dev, 0x29, 0x04); /*set B_212*/ 42 lcd_ts_write (lcd_ts_dev, 0x2A, 0x07); /*set B_255*/ 43 lcd_ts_write (lcd_ts_dev, 0x06, 0x03); /*set display on*/ /* gpio_set_value(lcd_ts_dev->resetpin,1);*/ 46 } 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 static int init lcd_ts_init(void) 2 { 3 printk(" Loading LCD D r i v e r module \ n "); 4 int i; 5 i = spi_register_driver(&lcd_ts_driver); 6 printk(" Renvoie : %i \ n ",i); 7 return i; 8 9 } static void exit lcd_ts_exit(void) 12 { 13 printk(" Unloading LCD D r i v e r module \ n "); 14 spi_unregister_driver(&lcd_ts_driver); } module_init(lcd_ts_init); 20 module_exit(lcd_ts_exit); MODULE_AUTHOR("HEINRICH Yannick <yageek@ free. f r >"); 23 MODULE_DESCRIPTION("HX5116 AMOLED D r i v e r "); 24 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

42 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. FIGURE 42 La fractale de Mandelbrot sur PC avec la librarie SDL 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

43 7.6. CONCEPTION DE LA CARTE 7. RÉALISATION FIGURE 43 Présentation du NCP 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 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)

44 7.6. CONCEPTION DE LA CARTE 7. RÉALISATION (a) Logo de eagle (b) Logo de Kicad FIGURE 44 Les deux logiciels de CAO utilisés Diamètre minimal des trous : Diamètre de foret = 0.2 mm (8mil) Schéma Le schématique de la carte n as pas changé entre les deux versions (cf Fig 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 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

45 7.6. CONCEPTION DE LA CARTE 7. RÉALISATION FIGURE 45 Schématique de la carte 42

46 7.6. CONCEPTION DE LA CARTE 7. RÉALISATION FIGURE 46 Première version de la carte 43

47 7.6. CONCEPTION DE LA CARTE 7. RÉALISATION (a) 2D (b) 3D FIGURE 47 Seconde version de la carte 44