Bodor Denis

Il devient de plus en plus difficile de trouver des devkits, SBC et autres cartes d'évaluation à un prix abordable. La pénurie s'est installée et risque de perdurer encore de nombreux mois. Ceci peut paraître surprenant puisqu'en parallèle, les semiconducteurs haut de gamme, comme les processeurs, ne semblent pas rencontrer de problème (du moins pas à la même échelle). Que se passe-t-il ?

Pour s'initier à Verilog et au monde des FPGA, il existe une pléthore de solutions, open source ou non, coûteuses ou non, riches en ressources ou non, modernes ou non... Certaines combinaisons de ces caractéristiques sont faciles à trouver, d'autres un peu moins, voire pas du tout. Ainsi, mettre la main sur une plateforme puissante, open source, économique et moderne relève encore du challenge, même s'il commence à y avoir des pistes intéressantes (voir [1], [2] ou encore [3]). Une autre option consiste à faire quelques concessions et à opter pour quelque chose d'ancien et propriétaire, mais bien fourni et économique. Un bon exemple concerne la famille de FPGA Cyclone d'Altera (maintenant Intel). Mais faire fonctionner, sur un système récent, un environnement de développement tout aussi dédié qu'obsolète n'est pas une mince affaire...

Il existe beaucoup de raisons d’utiliser GNU/Linux, et celles-ci ont naturellement évolué au cours des 25 dernières années. Mais, pour beaucoup, ce qui se cache derrière cette question est quelque chose de plus fondamental, de plus personnel, voire d’intime. Je parle de la véritable et réelle motivation qui nous pousse dans cette utilisation quotidienne et dans le choix initial de ce système.

Le courant consommé par un montage peut sembler être quelque chose de relativement secondaire, en comparaison avec sa fiabilité ou ses performances. Le plus souvent, on cherche à développer une solution robuste accomplissant le travail de façon efficace en partant du principe que l'alimentation est une source magique intarissable. Mais dès lors que le projet implique un accu ou une pile, les perspectives changent totalement. Fort heureusement, les constructeurs de microcontrôleurs ont prévu la prise en charge de ce type de contrainte, et proposent des solutions.

Voici quelques saines lectures pour vos soirées. Ces ouvrages ne sont pas nécessairement les plus récents, mais méritent de trouver place dans la bibliothèque de tout développeur qui se respecte, selon ses affinités personnelles bien sûr. Il vous faudra certes un minimum de pratique dans la langue de Shakespeare pour les « consommer », mais l'effort en vaut réellement la chandelle au regard de leur contenu...

Voici quelques saines lectures pour vos soirées. Ces ouvrages ne sont pas nécessairement les plus récents, mais méritent de trouver place dans la bibliothèque de tout développeur qui se respecte, selon ses affinités personnelles bien sûr. Il vous faudra certes un minimum de pratique dans la langue de Shakespeare pour les « consommer », mais l'effort en vaut réellement la chandelle au regard de leur contenu...

La ligne de commande est l'interface ultime, certes... mais pas pour tout le monde.

Si vous souhaitez développer un programme permettant à l'utilisateur de saisir des commandes et ainsi fournir une interface souple d'utilisation ayant des fonctionnalités avancées d'édition de lignes, plusieurs options s'offrent à vous. Vous pouvez tout faire à la main, choisir une alternative légère comme Linenoise [1] ou opter pour quelque chose de classique et éprouvé : GNU Readline.

Les cartes Arduino AVR, ainsi que d'autres plateformes utilisant cet environnement et cet « IDE », proposent de base une EEPROM permettant de stocker une quantité réduite de données survivant entre les phases d'alimentation d'un projet. Dans le cas des AVR, cette EEPROM est physiquement présente dans le microcontrôleur, mais avec un ESP32 par exemple, c'est une zone de la flash qui sera utilisée. Qu'en est-il d'une fonctionnalité similaire avec la Raspberry Pi Pico et son RP2040 ?