Bodor Denis

Si vous souhaitez développer un programme permettant à l'utilisateur de saisir des commandes et ainsi fournir une interface souple d'utilisation ayant des fonctionnalités avancées d'édition de lignes, plusieurs options s'offrent à vous. Vous pouvez tout faire à la main, choisir une alternative légère comme Linenoise [1] ou opter pour quelque chose de classique et éprouvé : GNU Readline.

Les cartes Arduino AVR, ainsi que d'autres plateformes utilisant cet environnement et cet « IDE », proposent de base une EEPROM permettant de stocker une quantité réduite de données survivant entre les phases d'alimentation d'un projet. Dans le cas des AVR, cette EEPROM est physiquement présente dans le microcontrôleur, mais avec un ESP32 par exemple, c'est une zone de la flash qui sera utilisée. Qu'en est-il d'une fonctionnalité similaire avec la Raspberry Pi Pico et son RP2040 ?

Cela n'est plus à démontrer, il existe actuellement un certain engouement pour les technologies des années 80 à 2000. Qu'il s'agisse de consoles, d'ordinateurs familiaux ou même d'équipements haut de gamme professionnels, les artefacts du monde d'avant les smartphones, de Twitter, de Facebook et d'internet partout et tout le temps ont le vent en poupe. Mais, au-delà de la simple collection visant à faire prendre la poussière à un objet à un endroit plutôt qu'un autre, nous avons là une caractéristique absolument fascinante : il est toujours possible de les utiliser et même de développer de nouveaux programmes pour ces reliques. Et c'est le cas, bien entendu, du plus mémorable des assistants personnels numériques, le Palm Pilot.

Dans le précédent article, nous avons vu comment prendre en main le STM32MP157F-DK2, mettre à jour le système, utiliser le SDK et reconstruire l'ensemble avec OpenEmbedded sur la base d'OpenSTLinux, mais aussi de Poky. Le système de build du projet Yocto n'est cependant pas le seul utilisable et, grâce au travail de Bootlin en partenariat avec ST, il est également possible d'utiliser Buildroot. Voyons cela ensemble...

Rootkits BSD - Mieux les comprendre pour mieux s'en protéger / Lions' Commentary on Unix: With Source Code

Interférences destructives de news...

Dernièrement, les chercheurs de l'université Carnegie Mellon ont publié les sources de PolyCoder [1], une IA génératrice de code entraînée avec GPT-2 et quelque 40 millions de fichiers sources, répartis en quelque 12 langages différents (dont quelque 55 Go de C provenant de plus de 10 000 dépôts Git). PolyCoder semble surpasser notamment Codex d'OpenAI qui alimente la très critiquée fonction Copilot de GitHub, visant à assister le développeur dans sa production de code.

Voici quelques saines lectures pour vos soirées. Ces ouvrages ne sont pas nécessairement les plus récents, mais méritent de trouver place dans la bibliothèque de tout développeur qui se respecte, selon ses affinités personnelles bien sûr. Il vous faudra certes un minimum de pratique dans la langue de Shakespeare pour les « consommer », mais l'effort en vaut réellement la chandelle au regard de leur contenu...

Dans l'article précédent, nous avons été capables d'afficher à l'écran une image, traitée par l'application Gimp et intégrée à notre code. Mais si vous avez reproduit ces essais, en particulier avec une image d'une dimension non négligeable, vous avez sans le moindre doute remarqué un petit problème de performances. Si nous voulons utiliser le framebuffer de façon acceptable, nous devons régler ce problème.

Voilà un titre digne d'une publication pour décideur pressé, mais nous parlerons bien de technique (quoi d'autre, sinon ?). Il n'y a pas si longtemps, STMicroelectronics annonçait l'arrivée de la famille de SoC STM32MP1, combinant la puissance de cœurs ARM Cortex-A7 à l'efficacité d'un Cortex-M4, le tout réuni sur une seule puce. La commercialisation récente des « Discovery Kits » et du STM32MP157F-DK2 en particulier est l'occasion rêvée de prendre la bête en main.