Un microcontrôleur (MCU, pour microcontroller unit) est un circuit intégré programmable qui réunit sur une seule puce un processeur, de la mémoire et des périphériques d’sortie : c’est le composant qui exécute le programme de commande au cœur d’un système mécatronique. Cette fiche est le hub d’entrée vers les familles de microcontrôleurs : elle en dresse le panorama et donne la méthode pour en choisir un, sans entrer dans les spécificités de chaque famille (traitées dans les fiches filles) ni dans la façon d’écrire le code (voir firmware).
À quoi ça sert ?
Le microcontrôleur est le cerveau de la chaîne de commande d’un système mécatronique : il lit les capteurs, exécute la logique de décision et pilote les actionneurs. Le choix du contrôleur se fait en phase de concept, typiquement via une matrice de décision par sous-système, puis se fige en dossier technique au moment de l’intégration.
Cette fiche tient une frontière nette avec les notions voisines :
- choisir une famille et une carte adaptées au projet → ici (panorama + aide au choix) ;
- structurer le code embarqué → firmware ;
- lire la datasheet d’un composant → lire-une-datasheet ;
- faire communiquer le MCU avec ses périphériques → bus-de-communication ;
- réagir immédiatement à un événement sans le surveiller en boucle → interruption ;
- outiller son poste et réutiliser du code existant → IDE, bibliothèque.
Panorama des familles
Le paysage va du microcontrôleur 8 bits historique (AVR des premières cartes Arduino) aux 32 bits ARM Cortex-M omniprésents aujourd’hui, jusqu’aux plateformes embarquées de type single-board computer (SBC) comme le Raspberry Pi, qui ne sont pas à proprement parler des microcontrôleurs (elles font tourner un système d’exploitation complet) mais qu’on range ici par usage pédagogique commun.
| Famille | Architecture | Langage / IDE | Conso | E/S & connectivité | Cas d’usage typique |
|---|---|---|---|---|---|
| Arduino | AVR 8 bits (Uno R3) à ARM Cortex-M4 (Uno R4) | C++/Wiring, IDE Arduino | modérée, veille matérielle possible mais peu outillée par le framework | GPIO num./ana., pas de sans-fil natif (sauf R4 WiFi) | apprentissage, prototypage rapide |
| ESP32 | Xtensa LX6/LX7 ou RISC-V, 32 bits | Arduino-core ou ESP-IDF | deep sleep ~µA, ~80–240 mA en Wi-Fi actif | Wi-Fi + Bluetooth intégrés, GPIO riche | objets connectés, projets sans-fil |
| XIAO (Seeed Studio) (format mini — base ESP32) | ESP32-C3 (RISC-V) ou ESP32-S3 (Xtensa), 32 bits | Arduino-core, MicroPython | deep sleep ~µA (base ESP32) | Wi-Fi + BLE, ~11 broches au format timbre-poste | projets compacts, objets portés, IoT miniature |
| Raspberry Pi Pico | RP2040, 2× Cortex-M0+ (Pico 2 : RP2350) | MicroPython (Thonny), C/C++ Pico SDK, Arduino-core | veille ~1 mA (carte) | 26 GPIO, PIO (E/S programmables), pas de sans-fil (Pico W : Wi-Fi + BT) | apprentissage MicroPython, E/S temps réel (PIO) |
| Raspberry Pi (SBC — plateforme embarquée) | ARM Cortex-A multicœur (SoC), sous Linux | Python ou tout langage | plusieurs W | USB/HDMI/Ethernet/Wi-Fi, GPIO | traitement lourd, vision, réseau, besoin d’un OS |
| ESP8266 | Xtensa 32 bits monocœur | Arduino-core | deep sleep ~20 µA | Wi-Fi intégré (pas de BT) | IoT Wi-Fi simple |
| STM32 | ARM Cortex-M0 à M7 | STM32CubeIDE, STM32duino, PlatformIO | modes basse conso soignés | périphériques très riches | projets pro/industriels exigeants |
| Teensy | ARM Cortex-M4/M7 (NXP, jusqu’à 600 MHz) | Arduino + Teensyduino | haute performance | E/S rapides, audio | audio, DSP, performance en cadre Arduino |
| PIC | 8 / 16 / 32 bits (Microchip) | MPLAB X, compilateurs XC | faible consommation | périphériques variés | industriel, legacy, production en très grande série, où la stabilité de la référence et la disponibilité à long terme priment |
Trois repères pour lire ce tableau. La XIAO de Seeed Studio n’est pas une famille de puces mais un format : une carte timbre-poste construite (le plus souvent) autour d’un ESP32. Tout ce qui vaut pour l’ESP32 s’y applique, dans un encombrement minimal. Le Raspberry Pi n’est pas un microcontrôleur mais un ordinateur miniature : il s’impose quand le projet demande un système d’exploitation, du réseau ou du calcul lourd (vision), au prix d’une consommation et d’une complexité supérieures. À ne pas confondre avec le Raspberry Pi Pico, qui est, lui, un vrai microcontrôleur (ligne dédiée du tableau) et notamment la carte canonique du parcours MicroPython. L’ESP8266 a ouvert la voie du Wi-Fi sur microcontrôleur. L’ESP32 le supplante aujourd’hui sur presque tous les plans. Il garde son utilité dans deux cas : quand des cartes ESP8266 sont déjà en parc, et pour reprogrammer des objets du commerce qui en sont équipés.
Aide au choix
Le bon réflexe n’est pas de partir du microcontrôleur à la mode, mais des besoins du projet. Six critères orientent le choix :
- Entrées/sorties — combien de GPIO, d’entrées analogiques (ADC), de sorties PWM, et quelles interfaces (I2C, SPI, UART) le projet exige-t-il ? Et sous quelle tension logique (3,3 V ou 5 V) les capteurs et modules retenus dialoguent-ils ? (→ notion niveaux-de-tension)
- Connectivité — le système doit-il communiquer sans fil (Wi-Fi, Bluetooth) ? Si oui, l’ESP32 part favori. Sinon, une carte sans radio suffit.
- Puissance de calcul et temps réel — une régulation rapide, du traitement de signal ou de l’audio appellent un 32 bits performant (STM32, Teensy). Une lecture de capteur lente se contente d’un 8 bits.
- Consommation — un système sur batterie impose des modes basse consommation (ESP32 en deep sleep, STM32) et un budget courant chiffré (→ notion alimentation-electronique). Sur secteur, le critère pèse moins.
- Écosystème et disponibilité — documentation, communauté, bibliothèques et surtout disponibilité du composant dans la durée comptent souvent plus que quelques mégahertz : un MCU bien documenté et qu’on retrouve chez deux distributeurs fait gagner un temps considérable. La maîtrise de l’équipe compte au même titre : une famille que personne n’a jamais programmée se paie en temps d’apprentissage pris sur le projet.
- Encombrement et intégration — quelle place la carte occupe-t-elle dans le produit, et comment s’y fixe-t-elle ? Une carte au format timbre-poste (XIAO) ouvre des intégrations qu’une Uno interdit. À l’inverse, une carte large aux broches espacées se câble et se dépanne bien plus facilement en phase de prototypage.
En pratique, ces critères se confrontent dans une matrice de décision menée en concept, au même titre que les autres choix d’architecture. La démarche complète dans le projet — chiffrer les besoins, confronter les candidats, tracer le choix — est déroulée dans choisir-le-materiel, l’étape 2 de la colonne de réalisation. Une stratégie fréquente en projet école : prototyper sur une carte facile (Arduino) pour valider le principe, puis migrer vers une cible plus adaptée (ESP32 pour le sans-fil, STM32 pour la performance) si le besoin le justifie.
Voir aussi
- Firmware — structuration du code embarqué (transverse, pseudocode)
- Lire une datasheet — compétence de lecture transverse
- Bus de communication — protocoles UART / I2C / SPI
- Matrice de décision — outil de choix du contrôleur en concept
- Choisir le matériel — la démarche de sélection MCU / capteurs / actionneurs dans le projet (étape 2 de la réalisation)
- Concept — phase où le contrôleur est choisi (étape 2)