Programmation bare metal : définition, fonctionnement et comment débuter

La « programmation bare metal » place le logiciel juste à côté du matériel : le programme s’exécute sur le processeur et dialogue directement avec les périphériques, sans Windows, sans Linux, sans aucun OS généraliste au milieu. On la retrouve dans les capteurs, les objets connectés portables, les bootloaders et les firmwares. Cet article explique ce qu’est la programmation bare metal, comment elle fonctionne, en quoi elle diffère de la programmation classique, comment le logiciel dialogue avec le matériel, à quoi ressemble un vrai projet bare metal, et comment se lancer sans risque.

Les bases de la programmation bare metal

En bare metal, votre logiciel s’exécute directement sur le matériel. Aucun système comme Windows ou Linux ne gère la mémoire, les processus ou les pilotes à votre place. À l’aide des registres et des E/S mappées en mémoire, le programme pilote lui-même le processeur et ses périphériques.

Dans la plupart des cas, une application de bureau fait tourner votre code par-dessus la machine. Lorsqu’elle doit afficher une fenêtre, écrire un fichier ou se connecter à un service réseau, c’est le système d’exploitation qui fait le travail. Il gère les fichiers, charge les pilotes et décide comment les différents programmes se partagent l’ordinateur. C’est lui aussi qui décide quand votre processus s’exécute.

En bare metal, il n’y a plus de couche OS entre votre code et le matériel. Votre code ne s’occupe que de ce dont la machine a besoin sur-le-champ : allumer une LED, lire un capteur de température, configurer une horloge ou un port série. Sur un projet plus ambitieux, il peut initialiser l’affichage, gérer les entrées, planifier des tâches et charger un programme de second étage. En arrière-plan, aucun bureau, aucun gestionnaire de processus, aucun service système ne prend de décision à votre place.

Cette approche directe devient précieuse quand vous avez besoin d’un timing précis, d’une faible consommation, d’un code compact ou d’un contrôle total. Aucun des microcontrôleurs de votre lave-linge n’a besoin d’un gestionnaire de fenêtres. Il doit lire des entrées, piloter un moteur en toute sécurité et réagir au bon moment. Les bootloaders, eux aussi, ne font que quelques choses : ils préparent la machine pour le logiciel suivant, puis lui passent la main.

Ce que « bare metal » veut vraiment dire

L’expression est une métaphore. Le « metal », c’est le processeur, la mémoire, les broches et toute l’électronique qui y est reliée. « Bare » (nu) signifie qu’il n’y a aucune couche de système d’exploitation entre le programme que vous avez compilé et ce matériel. Votre projet peut malgré tout s’appuyer sur un firmware, une boot ROM, une bibliothèque d’abstraction matérielle (HAL) ou un RTOS. L’idée essentielle, c’est qu’aucun système d’exploitation complet ne fait tourner la machine à votre place.

Cette distinction compte. Le développement classique n’est pas d’office meilleur, plus rapide ou plus sûr que le bare metal : ce sont deux ensembles de compromis différents. Vous gagnez en contrôle et en clarté sur le timing, mais vous récupérez aussi les tâches qu’un système d’exploitation prendrait normalement en charge. Une mauvaise valeur écrite dans un registre peut corrompre des données, empêcher un périphérique de fonctionner, voire figer le processeur. À ce niveau, on lit attentivement, on teste au fur et à mesure, et on documente ce que l’on fait.

Bare metal, ce n’est toujours pas la même chose que l’assembleur

Beaucoup de débutants en bare metal pensent qu’il faut tout écrire en assembleur. L’assembleur reste réellement utile à certains endroits précis — code de reset et de démarrage, vecteurs d’interruption, changement de contexte — mais il ne fait pas tout le travail. Aujourd’hui, l’essentiel du code bare metal s’écrit en C. À mesure qu’un projet grossit, le C se révèle pratique : il permet d’agir directement sur la mémoire et l’agencement binaire.

