UNIVERSITE DE BRETAGNE OCCIDENTALE

Transcription

1 UNIVERSITE DE BRETAGNE OCCIDENTALE DEPARTEMENT D INFORMATIQUE MASTER 2 LOGICIEL POUR SYSTEMES EMBARQUES Module Systèmes d Exploitation pour l Embarqué Exposé sur : Réalisé par : Encadreur : Akli AGUERCIF Jalil BOUKHOBZA

2 Table des matières Introduction Générale Chapitre I : Introduction aux Systèmes Embarqués I.1 Systèmes d exploitation embarqué... 7 I.2 Contraintes d un S.E... 7 I.2.1 Contraintes de temps... 7 I.2.2 Temps réel stricte... 7 I.2.3 Systèmes temps réel souple... 7 I.2.4 Performance temporelle... 8 I.2.5Consommation énergétique I.2.6 Mémoire... 8 I.2.7 Tolérance aux fautes... 8 I.3 Principaux types S.E I.5 Domaines d application des S.E Chapitre II : Linux et le monde de l embarqué II.1 Introduction II.2 Linux embarqué II.3 Le marché de l embarqué et le futur de linux embarqué II.4 Les offres linux embarqué II.5 Architecture logicielle d un système embarqué II.6 Systèmes linux embarqué existants Chapitre III : Etude et mise en œuvre de µclinux III.1 Historique de µclinux III.2 Présentation de µclinux III.3 Processeurs embarqué III.4 Fonctionnalités de la MMU III.5 Avantages et Inconvénients d un CPU sans MMU III.6 Portage de µclinux III.7 Limites de µclinux III.8 Caractéristiques de µclinux III.9 La plateforme µcsimm pour µclinux III.10 Mise en œuvre de µclinux III.11 Etape d installation de µclinux/coldfire III.12 Exemple d application du µclinux III.13 Description du système

3 III.14 Conclusion Conclusion Générale Bibliographie 3

4 LISTE DES FIGURES Figure 01 : Le développement de OSs Embarqués, En Figure 02 : Systèmes d exploitation pour les applications embarquées Figure 03 : Architecture d un Linux embarqué Figure 04 : Configuration du noyau µclinux/coldfire Figure 05 : Choix des applications (ici réseaux) µclinux/coldfire Figure 06 : système d'acquisition, traitement et restitution d'images Figure 07 : Système pour l'acquisition vidéo Figure 08 : Module VGA Lancelot

5 Introduction Comment ignorer aujourd hui le monde de l embarqué, véritable carrefour de métier ou se rencontre l électronique et le logiciel, dans une époque où il se vent chaque année plus de microcontrôleurs que de processeurs.dans ce monde bien à part, Linux prend une place toute particulière et quelle place, puisqu on le retrouve dans prêt de 50% de systèmes embarqués. Parmi les différents OS utilisés dans l embarqué, on retrouve en très bonne place le système Linux. L OS Linux (sous toutes les formes connues) occupe donc la part du lion. Sa gratuité et sa grande stabilité comptent pour beaucoup dans le choix des utilisateurs. Les distributions Linux les plus utilisées sont celle de µclinux (dite no MMU no FPU) et la distribution officielle issue du site kernel.org.ceci étant probablement du à sa réputation de très grande stabilité. On le retrouve notamment dans la plupart des firewall et autres routeurs. Ensuite viennent les versions «temps réel» de Linux. Ce rapport est une étude générale du système µclinux. 5

6 6

