Embedded LINUX (part 1)

Linux embarqué

===========

Préambule

La lecture de cet article nécessite des notions de programmation en langage C et en langage de script Unix (Bourne Shell), ainsi que quelques connaissances générales en informatique industrielle.
Les sources complets des exemples présentés sont disponibles en téléchargement sur le site d’accompagnement du livre à l’adresse:
http://www.editions-eyrolles.com.

Au niveau des exemples de réalisation, j'ai porté un
regard particulier sur la Freebox développée par Free SA. Le célèbre terminal de connexion
multimédia du premier opérateur Internet français est à ce jour un exemple d’innovation,
d’autant que c’est un pur produit de l’Hexagone.


Due to its low cost and ease of customization, Linux has been shipped in many consumer devices. Devices covering PDAs (like the Sharp Zaurus family), TomTom GPS navigation devices, residential gateways like the Linksys WRT54G series or smartphones: the Motorola exz series, the Openmoko handsets, the Nokia N900 and Nokia N9 cell phones were all using the Linux kernel. Nowadays the operating system that dominates the cell phone market is the Android operating system which is based on a modified Linux kernel along with a custom user space. The first device shipping with the Android operating system was the HTC Dream, which was released on 22 October 2008.

On machine control systems, industrial automation, and medical instruments Linux has also been used extensively. The website LinuxForDevices has many examples of such devices shipping with an embedded Linux as the operating system.

Introduction

Linux est un système d’exploitation multitâche de la famille Unix.
Linux est conforme à la norme Posix, ce qui signifie que les programmes développés sous Linux peuvent être recompilés facilement sur d’autres systèmes d’exploitation compatibles Posix.
Le système d’exploitation Linux est libre, le code source des différents composants du système est disponible gratuitement sur le réseau Internet(sous licence GPL).

Dans les cas les plus classiques d’utilisation de Linux, il est cependant possible de n’utiliser que des composants libres comme le serveur HTTP Apache, les langages de programmation Perl, PHP ou Python, ou bien les systèmes de base de données MySQL et PostgreSQL pour ne citer que les plus connus.
Linux est aujourd'hui bien implanté dans le monde des serveurs.

Systèmes embarqués - généralités

Un logiciel embarqué (embedded software en anglais) est un programme utilisé dans un équipement industriel ou un bien de consommation.
L’équipement est valorisé uniquement par son aspect fonctionnel et un bon
logiciel intégré le sera à un tel point qu’on finira par l’oublier.
Les concepteurs de logiciels embarqués sont rarement des informaticiens purs, plus souvent des êtres hybrides entachés de neurones d’électroniciens.
Dans la majorité des cas, un tel logiciel n’utilise pas les interfaces classiques clavier/souris propres à la micro-informatique.
S’ils existent, les périphériques d’affichage sont souvent limités à des panneaux de petite taille de type LCD (Liquid Crystal Display), et les périphériques d’entrée à quelques boutons poussoirs ou autres composants inhabituels dans l’informatique traditionnelle.
Attention un logiciel embarqué doit être optimisé:
"Software becomes slower faster than hardware becomes faster".

Alors que la micro-informatique a débuté avec 1 kilo-octet de mémoire vive et un système sur 8 Ko de ROM, il n’est pas rare aujourd’hui de voir des adolescents
pester contre le PIII de l’année précédente qui n’affiche pas assez vite les formes plantureuses de Lara Croft.
L’exemple le plus flagrant de cette course à la consommation est bien entendu les différentes moutures du système Microsoft Windows et les applications associées pour lesquelles chaque version est systématiquement accompagnée d’une augmentation de taille, compensée bien sûr par l’achat de quelques giga-octets de disque dur ou d’une barrette de mémoire supplémentaire.

Nous avons pour l’instant parlé de logiciel embarqué alors qu’il est fréquent d’entendre la terminologie de système embarqué. Cette terminologie désigne le plus souvent un système d’exploitation, version complexe et multi-usage du concept de logiciel.

Avantages

Les avantages de l’utilisation d’un système d’exploitation sont les suivants :