Les projets embarqués plus structurés peuvent aussi recourir au C++, à condition de se méfier des fonctionnalités d’exécution comme l’allocation dynamique et les exceptions. Rust suscite de plus en plus d’intérêt, car ses règles de propriété (ownership) détectent certains problèmes de mémoire avant même que le programme n’atteigne la carte. Le bare metal indique où le logiciel s’exécute et comment il atteint le matériel : vous n’êtes donc pas obligé d’écrire chaque ligne en assembleur.

Programmation classique et bare metal : la différence en pratique

Un coup d’œil aux couches logicielles éclaire la différence. En temps normal, quand vous créez une application, vous utilisez les services fournis par un système d’exploitation. En bare metal, vous remplacez ces services par votre propre code, une petite bibliothèque, ou rien du tout.

Légende : en programmation classique, votre code atteint le matériel via le système d’exploitation et ses pilotes. En bare metal, ces couches disparaissent — votre code parle directement au matériel.

D'ordinaire, un système d'exploitation s'occupe de l'ordonnancement, de la protection mémoire, des pilotes, des fichiers, des processus et des E/S. En bare metal, ce travail vous revient — ou n'existe tout simplement pas. Un petit contrôleur de LED n'a pas besoin de système de fichiers ; en ajouter un ne ferait qu'alourdir le logiciel et le rendre plus difficile à suivre. En revanche, un appareil qui pilote le moteur d'un drone peut réclamer des timers, des interruptions, des watchdogs et des règles de sécurité strictes inscrites au cœur même du programme.

Voilà pourquoi un programme bare metal peut sembler simple tout en exigeant beaucoup de vous. Le binaire final peut être minuscule, mais rien ne s'y trouve par hasard. La pensée floue ne survit pas longtemps à ce niveau.

Comment le code bare metal s'exécute vraiment

Un programme bare metal démarre à un emplacement fixe en mémoire, dialogue avec le matériel via des registres, et se lance dès que le processeur est mis sous tension ou sort de reset. Un microcontrôleur et un PC moderne diffèrent dans le détail, mais leurs chemins de démarrage suivent le même ordre général : préparer un environnement d'exécution sûr, initialiser la machine, puis passer la main à la logique de votre programme.

Le processus de démarrage (boot)

Un processeur ne connaît pas votre fonction main() à l'instant où il reçoit du courant. Il démarre à une adresse connue, appelée vecteur de reset. Sur un microcontrôleur, cet emplacement mène généralement à une table de vecteurs contenant l'adresse initiale de la pile et la première instruction à exécuter. Après avoir configuré les horloges et la pile, le code de démarrage recopie les données globales initialisées depuis le stockage non volatile vers la RAM, met à zéro les données non initialisées, puis saute à main().

Sur un PC, le chemin comporte une étape de plus. Le firmware UEFI met en place la plateforme et charge une application UEFI ou un bootloader précis via son gestionnaire de démarrage. La spécification UEFI Boot Manager décrit ce passage de relais piloté par le firmware, y compris le chargement de l'image et le moment où l'exécution commence. Une expérience bare metal sur PC peut donc se dérouler avant Windows ou Linux, tout en démarrant dans un environnement firmware qui a déjà configuré des éléments importants de la plateforme.

Cette séquence de démarrage n'a rien à voir avec le développement habituel. Avant que votre première ligne de code ne s'exécute dans un programme C classique, le système d'exploitation a déjà configuré la mémoire, transmis les arguments de ligne de commande et chargé les bibliothèques partagées. En bare metal, vous êtes bien plus près du moment où le courant se transforme en code exécutable.

Exécuter des instructions sans ordonnanceur

Une fois le travail du compilateur et de l'éditeur de liens terminé, votre code source devient un jeu d'instructions pour le processeur. Le CPU va chercher l'instruction suivante, en détermine le sens, l'exécute, puis passe à la suivante. Sur un ordinateur de bureau, l'ordonnanceur du système décide quand votre programme obtient du temps CPU. En bare metal, aucun ordonnanceur généraliste ne fait ce choix. Votre boucle principale tourne jusqu'à ce qu'une interruption survienne, que vous entriez dans un état de basse consommation, ou que votre propre code modifie le déroulement.

