Dans ce numéro...


« Changement de main, changement de vilain » comme disait le grand Bernard Lavilliers.
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.

Magazines précédents

Les derniers articles Premiums

Les derniers articles Premium

Game & Watch : utilisons judicieusement la mémoire

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Au terme de l'article précédent [1] concernant la transformation de la console Nintendo Game & Watch en plateforme de développement, nous nous sommes heurtés à un problème : les 128 Ko de flash intégrés au microcontrôleur STM32 sont une ressource précieuse, car en quantité réduite. Mais heureusement pour nous, le STM32H7B0 dispose d'une mémoire vive de taille conséquente (~ 1,2 Mo) et se trouve être connecté à une flash externe QSPI offrant autant d'espace. Pour pouvoir développer des codes plus étoffés, nous devons apprendre à utiliser ces deux ressources.

Raspberry Pi Pico : PIO, DMA et mémoire flash

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Le microcontrôleur RP2040 équipant la Pico est une petite merveille et malgré l'absence de connectivité wifi ou Bluetooth, l'étendue des fonctionnalités intégrées reste très impressionnante. Nous avons abordé le sujet du sous-système PIO dans un précédent article [1], mais celui-ci n'était qu'une découverte de la fonctionnalité. Il est temps à présent de pousser plus loin nos expérimentations en mêlant plusieurs ressources à notre disposition : PIO, DMA et accès à la flash QSPI.

Programmation des PIO de la Raspberry Pi Pico

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

La carte Pico de Raspberry Pi est appréciable à bien des égards. Ses ressources, son prix, ses deux cœurs ARM... Mais ce morceau de silicium qu'est le RP2040 renferme une fonctionnalité unique : des blocs PIO permettant de créer librement des périphériques supplémentaires qu'il s'agisse d'éléments standardisés comme SPI, UART ou i2c, ou des choses totalement exotiques et très spécifiques à un projet ou un environnement donné. Voyons ensemble comment prendre en main cette ressource et explorer le monde fantastique des huit machines à états de la Pico !

Body