• Comme dans le cas du développement de logiciel classique, il affranchit le développeur de l’applicatif embarqué d’un travail d’adaptation très proche du matériel, ce qui permet de diminuer le temps de développement et donc les coûts. L’écriture du support de standards du marché comme les bus PCI ou USB est extrêmement lourde en cas de non-utilisation d’un système d’exploitation.
• Si le système d’exploitation utilisé est suffisamment répandu, il permet aux applications industrielles et embarquées de bénéficier des mêmes avancées technologiques que les applications classiques. C’est ainsi qu’il est aujourd’hui possible d’utiliser dans des systèmes réduits des protocoles de communication hérités de l’informatique classique et du multimédia.
L’utilisation d’un système d’exploitation qui inclut un support natif et largement
débogué de ces protocoles est alors un bien meilleur choix car le support d’un protocole se réduira le plus souvent à l’ajout d’un module ou d’un programme externe déjà testé, comparé aux nombreuses heures de mise au point nécessaires à la mise en place d’une version « maison ».
Remarque:
HTTP est le protocole utilisé pour le transfert des données multimédias entre un serveur web et un poste client équipé d’un navigateur ou browser. Plus ancien, le protocole FTP est lui réservé au simple transfert de fichier.
L’utilisation dans l’embarqué de ces protocoles standards en remplacement de protocoles propriétaires facilite l’interopérabilité des systèmes.

• Les systèmes d’exploitation fournissent en général un environnement de développement facilitant la mise au point des programmes dans un contexte beaucoup plus accueillant et performant que le système cible – celui sur lequel est censé tourner le programme définitif.
Un exemple industriel célèbre est celui de la PlayStation2 de SONY. Les développeurs de jeux ne pouvant disposer de la console définitive immédiatement, ils utilisèrent un environnement de développement basé sur Red Hat Linux permettant de simuler le fonctionnement de la console sur des stations de travail.

Inconvénients

Le principal inconvénient de l’utilisation d’un véritable système d’exploitation proche d’un système classique est la taille mémoire nécessaire. Il est bien évident que, si l’espace disponible est réduit à quelques centaines d’octets pour accomplir une tâche rudimentaire, un vrai système d’exploitation ne s’imposera pas.

Champs d'application