Ce contrôle direct aide beaucoup pour le temps réel. Toutes les millisecondes, vous pouvez armer un timer pour interrompre le CPU, exécuter une tâche connue, puis revenir à la boucle principale. Vous ne pouvez pas toujours tout prédire — défauts de cache, priorités d'interruption et périphériques lents jouent encore un rôle — mais vous voyez le chemin de timing bien plus clairement.

La mémoire : Flash, RAM et la memory map

La plupart des systèmes embarqués travaillent avec deux zones de stockage principales. La Flash (ou ROM) conserve le programme lorsque l'alimentation est coupée. La RAM est la zone de travail des variables, des piles, des tampons et des données temporaires. Les réglages de votre éditeur de liens indiquent à la chaîne d'outils où placer le code, les données en lecture seule, les variables initialisées et les variables non initialisées.

La memory map (plan mémoire) indique les emplacements mémoire de tout l'appareil. Elle montre où commence la Flash, où finit la RAM, et où se situent les registres de contrôle de chaque périphérique. Le CPU ne vous préviendra pas poliment si vous écrivez à la mauvaise adresse : il peut déclencher une faute ou modifier un état matériel qui n'a rien à voir. Comprendre ce plan est une compétence bare metal essentielle, pas une simple lecture complémentaire.

Les registres : contrôles matériels et stockage CPU

Le mot « registre » peut dérouter les débutants, car il désigne deux choses distinctes mais liées. Les registres CPU sont de petits emplacements de stockage à l'intérieur du processeur. On y trouve notamment le compteur ordinal (program counter), qui repère l'instruction suivante, les registres généraux pour les calculs, et le pointeur de pile (stack pointer), qui suit la pile d'appels courante.

Les registres de périphériques sont différents. Ce sont des emplacements matériels qui définissent comment contrôler, consulter l'état et stocker les données de composants comme les timers, les blocs GPIO, les ports série et les ADC. Un bit par broche physique peut se trouver dans un registre de sortie GPIO. Un registre d'état de timer peut signaler qu'un événement temporisé a eu lieu. Un registre de données UART peut contenir soit le prochain octet à émettre, soit le dernier octet reçu. Le manuel de référence de la puce vous donne les adresses fixes qui permettent d'atteindre ces registres matériels.

Comment le logiciel interagit avec le monde réel : les périphériques

Les parties utiles d'un appareil, ce sont les composants qui entourent le CPU. Le GPIO permet de lire un bouton ou de piloter une LED. L'UART permet de dialoguer facilement avec un ordinateur ou un autre module en série. Les timers créent des délais précis et des événements déclenchés à intervalles fixes. Un ADC transforme la tension d'un capteur analogique en valeur numérique. L'I²C et le SPI relient cartes, capteurs, puces de stockage et écrans.

Du point de vue du programmeur, on configure ces modules en écrivant des motifs de bits dans les registres. Vous choisissez une source d'horloge, réglez le mode d'une broche, activez un périphérique et attendez un drapeau d'état. Le travail est très minutieux, et bien réel : quelques lignes de C suffisent à faire tourner un moteur ou à afficher la lecture d'un capteur dans un terminal.

E/S mappées en mémoire : quand le matériel se comporte comme de la mémoire

L'astuce qui fait ressembler le contrôle matériel à un simple accès mémoire, c'est l'E/S mappée en mémoire (memory-mapped I/O). Avec de la RAM ordinaire, écrire le nombre 100 à une adresse y stocke ce nombre. En memory-mapped I/O, écrire 1 à une certaine adresse peut faire passer une broche physique à l'état haut et allumer une LED.

Le processeur considère la RAM et les registres de périphériques comme appartenant au même espace d'adressage. Ce qui se cache derrière l'adresse fait toute la différence. Une zone peut être reliée à des cellules de RAM, une autre à l'UART, au timer, au contrôleur USB ou au matériel GPIO. Le manuel de référence du microcontrôleur vous dit ce que signifient chaque adresse et chaque bit.

