L'augmentation continue de la puissance de calcul, des fonctionnalités présentes et des empreintes mémoires (RAM, FLASH, ROM...) des processeurs 32 bits tend à créer une classe de processeurs hybrides :
- ils sont suffisamment puissants pour exécuter des tâches complexes (réseau, affichage...) ;
- ils sont trop petits pour faire fonctionner de façon raisonnable les systèmes d'exploitation Open Source classiques (GNU/Linux, Android, *BSD...).
Les architectures Cortex-M3 et Cortex-M4 d'ARM rentrent clairement dans cette catégorie.
Même si il existe un portage de uClinux sur STM32 (ici et là), il est indispensable de posséder une mémoire externe de plusieurs dizaines de mégaoctets (mémoire interne de l'ordre de centaines de Kio).
Dans cette optique nous avons décidé de publier le code source de Lepton/Tauon sous licence MPL/EPL (au moment de cette rédaction il s'agit de la MPL 1.1).
Lepton/Tauon est un système d'exploitation temps réel (RTOS, pour Real Time Operating System) qui tente de respecter au maximum le standard POSIX (« POSIX compliant ») tout en gardant à l'esprit les contraintes :
- d'empreinte mémoire ;
- de fiabilité ;
- de simplicité ;
- de portabilité.
Le micrologiciel (firmware) généré se présente sous la forme d'un ELF contenant :
- le noyau ;
- les pilotes de périphériques ;
- les bibliothèques ;
- les pseudo-binaires systèmes et utilisateurs.
Sommaire
Description générale
Lepton/Tauon ajoute une couche d'abstraction au-dessus d'un système d'exploitation temps réel.
Deux variantes existent donc, Lepton qui se base sur embOS de Segger (propriétaire) et Tauon qui est basé sur eCos (Open Source). Lepton, nom original du projet, signifie léger.
eCos, base de Tauon, est le RTOS sous-jacent qui fournit :
- le Hardware Abstraction Layer (HAL) permettant le démarrage et le fonctionnement sur une nouvelle architecture. Il peut être fourni ou à développer ;
- un mécanisme de gestion d'interruptions ;
- l'ordonnancement des tâches du RTOS ;
- les mécanismes basiques de synchronisation (sémaphores, mutex...) ;
- certaines bibliothèques standards (math.h, stdlib.h, string.h...).
Lepton/Tauon enrichit considérablement le RTOS utilisé. Il permet :
- l'utilisation de plus de 150 fonctions POSIX (IEEE Std 1003.1a) dont les extensions temps réel (1003.1b) et les extensions pour les threads (1003.1c) : cf. liste des fonctions POSIX prises en charge ;
- un modèle simple pour les pilotes de périphériques ;
- la notion de "streams" UNIX pour une réutilisation maximale ;
- la gestion du réseau au travers lwip 1.3 et uip 1.0 (Lepton/embOS pour l'instant) ;
- la gestion des systèmes de fichiers rootfs, ufs et fat16. Un VFS est disponible pour pouvoir ajouter simplement un nouveau système de fichiers ;
- les profils USB ACM-CDC, Ethernet-ECM et Mass Storage (le test a été effectué sur une AT91SAM9261-EK) ;
- l'intégration des bibliothèques NanoX et FLTK (FLNX pour être plus précis) ;
- l'intégration du serveur WEB mongoose et d'un serveur FTP (travail dérivé de trollFTP) ;
- un mini shell ;
- une simulation fonctionnant sous GNU/Linux (Tauon) et MS/Windows (Lepton).
Les cibles gérées pour l'instant sont :
- ARM7: AT91M55800A + mémoire externe nécessaire ;
- ARM9: AT91SAM9261-EK + mémoire externe nécessaire ;
- ARM9: AT91SAM9260-EK + mémoire externe nécessaire ;
- Cortex-M4: TWR-K60N512 tout en interne + déboguage en MRAM ;
- PC (simulation 32 bits pour GNU/Linux et MS Windows).
Fonctionnement général
Lepton ne possède pas pour l'instant de chargeur ELF. Les binaires que l'utilisateur souhaite avoir dans son ELF final sont incorporés à la compilation. Un fichier XML décrit la configuration du micrologiciel (nombre de processus maximum, nombre de fichiers ouverts, taille de pile pour les binaires...). Le développeur compile la bibliothèque du RTOS sous-jacent (eCos ou Segger) puis son application.
Un script d'installation en python est disponible. Il configure et compile une application basique pour 3 cibles : la simulation, la TWR-K60N512 et la AT91SAM9261-EK.
À titre indicatif, Lepton fonctionne sur la TWR-K60N512 équipée de 128 Kio de RAM (interne) et 512 Kio de FLASH. L'application contient :
- le système de base (mini-shell, systèmes de fichiers...) ;
- la pile LwIP ;
- l'utilitaire telnetd ;
- des pilotes de périphériques (uart, rtc, ethernet, sdcard, spi, i2c...).
Les configuration suivantes fournissent, à titre d'exemple, la RAM restante :
- telnetd présent mais non lancé : moins de 25 Ko (24980 bytes) ;
- telnetd lancé mais sans connexion : moins de 18 Ko (17988 bytes) ;
- connexion en Telnet : un peu plus de 10 Ko (10852 bytes).
Il est évidemment possible de faire une application sans shell, sans telnetd, etc. ce qui permet de gagner en mémoire vive et de maîtriser entièrement le lancement de son application.
TODO
Beaucoup d'améliorations restent à apporter à Lepton :
- une documentation détaillée des appels POSIX présents ;
- l'API d'appels système à l'extérieur des sources du noyau ;
- le nettoyage des sources ;
- l'intégration d'un chargeur ELF ;
- l'utilisation de la MPU sur cible Cortex-M ;
- la simplification de l'installation ;
- l'exécution de multiples instances simultanées de la simulation ;
- la gestion de plus de pilotes de périphériques et leur amélioration (particulièrement pour la TWR-K60N512) ;
- l'ajout d'autres plateformes (SAM4S, STM32, LPC43x...);
- des corrections de bogues ;
- etc.
Toutes les suggestions, les remarques et les contributions sont les bienvenues.
Aller plus loin
- Lepton/Tauon (817 clics)
- README (150 clics)
- eCos (164 clics)
# ...
Posté par M . Évalué à 5.
Pourrait on savoir ce qu'apporte Tauon par rapport a ce qui existe deja dans ecos.
Par exemple il y a deja une couche de compat posix :
http://trac.umnaem.webfactional.com/browser/trunk/Hardware/eCos/packages/compat/posix/v3_0/doc/posix.sgml?rev=38
[^] # Re: ...
Posté par Argon . Évalué à 2.
C'est surement une question bête mais concrêtement c'est utile pour faire quoi ? Quel type d'appareil pourrait en bénéficier ?
de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité
[^] # Re: ...
Posté par Gui13 (site web personnel) . Évalué à 6.
Comme il le dit très bien: c'est pour le matos qui embarque un processeur mais pas de RAM ou très peu.
Avec ce genre d'OS tu peux porter des applis existantes (mongoose par exemple) sans trop de soucis si elles sont à peu près POSIX, et faire un serveur web dans 150Ko de mémoire (noyau + serveur!!).
Je vois des milliers d'applications à ça: des capteurs (pression, T°, hygrométrie, intégrés dans une machine ou dans le corps) intelligents et adressables en REST, ton grille pain, la machine à laver, les interrupteurs, etc..
[^] # Re: ...
Posté par lepton.jjp . Évalué à 6.
Salut à tous,
Merci de l'intérêt que vous portez à Lepton.
La différence fondamentale avec eCos est qu'on tente de respecter le profil PSE-53 qui comprend notamment tout ce qui est multi-processus par exemple. (eCos est mono-processus et multithread)
Un gros travail reste à faire justement pour intégrer mongoosed et disposer d'un peu de RAM pour l'application.
[^] # Re: ...
Posté par cle_d_anton . Évalué à 7.
salut!
L'objectif c'est d'aller un peu plus loin que les services fournis par la plupart des noyaux temps réel.
Effectivement, eCos et RTEMS propose une interface POSIX. lepton propose lui aussi cette interface avec en plus une architecture qui s'inspire de la """philosophie""" UNIX. Fortement basé sur le système de fichiers ex:Les pilotes de périphériques sont accessibles depuis le système de fichiers. les i/o (périphériques, tubes, socket,...) se manipule à partir de descripteur de fichier ainsi les fonctions posix associées comme open(), read(), write(), fcntl(), ioctl(),lseek() ... peuvent être utilisées quelques soit la nature de l'i/o.
On peut aussi "superposer" des pilotes de périphériques:
ex: /dev/i2c0 c'est le pilote d'accès au bus i2c. /dev/i2ceeprom_modelA c'est le pilote qui permet de manipuler le contenu d'une eeprom i2c en implémentant les mécanismes d’accès spécifique à ce modèle. Il possible de créer un i/o qui permettra d'écrire sur la eeprom sans se soucier des mécanismes sous-jacents:
fd_i2c0=open("/dev/i2c0",O_RDWR,0);
fd_eeprom=open("dev/i2ceeprom_modelA",O_RDWR,0);
ioctl(fd_eeprom,I_LINK,fd_i2c0);
fattach(fd_eeprom,"/dev/disk0");
ensuite l'application ou un autre processus peut accéder à la mémoire eeprom i2c de manière générique:
fd=open("/dev/disk0",O_RDWR,0);
cb=read(fd,buf,sizeof(buf));
si le modèle de eeprom est modifié et un nouveau pilote doit être développé:
fd_i2c0=open("/dev/i2c0",O_RDWR,0);
fd_eeprom=open("dev/i2ceeprom_modelB",O_RDWR,0);
ioctl(fd_eeprom,I_LINK,fd_i2c0);
fattach(fd_eeprom,"/dev/disk0");
Le code de l'application ne sera pas modifié. L'application ne voit que le périphérique «/dev/disk0» qui lui cache tous les mécanismes d'accès. Idem pour le SPI (avec des périphériques ethernet, sdcard, flash...), pour le réseau (ex ppp au dessus du pilote de liaison série), USB et ses profils (déjà utilisé sur la cible at91sam9261-ek avec les profils série, ethernet et mass storage device)... .
C'est le principe des streams sur UNIX. Cela permet de faciliter le portage et la réutilisation d'applications, d'outils.
Le développement des pilotes de périphériques est simple et rapide, l'interface étant unifiée.
C’est un exemple de ce que peut apporter lepton en plus d'un noyau temps temps réel.
Je pense que ça peut faciliter le développement d'applications embarquées enfouies, égare notamment aux fonctionnalités logicielles de plus en plus importantes et évoluées qu'ils doivent à présent supporter et capitaliser d'un projet à l'autre les développements déjà réalisés. On évite le coté un peu "one shot" du développement sur ce type de cible, la prise en main est assez facile (ça reste largement à l'échelle humaine) et on peut le bricoler selon ses envies.
Il y a encore du travail et des améliorations à apporter.
voilà, voilà...
# Intéressant
Posté par elf32 . Évalué à 4.
C'est dingue, j'écrivais un tout petit noyau à but pédagogique, et je voulais aussi le baptiser avec une particule. Je voulais gluon ou boson, dans l'idée où un noyau est comme un médiateur entre le matériel et le logiciel.
Bonne continuation, le projet m'intéresse assez, mais en tant que curieux seulement ;)
[^] # Re: Intéressant
Posté par Michaël Ughetto . Évalué à 1.
Il y a 12 bosons de jauge +1 Higgs (particules de spin entier) dans le Modèle Standard, pour seulement cinq noms (photon, W, Z, gluon et Higgs) donc photon semble un choix moin limité que boson ;)
[^] # Re: Intéressant
Posté par scaife9 (site web personnel) . Évalué à 1.
Photon est le nom de l'environnement graphique de QNX, il doit probablement être déposé dans ce cadre.
Nasty thoughts are like buses - you don't get one for ages and then a whole army arrive at once.
[^] # Re: Intéressant
Posté par Mikis . Évalué à 3.
Tu as le « gluon_du_trou », utilisé dans un autre domaine que l'informatique.
# Des OS TR compatible posix y en a d'autres...
Posté par eric1803 . Évalué à 2.
RTEMS fait un peu comme eCos et est compatible posix aussi.
[^] # Re: Des OS TR compatible posix y en a d'autres...
Posté par vpinon . Évalué à 1.
et contiki ? je ne sais pas s'il y a des couches posix, mais il y a une bonne pile réseau+les clients/serveurs qui vont avec...
[^] # Re: Des OS TR compatible posix y en a d'autres...
Posté par lepton.jjp . Évalué à 2.
Il serait éventuellement possible de greffer Lepton au-dessus de contiki, comme nous l'avons fait pour eCos et segger.
Après vu le fonctionnement général et l'architecture de contiki, je ne sais pas si ça le ferait.
En tout cas, ça peut être tenté :).
[^] # Re: Des OS TR compatible posix y en a d'autres...
Posté par cle_d_anton . Évalué à 2.
salut!
contiki fonctionne trop différemment des RTOS classiques comme eCos par exemple. Il me semble qu'il n'est pas préemptible.
Pour lepton la pile IP de contiki (en fait c'est uIP) a été extraite et intégrée. La couche socket BSD a été ajouté. Cette pile IP fonctionne dans lepton et sera prochainement intégré au dépôt officiel. Elle fonctionne en ipv4 ou en ipv6 (ce n'est pas encore dual stack) et en tcp/udp.
Dans lepton on peut choisir d'utiliser cette stack ou lwip (pour l'instant en version 1.3.2), sans impact sur les applications ou les pilote de périphérique réseaux. D'autres stack IP peuvent être ajoutées.
lepton fonctionne aussi en simulation sous linux et utilise les périphériques de la machine (liaison série, carte réseau, ...).
# Merci pour le partage d'information
Posté par Floris DUBREUIL . Évalué à 10.
Moi, j'aime bien lire ces dépêches là. Merci.
[^] # Re: Merci pour le partage d'information
Posté par lolop (site web personnel) . Évalué à 3.
D'ailleurs, ça mériterais que vous postiez sur le site OSNews http://www.osnews.com/
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# Allons de suite à l'essentiel:
Posté par Maclag . Évalué à 5.
Est-ce que vous avez porté Gnome et/ou KDE dessus?
Plus sérieusement, je connais mal le secteur, et je serais donc curieux également de comprendre les avantages de la compatibilité POSIX pour ce que j'ai toujours pensé être des applications très spécialisées.
[^] # Re: Allons de suite à l'essentiel:
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
L'avantage est de pouvoir récupérer des programmes externes, par exemple busybox.
Le désavantage est que la norme posix est complètement pourris dans certain recoin. C'est pour cela que "Linux" devient une norme par lui-même pour les trucs un peu compliqué.
"La première sécurité est la liberté"
[^] # Re: Allons de suite à l'essentiel:
Posté par lepton.jjp . Évalué à 5.
Comme tu le souligne, l'avantage est de pouvoir porter des petits utilitaires (interpréteur LUA) ou de petites librairies (ustl, libpng, parseur XML).
Comme je le souligne dans la dépêche, la norme POSIX est un socle qui peut être adapté aux besoins de chacun.
# avantage par rapport à linux+RTAI ou linux+xenomai ?
Posté par gromit . Évalué à 1.
Et quel est l'avantage de cette approche par rapport à celle qui consiste à réutiliser un linux+RTAI ou linux+xenomai ? En reconstruisant un linux "from scratch" on doit pouvoir obtenir un système assez sobre non ?
[^] # Re: avantage par rapport à linux+RTAI ou linux+xenomai ?
Posté par lepton.jjp . Évalué à 4.
Pour une cible comme la Kinetis K60N512 (512 Kio Flash et 128 Kio RAM pour rappel), tu dois disposer d'une mémoire externe supplémentaire. De plus, cette cible ne possède de MMU (pas de mécanisme de mémoire virtuelle comme on peut trouver sur les AT91SAM926x).
Un port de uClinux a été réalisé sur STM32 et maintenant sur K70.
Tu pourras consulter la mémoire vive nécessaire pour faire fonctionner uclinux sur STM32(dernier lien - date : Edited: 1/14/2012 8:40 PM - auteur : khusainov.vladimir).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.