Cours Appli Emb Mobiles [PDF]

Zitiervorschau

Cours Applications mobiles et embarquées Dr Mvogo Joseph / Dr Bonde Lossan Objectifs du cours L’objectif de ce cours est d’introduire l’apprenant à l’étude des systèmes embarqués et à l’utilisation de la plate-forme Android pour le développement des applications mobiles. L’étudiant apprendra à identifier les spécificités d’un système embarqué, sa conception ainsi que ses applications. Au terme du cours, l’apprenant doit:  Pouvoir définir un système embarqué,  Enumérer les différents types de systèmes embarqués et leurs applications,  Décrire et expliquer l’architecture d’un système embarqué,  Cerner les problématiques de conception des systèmes embarqués,  Développer avec Android des applications pour des périphériques mobiles, plus particulièrement le téléphone mobile,  Déployer une application développée avec Android sur un téléphone compatible Android.

Organisation du cours Le cours est organisé en deux parties. La première présente de façon générale les systèmes embarqués. La seconde est constituée d’un ensemble de travaux pratiques (TPs) portant sur le développement avec Android et l’environnement de développement Eclipse. Le plan détaillé du cours se présente comme suit : Partie #1 Généralités sur les systèmes embarqués Chapitre 1 Introduction aux systèmes embarqués Chapitre 2 Architecture d’un système embarqué Chapitre 3 Conception des systèmes embarqués Partie #2 Développement d’applications mobiles avec Android TP N°1 Installation et configuration de l’environnement de développement TP N°2 Fondamentaux du développement avec Android TP N°3 Utilisation des outils de Google APIs TP N°4 Mini Projet : Références bibliographiques

Ouvrages (Livres)

[L01] Arnold S. Berger, Embedded Systems Design: An Introduction to Processes, Tools, & Techniques, CMP Books, 2002

Webographie (ressources tirées du Web)

[W01] Samia Bouzefrane, Introduction aux Systèmes Temps Réel, http://cedric.cnam.fr/~bouzefra/ [W02] www.technologuepro.com, Cours Systèmes Embarqués, Introduction, http://www.technologuepro.com/cours-systemes-embarques/cours-systemes-embarquesintroduction.htm [W04] www-igm.univ-mlv.fr, Architecture d’un système embarqué, http://wwwigm.univmlv.fr/~dr/XPOSE2002/SE/architecture.html [W05] Ramzi BOULKROUNE, Les systems embarqués, http://www.memoireonline.com/05/12/5830/Les-systemes-embarques.html [W06] Richard Grisel et Nacer Abouchi, Les systèmes embarqués - Introduction, http://richard.grisel.free.fr/Master_OSM/2_Introduction_Embedded_systems.pdf [W07] Jean-Luc Dekeyser, ARCHITECTURE EMBARQUÉE ET PROCESSEURS RISC, http://www.lifl.fr/~dekeyser/M1AEV/cours%202013/aev11.pdf

Partie #1 Généralités sur les systèmes embarqués La première partie du cours porte sur un enseignement théorique sur les systèmes embarqués. Cet enseignement est divisé en quatre chapitres. Le premier chapitre définit ce qu’est un système embarqué, ce qui le différencie des autres systèmes (non embarqués). Il présente également la classification des systèmes embarqués ainsi que les différentes utilisations (applications) de ces systèmes. Enfin, il se termine par la présentation de l’évolution des systèmes embarqués et de la spécificité dans la conception et l’implémentation des systèmes embarqués.

Le chapitre 2 décrit et explique l’architecture d’un système embarqué. Cette description fait également ressortir les contraintes à prendre en compte dans la détermination des constituants matériels et logiciel pour satisfaire aux performances attendues du système. Le dernier chapitre est orienté la conception et implémentation des systèmes embarqués.

3

Chapitre 1 Introduction aux systèmes embarqués Les systèmes embarqués sont beaucoup plus présents qu'il n'y paraît. On les trouve actuellement partout: à la maison, au bureau, dans la voiture, dans les industries, à l'hôpital, dans les appareils militaires électroniques, etc. Le nombre, le type et la complexité des services demandés sont sans cesse croissants. Les systèmes embarqués sont alors nombreux et d'une complexité croissante qui demande de nouvelles approches de conception, utilisant des outils de développement haut niveau et des compromis hardware/software, plutôt que des approches bas niveau (assembleur, logique). Le marché des systèmes embarqués est de loin supérieur à celui des PC et architectures clients/serveurs réunis.

1.1 Définitions Il est difficile de définir ce qu’est un système embarqué. Pratiquement tout calculateur en dehors de l'ordinateur est un système embarqué. Un système embarqué est un système autonome à microprocesseur (microcontrôleur) dédié à une tâche bien précise et évoluant dans un environnement souvent très contraignant (espace et consommation). Le système est dit embarqué parce qu’il se trouve encapsulé dans un dispositif ou un appareil qu'il contrôle, surveille, ou fait fonctionner. Le terme système enfoui est souvent utilisé pour désigner un système embarqué. Comparé à un système non embarqué, un système embarqué n'a pas d’entrées/sorties classiques (clavier, écran ou souris) clairement distinguables. Un système embarqué est l’union d’un système électronique (matériel/hardware) et d’un système informatique (logiciel/software) intimement liés et formant un tout. Les systèmes embarqués utilisent généralement des microprocesseurs à basse consommation d'énergie ou des microcontrôleurs dont la partie logicielle est en partie ou entièrement programmée dans le matériel ; généralement, ils sont en mémoire dans une mémoire morte (ROM, EPROM, EEPROM, FLASH, etc.) et non sur un disque dur. Un système embarqué (embedded system ou système enfoui) est un système informatique dans lequel le processeur/calculateur est englobé dans un système plus large et où le logiciel est entièrement dédié à une application donnée. Ex. : sonde spatiale, terminal GSM, carte à puce. Nous pouvons continuer à donner plusieurs autres définitions de systèmes embarqués, définitions qui vont plus ou moins exprimer les mêmes idées et concepts en des termes plus ou moins accessibles. Pour mieux percevoir ce qu’est un système embarqué, [L01, pages XVIII à XXVI] nous propose une liste de quelques éléments qui différencient les systèmes embarqués des autres systèmes : 1. Les systèmes embarqués sont dédiés à des tâches biens spécifiques: Les PCs ordinaires sont des instruments génériques de calcul, contrairement aux systèmes embarqués qui ont des tâches bien spécifiques. D’ailleurs, les systèmes embarqués sont souvent appelés des processeurs dédiés. 4

