1. Lepton système d'exploitation
temps-réel pour l'embarqué enfouis.
Philippe LE BOULANGER
Co-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é

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

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

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

5. 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érences
ECOS: eCos, eCos, , http://ecos.sourceware.org
RTEMS: RTEMS, RTEMS, , http://www.rtems.org
POSIX: 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.org
MGBSSI: Michel Gabassi, Bertrand Dupouy, L'Informatique répartie sous Unix,