7 I-1 Système d exploitation Embarqué Le terme système embarqué dénote un système autonome, disposant de l'ensemble des éléments physiques nécessaires à son fonctionnement (processeur, mémoire, périphériques d'entrées/sorties) et en forte interaction avec l'environnement extérieur dans lequel il évolue. Les contraintes lors de la construction de tels systèmes sont relatives au temps, imposées par l'interaction du système avec son environnement, et aussi au caractère limité et/ou périssable des ressources dont dispose le système énergie, mémoire, bande passante des communications vers l'extérieur). À ces contraintes s'ajoutent des contraintes de sûreté de fonctionnement plus ou moins importantes selon le type d'utilisation du système embarqué. Initialement, les systèmes embarqués ont été utilisés pour des applications temps réel critique, de sûreté et/ou de sécurité, comme le contrôle des fusées, missiles, satellites ; la production d énergie ; le contrôle de vol ; les télécommunications. I-2 Contraintes d un S.E [EMB] Voici les contraintes les plus courantes la plupart du temps combinées - auxquelles le S.E. doit satisfaire : I-2-1 Contraintes de temps Beaucoup de systèmes embarqués interagissent directement avec leur environnement via des capteurs/actionneurs ou un réseau de communications sans fil. Ces interactions contraignent les temps de réponse du système embarqué de manière plus ou moins forte selon le domaine d'applications visé. On parle alors de système temps-réel, dans le sens où le temps de livraison des résultats d'un calcul fait partie intégrante de la spécification de ce dernier, au même titre que le résultat lui-même. I-2-2Temps-réel strict Dans les systèmes temps-réel strict, ou dur, le non respect des contraintes temporelles du système, le plus souvent exprimées sous la forme d'échéances de terminaison, constitue une défaillance de l'application. Dans le cadre d'applications critiques, telles que par exemple le contrôle de centrales nucléaires, une telle défaillance peut avoir des conséquences catastrophiques, telles que la mise en danger de vies humaines ou des pertes financières importantes. I-2-3 Systèmes temps-réel souple Dans les systèmes temps-réel souple, bien que l'instant de livraison d'un résultat soit important, la violation des contraintes temporelles du système est acceptable si elle reste rare. Cette tolérance est acceptée car les applications concernées ne relèvent pas du domaine des applications critiques. Les exemples typiques d'applications ayant des contraintes temps-réel souples sont les applications multimédias à flux continus. Le système vise au respect des contraintes temporelles dans la délivrance des flux de données afin de garantir la qualité des images et du son ; toutefois, les contraintes temporelles peuvent être adaptées puisque une dégradation de la qualité des données ne sera que faiblement perçue par l'utilisateur. L'ordonnancement des calculs dans les systèmes temps-réel souple est important car il contribue au respect des contraintes temporelles des tâches. Toutefois, contrairement aux systèmes temps-réel strict, la violation d'une échéance a des contraintes moins sévères. On a alors recours à des méthodes d'ordonnancement qui diffèrent de plusieurs points de vue. D'une part, les données temporelles exploitées pour déterminer quel calcul effectuer ne sont plus 7

8 nécessairement des données pire-cas ; on peut se contenter de connaître les caractéristiques temporelles du système de manière statistique. I-2-4 Performance temporelle À cause de la demande toujours croissante de puissance de traitement des applications, la performance globale temporelle du système embarqué est également un critère de conception important. Aussi, dans la conception d'un système embarqué la performance temporelle des mécanismes est une préoccupation constante. Au niveau logiciel ce travail porte à la fois sur les algorithmes afin de diminuer leur complexité, mais aussi sur l'optimisation des séquences fréquentes de code d'un mécanisme particulier. Parfois, l'utilisation de processeurs spécialisés peut également permettre d'atteindre la performance désirée. Une autre approche consiste à proposer un ordonnancement qui permette de réduire le temps de réponse des traitements temps-réel. Conjointement à ces travaux, le couplage fort des mécanismes de synchronisation à la stratégie d'ordonnancement (par exemple la gestion des sémaphores) contribue à diminuer ce temps de réponse. I-2-5 Consommation énergétique Une grande majorité des systèmes embarqués (téléphones cellulaires, ordinateurs de poche,...) sont confrontés au problème de l'autonomie. Aussi, afin d'étendre l'autonomie de fonctionnement d'un système deux approches complémentaires sont possibles : augmenter la capacité de stockage des batteries ou réaliser un système embarqué à faible consommation énergétique. Dans le cadre de cette dernière approche, plusieurs méthodes sont alors envisagées qui touchent à la fois le domaine de l'électronique et du logiciel. La conception de composants électroniques consommant le minimum d'énergie, l'optimisation du logiciel afin de diminuer le coût énergétique de son exécution, et enfin la conception de stratégies logicielles exploitant les fonctionnalités du matériel. Nous nous intéressons plus particulièrement aux deux dernières méthodes (méthodes logicielles). I-2-6 Mémoire La mémoire est une ressource limitée dans un grand nombre de systèmes embarqués (de quelques Kilo-octets dans une carte à puce à quelques Mégaoctets dans un téléphone portable), et par conséquent une bonne utilisation de la ressource mémoire est cruciale pour ces systèmes. Les méthodes permettant d'utiliser des systèmes à faible capacité mémoire vont de l'utilisation de codes interprétés compacts, comme par exemple le bytecode Java, à l'utilisation d'algorithmes de compression, en passant par des algorithmes d'allocation dynamique de mémoire optimisés pour limiter le morcellement de la mémoire, ou fragmentation. Une difficulté supplémentaire dans les systèmes embarqués est que la gestion de la mémoire soit compatible avec les contraintes temps-réel des applications, qu'elles soient souples ou strictes. Bien que de nombreux systèmes temps-réel se cantonnent à une gestion statique de la mémoire, quelques études récentes visent à utiliser des techniques de gestion de mémoire élaborées (allocation et libération automatique de mémoire - garbage collection, espaces d'adressages séparés) dans un contexte temps-réel embarqué. 8

