Bodor Denis

Le FOSDEM [1] a eu 25 ans cette année et cela faisait (presque) 25 ans que, chaque année, je disais « cette fois, j'y vais » pour finalement revoir mes priorités et tristement m'abstenir. Mais pas cette fois ! Et ce en grande partie grâce à l'ami Fixou, que je remercie énormément.

Quelle plus belle récompense pour l'auteur d'un article ou un rédacteur en chef que de voir que sa prose aura inspiré un lecteur, et ce, au point de le pousser à faire quelque chose que lui-même ne s'est pas donné la peine de mener à terme ?

Acheter une carte à microcontrôleur en ligne, la réceptionner, la brancher en USB, rapidement installer un environnement de développement plus ou moins étoffé et/ou basique, programmer un bout de code en deux temps, trois mouvements, compiler, charger le binaire et voir la jolie LED clignoter... Vous connaissez la routine qui semble, de toute évidence, sans surprise et parfaitement normale. Mais il n'en a pas toujours été ainsi et nos aïeux devaient vraiment mériter leur dopamine quotidienne. Bien plus que les chanceux bidouilleurs que nous sommes aujourd'hui, la preuve en pratique...

Dans un précédent article [1], nous avons fait connaissance avec la possibilité (semi-sérieuse) de développer nos outils en ligne de commande en assembleur, pour le plaisir (et par masochisme). Ce qui va suivre n'est pas réellement une suite, mais plus exactement une exploration autour du sujet, accompagnée de quelques explications autour de la notion de Position Independent Code ou PIC.

Dans le numéro 56 [1], puis dans le 58 [2], nous avons vu qu'il était non seulement relativement facile de créer un périphérique USB, quel qu'il soit, avec une carte Raspberry Pi Pico, mais également que ceci n'avait rien de bien nouveau, en faisant de même avec le microcontrôleur CY7C68013A/FX2LP. Passons aujourd'hui à ce que l'on pourrait considérer comme le « concurrent » direct du RP2040, à savoir l'ESP32.

L'accès direct à la mémoire, ou DMA en anglais pour Direct Memory Access, est un mécanisme qui ne date pas d'hier. Il est présent partout, du monde des contrôleurs à celui des PC modernes, et permet d'accélérer grandement certaines opérations impliquant des transferts de données depuis ou vers un périphérique et la mémoire du système. L'avantage dans l'utilisation du DMA est le fait que le processeur n'intervient pas dans l'opération. Mais qui dit absence de participation de ce dernier, dit aussi absence de contrôle d'accès à la mémoire. Et ça, ça peut vite devenir un énorme problème de sécurité...

Une vidéo récente sur la chaîne secondaire de Matthias Wandel [1] m'a récemment fait vérifier presque l'ensemble des câbles que j'utilise pour mes montages et autres expériences. En effet, Matthias, qui généralement diffuse du contenu autour du travail du bois, a constaté que ses câbles munis de pinces, achetés très récemment, présentaient une résistance relativement surprenante, quelque 300 mΩ pour 15 cm, ce qui n'est peut-être pas un problème pour des signaux (selon la fréquence), mais en est clairement un pour une alimentation.

Lorsqu'il s'agit de tirer le maximum des ressources à disposition d'une plateforme, en particulier dans l'embarqué, le processeur n'est généralement pas souvent la solution la plus adaptée. Du matériel dédié comme les accélérateurs matériels, en particulier pour les calculs matriciels ou la cryptographie, viennent souvent assister le processeur et l'alléger des tâches demandeuses en calcul. L'une des options possibles dans ces situations est l'utilisation du GPU, via des frameworks dédiés. Une humble Raspberry Pi peut être un excellent terrain de découverte pour prendre en main ce type de technologies.

Je ne vous apprends rien en vous disant que GNU/Linux dispose de bien plus de pilotes de périphérique que, disons, OpenBSD. Ceci n'est pas bien grave en soi puisqu'il suffit d'en développer de nouveaux, tout en s'inspirant du travail du développeur s'étant déjà cassé les dents sur le sujet (merci, le logiciel libre). Là où cela devient pénible, c'est que les bêtises coûtent cher lorsqu'on touche à un noyau et qu'elles se soldent généralement par des resets brutaux et à répétition. Ne serait-il pas merveilleux de pouvoir accéder à certains matériels depuis l'intérieur d'une machine virtuelle, pour rendre cela plus digeste ?