Lepton système d'exploitation

temps-réel pour l'embarqué enfouis.

Philippe LE BOULANGERCo-Créateur et CTO de la société O10EE

Pour faire suite aux nombreux articles parus dans Linux Magazine et

particulièrement dans la rubrique « Le Labo Open Silicium » abordant souvent

le thème des systèmes embarqués sur des micro-contrôleurs, cet article vous

présente Lepton. Il s'agit d'un petit système d'exploitation temps réel taillé

pour des cibles possédant des ressources matérielles restreintes. Lepton

amène avec lui des possibilités intéressantes qui permettent de développer

rapidement des applications évoluées malgré cette contrainte de puissance de

traitement limitée.

Introduction:

On entend beaucoup parler de systèmes embarqués, de systèmes d'exploitation temps réel. Souvent, ce sont des appareils autonomes avec des puissances de traitement de plus en plus importantes et des ressources mémoires flash et RAM de l'ordre de plusieurs dizaines de méga-octets. Sur ces plateformes matérielles, on retrouve des systèmes d'exploitation évolués, Linux par exemple, ou d'autres systèmes propriétaires ou non. Comme nous l'avait fait remarquer Denis Bodor dans un de ses éditoriaux, les systèmes embarqués qui utilisent des micro-contrôleurs plus modestes en termes de puissance et de mémoire sont un peu oubliés alors qu'ils permettent de réaliser tout un panel d'applications étonnantes, loin des sentiers battus, à peu de frais et à une échelle maîtrisable par un seul individu. Dans ces petits systèmes au ras de l'électronique, on peut apprendre, (re)découvrir des principes de base, développer des solutions astucieuses (pas trop le choix vu les contraintes matérielles).

De nombreux noyaux «temps réel» sont destinés à ce type de cibles. Ils utilisent l'appellation RTOS (RealTime Operating System) et ils font référence à la notion de système d'exploitation dans leur appellation alors que souvent ils n'offrent « que » la partie noyau temps réel (gestion de taches, synchronisations, temporisateurs logiciels), mais pas de gestion de périphériques, de système de fichiers ou de pile protocolaire. Ces services supplémentaires sont disponibles, mais moyennant un petit détour par la caisse enregistreuse et le plus souvent ne font pas preuve d'une réelle intégration.

Cette approche système d'exploitation est présente dans les solutions comme eCos[ECOS] ou RTEMS[RTEMS] . C’est aussi celle de Lepton. Toutefois Lepton ajoute quelques propriétés plus avancées qui le rendent un peu plus proche de système plus imposant sur lesquels il a pris exemple, mais en conservant sa légèreté.

Une des raisons majeures qui a motivé le développement de lepton[LEPTON], est la réutilisation logicielle. Offrir la possibilité de concevoir des briques logicielles et de les réutiliser sur plusieurs développements de produits différents. Partager les évolutions et les résolutions d'anomalies entre les différentes équipes de développeurs. Créer une réelle synergie et par conséquent mettre en place une organisation de développement logiciel dont le moteur central est le système d'exploitation. En résumé, utiliser le modèle de développement que l'on retrouve dans le monde « open source » pour l'appliquer à un projet industriel interne à l'entreprise.

L'interaction des périphériques matériels qui contrôle l'envoi et la réception de données avec la couche logicielle qui réalise le traitement de ces mêmes données peut-être présentées comme point de départ originel du développement de lepton. Ce sera aussi celui de cet article. Nous verrons ainsi comment nous sommes passés d'un développement monolithique, fortement intriqué et très peu réutilisable (voir pas du tout) à une approche plus modulaire. Modulaire et plus évolué certes, mais en préservant au maximum la légèreté et la réactivité du système ainsi que les propriétés du noyau temps-réel sur lequel il est basé.

1. Historique

Pour expliquer la genèse de ce projet, il est, je pense, judicieux d'en rappeler le contexte. Ce projet a été

initié au sein d'une entreprise qui développe des appareils de mesure pour un secteur essentiellement industriel. Ces appareils sont pour la plupart portables et amenés à fonctionner dans des environnements ou leur robustesse est mise régulièrement à l'épreuve. Des contraintes sur la taille des appareils et leur autonomie obligent à utiliser des micro-contrôleurs de basse consommation avec peu de puissance de calcul et des capacités mémoires faibles. À chaque nouvelle étude, peu de chose était repris des développements précédents, essentiellement pour des raisons d'architecture logicielle. Cette dernière était souvent monolithique avec un enchevêtrement inextricable entre le code en charge de la mesure et celui qui assure la gestion des périphériques d'entrées et de sorties.

