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é:
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.
[^] # Re: ...
Posté par cle_d_anton . En réponse à la dépêche Lepton/Tauon : un système d'exploitation temps réel "POSIX compliant" pour cibles embarquées. É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à...