9 I-2-7 Tolérance aux fautes Certains systèmes embarqués doivent pouvoir remplir leurs fonctions malgré la présence de fautes, qu'elles soient d'origine physique ou humaine. Les moyens pour la sûreté de fonctionnement, et plus spécifiquement les méthodes de tolérance aux fautes, permettant au système de remplir ses fonctions en dépit des fautes pouvant affecter ses composants, ont fait l'objet de travaux fournis dans les trente dernières années pour des systèmes généralistes. Par exemple, en ce qui concerne les fautes d'origine physique, il est nécessaire de détecter les erreurs, par l'utilisation de méthodes telles que les codes détecteur d'erreurs, les contrôles de vraisemblance ou encore le diagnostic en-ligne, puis d'effectuer un recouvrement d'erreur permettant au système de continuer à remplir ses fonctions malgré l'erreur, que ce soit par reprise de son exécution à partir d'un état sauvegardé au préalable (point de reprise) ou par compensation exploitant la redondance présente dans le système (par exemple la duplication active de tâches). Les difficultés issues du contexte embarqué sont relatives aux contraintes de temps des logiciels embarqués, ainsi qu'aux ressources limitées de l'architecture. Ceci contraint les types de méthodes de tolérance aux fautes utilisables dans un contexte embarqué temps-réel. En particulier, dans les systèmes temps-réel strict, il est nécessaire d'intégrer les mécanismes de tolérance aux fautes dans l'analyse d'ordonnançabilité du système. I-3 Principaux types de S.E On distingue en général 4 catégories de systèmes embarqués en fonction des contraintes auxquels ils doivent satisfaire: Les systèmes embarqués critiques Les systèmes embarqués grand public Les systèmes communicants Les capteurs embarqués, sachant naturellement qu un système réel combine parfois ces différentes caractéristiques. I-4 Domaine d application des S.E Désormais, les S.E. sont partie prenante de la très grande majorité des moyens, équipements, produits et réseaux actuels : Transport : (Automobile, Avion, Train, Espace ) Produits électriques/électroniques (caméra, télévision, système audio, GPS, téléphone cellulaire, console vidéo, Pda, ordinateur portable, machine-à-laver, micro-ondes ) Contrôle de processus continus ou discrets (production et distribution d électricité, production industrielle automatisée, optimisation de process de transformation, contrôle de machines-outils et de chaîne d assemblage, robotique, ) Télécommunications (satellites, téléphonie et vidéo mobiles, réseaux Wan, routeurs ) Sécurité (e-commerce, cartes à puce, authentification ) Santé (équipement, hospitalisation à domicile, appareils implantés, prothèses) Développement durable (éolienne, éclairage public, chauffage ) jouets et autres produits grand publics. 9

10 10