Nous avons d'abord isolé l'ensemble des fonctionnalités qui nous semblaient les plus transversales sur tous les appareils jusqu'alors réalisés. Il est rapidement apparu que c'était majoritairement les fonctionnalités de communication avec l'environnement extérieur des appareils. Communication avec d'autres appareils (liaison série RS232 ou RS485, réseau informatique, réseau industriel…) ou avec l'utilisateur (clavier, écran graphique, terminal).

Le premier objectif que nous nous étions fixé consistait à obtenir une utilisation le plus générique possible des périphériques d'entrées et de sorties et ainsi diminuer le couplage entre les «briques» logicielles et le matériel sur lequel elles seraient utilisées. Disposer aussi de mécanismes simples qui permettent leur intégration naturelle et rapide pour une réutilisation qui le sera tout autant.

Alors, pourquoi avoir choisi de développer en interne une telle solution plutôt que de réutiliser des solutions déjà existantes comme eCos ou RTEMS par exemple? Il faut remonter à plus d'une dizaine d'années, les produits développés utilisaient encore des micro-contrôleurs 8 bits et nous commencions à basculer vers du 16 bits. Les empreintes mémoires étaient par conséquent très réduites, une trentaine de kilo-octets de mémoire vive et quelques centaines de kilo-octets pour le code.

Nous n'avions alors que peu de recul sur l'utilisation dans le monde industriel de solutions logicielles issues de l'open source. Le système eCos était encore peu répandu et supportait uniquement des architectures 32 Bits. Nous nous sommes résolus à développer notre propre solution en utilisant un noyau temps réel propriétaire.

La première version de notre « système d'exploitation » proposait une gestion de périphériques, de fichier et du réseau. Nous avions commencé son développement en septembre 2001 et fut achevé environ 6 mois plus tard. Malheureusement les fonctions et appels systèmes proposés manquaient de cohérence. Il y avait une interface logicielle dédiée à la gestion de périphérique, une autre pour les fichiers et encore une autre pour le réseau. Cette solution certes fonctionnait, mais ce n'était pas encore ce que nous recherchions. Il était nécessaire de s'inspirer de systèmes d'exploitations évolués malgré leurs exigences en ressources matérielles qui étaient à des années-lumière de ce que nous pouvions espérer.

Toujours sur la même base de noyau temps-réel, dans le courant de l'année 2003, la première version de lepton tournait enfin sur une cible réelle, un micro-contrôleur Renesas M16c62p avec 30 Kilo-octets de mémoire RAM et 256 Kilo-octets de Flash. Cette version intégrait les gestions de processus, de périphériques, et les systèmes de fichiers par l'intermédiaire d'un VFS. Le premier processus lancé fut l’« init » suivi d'un petit interpréteur de commandes.

Les évolutions logicielles suivantes ont fini de débarrasser les dernières dépendances à des solutions propriétaires. L'environnement de développement est dorénavant sous une distribution GNU/Linux et la partie noyau temps-réel fait appel à eCos. Nous avons ainsi maintenant une version de lepton complètement open source, que ce soit pour lepton lui-même, certaines briques logicielles dont il est aujourd'hui constitué (noyau temps réel, pile réseau, librairie graphique…) et pour finir son environnement de développement (GNU Tools chain).

