L'affichage peut se faire sur archi ARM9. Le plus souvent une partie de l'acquisition et la gestion du déclenchement sont dédiées à un chip style fpga.
Avec des collègues nous avons il y a peu réalisé un oscillo portable industriel avec un ARM9 et justement un fpga spécialement conçu pour l'acquisition et le déclenchement rapide. L'affichage étant réalisé par un arm9 (200MHZ). La partie «ihm» est gérée par flnx/nanox et l'os c'est le projet open source lepton (je fais un peu pub, lepton avait fait l'objet d'une news ici il y a peu lepton/tauon). Avec Linux il sera à mon avis nécessaire d'utiliser les patchs préemptifs, PREEMPT-RT, et les extensions temps réel POSIX (pthread, timer temps réel, gestion signaux temps réel). Le défi: ne pas rater d'évènements et avoir un affichage fluide même si la bande passante ne pourra surement pas rivaliser avec un oscillo du commerce. C'est un chouette défi.
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, ...).
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: Oscillo ?
Posté par cle_d_anton . En réponse à la dépêche Concours linuxembedded.fr 2012. Évalué à 2.
L'affichage peut se faire sur archi ARM9. Le plus souvent une partie de l'acquisition et la gestion du déclenchement sont dédiées à un chip style fpga.
Avec des collègues nous avons il y a peu réalisé un oscillo portable industriel avec un ARM9 et justement un fpga spécialement conçu pour l'acquisition et le déclenchement rapide. L'affichage étant réalisé par un arm9 (200MHZ). La partie «ihm» est gérée par flnx/nanox et l'os c'est le projet open source lepton (je fais un peu pub, lepton avait fait l'objet d'une news ici il y a peu
lepton/tauon). Avec Linux il sera à mon avis nécessaire d'utiliser les patchs préemptifs, PREEMPT-RT, et les extensions temps réel POSIX (pthread, timer temps réel, gestion signaux temps réel). Le défi: ne pas rater d'évènements et avoir un affichage fluide même si la bande passante ne pourra surement pas rivaliser avec un oscillo du commerce. C'est un chouette défi.voilà, voilà
[^] # Re: Des OS TR compatible posix y en a d'autres...
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é à 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, ...).
[^] # 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à...