Bodor Denis

Lorsqu'on cherche à développer un support pour un composant interfacé en i2c qui ne dispose pas encore de bibliothèque, que ce soit pour Arduino ou toute autre plateforme pour microcontrôleur (RP2040, ESP32, etc.), la phase de mise au point et de test n'est pas toujours très aisée. Il faut travailler sur un code de firmware, programmer le MCU, tester et itérer, ce qui fait perdre un temps conséquent. Il est bien plus facile de développer sur PC ou Pi pour ensuite porter le code sur MCU. Mais encore faut-il disposer d'un bus i2c facilement accessible...

Soyons clairs, je ne suis pas fan de Lua en tant que langage de programmation. Le simple fait que les tableaux débutent à l'indice 1 me perturbe totalement et constitue pour moi une véritable aberration. Mais, d'un autre côté, Lua est aussi le langage par excellence lorsqu'il s'agit d'embarquer des fonctionnalités de scripting au sein d'une application ou d'un outil. Du moins, c'est ce que tend à montrer sa popularité dans ce domaine et, si l'on n’a jamais tenté l'expérience, on peut se demander pourquoi. La réponse est évidente après quelques lignes de code et on se surprend soi-même à dire, à haute voix qui plus est, « Ah ! Mais c'est excellent, en fait ! ».

Les cartes à puce ou smartcards reposant sur la norme ISO/IEC 7816 sont omniprésentes dans nos vies. Cartes bancaires, cartes Vitale, cartes SIM dans votre smartphone ou encore tantôt cartes permettant l'authentification ou la signature électronique sont autant d'exemples des services que ces petits bouts de plastique peuvent rendre. Il existe maintes solutions permettant d'interagir avec une smartcard sur PC, un Mac ou un SBC sous GNU/Linux, généralement via un lecteur USB CCID. Mais qu'en est-il lorsqu'on souhaite que notre montage à microcontrôleur utilise ce type de périphérique ? Il y a la voie simple avec l'utilisation d'une IC dédiée ou un support intégré au MCU, et la voie plus « créative » que nous allons explorer de ce pas...

Au détour d'un petit projet incluant des échanges USB avec un adaptateur série utilisant une puce FTDI FT232R, j'ai rencontré un problème susceptible de survenir dans diverses situations. Même si aujourd'hui UTF-8 semble avoir toujours été présent dans nos terminaux, éditeurs, codes et que sais-je encore, les utilisateurs et programmeurs les plus aguerris se souviennent sans peine de la souffrance vécue lors de la transition depuis le bon vieux Latin1 (alias iso-8859-1). Mais la dure réalité est la suivante : UTF-8 n'est pas partout !

Une installation domotique ou un déploiement de capteurs repose généralement sur différents types de communication radio ou filaires : Wi-Fi, Zigbee, Z-Wave, Bluetooth, i2c, EIA-485, Ethernet, etc. Mais lorsque les distances se comptent en centaines de mètres voire en kilomètres, le problème devient plus épineux. L'option 4G est toujours possible, toutefois comme avec d'autres solutions d'IoT, ceci suppose de non seulement ajouter une charge financière au projet, mais implique également de reposer sur un réseau contrôlé par un opérateur susceptible de changer les règles comme il l'entend. Meshtastic est une réponse à cette contrainte : une réponse hors réseau (off grid), gratuite, participative et très économique...

J'aime bien LIDL, on y trouve des produits qu'on n'a pas ailleurs. De délicieuses olives farcies aux amandes, des pistaches décortiquées non salées, de la litière agglomérante pas chère, parfois des Guinness West Indies Porter... et des passerelles domotiques Ethernet/Zigbee à 20 €. Ai-je besoin d'une telle passerelle ? Non. Je n'ai pour l'instant aucun périphérique Zigbee dans mon installation domotique. Ce que j'ai, en revanche, c'est de la curiosité. Celle de savoir ce que renferme ce produit et éventuellement, d'apprendre comment je pourrais en faire un autre usage. C'est parti pour un week-end de chasse au trésor...

Chers consœurs et confrères journalistes de la presse « technique » et « scientifique », si je vous écris ce mot aujourd'hui, c'est pour vous donner un petit conseil qui pourra peut-être à la fois vous éviter de passer pour des demeurés, mais aussi, accessoirement, de prendre vos lecteurs pour des demeurés d'un calibre similaire, sinon bien supérieur.

Lorsqu'on fait connaissance avec l'un des systèmes héritiers du BSD d'origine, à savoir FreeBSD, NetBSD ou encore OpenBSD, tout en ayant une certaine expérience de GNU/Linux, il est relativement facile de retrouver ses petits. Certes, depuis quelques années, le système d'init et la gestion des services de GNU/Linux se sont drastiquement écartés des principes propres à la philosophie Unix, jusqu'alors respectés par GNU/Linux. Dans l'ensemble, la transition est relativement aisée, mais il y a cependant un point sur lequel les différences sont telles que quelques explications s'avèrent nécessaires : la gestion des périphériques « hotplug » (USB) et de leurs permissions.

Lorsqu'il s'agit d'utiliser un microcontrôleur de la famille ESP32, deux approches sont généralement raisonnablement envisageables. La première consiste à utiliser l'environnement dédié proposé par Espressif, ESP-IDF, et la seconde à reposer sur un niveau d'abstraction supérieur via le framework, et implicitement, l'environnement Arduino. L'une assure une maîtrise totale du développement et l'autre, une plus grande facilité d'implémentation du projet que vous avez en tête. Le coût du choix de l'une ou de l'autre solution est, pour la première, une complexité accrue et pour la seconde, un environnement relativement limité, sinon simpliste. Il existe cependant une voie du milieu qu'il est important de considérer...