Tout au long de ce processus d'évolution, le matériel lui aussi a suivi la tendance. Nous sommes passés d'une architecture 16 bits à 32 bits avec des micro-contrôleurs intégrant un cœur ARM. Cette migration matérielle nous a permis d'évaluer la capacité de portage de lepton entre ces deux architectures matérielles. Les applications développées sur lepton sur les architectures 16bits n'ont nécessité que très peu de modifications (quelque effets de bord avec les « typages » de données dépendant de l'architecture) et pour la majeure partie aucune. Le portage fut donc réalisé très rapidement, une demi-journée, le temps d'écrire un pilote de périphérique pour la liaison série UART afin de pouvoir interagir avec l'interpréteur de commande.

Aujourd'hui lepton est à disposition de la communauté open source et son utilisation libre sous licence mixte ePL (eCos Public License) et MPL v1 (Mozilla Public License).

2. Architectures

Pour créer lepton nous avons donc fait le tour des architectures de système d'exploitation et sélectionner celles qui pourraient servir nos objectifs. Pour des raisons de concision et ainsi éviter l'écriture d'un roman je

résume la démarche au travers de quelques points clés qui me semble être les plus significatifs et qui, je l'espère, pourront vous éclairer sur notre démarche et nos choix.

Les schémas de la figure 1 représentent différentes architectures logicielles possibles pour développer une application embarquée, disons « baremetal ». Ce n'est pas exhaustif, mais ce sont celles que nous avons rencontrées.

// Image : shell-illustration.png ///

Fig. 1 : Illustration des architectures logicielles possibles.

/// Fin légende ///

La première de ces architectures (fig1.a) est celle que l'on retrouve assez souvent sur les petits systèmes. C'est une architecture monolithique avec une forte intrication entre le code qui réalise le traitement des données et celui qui prend en charge leur réception et émission par l'entremise de périphériques matériels de communication.

La seconde (fig1.b) propose une séparation entre la partie traitement des données et celle qui assure la communication. Cette partie communication est scindée en plusieurs modules logiciels chacun ayant sa spécificité et une interface dédiée pour accéder aux fonctionnalités proposées. C'est ce type d'organisation que l'on retrouve souvent notamment dans les solutions commerciales, avec un paquet noyau temps-réel, un autre orienté réseau, ou système de fichier, etc. On ne retrouve pas d'intégration homogène de toutes ces fonctionnalités.

La suivante (fig1.c) illustre quant à elle une approche plus structurée. On obtient une organisation clairement séparée. D'un coté le traitement des données que l'on peut appeler « application » et d'un autre coté des flux de données. Le contrôle et l'accès à ces flux de données sont à présent complètement génériques. Les interfaces d'accès sont identiques quelques soit la nature du matériel qui permet de faire transiter ces flux de données (ex :liaison série, réseau, système de fichier, spi, i2c...).

Cette dernière approche est celle que nous avons choisie afin d'obtenir le couplage minimum entre la partie qui utilise les données à des fins de traitements logiciels (filtrage, conversion, affichage…) et celle qui les achemine matériellement.

2.1 Comment contrôler et utiliser les périphériques ?

Première étape, définir une interface de programmation qui permette depuis la partie logicielle en charge du traitement des données (l'application) de manipuler facilement les périphériques d'entrées et de sorties. Les opérations de base que l'on utilise le plus souvent sur un périphérique peuvent être réduites à la liste suivante

- 1: Désigner et réserver le périphérique à utiliser,

- 2: Lire des données en provenance de ce périphérique,

- 3: Écrire des données vers ce périphérique,

- 4: Libérer le périphérique,

- 5: Configurer le périphérique.

mesure sont écrits sur la sortie standard dans un format texte humainement compréhensible, avec par exemple la fonction printf() et au format binaire, la structure de résultat dans le fichier msr.o. Le processus 4 est utilisé par l'application ihm en charge de l'affichage sur un écran graphique des résultats de mesure contenu dans ce fichier msr.o. L'application msr dans cet exemple est lancé par l'utilisateur depuis un terminal connecté sur une liaison série et par l'intermédiaire de l'interpréteur de commande. Mais il pourrait tout aussi bien être lancé depuis l'application ihm ou encore, en réutilisant l'exemple précédent, par une requête HTTP demandant l’exécution d'un script cgi. Nous avons trois possibilités pour interagir avec l'application mesure en réutilisant totalement plusieurs applications.

Dans chacun de ces exemples l'application lsh est indépendante du contexte d'utilisation, son code n'a jamais été modifié spécifiquement pour s'adapter à chaque situation. Le code est resté totalement générique.

Autres conséquences la portabilité sur des architectures matérielles différentes. La capacité de portage s'est considérablement accrue notamment via l'utilisation de couche d'abstraction matériel et de la gestion de périphérique qui permettent un découplage entre les couches purement logicielles et celle en charge du matérielles et des périphériques.

7 Conclusion

Il est difficile en quelques pages faire le tour de lepton et encore plus des concepts utilisés sur les systèmes UNIX. J'espère toutefois avoir montré (peut-être démontré) l'intérêt de cette approche qui devient à présent, avec lepton, un peu plus accessible sur de petits systèmes embarqués. Il y a un petit côté retour vers le futur, puisque ce type d'architecture existe depuis 40 ans. Donc en ce qui nous concerne nous n'avons rien inventé. Juste transposé ce qui existait alors sur des architectures matérielles relativement puissantes vers des micro-contrôleurs récents avec des capacités mémoires de quelques dizaines de kilo-octets.

Lepton n'a pas pour objectif de devenir GNU/Linux. Il est développé pour les contextes matériels où GNU/Linux ne peut pas trouver sa place. Lepton est à GNU/Linux ce que le karting est à la berline de luxe. Il est au ras de l'électronique tout en proposant des fonctionnalités avancées, mais sans toutes les options. Les mécanismes évolués de gestion et protection mémoire comme la MMU ne sont pas implémentés. Il est par conséquent très léger et réactif, mais toute erreur de programmation occasionnera une sortie route (crash du système).

C'est un découpage en fonctionnalités élémentaires qui autorise l'organisation logicielle modulaire de lepton. Ce découpage permets d'obtenir un code réutilisable, une meilleure portabilité et un développement, il me semble, plus agréable. Le couplage entre les modules qui le constitue est suffisamment faible pour autoriser des modifications et évolutions tout en limitant l'impact sur l'ensemble du système. Lepton peut être vu comme une sorte de structure d’accueil pour des briques logicielles et en facilité l'utilisation. C'était son objectif et il utilise déjà de nombreuses briques du monde open source comme les piles protocolaire IP des projets uIP et lwIP, le système de fichier yaffs, les librairies graphiques comme nanox et fltk, le serveur web mongoose.

La dimension environnement de développement n'a pu être réellement abordée dans cet article. C'est un aspect qui a été pris en compte dès le début de la conception de l'architecture. L'organisation des fichiers sources et des scripts de compilation permettent de se faire rapidement une idée du fonctionnement du système et de son orientation transversale. L'intégration de son développement dans l’arborescence de lepton se fait naturellement. L'article de Jean-Jacques Pitrolle sur la mise en place de l'environnement de développement explique comment réaliser cette opération.

Toute personne souhaitant contribuer peut rapidement intégré sont projet dans lepton, que ce soit au niveau application, noyau, système de fichier, pilote de périphérique ou support de nouveau micro-contrôleur. Les contributions pourront être rapidement réutilisées et mises en oeuvre dans le cadre de nouveau développement de produit.

Actuellement le système lepton est utilisé sur environ une douzaine de modèles d'appareils de mesure différents. Leur application va du multimètre haut de gamme graphique à l'oscilloscope portable. De nouveaux projets sont en cours de développement. Chacun de ces projets a amené de nouvelles fonctionnalités qui ont pu être intégralement utilisées sur les autres. La fiabilité aussi s'est améliorée par une plus grande utilisation du système dans des situations différentes ce qui permet d'obtenir une plus grande couverture de code. Plusieurs équipes travaillent depuis une base centralisée et y remontent régulièrement les corrections d'anomalies et améliorations. C'est ce modèle intraentreprise que nous souhaitons exporter avec la mise à disposition de lepton en open sources.

Lepton supporte actuellement près de 150 fonctions et appels système du standard POSIX. Nous l'avons utilisé sur des micro-contrôleur 16 bits et 32 bits, avec des cœurs ARM7, ARM9 et plus récemment sur du Cortex M3 et M4.

Plusieurs améliorations sont envisagées. Notamment la gestion de la protection mémoire avec les dispositifs matérielle comme la MPU que l'on retrouve désormais sur de nombreux micro-contrôleur (notamment ARM Cortex-M4). Le développement de son propre noyau temps-réel. Un projet en ce sens est en cours d'investigation. Le support de l'interface POSIX pour la gestion asynchrone des entrées et sorties. Le code reloger dynamiquement qui permettrait d'obtenir des fichiers exécutables et de réels processus. L'utilisation de QEMU pour l'émulation.

RéférencesECOS: eCos, eCos, , http://ecos.sourceware.orgRTEMS: RTEMS, RTEMS, , http://www.rtems.orgPOSIX: THE OPEN GROUP, The Single UNIX Specification, Version 4, , http://www.unix.org/version4/ATNBM: Andrew Tanenbaum, Systèmes d'exploitation, JMRFFLT: Jean-Marie Rifflet, Jean-Baptiste Yunes, UNIX : Programmation et communication, CBLSS: Christophe BLAESS, Programmation système en C sous Linux, LWIP: lwIP, lwIP, , http://savannah.nongnu.org/projects/lwip/uIP: Contiki, Contiki, , http://www.contiki-os.orgMGBSSI: Michel Gabassi, Bertrand Dupouy, L'Informatique répartie sous Unix,