11 II-1 Introduction Linux depuis presque trois ans est en train de conquérir un domaine où on ne l attendait pas vraiment : l univers des systèmes embarqués. Pourquoi retrouve-t-on Linux dans l embarqué? Tout d abord pour ses qualités qu on lui reconnaît maintenant dans l environnement plus standard du PC grand public. Libre, disponible gratuitement au niveau source : pas de royalties à reverser. Ouvert. Différentes distributions proposées pour coller au mieux à un type d application. Stable et efficace. Aide rapide en cas de problèmes par la communauté Internet des développeurs Linux. Nombre de plus en plus important de logiciels disponibles. Connectivité Internet en standard. Linux a aussi d autres atouts très importants dans le domaine plus feutré des systèmes Embarqués. Linux embarqué supporte aussi différentes extensions Temps Réel qui mettent en place une couche d abstraction logique entre matériel, interruptions et Linux. II-2 Linux Embarqué [LIN] Linux embarqué est une adaptation du noyau Linux à un système embarqué. Suivant les capacités du système, on ne retrouve qu une partie des fonctionnalités du noyau : Moins de services disponibles. Moins de mémoire requise (< 8 Mo). Boot depuis une mémoire ROM. Pas de clavier ou de souris requis. Logiciels spéciaux pour piloter les périphériques du système (écran LCD, flash disk, Disk On Chip DOC, touch screen ). Une version de Linux embarqué peut être spécialement configurée pour coller à une plateforme ou application précise : Linux embarqué pour routeur IP. Linux embarqué sur PDA. Linux embarqué pour microcontrôleur sans MMU. Linux embarqué sur processeur et inférieur. II-3 Le marché de l'embarqué et le futur de Linux Embarqué [EMB] Le champ d'application des systèmes embarqués est très vaste. Le fait est d'ailleurs de plus en plus large. Car, tout d'abord, beaucoup de fonctions autrefois réalisé par des systèmes mécaniques ou analogiques sont aujourd'hui remplacées par des composants électroniques pilotés par des logiciels. De plus, grâce à la diffusion des téléphones portables, des assistants personnels de poche (PDA : Pocket Digital Assistant) et baladeurs MP3. L'embarqué paraît aujourd'hui indispensable dans le domaine portable. Les jeux en mobile sont téléchargés par des millions d'utilisateurs, on peut surfer sur le net, ou consulter des mails et utiliser des logiciels de comptabilité et de lecture multimédia. On peut dire que la mis d un système embarqué facilite à réaliser ces services. 11

12 Linux embarqué devient la principale plateforme de l'embarqué Figure 1 : Le développement de OSs Embarqués, En 2004 II-4 Les offres Linux Embarqué Les offres de version de Linux embarqué (et Temps Réel) peuvent être rangées dans l une des 3 catégories suivantes : Les distributions Linux classiques : RedHat, Mandrake,.. Suivant la quantité de mémoire disque du système embarqué. Les distributions Linux embarqué libres : Non TR : µclinux, Embedded Debian Project. TR : FSMLabs/RTLinux/free (ex OpenRTLinux GPL), RTAI La figure suivante illustre les différents systèmes d exploitation pour les applications embarquées Figure2 : Systèmes d exploitation pour les applications embarquées 12

13 II-5 Architecture logicielle d'un Linux Embarqué [LIV] L'architecture logicielle d'un Linux Embarqué est décrite par la figure suivante Figure 3 : Architecture d un Linux embarqué. II-6 Systèmes Linux Embarqué existants Voici, la liste de distributions concernant le «Embedded Linux». Lineo Embedix Lineo développe et vend des composants logiciels et des solutions de système embarqué en interaction avec Internet. Cette société possède 3 familles de produits : Embedix (Système d exploitation embarqué), Embrowser (embedded web browser) et de nombreuses technologies de l embarqué. Elle développe aussi les applications du temps réel à base de Linux. MontaVista Hard Hat Linux Hard Hat Linux est un produit commercial de la société Monta Vista qui s attache à faciliter le développement de système embarqué. Elle se concentre aux travaux pour améliorer les performances temps réel du noyau Linux. LEM Linux EMbedded est une petite distribution basée sur la Mandrake. Elle fait tenir sur moins de 8Mo un système complet contenant même XWindow. On peut ajouter le navigateur Netscape 4 et un serveur web. uclinux Une version libre de Linux qui ne possède pas l unité de gestion de mémoire (voir le chapitre suivant). 13

14 14

