Bodor Denis

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

Dans un précédent article [1] nous avons exploré la possibilité, sous GNU/Linux, de créer des machines virtuelles capables d'accéder à du matériel PCI/PCIe dans le but, entre autres, de faciliter le développement de pilotes de périphériques OpenBSD. Ce type de fonctionnalités n'est pas spécifique à QEMU/KVM et il est temps de voir comment cela se passe de l'autre côté de l'univers Unix open source, avec FreeBSD.

Cela fait quelque temps déjà qu'une nouvelle Pico est arrivée chez les revendeurs et fait doucement son bonhomme de chemin. Celle-ci intègre un nouveau microcontrôleur très particulier qui, en plus de fournir davantage de ressources que son prédécesseur, à une double nature : ARM Cortex-M33 et RISC-V Hazard3. Le fait d'utiliser l'une ou l'autre architecture est laissé au choix du développeur et nous allons bien entendu explorer les deux options. Pour accompagner cette évolution, le SDK lui aussi change en passant de la version 1.5.1 à 2.0.0, puis dernièrement, à 2.1.0. Faisons donc un petit tour de ce que tout cela implique...

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.

Vous avez remarqué que le FUD (Fear, Uncertainty and Doubt), tant utilisé par le passé contre GNU/Linux et le logiciel libre en général, est devenu la norme pour la promotion de bon nombre de solutions et services en ligne ?