/* À titre d'illustration : l'adresse et le bit seront différents sur votre carte. */
volatile unsigned int *gpio_output = (volatile unsigned int *)GPIO_OUTPUT_ADDRESS;
*gpio_output |= LED_PIN_MASK;   /* Met la broche de la LED à l'état haut */

Le mot-clé volatile est ici crucial. Il indique au compilateur qu'une valeur peut changer en dehors du déroulement normal du programme, ou qu'une écriture a un effet matériel observable. Sans lui, un optimiseur pourrait supprimer une lecture de registre qu'il juge inutile, ou regrouper des écritures d'une manière qui casse le fonctionnement de l'appareil. Avec volatile, le compilateur ne peut plus traiter une E/S matérielle comme de la mémoire ordinaire. En revanche, cela ne rend pas le code thread-safe et ne remplace pas une synchronisation en bonne et due forme.

Cette petite différence montre pourquoi le bare metal exige de la rigueur. À ce niveau, vous n'appelez pas un aimable bouton « on » pour une LED. Vous choisissez quel bit du registre correspond à cette action, et vous l'écrivez délibérément.

Les langages employés pour le bare metal

Le C est l'un des langages les plus courants pour débuter en bare metal. Il se marie bien avec les pointeurs, les adresses mémoire, les opérations bit à bit, les structures et les données de taille fixe. De plus, les chaînes d'outils existent pour presque tous les types de microcontrôleurs. Certains développeurs parlent de « C bare metal » : écrire du C sans système d'exploitation ni framework lourd.

L'assembleur est plus proche du jeu d'instructions du processeur. Il permet de préciser les toutes premières instructions exécutées après le reset, de construire une table de vecteurs d'interruption, de changer les modes du CPU ou d'examiner la manière dont un compilateur interprète le code. Écrire un projet embarqué entier en assembleur n'est cependant pas toujours une bonne idée : c'est plus difficile à maintenir, à relire et à porter.

Les classes et les templates du C++ peuvent aider à mieux organiser des projets embarqués de plus grande taille. Évitez de faire des hypothèses valables sur un ordinateur de bureau mais pas sur une petite cible : sachez plutôt combien de temps prend chaque fonctionnalité. L'allocation dynamique, les exceptions et une bonne partie de la bibliothèque standard ne conviennent pas toujours.

Rust attire de plus en plus l'attention, car il offre un contrôle bas niveau sans beaucoup des problèmes de sécurité mémoire propres au C. Le livre officiel Embedded Rust Book explique comment utiliser Rust en développement no-std, au ras du matériel. C'est un bon choix une fois que vous comprenez le fonctionnement du matériel, mais le C reste le meilleur moyen de lire la plupart des exemples et documents de référence des fabricants.

Vous n'êtes donc pas obligé d'écrire tout votre code en assembleur pour faire du bare metal. Choisissez le langage qui apporte à votre projet la sécurité, le contrôle, le support outillé et la facilité de maintenance dont il a besoin.

Ce que l'on peut réellement construire en bare metal

Projets pour microcontrôleurs

La plupart du temps, vos premiers projets sont petits et simples : faire clignoter des LED, lire un capteur, piloter un servomoteur, enregistrer des mesures via l'UART, ou créer le firmware d'un objet connecté ou d'un wearable. Ces exemples vous apprennent les bases sans vous imposer d'apprendre tout un système d'exploitation.

Logiciels système

Les noyaux de RTOS, les petits systèmes d'exploitation, les bootloaders et les firmwares d'appareils s'appuient tous, au niveau suivant, sur des techniques bare metal. Un bootloader peut chercher une mise à jour de firmware valide, vérifier qu'elle porte la bonne signature, la copier en Flash, puis passer la main. Même un RTOS doté d'un ordonnanceur et de files de messages a besoin d'un travail bas niveau pour démarrer, mapper la mémoire et gérer les interruptions.

Expériences en classe PC

Sur du matériel x86-64, le « bare metal » peut désigner l'écriture d'applications UEFI, l'exploration du code de boot, la création d'un petit système d'exploitation ou l'essai de graphismes bas niveau. Les idées sont les mêmes, mais la plateforme est plus difficile à appréhender. Vous disposez de plusieurs cœurs, d'interfaces graphiques modernes et de beaucoup de RAM. Vous devez aussi composer avec les services du firmware et un écosystème matériel bien plus vaste.