15 III-1 Historique de µclinux 1997 : µclinux est basé sur le noyau Linux version Février : µclinux est mis à jour avec le noyau Linux version : µclinux est mis à jour avec le noyau Linux version C est la version la plus employée (notée 2.0). Fin 2000 : µclinux est mis à jour avec le noyau Linux version : La bibliothèque C standard GNU libc utilisée par µclinux est réécrite et édulcorée pour prendre moins de place en mémoire :bibliothèque uclibc ( III-2 Présentation de µclinux [COL] µclinux est originellement un dérivé du noyau Linux 2.0 pour les microcontrôleurs sans MMU (Memory Management Unit) (février1998).le noyau uclinux permet l'utilisation de Linux sur des processeurs sans MMU. Les applications, qui fonctionnent parfaitement avec un noyau standard, peuvent écrire dans les parties de la mémoire réservées au kernel mais elles risquent de rencontrer certains problèmes. Le système d'exploitation uclinux est encore à son stade de développement. Il est le plus utilisé pour Linux Embarqué. µclinux se prononce "you-see-linux» : µc pour microcontrôleur. µclinux a été porté en premier lieu sur le microcontrôleur Motorola MC68328 DragonBall. Le premier système sous µclinux a été un ordinateur de poche 3Com PalmPilot using La maintenance de µclinux est assurée au départ par Rt-Control, à Toronto, Canada, racheté par Lineo, Inc puis Arcturus Networks Tous les portages µclinux suivant le type du processeur sont sous licence GPL. C est un logiciel libre. III-3 Processeur embarqué Les principales architectures : ARM, MIPS, PowerPC, x86 Une caractéristique que partage beaucoup de CPU embarquées est l absence de MMU (Memory Management Unit) III-4 Fonctionnalités de la MMU Traduction adressage virtuel-adressage physique : rend possible l utilisation d un swap. Protection matérielle des accès mémoire : des limites peuvent être définies par processus et en cas de violation le processeur génère une interruption. III-5 Avantages et Inconvénients d un CPU sans MMU [µcl] Avantages Simplicité du processeur : la surface du processeur est 30% plus réduite. Plus rapide : le changement de contexte n inclut pas la protection mémoire. Accès complet au matériel sans restriction Support e dans linux 2.6 de manière native. Inconvénients Pas de protection de la mémoire : un processus user peut corrompre tout le système. Debugage delicate. Pas de swap. Consommation importante de la mémoire qui devient fragmentée. 15

16 III-6 Portage de µclinux µclinux est porté sur les processeurs suivants : Motorola DragonBall (M68EZ328), M68328, M68EN322,ColdFire, QUICC (Quad Integrated Communications Controller). ARM7TDMI. MC68EN302. Axis ETRAX. Intel i960. PRISMA. III-7 Limites de µclinux L absence de MMU impose quelques limitations d usage par rapport à l environnement Linux La mémoire virtuelle n existe pas. L appel système fork() n'est pas supporté. Il faudra utiliser alors une implémentation de l appel système vfork() d UNIX. BSD (le processus parent est suspendu jusqu à ce que le processus fils appelle exec() ou exit() ). L appel système exec() ne peut pas charger actuellement une image binaire supérieure à 256 Ko. La taille de la pile est fixe pour chaque processus. III-8 Caractéristiques de µclinux [LIN] Supporte une vaste gamme d architectures (H8, SH, MIPS, x86,i960, ARM, m68k) Fonctionne en l absence de gestionnaire de mémoire (MMU) Nécessite une quantité minime de mémoire (noyau de taille réduite) Fournit un scheduler pour le multitâches Fournit une couche de communication réseau (IP, TCP, UDP) Grand nombre de systèmes de fichiers Emulation logicielle du calcul flottant en l absence de FPU III-9 La plateforme µcsimm pour µclinux [COL] Les responsables du projet µclinux ont proposé originellement une plateforme matérielle à des fins de tests : le kit µcsimm. Ce kit comprend un module qui se présente sous la forme d'une barrette SIMM à 30 broches. Le module µcsimm se compose de : Un microcontrôleur DragonBall EZ (68EZ328) basé sur un cœur Motorola à 16MHz. Il intègre un contrôleur de DRAM, un port série (interface RS.232), une interface SPI, un contrôleur LCD (résolution QVGA), une sortie Timer et une sortie PWM. Jusqu à 18 E/S parallèles. Une horloge Temps Réel calendrier. De la mémoire dynamique DRAM de 8 Mo. De la mémoire FLASH de 2 Mo. Une interface Ethernet IEEE BaseT. Le module µcsimm est commercialisé sous forme d un kit de développement comprenant le module µcsimm et une carte d assemblage / développement. 16

17 La mémoire FLASH La mémoire FLASH contient un moniteur (bootloader) qui permet de télécharger une image via la liaison série en mémoire DRAM et éventuellement la recopier en mémoire FLASH. L image contient par défaut le noyau µclinux et son systèmes de fichiers avec un petit nombre d'utilitaires (client NFS, miniserveur Web ). La platforme ColdFire pour µclinux Le processeur ColdFire est le dernier né de Motorola dont la première version est sortie en Le processeur ColdFire est le digne successeur du célèbre processeur Motorola dont la production s est arrêtée avec le microprocesseur il y a quelques années. Il reprend le jeu d instructions du microprocesseur où l on a supprimé les instructions qui ne servaient guère ainsi que certains modes d adressage. Le processeur ColdFire reprend une architecture Suivant les versions de processeur ColdFire, Motorola a rajouté des instructions de type MAC (Multiply and ACCumulate) quel on retrouve dans les processeurs de traitement du signal(digitalsignal Processing). Il a aussi intégré des périphériques ; ce qui confère au processeur ColdFire les propriétés d un microcontrôleur / DSP. Le marché visé par Motorola est clairement celui des télécommunications où l on retrouve ce genre de besoins. III-10 Mise en œuvre de µclinux La mise en œuvre de µclinux sera présentée pour le processeur ColdFire en utilisant comme plateforme matérielle la carte d évaluation Motorola M5407C3. La démarche à suivre sera bien sûr similaire pour µclinux porté sur d autres processeurs. La distribution µclinux/coldfire est basée initialement sur un noyau Linux mais propose aussi une version basée le noyau Linux L ensemble est stable et offre une large palettes de services comme : Les systèmes de fichiers NFS et SMB côté client. Un client DHCP. L IP masquerading. Des serveurs Web (boa et thttpd) La mise en oeuvre de µclinux/coldfire pour la génération de l image à télécharger dans la carte d évaluation ressemble fort à une génération d un noyau sous Linux. Il faut d abord récupérer les archives sur le site µclinux/coldfire : De la chaîne de compilation croisée ColdFire (fichier m68k-elf-tools-xxxxxxxx.tar.gz). De la distribution de µclinux/coldfire (fichier uclinux-dist-xxxxxxxx.tar.gz). 17

18 III-11 Etape d installation de µclinux/coldfire [COL] Etape1 : La première chose est d installer sur le PC hôte (sous Linux) pour le développement croisé (cross development) la chaîne de compilation croisée ColdFire. En étant root : sh-2.04# cd / sh-2.04# tar xvfz m68k-elf-tools tar.gz sh-2.04# exit Etape2 La deuxième chose est d installer la distribution de µclinux/coldfire dans son répertoire de travail en étant simple utilisateur : sh-2.04$ tar xvfz uclinux-dist tar.gz sh-2.04$ cd uclinux-dist/ Etape3 On retrouve ensuite l enchaînement classique de compilation d un noyau sous Linux : sh-2.04$ make xconfig Une série de fenêtres apparaît pour configurer le noyau µclinux/coldfire et choisir ses applications : Figure 4 : Configuration du noyau µclinux/coldfire 18

19 Figure 5 : Choix des applications (ici réseaux) µclinux/coldfire Etape 4 Puis on retrouve ensuite la phase de compilation (croisée) : sh-2.04$ make dep sh-2.04$ make Une image binaire du système µclinux/coldfire image.bin est placée sous /tftpboot pour pouvoir être téléchargée en RAM de la carte d évaluation via le réseau Ethernet avec le protocole TFTP. Pour cela, on se connecte à la carte par le port série en utilisant l application kermit ou minicom par exemple : sh-2.04$ kermit Connecting to /dev/ttys1, speed The escape character is Ctrl-\ (ASCII 28, FS) Type the escape character followed by C to get back, or followed by? to see other options Hard Reset DRAM Size: 32M Copyright Motorola, Inc. All Rights Reserved. ColdFire MCF5407 EVS Firmware v2e.1a.1a (Build 1 on Jul :35:59) Enter 'help' for help. dbug> dn image.bin Eth Mac Addr is 00:CF:54:07:C3:01 Downloading Image 'image.bin' from bytes read via TFTP 19

20 Etape 5 On lance le noyau µclinux/coldfire : dbug> go uclinux/coldfire(m5407) COLDFIRE port done by Greg Ungerer, gerg@lineo.com Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne Calibrating delay loop.. ok BogoMIPS Memory available: 30892k/32768k RAM, 0k/0k ROM (359k kernel code, 140k data) Execution Finished, Exiting Sash command shell (version 1.1.1) /> On remarquera sur les traces précédentes la taille du noyau inférieure à 500 Ko. On a alors maintenant un système Linux embarqué opérationnel et l on peut lancer des applications comme par exemple le serveur Web embarqué boa : /> boa& [20] /> III-12 Exemple d application du µclinux III-12-1 Système d'acquisition et de traitement vidéo Cet exemple concerne la réalisation d'un système d'acquisition-traitement d images en temps réel. Ce travail fait l'objet d'une thèse sur l'implantation matérielle d'algorithmes de traitement d'images. Figure 6 : système d'acquisition, traitement et restitution d'images III-13 Description du système Le système réalisé est composé d une caméra numérique permettant l acquisition de l image et la génération des signaux numériques. Ces signaux sont traités par la carte cible Altera Stratix 1S10. Après traitement par la carte cible, les échantillons de l'image traitée ainsi que les signaux de contrôle sont envoyés vers un module contrôleur VGA connecté à un moniteur VGA. L'image restituée a une résolution de 640x480 en niveaux de gris. Pour cela, un bloc IP pour l'acquisition de l'image de la caméra a été développé en VHDL. Il intègre une mémoire FIFO et un contrôleur DMA connecté au bus du processeur softcore NIOS IIde la carte cible (bus Avalon). Le module contrôleur VGA est le module Lancelot ( qui est du matériel libre fourni avec un bloc IP en libre. Ce module intègre aussi une mémoire FIFO et un contrôleur DMA connecté au bus du processeur softcore NIOS II de la carte cible. 20

21 Figure 7: Système pour l'acquisition vidéo Pour le bon fonctionnement du système cible, une synchronisation est nécessaire entre ces deux modules car un seul peut accéder à la mémoire partagée SDRAM à un instant donné. C est le module VGA ici qui est prioritaire puisqu une discontinuité de transfert de données entre la mémoire SDRAM et la FIFO du module VGA provoque une perturbation au niveau de l affichage de l image. Figure 8 : Module VGA Lancelot. Le processeur NIOS II est cadencé à la fréquence de 50 MHz. A cette fréquence, 20 % du temps est consommé pour les transferts DMA caméra et module VGA, ce qui laisse 80% du temps pour le processeur NIOS II pour l'exécution d'un système d'exploitation et des algorithmes de traitement vidéo. Le noyau Temps Réel microc/os II a été dans un premier temps adapté à la carte cible pour contrôler le système d'acquisition, traitement et d'acquisition d'images. Un algorithme simple de détection de contours a été implanté sous forme logicielle dans un premier temps. µclinux a été intégré ensuite au système cible sans problème. Les drivers Linux de contrôle des modules caméra et VGA sont en cours d'écriture. L'idée est d'intégrer un codeur de compression vidéo H.263 modifié pour accepter des accélérations matérielles. 21

22 III-14 Conclusion Ce rapport est insuffisant pour le développeur de LE, mais donne la connaissance de Linux Embarque sur des technologies les plus utilisées, l analyse de composants, les méthodes, les outils et ressources nécessaire à construire un tel système. LE se développe très vite et il peut devenir le standard industriel dans l avenir. Linux embarqué est prometteur. On peut signaler particulièrement un point très intéressant. C est l utilisation de Linux embarqué sur les ordinateurs de poche, PDA, téléphone portable. Ce domaine est très actif avec des offres Linux sur les applications portables. Personnellement, J obtiens quelques expériences qui me permet comprendre profondément le système Linux embarqué et d utiliser les différentes fonctionnalités associées 22

23 Conclusion Tout au long de ce rapport j ai présenté le monde de l embarqué sous Linux au travers des aspects matériels, logiciels mais aussi des outils et des méthodes de développement. On a pu voir à travers ce rapport que Linux fait vraiment bon ménage avec les systèmes embarqués. La mise en oeuvre de la distribution Linux embarqué µclinux/coldfire sur les plans matériels et logiciels. Cette mise en oeuvre est relativement simple pour un spécialiste Linux. L avenir de Linux embarqué est prometteur. On peut signaler particulièrement deux points très intéressants : Le mariage de Linux embarqué et les Systèmes Programmables (System On Programmable Chip). L utilisation de Linux embarqué sur les ordinateurs de poche (handheld). Ce domaine est très actif avec des offres Linux sur ordinateurs de poche Compaq ipaq par exemple. 23

24 Bibliographie [EMB]: «Embedded Linux Hardware, Software, and Interfacing» Editions Addison Westley ISBN [LIN] : «Linux embarqué : le projet µclinux» Edition : Eyrolles, Octobre 2002 [LIV] : «Le livre blanc des systèmes embarqués» Juin 2009 Webliographie [µcl] : Site de µclinux, version embarquée de Linux pour microcontrôleurs [PRA] : Site officiel de Pragmatec, spécialiste en systèmes temps réel et Linux embarqué [COL]: 24