Cette question peut faire penser à la controverse de Valladolid https://fr.wikipedia.org/wiki/Controverse_de_Valladolid
Des mois pour décider que " les Indiens et les autres peuples sont de « véritables êtres humains » "
Les Indiens ont-ils une âme ? Les microcontrôleurs ont-ils un systême ?
(on passera sur "le sexe des anges")
1.
Parmi les personnes qui pratiquent l'informatique, nombreuses sont celles qui savent que l'ordinateur possède une "processeur" et que les programmes qu'ils utilisent ont besoin d'un système. Mais cela, c'est pour les grosses machines, disposant de ressources suffisantes.
Mais est-ce le cas des petits processeurs comme celui du Pico Pi ou des ESP32, très répandus aussi ?
2.
J'ai commencé à chercher et ai trouvé les noms de RTOS, FreeRTOS, qui permet d'utiliser les deux coeurs de certains ESP32. Par exemple. https://www.aranacorp.com/fr/programme- ... -freertos/
(remarque : utilisation du langage C, ce qui n'a rien de surprenant. Une autre page, utilisant le langage de programmation rust propose un peu la même chose : https://dev.to/theembeddedrustacean/esp ... dings-251g )
Si des gens ici ont acquis des compétences sur ce sujet, j'aimerais bien lire la suite.
Les microcontrôleurs ont-ils un systême d'exploitation ?
Re: Les microcontrôleurs ont-ils un systême d'exploitation ?
Un firmware : de plus en plus souvent à mesure que la puissance générale des microcontrôleurs progresse.
Un OS : tout dépend. Il en existe des tas (souvent des OS temps réel), mais la plupart du temps il n'y aura qu'une application de déployée, alors plutôt que de développer pour un OS (qui propose des API standardisées), on développe avec un jeu de librairies standardisées (ce qui revient exactement au même), permettant ainsi d'avoir un résultat plus frugal en ressources.
Une approche que j'aime bien est le multiboot de programmes dits "bare metal". Plutôt que d'utiliser un OS, qui consomme des ressources, ou de déployer en dur une application sans OS, ce qui n'est pas très flexible, on utiliser un petit chargeur, qui "flashe" au démarrage l'application que l'on va utiliser. C'est ce que fait le PicoCalc avec les derniers outils de sa suite logicielle et c'est bien pratique.
A+, David
Un OS : tout dépend. Il en existe des tas (souvent des OS temps réel), mais la plupart du temps il n'y aura qu'une application de déployée, alors plutôt que de développer pour un OS (qui propose des API standardisées), on développe avec un jeu de librairies standardisées (ce qui revient exactement au même), permettant ainsi d'avoir un résultat plus frugal en ressources.
Une approche que j'aime bien est le multiboot de programmes dits "bare metal". Plutôt que d'utiliser un OS, qui consomme des ressources, ou de déployer en dur une application sans OS, ce qui n'est pas très flexible, on utiliser un petit chargeur, qui "flashe" au démarrage l'application que l'on va utiliser. C'est ce que fait le PicoCalc avec les derniers outils de sa suite logicielle et c'est bien pratique.
A+, David
David Feugey - Mag42
Re: Les microcontrôleurs ont-ils un systême d'exploitation ?
Intéressant.
Il y aurait donc plusieurs cas possibles :
- Microcontrôleur + programme bare métal installé en dur : ne sait faire qu'une chose.
Exemple un pico pi dans une alarme.
- Le même avec une surcouche système pas forcément nécessaire.
- Le même pouvant charger tel ou tel programme bare métal en fonction d'une option de départ. Dans ce cas, les différents programmes sont stockés dans une mémoire annexe. Ce serait le cas de Picocalc.
Le Pico "sait faire" plein de choses en fonction de l'option initiale : contrôler une station météo, faire de la musique, faire une calculatrice.
Le plus étant le petit chargeur et son aptitude à "faire rentrer" (flasher ?) l'application dans le bidule.
On gagnerait sur deux tableaux :
- compacité
- versatilité.
En se référant aux anciens ordinateurs 8 bits, on pourrait imaginer qu'au démarrage on charge dans la même base matérielle : un Oric, un TI 99 ... et tout ça avec une base pico pi ou ESP32.
C'est plus compliqué que ça ?
Il y aurait donc plusieurs cas possibles :
- Microcontrôleur + programme bare métal installé en dur : ne sait faire qu'une chose.
Exemple un pico pi dans une alarme.
- Le même avec une surcouche système pas forcément nécessaire.
- Le même pouvant charger tel ou tel programme bare métal en fonction d'une option de départ. Dans ce cas, les différents programmes sont stockés dans une mémoire annexe. Ce serait le cas de Picocalc.
Le Pico "sait faire" plein de choses en fonction de l'option initiale : contrôler une station météo, faire de la musique, faire une calculatrice.
Le plus étant le petit chargeur et son aptitude à "faire rentrer" (flasher ?) l'application dans le bidule.
On gagnerait sur deux tableaux :
- compacité
- versatilité.
En se référant aux anciens ordinateurs 8 bits, on pourrait imaginer qu'au démarrage on charge dans la même base matérielle : un Oric, un TI 99 ... et tout ça avec une base pico pi ou ESP32.
C'est plus compliqué que ça ?
Re: Les microcontrôleurs ont-ils un systême d'exploitation ?
On peut faire plus que l'imaginer.lerautal a écrit : dim. 28 juin 2026 11:27 En se référant aux anciens ordinateurs 8 bits, on pourrait imaginer qu'au démarrage on charge dans la même base matérielle : un Oric, un TI 99 ... et tout ça avec une base pico pi ou ESP32.
Le MEGA65, ordinateur basé sur un FPGA, peut changer de "personnalité" (entre 8) à chaque démarrage. On y retrouve presque tous les ordinateurs Commodore 8 bits et un clone du TI99/4A avec mode turbo x36 !
David Feugey - Mag42
Re: Les microcontrôleurs ont-ils un systême d'exploitation ?
Pour illustrer ce qui a été écrit plus haut voir
https://forum.clockworkpi.com/t/i-made- ... card/16664
Les applications sont sur la carte SD
Un bootloader (chargeur au démarrage ?) permet de charger celle que l'on veut.
Cela fonctionne sur le Pico Calc qui permet d'afficher un menu des applications disponibles (voir illustration sur la page citée).
C'est beaucoup plus interactif que de charger un programme en utilisant Thonny ou Vscode.
https://forum.clockworkpi.com/t/i-made- ... card/16664
Les applications sont sur la carte SD
Un bootloader (chargeur au démarrage ?) permet de charger celle que l'on veut.
Cela fonctionne sur le Pico Calc qui permet d'afficher un menu des applications disponibles (voir illustration sur la page citée).
C'est beaucoup plus interactif que de charger un programme en utilisant Thonny ou Vscode.
Re: Les microcontrôleurs ont-ils un systême d'exploitation ?
Retour sur les chargeurs d'application.
1.
Partons d'un constat simplificateur : j'allume le machin et l'écran m'affiche l'environnement familier.
Je sais qu'il y a un objet magique qui fait le "gros du boulot" : le microprocesseur (6502, Z80, ARM, Intel, AMD, 68000,...).
Mais qu'y a-t-il entre lui et le résultat qui s'affiche ?
Pour un PC, il y a le système : Windows, Linux, BSD et c'est lui que je vois (plutôt une interface que s'appuie sur les services qu'il propose).
C'est tout ? Je n'ai rien oublié ?
2.
Si, un élément essentiel : le chargeur d'application (Boot Loader).
Le programme qui, à partir d'une instruction du processeur, va lancer l'exécution du système.
Il doit en exister "plein" mais on peut ici en signaler un qui est libre : Das U-Boot.
Une petite page en français présente ses fonctionnalités :
https://fr.wikipedia.org/wiki/Das_U-Boot
On y découvre qu'il est utilisé, en particulier, par SpaceX pour les lanceurs Falcon et la capsule Dragon.
L'article en anglais est beaucoup plus complet, et peut être traduit automatiquement :
https://en.wikipedia.org/wiki/Das_U-Boot
3.
Le langage de programmation Forth est évoqué ailleurs sur ce forum.
Signalons un projet de système Forth qui utilise U Boot comme chargeur de démarrage.
https://www.onirom.fr/wiki/blog/30-11-2 ... tal_usage/
4.
Un Boot Loader est-il toujours nécessaire ?
Non : on peut décider d'écrire une application qui communique directement avec le processeur et prend en charge la gestion du matériel : processeur principal, clavier, affichage...
Dans ce cas, on parle d'application "bare-métal", par exemple pour l'informatique embarquée.
Voir https://fr.wikipedia.org/wiki/Bare_metal
J'espère n'avoir pas égaré ceux qui avaient besoin de ces éclaircissements.
1.
Partons d'un constat simplificateur : j'allume le machin et l'écran m'affiche l'environnement familier.
Je sais qu'il y a un objet magique qui fait le "gros du boulot" : le microprocesseur (6502, Z80, ARM, Intel, AMD, 68000,...).
Mais qu'y a-t-il entre lui et le résultat qui s'affiche ?
Pour un PC, il y a le système : Windows, Linux, BSD et c'est lui que je vois (plutôt une interface que s'appuie sur les services qu'il propose).
C'est tout ? Je n'ai rien oublié ?
2.
Si, un élément essentiel : le chargeur d'application (Boot Loader).
Le programme qui, à partir d'une instruction du processeur, va lancer l'exécution du système.
Il doit en exister "plein" mais on peut ici en signaler un qui est libre : Das U-Boot.
Une petite page en français présente ses fonctionnalités :
https://fr.wikipedia.org/wiki/Das_U-Boot
On y découvre qu'il est utilisé, en particulier, par SpaceX pour les lanceurs Falcon et la capsule Dragon.
L'article en anglais est beaucoup plus complet, et peut être traduit automatiquement :
https://en.wikipedia.org/wiki/Das_U-Boot
3.
Le langage de programmation Forth est évoqué ailleurs sur ce forum.
Signalons un projet de système Forth qui utilise U Boot comme chargeur de démarrage.
https://www.onirom.fr/wiki/blog/30-11-2 ... tal_usage/
4.
Un Boot Loader est-il toujours nécessaire ?
Non : on peut décider d'écrire une application qui communique directement avec le processeur et prend en charge la gestion du matériel : processeur principal, clavier, affichage...
Dans ce cas, on parle d'application "bare-métal", par exemple pour l'informatique embarquée.
Voir https://fr.wikipedia.org/wiki/Bare_metal
J'espère n'avoir pas égaré ceux qui avaient besoin de ces éclaircissements.