Un jeu sans OS illustre le fonctionnement du bare metal

L'idée devient bien plus concrète qu'avec une démo de LED. En tant qu'application UEFI, le développeur Inkbox a recréé le jeu d'arcade isométrique Zaxxon (1982) en assembleur x86-64. On peut placer le fichier exécutable BOOTX64.EFI dans le répertoire EFI/BOOT/ de la partition système EFI d'un disque GPT. La configuration de test n'utilise pas le Secure Boot : le PC passe donc directement du firmware au jeu, sans Windows ni Linux.

Comme le montre la vidéo de démonstration du projet, Inkbox a développé et testé le jeu sur un mini PC GEEKOM A9 Max (Ryzen AI 9 HX 370). Le projet révèle tout ce que l'on tient d'ordinaire pour acquis dans la pile logicielle d'un jeu. Pour que le jeu tourne correctement, Inkbox a dû lire l'horloge système avec exactitude, localiser le Graphics Output Protocol (GOP), utiliser des opérations BLT pour écrire les pixels, et passer de la saisie clavier à la saisie souris afin de contourner la latence du clavier sous UEFI. Il a aussi mobilisé des cœurs CPU supplémentaires pour passer d'un tampon 256×256 à un tampon 1024×1024, et a bâti un moteur de rendu inspiré du PPU d'une vieille console.

La démo d'Inkbox : le remake de Zaxxon sans OS, tournant sous UEFI.

Le build n'a pas de son, mais dans la vidéo le remake tourne à environ 128 images par seconde. On y voit aussi les problèmes bien réels que le développeur a dû résoudre côté graphismes, timing et saisie clavier. La documentation du Graphics Output Protocol d'UEFI explique l'intérêt du GOP dans ce cas : il fournit une sortie graphique de base avant même le démarrage du système d'exploitation.

Un point technique mérite d'être clarifié. Parler d'« un jeu sans système d'exploitation » a du sens, puisqu'il n'utilise ni Windows ni Linux. Cela dit, certains développeurs bas niveau décrivent l'UEFI comme un environnement d'exécution minimal, car il propose des Boot Services et des Runtime Services. Les deux points de vue se défendent. Le jeu ne tourne pas sur un système d'exploitation de bureau classique : il s'exécute directement sous les services du firmware.

Apprendre à débuter en programmation bare metal

Étape 1 : maîtriser les bases du C

Commencez par les bases du C qui comptent au niveau matériel : pointeurs, manipulation de bits, structures, types entiers de largeur fixe et volatile. Nul besoin de connaître chaque subtilité du langage avant de toucher une carte. En revanche, vous devez comprendre pourquoi un pointeur peut être une adresse, et pourquoi value |= (1U << bit) modifie un seul bit sans toucher aux autres.

Étape 2 : comprendre la mémoire et le CPU

Découvrez ce que sont — et comment fonctionnent — un espace d'adressage, une memory map, une pile, un tas, la Flash, la RAM et les appels de fonction. En bare metal, la taille de la pile n'est pas une ressource invisible : c'est un choix de conception. Les personnes qui travaillent sur du firmware critique pour la sécurité ne peuvent parfois pas utiliser l'allocation dynamique, ou choisissent délibérément de l'éviter.

Étape 3 : approfondir les E/S mappées en mémoire et les registres

C'est la compétence la plus importante. Choisissez un périphérique, par exemple le GPIO, et suivez les étapes du manuel de référence jusqu'au code. Repérez les bits nécessaires, le registre d'activation d'horloge, le registre de mode de broche et le registre de données de sortie. Pour votre tout premier projet de LED, n'utilisez pas la couche d'abstraction matérielle (HAL) du fabricant. La HAL vous servira plus tard, mais écrire la première version registre par registre vous apprendra comment la bibliothèque fonctionne.

Étape 4 : apprivoiser la datasheet d'un microcontrôleur

