L’ADULLACT, association des développeurs et utilisateurs de logiciels libres pour les administrations et les collectivités territoriales, fête cette année ses 20 ans. Elle est notamment à l’initiative de nombreux projets et services visant à développer et promouvoir des logiciels libres utiles aux missions de services publics. Son délégué général a bien voulu revenir avec nous sur ses diverses missions et actions en cours.

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...

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 ?

Dans cet article, on se propose d’aborder la méthode de vérification formelle pour le VHDL. Cette méthode a récemment été rendue possible avec GHDL et Yosys grâce au projet d’extension ghdl-yosys-plugin qui fait le lien entre les deux logiciels. Nous allons également découvrir le langage PSL (Properties Specification Langage) qui permet de décrire efficacement les propriétés utilisées en preuve formelle. Le support du PSL ayant été ajouté dans GHDL, il sera possible de l’utiliser librement en VHDL.

Il y a de petits projets de week-end qui paraissent anodins à première vue, mais qui, une fois dans les méandres du code, révèlent des problématiques aussi intéressantes que les solutions qui les accompagnent. L'objet du présent article n'est pas réellement de vous détailler le montage en lui-même, après tout il ne s'agit que d'une horloge décorative avec un microcontrôleur AVR, un module RTC, quelques LED adressables APA106 et le framework Arduino. Non, l'idée est simplement de vous présenter quelques « points de friction » et les approches utilisées pour les « lubrifier »...

Dans le précédent article, nous avons vu comment prendre en main le STM32MP157F-DK2, mettre à jour le système, utiliser le SDK et reconstruire l'ensemble avec OpenEmbedded sur la base d'OpenSTLinux, mais aussi de Poky. Le système de build du projet Yocto n'est cependant pas le seul utilisable et, grâce au travail de Bootlin en partenariat avec ST, il est également possible d'utiliser Buildroot. Voyons cela ensemble...

Pour faire connaissance avec une technologie, qu'elle soit nouvelle ou non, il y a généralement deux méthodes envisageables. Potasser sagement la documentation et étudier ce qui existe, ou avoir une approche plus empirique consistant à jouer et expérimenter au risque d'éventuellement « casser » quelque chose. Lorsqu'il est question de matériel, on y réfléchira à deux fois, mais s'il s'agit d'un protocole réseau, l'approche la moins ennuyeuse est évidente. Voyons cela avec les trames de gestion 802.11.

Lorsqu'on parle de technologies NFC, on pense généralement aux tags comme les NTAG, les MIFARE Classic ou plus raisonnablement, les DESFire EV1. Mais il existe tout un monde en dehors des produits NXP souvent parfaitement pris en charge par des bibliothèques de haut niveau, et c'est là l'occasion parfaite d'explorer, plus en profondeur, les protocoles et fonctionnalités offertes par la libNFC. Penchons-nous donc sur les tags ST25TA de chez STMicroelectronics...