Bodor Denis

Dans un précédent article [1], nous avons vu comment il était possible, avec une Raspberry Pi Pico, de créer relativement facilement un périphérique USB au comportement arbitrairement défini. Mais bien avant l'arrivée du microcontrôleur RP2040, il était déjà possible de faire cela depuis bien longtemps, trèèèèèès longtemps même. Et je ne parle pas d'Arduino (Leonardo en l'occurrence et son ATmega32u4), mais d'un composant que vous possédez peut-être déjà, sans le savoir, dans votre boîte à outils : l'EZ-USB FX2LP.

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 ?

Dans un précédent article [1], nous avons découvert LiteX, une solution permettant de créer des périphériques et SoC en toute simplicité, sans avoir à apprendre à utiliser des langages de description de matériel comme Verilog et VHDL. Aujourd'hui, poussons plus loin l'exploration de ce framework doublé d'une infrastructure de construction et basé sur Python en faisant fonctionner un système d'exploitation GNU/Linux sur une plateforme « full FPGA » RISC-V.

Lorsqu'on parle de domotique, on pense généralement aux capteurs et aux automatisations permettant de gérer facilement son habitation pour piloter son chauffage, simuler une présence, faire des économies d'énergie ou tout simplement améliorer son confort en se débarrassant des tâches fastidieuses et répétitives. Cependant, la sécurité est également un point important, qu'on soit sur place ou à distance, et dans ce cas précis, rien de tel que de mettre en place une vidéosurveillance.

Au moment où je rédige ceci, le Super Heavy Booster de Starship vient tout juste de se poser délicatement sur Mechazilla, la tour de lancement équipée de « bras » et située à Starbase, la plateforme de lancement de SpaceX à Boca Chica, Texas. Voir ce moment réellement historique et presque irréel, en direct, est un événement en soi. C’est être témoin de la progression technologique humaine, qui, on ne peut le nier, ne cesse de s'accélérer.

La surveillance de masse, la censure et les nombreuses restrictions qui pèsent sur Internet, et les communications en général, représentent un énorme problème pour la vie privée et la liberté d'expression. Bien entendu, en Europe, nous ne sommes certainement pas les moins bien lotis, en particulier en comparaison avec des pays aux régimes totalitaires. Mais le fait de dissimuler ses communications et ses échanges de données n’est pas l'apanage des journalistes, des lanceurs d'alerte, des freedom fighters ou même, à l'autre extrême, des groupes mafieux ou terroristes et des réseaux pédophiles. L'anonymisation, le chiffrement et la dissimilation sont devenus l'affaire de tout un chacun désormais.

Le C est sur la sellette ces derniers temps, car, voyez-vous, c'est un langage peu sûr, qui laisse faire tout et n'importe quoi au programmeur. Et comme on ne peut pas faire confiance aux programmeurs pour s'occuper proprement de la mémoire qui leur est gracieusement confiée, il est important de promptement leur confisquer ce langage dangereux, permissif, et disons-le franchement, totalement maléfique. Si, si ! J'adhère totalement à cette vision et, moi aussi, je vais changer de langage préféré pour assurer ma sécurité, protéger les chatons et sauver les petits enfants. Au revoir le méchant C, bonjour le gentil assembleur !