Vous pouvez démarrer avec un Raspberry Pi Pico, un STM32 « Blue Pill » ou une carte ESP32. Le Pico est facile à prendre en main, car il est très bien documenté. La datasheet officielle du Raspberry Pi Pico est un bon point de départ pour découvrir la carte et son microcontrôleur RP2040. Commencez par la memory map et le brochage, puis passez aux chapitres consacrés aux périphériques. Inutile de lire un manuel de référence de 1 000 pages de bout en bout : apprenez plutôt à trouver la description de registre qui correspond à la tâche du moment.

Étape 5 : réaliser un petit projet

Vous pouvez faire clignoter une LED sans la HAL du fabricant. Réglez l'horloge et le mode GPIO, puis positionnez et effacez le bit de sortie. Aussi modeste soit-il, ce projet prouve que vous savez compiler du code, le flasher sur le matériel, lire une memory map et piloter une vraie puce. Si ça ne marche pas, il faut déboguer : vérifiez les broches, assurez-vous que l'horloge est correcte, relisez les définitions des bits de registre et rendez le code plus lisible.

Étape 6 : passer aux timers et aux interruptions

Les timers et les interruptions vous font sortir des exemples-jouets. Avec une interruption de timer, vous pouvez exécuter une tâche à intervalles réguliers sans figer tout le système dans une boucle d'attente. Une interruption externe permet à un signal de capteur ou à l'appui d'un bouton de déclencher une réponse rapide. Apprenez le fonctionnement des priorités d'interruption et gardez les gestionnaires d'interruption courts. Tout travail trop long doit repartir vers la boucle principale ou être différé.

Étape 7 : viser plus difficile

Une fois le GPIO, l'UART et les timers maîtrisés, vous pouvez réaliser une console UART, un petit bootloader, un ordonnanceur coopératif minimal, ou profiter d'un PC de rechange pour essayer une application UEFI. Là, il ne s'agit plus seulement de périphériques : vous apprenez comment fonctionne un ordinateur et comment le logiciel prend en charge chaque partie de la machine.

Utiliser un mini PC pour le travail bare metal

Un mini PC x86-64 est effectivement une plateforme utile pour développer des applications UEFI, explorer les processus de boot, l'assembleur et les systèmes d'exploitation. En effet, il vous offre du vrai matériel PC, que vous pouvez redémarrer autant de fois que nécessaire sans mettre en péril votre machine principale.

Comme l'architecture est la même que celle des PC de bureau (x86/x64), les compétences liées aux conventions d'appel, à l'agencement mémoire, à l'UEFI et aux bootloaders sont immédiatement réutilisables. Son firmware UEFI permet de créer des applications EFI et de les démarrer. Vous pouvez tester l'ordonnancement multicœur ou des tâches de rendu si vous disposez de plusieurs cœurs CPU. Une RAM et un stockage SSD suffisants facilitent le travail avec les compilateurs, les émulateurs comme QEMU, les images disque et les machines virtuelles.

Utiliser un mini PC pour deux usages à la fois est également pratique. Vous pouvez compiler sous Windows ou Linux, tester d'abord dans QEMU, puis basculer vers un environnement bare metal une fois prêt. Comme il tient peu de place, un ordinateur de test dédié peut se poser à côté de votre machine principale sans envahir tout le bureau.

FAQ

Comment la programmation bare metal change votre façon de penser le code

Vous voyez le logiciel se transformer en action physique d'une manière qu'aucun autre style de programmation ne permet vraiment. Vous découvrez le tout début d'un programme, l'organisation de la mémoire, l'importance des registres, et comment un seul bit peut commander un appareil bien réel. Commencez par le C, une carte richement documentée, un simple projet de LED et la capacité de lire les manuels de référence sans se presser. Vous pourrez ensuite aborder des sujets longtemps restés mystérieux : timers, consoles série, bootloaders et applications UEFI. Pour les expériences de classe PC, un petit système dédié comme un mini PC GEEKOM vous permet de tester, de redémarrer et d'apprendre sans importuner votre poste de travail principal.