2. Les systèmes embarqués sont en général sensibles aux coûts : Dans la conception des systèmes embarqués, le choix du microprocesseur, des cartes et autres est effectué de manière à optimiser le coût du système. 3. Les systèmes embarqués sont souvent soumis à des contraintes de temps réel : Les systèmes embarqués sont souvent soumis à deux types de contraintes temps réel : a. Les contraintes temps réel dur ou critique : le non-respect des contraintes temporelles entraîne la faute du système et les conséquences sont graves, voire catastrophiques. C’est le cas, par exemple, du contrôle du trafic aérien, du contrôle du système de conduite de missile, etc. b. Les contraintes temps réel souple (soft real-time) : le respect des échéances de temps est important, mais un manquement n’engendre pas des conséquences graves. Par exemple, dans une projection vidéo, un manquement d’échéance peut entraîner un décalage entre le son et l’image, ce qui est désagréable, mais n’est pas une catastrophe. Certains subdivisent cette catégorie en deux classes en considérant les contraintes temps réel ferme (firm real-time), où les contraintes sont occasionnellement non respectées. 4. En général, les systèmes embarqués n’ont pas de système d’exploitation, sinon alors un système d’exploitation dédié : Les systèmes d’exploitation généraux tels que Windows 9X, Windows NT, Windows 2000, Windows XP, Vista, Seven, Unix, Solaris, HPUX, … ne sont pas souvent utilisés pour piloter un système embarqué. Quand un système embarqué est doté d’un système d’exploitation, ce dernier est un système d’exploitation temps réel (RTOS : realtime Operating System). 5. Les implications d’échec logiciel sont sévères dans un système embarqué : par conséquent, dans les systèmes embarqués, des mécanismes plus poussés seront mis en place pour contrôler et détecter les dysfonctionnements. 6. Les systèmes embarqués ont souvent des contraintes de consommation d’énergie: les systèmes embarqués sont souvent alimentés avec de petites batteries et doivent pourtant fonctionner pendant longtemps avec ces batteries. Cette contrainte de consommation d’énergie a des implications sur la conception et l’implémentation du système. 7. Les systèmes embarqués opèrent souvent dans un environnement avec des conditions extrêmes: Les systèmes embarqués sont partout, y compris dans des environnements avec des conditions de température ou d’humidité extrêmes. 8. Les systèmes embarqués ont peu de ressources : Comparés aux ordinateurs de bureau, les systèmes embarqués ont très peu de ressources (mémoires, disques, entrées/sorties, …). 9. Les systèmes embarqués stockent tout leur code objet dans une ROM: Cette contrainte de stockage oblige à optimiser afin de réduire au minimum la taille du système. Le fait que tout le code réside en ROM a aussi des implications sur la conception du système. 10. La conception des systèmes embarqués nécessite des outils et des méthodes spécialisés. 11. Les systèmes embarqués récents comportent un circuit dédié au débogage. La figure 1, tirée de [W02] permet de mieux illustrer un système embarqué. Un système embarqué est constitué de deux parties : le système contrôlé et le système de contrôle. 

Le système contrôlé: environnement (procédé) équipé d'une instrumentation qui réalise l'interface avec le système de contrôle.

5



Le système de contrôle : éléments matériels (microprocesseurs…) et logiciels dont la mission est d'agir sur le procédé via les actionneurs, en fonction de l'état de ce procédé indiqué par les capteurs, de manière à maintenir ou conduire le procédé dans un état donné.

Figure 1: Système embarqué et son environnement

Les principales caractéristiques d’un système embarqué sont :  



Autonomes. Une fois enfouis dans l'application, les systèmes embarqués ne sont (le plus souvent) plus accessibles. Temps réel. Les temps de réponse de ces systèmes sont aussi importants que l'exactitude des résultats. Réactifs. Il doit réagir à l'arrivée d'informations extérieures non prévues

1.2 Classification des systèmes embarqués On peut classer les systèmes embarqués selon plusieurs critères : Le type d’activités réalisées, le type de mission du système, le mode d’interaction avec le système. 1.2.1 Classification par type d’activités réalisées Par type d’activités réalisées, on distingue les systèmes embarqués orientés contrôle et les systèmes embarqués orientés calcul/traitement. Les systèmes embarqués orientés contrôle sont le plus souvent rencontrés en : Automobile, Avionique, Centrales nucléaires. Les systèmes orientés calcul/traitement sont présents dans les : Télécommunications, MultiMedia, Radio logicielle, TV numérique. 1.2.2 Classification par type de mission du système Selon la nature de la mission réalisée par le système, on peut distinguer plusieurs catégories de systèmes embarqués. Sans être exhaustif, on peut citer dans cette classification : authentification, calculs numériques, navigation / Internet, automatisme, etc. 1.2.3 Classification par mode d’interaction Selon le mode d’interaction, on peut distinguer les systèmes transformationnels, les systèmes interactifs et les systèmes réactifs, ou systèmes temps réel.