D’un point de vue technique, le champ d’application peut être grossièrement divisé en deux grandes familles :
• le contrôle de processus sans contrainte ou à faible contrainte temps réel (on pourra envisager l’utilisation d’un système d’exploitation dérivé d’un système classique comme Linux. L’adaptation se situera principalement au niveau du développement de pilotes de périphériques et de l’optimisation du système en taille ou en performances.

• le contrôle de processus avec contrainte temps réel. Les contraintes matérielles nécessiteront l’utilisation de composants spécialisés, soit un logiciel spécifique, soit un système d’exploitation dit temps réel (Real Time Operating System ou RTOS).

Typologie des systèmes embarqués

Un système d’exploitation classique comme Unix, Linux ou Windows utilise la notion de temps partagé, par opposition au temps réel. Dans ce type de système, le but de l’ordonnanceur est de donner à l’utilisateur une impression de confort d’utilisation tout en assurant que toutes les tâches demandées sont finalement exécutées. Ce type d’approche entraîne une grande complexité dans la structure même de l’ordonnanceur qui doit tenir compte de notions comme la régulation de la charge du système ou la date depuis laquelle une tâche donnée est en cours d’exécution.

La notion de priorité entre les tâches est peu prise en compte, car l’ordonnanceur a pour but premier le partage équitable du temps entre les différentes tâches du système. Notez que sur les différentes versions d’Unix dont Linux, la commande nice permet de modifier la priorité de la tâche lors du lancement.
Ensuite, les différentes tâches doivent accéder à des ressources dites partagées, ce qui entraîne des incertitudes temporelles. Si une des tâches effectue une écriture sur le disque dur, ce dernier n’est plus disponible pour les autres tâches à un instant donné et le délai de disponibilité du périphérique n’est pas prévisible.

Rappel:
La gestion des ressources partagées entre différentes tâches se fera grâce à des composants appelés sémaphores.

En outre, la gestion des entrées/sorties peut générer des temps morts, car une tâche peut être bloquée en attente d’accès à un élément d’entrée/sortie.

La gestion des interruptions reçues par une tâche n’est pas optimisée. Le temps de latence – soit le temps écoulé entre la réception de l’interruption et son traitement – n’est pas garanti par le système. Par comparaison, le temps de latence dans le cas d’un système temps réel est souvent inférieur à 100us.

Enfin, l’utilisation du mécanisme de mémoire virtuelle peut entraîner des fluctuations dans les temps d’exécution des tâches.
Rappel:
La mémoire virtuelle permet au système de disposer d’une quantité de mémoire, supérieure à la quantité de mémoire vive réellement disponible. Le système pourra pour cela utiliser des espaces dédiés sur la mémoire de masse afin de simuler une mémoire virtuelle. L’inconvénient en sera bien sûr une forte dégradation des performances.
Toutes ces limitations font que le temps de réponse d’un système classique n’est pas garanti.

Un système est dit temps réel lorsqu’il est soumis à des contraintes de temps et qu’il y répond dans un intervalle acceptable.
On pourra diviser les systèmes temps réel en deux catégories :
• Les systèmes dits à contraintes souples ou molles (soft real time). Ces systèmes acceptent des variations dans le traitement des données de l’ordre de la demi-seconde (ou 500 ms) ou la seconde. On peut citer l’exemple des systèmes multimédias : si quelques images ne sont pas affichées, cela ne met pas en péril le fonctionnement correct de l’ensemble du système. Ces systèmes se rapprochent fortement des systèmes d’exploitation classiques à temps partagé.
• Les systèmes dits à contraintes dures (hard real time) pour lesquels une gestion stricte du temps est nécessaire pour conserver l’intégrité du service rendu. On citera en guise d’exemples les contrôles de processus industriels sensibles comme la régulation des centrales nucléaires ou les systèmes embarqués utilisés dans l’aéronautique.

Commutation de contexte

Le noyau (kernel) est le composant principal d’un système d’exploitation multitâche moderne. Dans un tel système, chaque tâche (ou processus) est décomposée en threads (processus léger ou tâche légère) ; ce sont des éléments de programmes, chacun étant capable d’exécuter une portion de code dans un même espace d’adressage. Chaque thread est caractérisé par un contexte local contenant la priorité du thread, ses variables locales ou l’état de ses registres. Le passage d’un thread à un autre est appelé changement de contexte (context switch). Ce changement de contexte sera plus rapide sur un thread que sur un processus car les threads d’un processus évoluent dans le même espace d’adressage, ce qui permet le partage des données entre les threads d’un même processus.
Dans certains cas, un processus ne sera composé que d’un seul thread et le changement de contexte s’effectuera sur le processus lui-même.

Remarque:
Dans le cas du système Linux, le même appel système clone() est utilisé pour créer un processus ou un thread. La primitive fork() de création de processus correspond en fait à clone(0, SIGCLD|COPYVM).

Dans le cas d’un système temps réel, le noyau est dit préemptif, c’est-à-dire qu’un thread peut être interrompu par l’ordonnanceur en fonction du niveau de sa priorité, et ce afin de permettre l’exécution d’un thread de plus haut niveau de priorité. On peut ainsi affecter les plus hauts niveaux de priorité à des tâches dites critiques par rapport à l’environnement réel contrôlé par le système. La vérification des contextes à commuter est réalisée de manière régulière par l’ordonnanceur en fonction de l’horloge logicielle interne du système, ou tick système.
Dans le cas d’un noyau non préemptif, un thread sera interrompu uniquement dans le cas d’un appel au noyau ou d’une interruption externe. La notion de priorité étant très peu utilisée (excepté avec la commande nice dans le cas de Linux), c’est le noyau qui décide ou non de commuter le thread actif en fonction d’un algorithme complexe.

Extensions Posix

Posix est l’acronyme de Portable Operating System Interface ou interface portable pour les systèmes d’exploitation.
Un programme qui est destiné à un système d’exploitation qui respecte Posix doit pouvoir être adapté à moindre frais sous n’importe quel autre système Posix.
En théorie, le portage d’une application d’un système Posix vers un autre doit se résumer à une compilation des sources du programme.

Empreinte mémoire

Par définition, l’empreinte est la taille mémoire occupée par le système. Même si ce n’est pas une obligation, les systèmes embarqués ont en général une faible empreinte, et ce afin d’optimiser le système tant au niveau des coûts que de la sécurité de fonctionnement. La réduction de l’empreinte mémoire est la tâche principale d’un développeur de système embarqué car elle a un impact économique énorme sur l’industrialisation finale du produit.
Il faut faire la différence entre l’empreinte mémoire du système d’exploitation et celle des données.
Dans certains cas, on pourra par sécurité avoir un système d’exploitation réduit à quelques (Mo) sur une mémoire morte et dans d'autres cas un disque dur de plusieurs dizaines ou centaines de (Go) destiné à recevoir les données.

Langages utilisés

Les langages C et C++ restent aujourd’hui le choix favori des développeurs en partie à cause des liens privilégiés du langage C avec les standards Posix et les systèmes de type Unix. Historiquement, le langage C est également un langage permettant une programmation relativement proche du matériel, donc bien adaptée au logiciel embarqué.
La contrainte principale étant le plus souvent l’empreinte mémoire, la programmation en langage C nécessite d’utiliser le compilateur de la manière la plus efficace possible, et ce en utilisant au maximum les options d’optimisation adaptées au matériel.
Dans le cas du compilateur GNU gcc (GNU C Compiler), on notera en particulier les options suivantes
-O3, -O2, -O3, selon le niveau d’optimisation, et -Os qui permet d’optimiser le code afin de minimiser sa taille.
Des options spécifiques au processeur utilisé comme -m386 ou -mpentium permettront également d’adapter le code au matériel utilisé.
Dans le cas de l’utilisation de systèmes de type Unix (UNIX-like), on pourra également employer d’autres langages de programmation ou langages de scripts en particulier le shell-script, langage de script d’Unix (ou Bourne shell), qui associé à d’autres commandes pourra se révéler très utile dans l’écriture de procédures système. Le résultat sera le plus souvent plus facile à maintenir qu’un programme écrit en langage C et surtout ne nécessitera pas de recompilation avant exécution sur un autre système de type Unix.
D’autres produits encore plus réduits, comme BusyBox permettent d’intégrer des versions simplifiées d’un bon nombre de commandes Unix dans seulement 150 kilo-octets.
D’autres langages de scripts célèbres dans le monde Unix comme Perl, Tcl/Tk ou Python sont eux assez peu utilisés dans les environnements embarqués de par l’espace mémoire nécessaire à leur installation et à leur fonctionnement.

Les langages les plus répandus dans le monde de l’embarqué sont le C, le C++ et l’assembleur.
L’empreinte mémoire d’un système embarqué peut varier de 64 Mo à 0,1 Mo. On parle alors de système profondément enfoui.

Tour d’horizon des systèmes existants

Rappel:
Un environnement de compilation croisé permet de développer pour le système cible sur une autre machine
dans un environnement plus confortable. On peut citer par exemple la disponibilité sous Linux d’un environnement de développement pour PalmOS, basé sur le compilateur GNU gcc.

• VxWorks et pSOS 

VxWorks est aujourd’hui le noyau temps réel le plus utilisé dans l’industrie. VxWorks inclut en natif un support TCP/IP et une interfacede programmation intégrant les sockets. Le gros inconvénient de ces deux systèmes est le coût important des licences. Il est également nécessaire d’utiliser un environnement de compilation croisé.

• QNX

QNX est un noyau temps réel de type Unix très intéressant. Il est parfaitement conforme à Posix, permet de développer directement sur la plate-forme cible et intègre l’environnement graphique Photon.

QNX peut être utilisé gratuitement pour des applications non commerciales. Il peut occuper une très faible empreinte mémoire et, de ce fait, peut être utilisé dans des environnements très réduits comme les téléphones portables GSM Timeport de chez Motorola.

• Windows CE, μC/OS et μC/OS II, etc...

Linux comme système embarqué

Les trois points suivants de la définition du logiciel Open Source sont fondamentaux dans le cas du logiciel embarqué :
• redistribution sans royalties ;
• disponibilité du code source ;
• possibilité de réaliser un développement dérivé de ce code source.

La disponibilité du code source est encore plus fondamentale car elle est la base de la conception d’un logiciel de qualité et surtout maintenable dans le temps.
La documentation des logiciels Open Source largement répandus comme Linux est souvent de très bonne qualité car elle a pu bénéficier d’un gros travail collaboratif.

Fiabilité
Le fameux kernel panic (erreur fatale du noyau) tant redouté par les développeurs est un animal rare, presque autant que le Yéti ou le monstre du LochNess. Une erreur de ce type s’explique toujours par un problème matériel ou une erreur de programmation dans un pilote de périphérique. Ces derniers travaillant dans un espace privilégié appelé « espace noyau » (kernel space ou kernel level), ils sont les seuls à pouvoir provoquer ce type d’erreur.
Les autres applications travaillent dans l’espace dit utilisateur (user space ou user level) et n’ont pas les droits nécessaires à la génération de ce type d’erreur.
La fiabilité de Linux est démontrable au moyen de la commande uptime qui permet d’afficher le temps d’activité du système depuis le dernier redémarrage. La couche TCP/IP de Linux, au cœur de nombreuses applications embarquées communicantes, est également d’une grande fiabilité.
Faible cout:
Linux est non seulement exempt de royalties mais les outils de développement sont également disponibles sous GPL. Le seul effort financier nécessaire à l’adoption de Linux se situe sur la formation – souvent indispensable – et le support technique.
Performance:
De nombreux tests comparatifs (benchmarks) entre Linux et d’autres systèmes concurrents comme Windows NT on démontré la supériorité de Linux.
Portabilité et adaptabilité:
Linux est aujourd’hui porté sur un très grand nombre de processeurs et d’architectures matérielles, y compris des processeurs de faible puissance, comme le démontre le projet μClinux. Même si le processeur ou l’architecture que vous désirez utiliser ne figurent pas dans la liste des portages actuels, l’énorme base de connaissance disponible facilitera le travail et vous pourrez souvent vous inspirer de travaux déjà réalisés.
La structure modulaire de Linux héritée de l’architecture Unix est également un de ses gros avantages. La structure du système est stricte et clairement définie, et il sera aisé de le configurer de manière à trouver une correspondance exacte avec les besoins requis.
Ouverture:
Linux cohabite facilement avec d'autres OS installés sur la même machine comme Windows, alors que le contraire n'est pas forcément vrai.

Choix matériels pour un système Linux embarqué

 

Le concept du MMU

Linux a été initialement développé sur la base du mécanisme de mémoire protégée du processeur Intel 80386. Ce mécanisme, qui repose sur un composant matériel appelé MMU (Memory Management Unit), permet à un processus de ne jamais écraser l’espace mémoire d’un autre processus. La MMU autorise la conversion entre les adresses physiques – adresses effectivement utilisées dans la machine – et les adresses logiques – adresses vues par le
processus et allouées par le système d’exploitation.
Si un processus tente de sortir par erreur de l’espace mémoire qui lui est accordé, la MMU détecte l’erreur et stoppe le programme en générant une erreur de « violation de segmentation » (segmentation violation ou SIGSEGV). De ce fait, un programme tournant sous Linux dans l’espace dit « utilisateur » – par opposition à l’espace « noyau » – ne peut jamais « planter » le système.
Les versions courantes du noyau Linux sont prévues pour fonctionner sur des processeurs avec MMU, ce qui concerne la majorité des processeurs utilisés dans la micro-informatique classique et aussi dans un bon nombre d’applications embarquées. En revanche, ces processeurs sont en général plus gourmands en ressources matérielles, et certaines applications dites « profondément enfouies » (deeply embedded) ne pourront utiliser que des processeurs dépourvus de MMU.
Il existe bien entendu des systèmes d’exploitation dédiés à ces micro-contrôleurs – μC/OS en est un très bon exemple – mais ceux-ci sont en général bien plus limités que Linux au niveau des protocoles standards et de l’interopérabilité avec le monde extérieur.

μClinux: Linux sans MMU

Un portage du noyau Linux est cependant disponible pour les processeurs dépourvus de MMU : μClinux – pour Micro-C Linux (Linux pour micro-contrôleurs) mais à prononcer You see Linux (http://www.uclinux.org). Le portage est initialement basé sur la version 2.0.38 du noyau Linux mais des versions basées sur les noyaux 2.4 et 2.6 sont également disponibles.
L’API du système est identique au vrai noyau Linux bien que μClinux utilise une libC – bibliothèque de base de programmation – différente de la glibc de la version standard de Linux. La motivation est toujours la même : le gain d’espace, lorsqu’on sait que les versions récentes de la glibc ont une taille largement supérieure au méga-octet. La principale limitation de μClinux par rapport à Linux est l’absence de protection de mémoire entre les processus mais également avec le noyau. De ce fait, une application erronée pourra facilement « planter » le système.

Les system on Chip

A system on a chip or system on chip (SoC or SOC) is an integrated circuit (IC) that integrates all components of a computer or other electronic system into a single chip. It may contain digital, analog, mixed-signal, and often radiofrequency functions—all on a single chip substrate.
A typical application is in the area of embedded systems.

The contrast with a microcontroller is one of degree. Microcontrollers typically have under 100 kB of RAM (often just a few kilobytes) and often really are single-chip-systems, whereas the term SoC is typically used with more powerful processors, capable of running software such as the desktop versions of Windows and Linux, which need external memory chips (flash, RAM) to be useful, and which are used with various external peripherals. In short, for larger systems, the term system on a chip is hyperbole, indicating technical direction more than reality: increasing chip integration to reduce manufacturing costs and to enable smaller systems. Many interesting systems are too complex to fit on just one chip built with a process optimized for just one of the system's tasks.

For instance, the Samsung Galaxy S II has a 1.2 GHz dual core ARM Cortex-A9 processor(équivalent microcontrolleur) that uses Samsung's own 'Exynos 4210' System on a chip (SoC).

###########################################################

Bibliographie

• Linux embarqué (2e edition - Eyrolles)
• wikipédia
  

SERGE ABOU-SALEH

Author & Editor

Senior software engineer with 12 years of experience in both embedded systems and C# .NET