Bodor Denis

Dans de précédents articles ([1] et [2]), nous avons découvert le framework LiteX permettant de créer simplement des SoC softcores en utilisant le langage Python et d'instancier ces designs sur différents devkits FPGA, ceci au point de faire démarrer un système GNU/Linux à partir d'un disque SATA. Mais tout ceci n'était, somme toute, que de la prise en main, reposant massivement sur des exemples du projet. Aujourd'hui, nous allons creuser un peu davantage le sujet en voyant comment, via quelques fichiers Python, nous pouvons créer notre SoC (ou MCU) bien à nous, en rassemblant toutes les briques nécessaires dans un projet « maison »...

C'est officiel, la toute dernière version de FreeBSD intègre, par défaut, un dépôt spécifique aux modules noyau, c'est FreeBSD-kmods (jetez un œil à votre /etc/pkg/FreeBSD.conf). Ceci règle un problème de longue date découlant du fait que les paquets binaires sont construits sur la base de la version x.(y-1) pendant trois mois après la diffusion de la version x.y, pour des questions de support. Ça marche sans problème pour les paquets « userland », mais pose un vrai souci pour les modules noyau (et drm-kmod en particulier). Ainsi, 14.3 a décidé d'officialiser l'existence d'un dépôt dédié, et c'est là la parfaite excuse pour enrichir le support, se retrousser les manches et, pourquoi pas, développer vos modules/pilotes bien à vous...

Dans le numéro 54 [1], nous avions exploré la façon d'interfacer une smartcard avec une carte Raspberry Pi Pico (RP2040) et un MCU ESP32, jusqu'à arriver à converser et à échanger des données avec une applet Java que nous avions développée par ailleurs [2], et ce sans aucun circuit spécialisé. Nous allons ici recycler ces travaux et découvrir qu'il est parfaitement possible de faire de même avec un adaptateur USB à 4 €, normalement destiné aux manipulations de cartes SIM avec de douteuses applications Windows.

Dans le précédent article, nous avons exploré le fait de composer un SoC « maison » grâce au framework LiteX, de le synthétiser, de le configurer dans la mémoire du FPGA et de créer un petit code en C qui, une fois compilé, est exécuté par le softcore RISC-V. Mais ce n'était pas suffisant et j'ai continué les expérimentations, tombant sur plusieurs subtilités très intéressantes que je me dois de partager avec vous ici. Poursuivons donc notre découverte du fabuleux et captivant monde de LiteX...

Versé dans l'art de la programmation et coutumier des subtilités du fonctionnement d'un OS, vous savez. L'utopie d'un système parfait, exempt de tout bug et de toute faille n'existe pas, et n'existera probablement jamais. Mais ce savoir n'est pas courant, ni chez le commun des mortels ni chez le politicien, l'élu ou le parlementaire (probablement même encore moins, d'ailleurs). Et c'est précisément là que le déséquilibre existe entre la praticité subjective d'une solution et le risque, bien réel, qu'elle implique dès lors que l'informatique s'en mêle.

Ah, le monde des FPGA et du gateware, entre les suites propriétaires d'une taille monstrueuse, les problèmes de compatibilité et les installations sauvages d'outils et de composants pour pouvoir « rester dans la course », force est de constater que ce n'est pas toujours une partie de plaisir. C'est ainsi que, sur le coup d'un énervement ponctuel, une idée folle a déboulé dans mon esprit : et si je tentais le coup sous un autre OS, réputé pour son caractère carré, propre et robuste ?

Rassurez-vous, j'ai tenté l'expérience, mais j'aime bien trop mon Vi pour utiliser des salop^Woutils comme VSCode/Copilot/Kiro/Cursor/machin/IDE gluant. Non, ce fut par l'intermédiaire de la simple interface web de Claude Sonnet 4 et l'aventure fut assez, heu, disons... « intéressante ».

Proposer une ligne de commande, ou du moins une forme de REPL (read–eval–print loop) pour manipuler interactivement un montage ou une installation à base de microcontrôleur est un grand classique. Lorsque cela se fait via une connexion réseau, par opposition à une liaison série, par exemple, on en arrive souvent à utiliser quelque chose qui ressemble à Telnet avec une authentification assez basique et surtout une absence totale de chiffrement. Sur PC ou SBC, cela fait longtemps que ce genre de choses est devenu totalement obsolète, au bénéfice du classique SSH. Pourquoi n'en serait-il pas de même avec un MCU un peu « musclé » ?

Qu'il s'agisse de simple confort ou de sécurité, la capacité à détecter une personne ou un mouvement est une part importante d'un système domotique. L'idée ne date pas d'hier avec des dispositifs d'éclairage automatique, intérieur ou extérieur, mais l'utilisation de concert avec une installation comme Home Assistant apporte une tout autre dimension et offre une infinité de possibilités. Cependant, à la base de toute scénarisation, même complexe, se trouve le capteur lui-même et nous allons voir que tous ne se valent pas...