6



Système Transformationnel: activité de calcul qui lit ses données et ses entrées lors de son démarrage, qui fournit ses sorties, puis meurt.



Système Interactif: Système en interaction quasi permanente avec son environnement, y compris après l'initialisation du système; la réaction du système est déterminée par les événements reçus et par l'état courant (fonction des événements et des réactions passés); le rythme de l'interaction est déterminé par le système et non par l'environnement.



Système Réactif ou Temps Réel: Système en interaction permanente avec son environnement, y compris après l'initialisation du système; la réaction du système est déterminée par les événements reçus et par l'état courant (fonction des événements et des réactions passées), mais le rythme de l'interaction est déterminé par l'environnement et non par le système.

1.3 Domaines d’utilisation des systèmes embarqués Les domaines d’application des systèmes embarqués sont de plus en plus nombreux :  

Transport : automobile (contrôle de suspension, réseau), Aéronautique (avionique), etc. Astronautique : fusée, satellite artificiel, sonde spatiale, etc. Le premier système moderne embarqué reconnaissable a été le Apollo Guidance Computer (AGC), système de guidage de la mission lunaire Apollo.  Militaire : missile  Télécommunication: téléphonie, routeur, pare-feu, serveur de temps, télécopieur, téléphone portable, stations de base des cellulaires, etc.  Electroménager : télévision, four à micro-ondes, machine à laver  Impression : imprimante multifonctions, photocopieur, etc.  Informatique : disque dur, lecteur de disquette, imprimante, scanner, etc.  Multimédia : console de jeux vidéo, assistant personnel = PDA = Personal Digital Assistant est un ordinateur de poche conçu à l'origine comme un agenda électronique, puis il a intégré les fonctions de bureautique (dictaphone, reconnaissance vocale) ou d'écriture avec des Systèmes d’exploitations divers (Microsoft Windows mobile).  Guichet Automatique Bancaire (GAB) : Différents modèles de GAB permettent de faire des retraits, acceptent des dépôts en liquide ou par chèque, ordonnent des transferts de fonds, impriment des mises à jour de carnets, augmentent le montant d'une carte d'appel téléphonique et, même, vendent des timbres-poste. En Espagne, au Portugal (réseau ≪ Multibanco ≫) et au Canada, il est aussi possible de régler certaines factures via un GAB. Le GAB est une extension du DAB (distributeur automatique de billets) qui est un GAB simplifié ne permettant que les retraits.  Jeux : consoles, appareils photos, chargeurs de batteries.  Métrologie: appareils photos, caméras En somme, les systèmes embarqués sont présents dans la quasi-totalité des domaines d’activités des hommes. Aussi, la production et la vente des microprocesseurs pour systèmes embarqués sont, en général, des millions de fois supérieures à la production et à la vente des ordinateurs classiques. Pour ne considérer que le cas de l’automobile, nous avons les chiffres suivants : 

Production de véhicules : 40 millions (1998) → → 60 millions (2010) 7

  

Coût des systèmes électroniques embarqués : 37 000 M$ (1995) → →60 000 M$ (2000) Coût de l'électronique embarquée : > 20% Coût du véhicule Logiciel : 1,1 KBytes (1980) → →2MBytes (2000) → → 10MBytes (2004)

1.4 Evolution des systèmes embarqués (Historique) Années 70: la conception de systèmes d'électronique numérique se fait essentiellement sous forme de cartes. On utilisait les circuits imprimés (PCB : Printed Circuit Board). La conception d’un système complexe se faisait par assemblage de circuits du marché, ce qui conduisait à une mise au point longue et une évolutivité faible. A cette époque, le développement de circuits VLSI nécessitait une maîtrise des technologies de conception au niveau silicium. Cette expertise était rare et constituait un métier spécifique. Années 80: apparition des composants (re)programmables par l'utilisateur (PLD) ; cela permet une diminution sensible du nombre de circuits par carte (augmentation du taux d'intégration) et une souplesse (évolutivité) accrue. Apparition des ASICs, mais leur usage n'est alors justifié que pour de forts taux d'intégration, de gros volumes de production et/ou des soucis de confidentialité. Au milieu des années 80: apparition des FPGAs qui combinent les avantages des ASICs (taux d'intégration) et des PLDs (souplesse), mais la complexité des fonctions implantables rend nécessaire des méthodes et outils de développement jusque-là réservés aux ASICs (VHDL, ...). Le microprocesseur est au centre des systèmes embarqués. Comment en est-on arrivé là ? C'est par dizaines que se comptent actuellement les fabricants de microprocesseurs et chacun des fabricants possèdent des dizaines, voire des centaines de produits. Cependant, il n'en était pas ainsi au début. D'ailleurs, le microprocesseur n'est pas né volontairement et n'a reçu ce nom qu'un an plus tard ! C’était au début des années 1970. Cela ne veut pas dire que l'ordinateur date des années 1970. Les ordinateurs, au contraire, ont toujours été étudiés et déterminés avant que les technologies pouvant les supporter ne soient disponibles. L'architecture de Harvard qui est la 1ere architecture significative réalisée dans le calculateur électromécanique Mark 1 par Howard Aiken, physicien de l'Université de Pennsylvanie a été fonctionnelle en 1944 et a été développée dans les années 30. La 1ere machine électronique générale fut probablement l'ENIAC (Electronic Numerical Integrator Analyser and Computer), développée entre 1943 et 1946 à l'Université de Pennsylvanie avec la même architecture que le Mark 1 : espaces mémoires données et programmes séparés. Cette architecture ne s'est pas avérée populaire, car compliquée pour les machines à usage général. Un consultant du projet ENIAC, J. V. Neumann est reconnu créateur d'une architecture alternative publiée plus tard par Burks, Goldstine et V. Neumann en 1946. Son idée simple est basée sur 2 prémisses : pas de différence intrinsèque entre données et programmes ; une instruction peut être partitionnée en un champ commandant l'opération et un autre l'opérande (donnée sur laquelle on veut opérer). On a alors une seule mémoire pour les instructions et les données. L'IAS a été construit en 1951 à l'Institute of Advanced Studies de Princeton sur ce principe : machine bien simplifiée avec l'inconvénient de ne pouvoir accéder simultanément aux données et aux programmes. L'histoire du microprocesseur part d'Intel, Société américaine fondée en 1969 par Gordon Moore 1 et Robert Noyce. Le premier microprocesseur commercialisé fut le 4 bits 4004 d'Intel en 1971. Avant cela, les processeurs utilisés dans les ordinateurs n'étaient pas intégrés. Dès 1971, il y a une grande accélération, avec plusieurs fabricants qui se disputent le marché. Intel introduit successivement le 8008 en 1972, le 8080 en 1973 et le 8080A en 1974. En 1974 également, Motorola lance son 6800 avec des modes d'adressages plus performants et qui ont permis de créer des codes plus compacts. En 1976, des transfuges d'Intel, ayant fondé Zilog en 1974, lancent le Z80 qui a été très utilisé à l'époque. En 1975, Motorola subissait à son tour la désertion des ingénieurs ayant créé la MOS Technology qui lança le 6500, puis le 6502 (Apple II).

