Open Silicium N°

Numéro

16

Trente ans après l'introduction des premiers RTOS commerciaux, Linux est une option viable pour les applications temps réel sophistiquées. Mais l'univers temps réel des applications industrielles ne se résume pas à une plate-forme x86 gavée de processeurs dopés à la fréquence d'horloge, avec POSIX pour seul horizon. C'est pourquoi nous avons imaginé Xenomai 3.

La carte Beaglebone Black offre de nombreuses entrées-sorties de types assez variés : série asynchrone, SPI, i²c, GPIO, etc. Dans cet article, nous allons nous intéresser aux broches GPIO et PWM. Suivant les distributions et les configurations du noyau, l'accès à ces entrées-sorties n'est pas toujours identique. Heureusement, un overlay du Device Tree nous simplifie la tâche.

Eclipse est un sujet de « fâcheries » entre les communautés de développeurs. Les développeurs « système » sont en général rétifs à cet outil qui consomme autant de dizaines de Mo de mémoire qu'il ouvre de fenêtres. La plupart des développeurs d'application en sont friands (par habitude ou par nécessité). Le fait est que le TP Eclipse est le plus attendu lors des formations Yocto que nous délivrons, un peu le « clou du spectacle », le bouquet final et nous ne pouvons priver les lecteurs d'Open Silicium d'un tel plaisir ! Nous verrons donc comment intégrer le SDK Yocto dans Eclipse, créer une application de test à exécuter ou mettre au point à distance sur une cible Raspberry Pi. Nous verrons également comme produire – et tester - une distribution Yocto simple avec Eclipse.

L'extension temps-réel Xenomai est très souvent évoquée dans les colonnes d'Open Silicium. Une fois n'est pas coutume, cet article n'a pas pour but d'évaluer des performances temps-réel, mais plutôt de décrire comment intégrer cette extension dans l'outil Yocto. En partant d'un projet existant disponible sur GitHub, nous verrons comment l'améliorer et surtout enrichir la liste des cartes supportées (Raspberry Pi, BeagleBone Black, RIOToard i.MX6 et enfin x86 générique).

Le FPGA est désormais très utilisé dans les solutions embarquées. C'est souvent un composant assez coûteux même s'il existe désormais des cartes CPU abordables intégrant directement un FPGA. Cet article va nous permettre de nous familiariser avec une solution « bon marché », mais performante fonctionnant sur une carte Raspberry Pi. Dans un même souci de simplicité, nous proposerons quelques exemples écrits en langage Verilog, concurrent - à notre avis – plus simple du langage VHDL.

La virtualisation est un sujet très présent actuellement. Que ce soit à propos du Cloud de calcul ou de stockage, du contrôle de système (monitoring), de la sécurité, ou de façon plus générale du cloisonnement. Cependant, peu des hyperviseurs sont conçus pour le milieu embarqué, et encore moins sont vraiment libres et ouverts. Je vous propose dans cet article de découvrir et de tester un de ceux-là : Xvisor.

Nous avons récemment évoqué à nouveau l'API RTDM (Real Time Driver Model) à l'occasion de l'article sur RTnet dans le précédent numéro d'Open Silicium. RTDM dispose d'une fonctionnalité « double ordonnancement » (temps réel et non temps réel) qui est rarement évoquée dans les exemples disponibles. Nous profitons de ce court article pour décrire un exemple simple dans le cas d'une cible Raspberry Pi.

« 3R » signifie Recursive Range Reduction, ou Réduction Récursive des Bornes en français. Comme la plupart des algorithmes de compression, son fonctionnement n'est pas évident au premier abord, à cause des choix et subtilités un peu inhabituels. Mais une fois ceux-ci compris, 3R est assez élégant, c'est-à-dire que si on l'utilise bien, il remplit son rôle dans la plupart des cas avec un nombre minimal d'opérations très simples.