8

A la fin des années 70, Intel introduisit le fameux 8088 et Motorola le 6809. Depuis lors, bien que certains acteurs aient disparu et que de nouveaux soient apparus, le marché des microprocesseurs reste dominé par ces 2 sociétés : on retrouve les processeurs d'Intel (80x86 ) dans les compatibles PC et ceux de Motorola ( 680x0 ) dans les MacIntoshs.

1.5 Problématique de la conception et réalisation des systèmes embarqués Plusieurs des caractéristiques propres aux systèmes embarqués (contrainte de résidence du code en ROM, réduction maximale de la consommation d’énergie, la maîtrise du temps de réponse du système, sûreté de fonctionnement,…) font que la conception et la réalisation des systèmes embarqués ne peuvent être envisagées avec les outils et méthodes classiques du génie logiciel. Un autre facteur qui influence de manière très significative la conception et la réalisation des systèmes embarqués est l’évolution de la technologie. La loi de Moore, bien qu’étant en ralentissement progressif, demeure encore vraie. Selon cette loi, la capacité en transistors des circuits intégrés (CI) double tous les 18 mois depuis plusieurs décades passées. Un circuit d'aujourd'hui (2000) peut contenir environ 15 000 circuits de 1989. Cette évolution est illustrée par la figure 2.

Figure 2: La loi de Moore (source: http://www.intel.com/research/silicon/mooreslaw.htm)

En plus de la loi de Moore, deux autres lois empiriques sont vérifiées depuis 30 ans dans le monde des microprocesseurs : 1. La loi de JOY: la puissance CPU en MIPS double tous les 2 ans. 2. La loi de RUGE : on a besoin d’une Bande Passante de 0,3 à 1 Mb/s par MIPS. Toutes ces lois ont influencé le développement des systèmes embarqués. Hier, les systèmes embarqués étaient construits avec des circuits intégrés ; aujourd’hui, on construit les SoC (System on Chip), demain ce seront les MPSoC (Multi-Processors System on Chip) et peut-être que la nanotechnologie avec l’électronique moléculaire nous apportera une révolution.

9

Conclusion Ce chapitre a présenté plusieurs définitions d’un système embarqué. Trois choses importantes sont à retenir de ces définitions: un système embarqué remplit une mission (tâche) bien spécifiée ; un système embarqué est composé de matériel et logiciel formant un tout ; un système embarqué est soumis à des contraintes de temps et de consommation d’énergie et fonctionne, en général, dans un environnement contraint. Les systèmes embarqués peuvent être classés selon plusieurs critères. Ces critères ainsi que les classes associées ont été présentés. Les domaines d’application des systèmes ont été énumérés. Cette énumération nous a révélé que les systèmes embarqués sont quasiment présents dans tous les domaines d’activités de l’homme. Les caractéristiques spécifiques aux systèmes embarqués ainsi que l’évolution des technologies font que leur conception et réalisation sont effectuées avec des outils et langages spécifiques. Les chapitres 3 et 4 du cours présenteront ces outils, méthodes et langages. Au terme de ce chapitre, nous avons une idée plus claire de ce que sont les systèmes embarqués, leurs applications et leurs spécificités. Nous pouvons maintenant commencer leur étude à proprement parler.

10

Chapitre 2 Architecture d’un système embarqué Dans le chapitre d’introduction, nous avons vu qu’un système embarqué est constitué de matériel et de logiciel et que le logiciel réside dans une mémoire ROM. Dans ce chapitre, nous allons plus nous focaliser sur l’architecture matérielle d’un système embarqué. L’organisation du code (partie logicielle) sera abordée dans les chapitres 3 et 4 où nous traiterons de la conception et de l’implémentation des systèmes embarqués. Le chapitre comporte deux sections. La première section décrit les différents composants de l’architecture ainsi que les relations entre ces composants. La seconde traite du fonctionnement d’un système embarqué.

2.1 Structure d’un système embarqué

Figure 3: Architecture matérielle interne d'un Système Embarqué

La figure 3 décrit l’architecture matérielle interne d’un système embarqué. Les principaux éléments de cette architecture peuvent être décrits comme suit :     

Le microprocesseur: désigné ici par UC ; c’est le cerveau du système. RAM: mémoire de travail du système. ROM: stocke le logiciel du système. Interfaces E/S: ces interfaces permettent de connecter des périphériques au système. Bus: les bus sont les nerfs permettant de relier les différents éléments de l’architecture. Dans cette architecture on a trois types de bus : le bus de données (D), le bus d’adresse (A) et le bus de contrôle (C). o Bus de Données (D): bus directionnel permettant le transfert des données entre l’UC, la RAM et les périphériques d’E/S. Entre la ROM et l’UC, le transfert est unidirectionnel (ROM vers UC). o Bus d’adresse (A): est utilisé pour désigner les interlocuteurs. La taille de ce bus détermine le nombre d’adresses mémoires disponibles. Pour 16 lignes, on aura 216 adresses soit des adresses allant de 0 à 216-1 (65535).

11

o

Bus de contrôle(C): est utilisé pour le transfert des signaux de synchronisation entre l’UC et les autres éléments interconnectés. Comme exemples de signaux, on peut citer : Read, Write, Interupt, Acknowledgments, … D’un point de vue externe et fonctionnel, l’architecture d’un système embarqué est dépeinte par la figure 4 [W04].

Figure 4: Architecture externe et fonctionnelle d'un système embarqué (source : http://www-igm.univmlv.fr/~dr/XPOSE2002/SE/architecture.html)

Cette architecture peut varier selon les systèmes: on peut, par exemple, ne pas trouver de systèmes auxiliaires dans de nombreux systèmes embarqués autonomes et indépendants. En revanche, l'architecture de base est la plupart du temps composée d'une unité centrale de traitement (CPU), d'un système d'exploitation qui réside parfois uniquement en un logiciel spécifique (ex: routeur), ou une boucle d'exécution (ex: ABS). De même, l'interface IHM n'est pas souvent existante, mais est souvent utile pour reconfigurer le système ou vérifier son comportement. Les capteurs et acteurs (actionneurs) sont des organes permettant au système de communiquer avec son environnement. Ces actionneurs et capteurs sont, en général, connectés au CPU au moyen d’un convertisseur (A/N et N/A). 



Capteurs : [W05] définit le capteur comme étant un organe de prélèvement d'information qui élabore, à partir d'une grandeur physique, une autre grandeur physique de nature différente (très souvent électrique). Cette grandeur représentative de la grandeur prélevée est utilisable à des fins de mesure ou de commande. Virtuellement, tous les stimuli physiques peuvent être captés (température, lumière, couleur, son, vélocité, accélération (linéaire, angulaire), pression, champ magnétique, tension, courant, capacité...). Les capteurs sont des organes d’entrées, car ils permettent d’obtenir des informations de l’environnement et de transmettre ces informations au système. Actionneurs : un actionneur est un organe qui, recevant un ordre de la partie commande, convertit l'énergie qui lui est fournie en un travail utile à l'exécution de tâches éventuellement programmées - du système. Les actionneurs permettent au système d’agir sur l’environnement.

12







IHM: sont les éléments utilisés pour entrer les données (clavier, boutons poussoirs, interrupteurs à main, à pied) ainsi que les dispositifs de pointage (souris, touchpad, stylos optiques) d’une part et les afficheurs (LED, afficheurs LCD, écrans CRT, sortie télévision) d’autre part. Mémoires: On retrouve les deux types de mémoires (volatile et non volatile) dans un système embarqué. o Mémoire vive (volatile) : La RAM du système est utilisée pour le fonctionnement du CPU. Elle est utilisée pour acquérir et restituer des données à haut débit. C’est une mémoire qui joue un rôle de tampon (buffer). Le choix du type de RAM (Statique ou dynamique) dépend du type d’interface disponible sur le processeur. o Mémoire non volatile : est constituée de ROM et/ou de NVRAM (mémoire RAM non volatile). Cette composante est utilisée pour stocker :  La partie logicielle (firmware) du système,  Les données de calibration ou de configuration,  Les horloges temps réel (RTC) sauvegardées par batteries. ASIC / FPGA: Le fonctionnement du processeur peut être amélioré ou rendu plus performant en utilisant un ASIC ou un FPGA pour réaliser certaines tâches. La figure 5 tirée de [W07] permet d’illustrer cette approche.

Figure 5: Utilisation ASIC/FPGA dans un système embarqué

2.2 Fonctionnement d’un système embarqué Le fonctionnement du système embarqué se résume ainsi:  Le système reçoit des informations de l'environnement extérieur (grâce aux capteurs) et il les convertit en signal numérique.  L'unité de traitement composée du CPU, de la mémoire, du logiciel, de l'ASIC et éventuellement de systèmes externes traite l'information.  Le traitement génère éventuellement une sortie qui est envoyée vers la sortie, les systèmes auxiliaires, les ports de monitoring ou l'IHM.

Conclusion Ce chapitre a présenté l’architecture d’un système embarqué en mettant l’accent sur les éléments matériels constituant le système. Les organes de calcul, d’entrées/sorties et de stockage ont été décrits. L’aspect fonctionnement a été décrit du point de vue d’un observateur externe. Le fonctionnement interne des différents organes ne relève pas des objectifs de ce cours. 13

Chapitre 3 Outils et langages de conception des systèmes embarqués Contrairement à la conception des applications informatiques sur des plates-formes standard, la conception des systèmes embarqués implique que le matériel et le logiciel se conçoivent, tous deux, en parallèle. Bien que cette approche ne soit pas toujours suivie, elle demeure, de nos jours, la norme. Cette conception simultanée a une profonde influence sur la façon dont la conception est réalisée.

3.1 L’Evolution de la conception des systèmes embarqués Aujourd’hui, les systèmes embarqués deviennent de plus en plus complexes au niveau intégration et fonctionnalités et l'on est en mesure d'intégrer tout dans un même composant : c'est le concept du single chip. Ceci est en fait lié à la loi empirique de Moore qui stipule que pour une surface de silicium donnée, on double le nombre de transistors intégrés tous les 18 mois. La figure 6 montre cette évolution.

Figure 6: Loi de Moore

La loi de Moore a radicalement changé la façon de concevoir les systèmes embarqués. On travaille maintenant au niveau système (ou fonctionnalité) et non au niveau porte logique (pour le grand bien des électroniciens). Les fonctionnalités peuvent être implantées de deux façons :  dans des composants spécifiques de type ASIC (Application Specific Intregrated Circuit). On parle alors de Système sur Silicium SoC (System on Chip).  dans des composants logiques programmables de type FPGA (Field Programmable Gate Array). On parle alors de système SoPC (System on Programmable Chip). La figure 7 résume l’évolution dans la conception des systèmes embarqués.

Figure 7: Evolution dans la conception des systèmes embarqués 14

L'approche « schématique » au niveau des portes logiques ou fonctionnalités de base RTL (Register Transfer Logic) est délaissée pour la conception des systèmes complexes au profit d'une approche « textuelle », mais elle reste, bien sûr, toujours valable pour la conception des systèmes embarqués plus modestes. Pour cela, on utilise des langages de description de matériel comme VHDL (Very high speed integrated circuit Hardware Description Language) ou Verilog pour synthétiser une fonctionnalité numérique. Ces langages de description de matériel sont en fait de véritables langages de programmation informatiques orientés objet et peuvent être utilisés comme tels par les informaticiens. Ils sont utilisés conjointement avec un compilateur ou un simulateur. Il est d'ailleurs faux de dire compilateur ; il faut plutôt dire synthétiseur, car finalement, on génère dans la majorité des cas (conception SoPC) un fichier de programmation d'un composant logique programmable ! On synthétise un circuit numérique, mais on ne le compile pas, bien que l'on ait une approche logicielle pour concevoir du matériel. Ces langages ont permis de travailler avec un niveau d'abstraction plus grand, laissant les basses besognes au synthétiseur. On a pu rapidement développer des bibliothèques de fonctionnalités comme une interface USB, un contrôleur MAC Ethernet que l'on appelle blocs IP (Intellectual Property). Ces blocs IP peuvent être un peu comparés à un composant logiciel comme le Java Bean. On peut les acheter ou bien utiliser des blocs IP libres (comme du logiciel libre) dont le site phare de référence est http://www.opencores.org. On peut ainsi voir la conception d'un système embarqué complexe comme un assemblage de blocs IP, si bien que les langages de description de matériel sont un peu comme un langage assembleur visà-vis d'un langage plus évolué comme le langage C. Il est à noter que l’exploit serait de pouvoir générer un circuit numérique à partir d'un fichier source écrit en langage informatique comme le langage C : c'est ce que propose SystemC, mais bien des progrès restent encore à faire dans ce domaine. Les langages de description de matériel sont aussi intéressants pour la facilité de modification et de réutilisation d'un design précédent pour un nouveau design : c'est le design reuse. De plus, cela permet de réduire aussi le Time To Market (TTM) cher aux gestionnaires. Il faut noter que lorsque l'on conçoit un système embarqué complexe, on met en œuvre généralement un processeur embarqué. Ce processeur embarqué est :  Soit un bloc IP : on parle de processeur softcore.  Soit déjà implanté dans le circuit électronique en « dur » : on parle de processeur hardcore. Le processeur de ce type est généralement plus performant que le processeur du type précédent. Le processeur embarqué allie la souplesse du logiciel à l'accélération du temps d'exécution du matériel. Une fonctionnalité particulière peut donc être composée d'une partie matérielle couplée à une fonctionnalité logicielle dédiée : on a donc une conception conjointe matérielle-logicielle ou codesign. Le codesign implique donc une conception en même temps du matériel et du logiciel, ce qui est une nouvelle méthodologie par rapport à la méthodologie de conception classique (conception matérielle, puis conception logicielle).

Figure 8:Conception traditionnelle et Codesign

15

Il faut noter que les processeurs embarqués, comme leurs cousins du grand public, sont de plus en plus puissants et que la puissance CPU en MIPS double tous les 2 ans (loi empirique de Joy). En outre, ils sont de plus en plus communicants et l'on estime que l'on a besoin d'une bande passante réseau de 0,3 à 1 Mb/s par MIPS (loi empirique de Ruge). La course à la performance gagne aussi le monde de l'embarqué et des systèmes embarqués complexes. Enfin, qu'en est-il des systèmes mixtes ou purement analogiques ? Des langages de description du matériel apparaissent comme VHDL-AMS, par exemple, mais restent confinés à la simulation. Il est à noter qu'il commence à y avoir des composants analogiques programmables sur le marché. On peut citer, par exemple, les pSoC de Cypress qui intègrent dans un même circuit un microcontrôleur, une zone de logique programmable et une zone analogique. La zone analogique comporte des blocs contenant des composants analogiques élémentaires (capacités, capacités commutées, résistances, amplificateurs...) pour construire des fonctionnalités analogiques ou mixtes.

3.2 Le codesign Le codesign est la méthodologie de conception la plus utilisée de nos jours pour concevoir les systèmes embarqués. Il permet de concevoir à la fois le matériel et le logiciel pour une fonctionnalité à implémenter. Les circuits logiques programmables offrent encore plus de possibilités d’intégration et favorisent la mise en œuvre du codesign. Contrairement à l’approche classique où les choix matériels sont faits en premier lieu, le codesign a l’avantage de repousser, le plus loin possible dans la conception du système, les choix matériels à faire. 3.2.1 Les étapes dans le codesign Le cycle de développement dans le codesign peut être découpé en sept étapes qui peuvent être brièvement décrites comme suit : 1. Spécification : On réalise la liste des fonctionnalités du système de façon abstraite. 2. Modélisation : On conceptualise et on affine les spécifications pour produire un modèle du matériel et du logiciel. 3. Partitionnement : on décide quelles fonctionnalités seront implémentées en logiciel et lesquelles doivent l’être en matériel. 4. Synthèse et optimisation : on réalise la synthèse matérielle et la compilation logicielle. 5. Validation : la validation est essentiellement effectuée par co-simulation. 6. Intégration : on réalise un rassemblement des différents modules. 7. Tests d’intégration : on réalise la vérification du fonctionnement. 3.2.2 Les avantages du codesign Le codesign présente les avantages suivants :     

Amélioration des performances : apport du parallélisme, apport d’algorithmes distribués, architectures spécialisées, etc. Reconfiguration : on peut faire une reconfiguration statique ou dynamique en cours de fonctionnement. Indépendance vis-à-vis des évolutions technologiques : grâce aux circuits logiques programmables. Amélioration des outils de conception : on peut tirer profit des améliorations fournies par les fabricants de circuits logiques. Programmables : permettent une synthèse plus efficace et une performance accrue.

16

3.2.3 La méthodologie de conception Comme dans toute approche de conception, une méthodologie est nécessaire. L’utilisation d’une méthodologie bien définie assure que l’on ne va pas passer « à côté » des paramètres importants. Une fois qu’une méthode est bien élaborée, on peut utiliser les compilateurs, les outils d’aide à la conception logicielle ainsi que les outils de conception assistée par ordinateur pour automatiser les étapes méthodologiques, surveiller et tracer la méthodologie. Une méthodologie commence par définir les niveaux d’abstraction. Un niveau d’abstraction offre une perception du système en mettant de côté certains détails pour se concentrer sur un point de vue donnée. A chaque niveau d’abstraction, on doit analyser le système pour déterminer ses caractéristiques actuelles et l’améliorer pour prendre en compte les détails manquants. Dans le cas de la conception des systèmes embarqués, on peut proposer les niveaux d’abstractions indiqués dans la figure 9. Une fois les niveaux d’abstraction définis, on peut procéder de deux façons : « Top-down » (approche descendante) ou « Bottom-up » (approche ascendante).  Top-down : on part du niveau d’abstraction le plus élevé et on descend jusqu’au niveau le plus détaillé.  Bottom-up : on part des composants de base nécessaires et on remonte vers le système. En général, on est souvent amené à utiliser conjointement les deux approches.

Figure 9: Niveaux d'abstraction

Expression des besoins L’expression des besoins consiste à décrire de façon précise ce que veut l’utilisateur (le client) et ce qu’il peut espérer obtenir. Les besoins peuvent être classés en besoins fonctionnels et en besoins non fonctionnels. Les besoins fonctionnels expriment les sorties attendues en fonction des entrées et des paramètres. Ce sont les besoins en termes de réalisations attendues du client. Les besoins non fonctionnels traitent des problèmes d’efficacité, de performance (temps nécessaire pour calculer la sortie, la taille, le poids, etc.), de consommation d’énergie, de fiabilité et de sureté du système. Ce sont des besoins non exprimés directement par le client, mais qui doivent être pris en compte pour l’acceptation du produit final. Dans l’expression des besoins, il faut définir un modèle de fonctionnalité. Ce dernier propose un format pour décrire une fonctionnalité. Un exemple de modèle de fonctionnalité peut inclure les éléments suivants : Nom, Objectifs, Entrées, Sorties, Fonctions, Performances, Coût de production, Consommation, Taille et Poids.

17

Spécifications La spécification consiste à donner une description plus précise du système. Elle n’identifie pas une architecture particulière, mais donne les éléments nécessaires à la conception de l’architecture. La spécification prend en compte à la fois les besoins fonctionnels et non fonctionnels. Conception de l’architecture La conception de l’architecture consiste à se demander quels sont les composants qui satisfont aux spécifications majeures. Il s’agit des composants matériels (CPUs, périphériques, etc.) et pour ce qui est des composants logiciels, il faut déterminer les programmes principaux et leurs opérations. Cette conception doit prendre en compte les spécifications fonctionnelles et non fonctionnelles. 3.2.4 Exemple : Le système GPS Pour illustrer la méthodologie présentée, nous allons prendre un exemple traitant partiellement de la conception du système GPS. Une carte GPS dispose d’une base de données locale et obtient la position du GPS lui permettant de se localiser sur la carte. Figure 10:GPS

Besoins pour le GPS  Fonctionnalités : Pour l’automobiliste, il faut montrer les axes principaux et les repères.  Interface utilisateur : il faut : o un écran 400x600 pixels, au moins, o 3 boutons, au maximum, o des menus déroulants.  Performances : la carte doit être balayée en 1 seconde au maximum, après la mise sous tension et le calage sur le GPS en moins de 15 secondes.  Coût : 100 € maximum pour les fournitures et un coût de vente approximatif de 500€.  Taille/poids : le produit doit tenir dans la main.  Consommation : le produit doit fonctionner au moins 8 heures avec 4 piles de type AA. Le modèle de besoins pour le GPS peut être celui présenté par le tableau ci-dessous. Eléments Nom Objectifs Entrées Sorties Fonctions Performances Coût de fabrication Consommation Taille Poids

Descriptions Carte GPS Carte Routière GPS pour automobile 1 bouton on/off, 2 boutons de contrôle LCD 400x600 rétro-éclairé Récepteur GPS, 3 résolutions, affichage latitude et longitude Mise à jour de l’écran 0,25 secondes 100 € (fournitures) 100 mW 5 cm x 12 cm 100 g

18

Spécifications pour le GPS Cette spécification doit comprendre : ce qui est reçu du GPS, les données de la carte, l’interface utilisateur, les opérations nécessaires pour satisfaire à la demande du client, les opérations d’arrièreplan permettant au système de continuer à fonctionner. Conception de l’architecture Les figures 11 (Schéma bloc du système GPS), 12 (Architecture matérielle du système GPS) et 13 (Architecture logicielle du système GPS) décrivent l’architecture de notre système.

Figure 11: Schéma bloc du GPS

Figure 12: Architecture matérielle du GPS

Figure 113: Architecture logicielle du GPS

3.2.5 Les challenges en conception des systèmes embarqués Les concepteurs des systèmes embarqués font face à de nombreux défis dont les plus importants peuvent être résumés comme suit :    



De quoi avons-nous besoin en termes de matériel (hardware) ? : caractéristiques du CPU, taille mémoire. Comment respecter les délais ? : faut-il un hardware rapide, ou un software intelligent ? Comment minimiser la consommation ? : on peut envisager de mettre en sommeil de la logique non utilisée et/ou réduire les cycles d’accès mémoire. La conception fonctionne-t-elle ? : les spécifications sont-elles correctes ? est-ce que la réalisation couvre toutes les spécifications ? comment tester les caractéristiques temps réel ? comment teste-t-on en grandeur nature (avec des données réelles) ? Quelle plateforme de développement utiliser ?

3.3 La réutilisation (Reuse): IP Les systèmes embarqués se sont compliqués et la mise sur le marché se veut plus rapide. La réutilisation est alors indispensable pour faire face à ce défi ; d’où la notion de « Design Reuse et d’Intellectual Property (IP) ». Le principe consiste à développer des « composants virtuels » réutilisables. Le postulat à la base de cette approche est « qu’une compagnie seule ne peut pas toujours produire tous les composants dont elle a besoin ». Il y a donc nécessité d’organiser un commerce de composants virtuels. Cette démarche pose deux problèmes qu’il faut résoudre : 19

 

Nécessité d’instaurer une protection juridique, d’où le terme « Intellectual Property » Nécessité d’utiliser un même formalisme pour la modélisation et l’utilisation pour l’adaptation rapide au système

L’usage et le format des IPs sont présentés par la figure 14.

Figure 14: Usage et format des IPs

Les fournisseurs d’IPs  Sociétés d’études et de conception o Sociétés sans fonderie (« fab ») dont le profit vient des droits sur les licences  DSP Group (IP pour les télécoms), ARM (processeurs RISCs), o offre incluant des IPs SOFT, de simulation et synthèse.  Sociétés de semi-conducteurs o Peuvent fournir des Ips HARD en plus des Ips SOFT o TI, Motorola, Lucent, Altera, Xilinx, LSI Logic, STM  Fournisseurs d’outils de CAO o Fournissent des Ips SOFT uniquement  Mentor Graphics, Cadence, Synopsys,… Types d’IPs généralement disponibles  Processeurs: o Picoblaze, microblaze, Leon, Nios, LSI logic CW4001/4010/4100, ARM 7TDMI, ARM 810, NEC 85x, Motorola 680x0, IBM PPC,…  DSPs: o TI TMS320C54X, Pine, Oak,…  Composants de traitement spécialisés o Cryptographie, traitement d’images, multimédia : JPEGcodec, MPEGdecoder.  Contrôleurs mémoire et bus : SDRAM, USB, PCI, UART, AMBA  Réseaux : ATM, Ethernet 20

Sources d’informations sur les IP  IP commerciales o www.design-reuse.com  IP libres o www.opencore.org

Conclusion Dans ce chapitre, nous avons présenté d’une manière sommaire la conception des systèmes embarqués. Nous avons vu que la conception de tels systèmes diffère de la conception des systèmes informatiques classiques, car ces systèmes impliquent à la fois un aspect matériel (hardware) et un aspect logiciel (software). L’évolution des méthodologies de conception a été présentée et nous avons relevé que la méthode actuellement en cours est le codesign. La complexité croissante des systèmes et le temps de mise sur le marché (TTM : Time To Market) de plus en plus court force à allier le codesign à la réutilisation au moyen des IPs. Nous avons également décrit les défis auxquels font face les concepteurs de systèmes embarqués. La réalisation intégrale d’un système embarqué exige à la fois des compétences informatiques et électroniques qui dépassent le cadre de ce cours. Au terme de la première partie de notre cours, nous pouvons, en guise d’évaluation par rapport aux objectifs fixés au départ, stipuler que l’étudiant qui a suivi le cours est capable de:  Définir un système embarqué (voir section 1.1),  Enumérer les différents types de systèmes embarqués et leurs applications (voir section 1.2),  Décrire et expliquer l’architecture d’un système embarqué (voir chapitre 2),  Cerner les problématiques de conception des systèmes embarqués (voir chapitre 3). La seconde partie du cours nous permettra de réaliser la partie logicielle de systèmes embarqués où le matériel est fixé : un téléphone mobile compatible Android.

21