On en parle partout: dans les téléphones, les montres connectées, les voitures, les ordinateurs portables - et dans 99% des cartes de développement qui traînent sur nos bureaux d'ingénieurs. ARM est devenu aussi omniprésent que l'air qu'on respire dans le monde de l'embarqué.
Mais d'où vient cette architecture, pourquoi a-t-elle si bien réussi là où tant d'autres ont échoué, et qu'est-ce que ça change concrètement pour les développeurs de systèmes embarqués ?
Une histoire de contraintes, d'élégance... et d'un peu de chance.
Nous sommes en 1983. Une petite société britannique nommée Acorn Computers veut concevoir un processeur pour ses futurs ordinateurs personnels. Faute de budget pour une grosse équipe d'ingénieurs et car Motorola ne veut pas fournir certains de ces CPU, elle prend un pari audacieux: faire simple. Très simple. Radicalement simple.
L'équipe s'inspire des travaux universitaires sur les architectures RISC (Reduced Instruction Set Computer), portés notamment par Patterson et Hennessy à Berkeley. L'idée centrale est à contre-courant de l'époque: plutôt que d'avoir des centaines d'instructions complexes câblées dans le processeur, n'en garder qu'un petit nombre, toutes exécutables en un seul cycle d'horloge (1 cycle throughput c'est potentiellement plusieurs cycles en réalité, mais un seul en apparence)
Le premier processeur Acorn RISC Machine, l'ARM1, voit le jour en 1985. Il utilise 25 000 transistors alors que l'Intel 80386 de la même époque en embarque 275 000. Moins de transistors, c'est moins de consommation électrique, moins de chaleur et une conception plus fiable. Acorn a, sans le savoir, inventé le futur du calcul embarqué.
En 1990, Acorn, Apple et VLSI Technology s'associent pour créer Advanced RISC Machines Ltd qui est la société ARM telle qu'on la connaît aujourd'hui. Apple cherche alors un processeur pour son Newton, le premier PDA grand public. Ce sera l'ARM610.
ARM ne fabrique pas de puces. ARM conçoit des architectures et vend des licences aux fabricants qui souhaitent produire leurs propres processeurs. C'est ce qu'on appelle un modèle fabless: pas d'usine, pas de wafers, juste de la propriété intellectuelle.
Ce choix stratégique est brillant. Il permet à des centaines d'entreprises telles que Qualcomm, Apple, Samsung, STMicroelectronics, NXP, Texas Instruments de concevoir leurs propres SoC (System on Chip) en partant d'une base commune, éprouvée et documentée. Chacun peut y ajouter ses propres périphériques, ses propres accélérateurs, sa propre sauce maison.
Et dans le monde de l'embarqués cela a une conséquence directe: l'ISA (Instruction Set Architecture) ARM est très similaire pour tous les CPU qui la partagent. Un binaire compilé pour Cortex-M4 générique aura de très grandes chances de fonctionner sur un STM32, un nRF52 ou un LPC55 si il a les même particularité. En vrai il faut quand même recompiler, car les fondeurs ne garantissente en aucun cas le passage d'un CPU à l'autre ! Par ailleurs les outils (GCC, LLVM, GDB) sont communs. Les formations sont transférables. L'investissement en compétences ARM est capitalisable d'un projet à l'autre et d'un client à l'autre.
Résultat: plus de 260 milliards de puces ARM avaient été produites en 2024. C'est l'architecture qui a unifié l'embarqué.
Le premier à connaître un succès de masse. On le trouve dans les Game Boy Advance, dans d'innombrables téléphones Nokia, dans des calculatrices Texas Instruments. Petit, sobre, robuste. L'ARM7TDMI a initié une génération entière d'ingénieurs embarqués aux joies de l'architecture ARM: pas de pipeline superscalaire, pas de cache d'instructions par défaut, une consommation dérisoire. Un outil parfait pour apprendre et entreprendre.
La gamme Cortex-M est aujourd'hui la colonne vertébrale des microcontrôleurs modernes. C'est la famille qui nous concerne le plus directement dans l'industrie.
On les retrouve partout: STM32, nRF52, RP2040, SAMD51, LPC55... Si vous développez du firmware aujourd'hui, vous avez très probablement écrit du code pour un Cortex-M.
La gamme Cortex-A est destinée aux applications "riches": Linux, Android, systèmes de fichiers complexes, interfaces graphiques. Le Cortex-A8 a par exemple équipé l'iPhone 3GS. Le Cortex-A53 a démocratisé le 64 bits dans l'embarqué milieu de gamme. Le Cortex-A76 a marqué un saut générationnel qui a rendu ARM crédible pour des charges de travail lourdes.
La frontière Cortex-M / Cortex-A c'est aussi la frontière bare-metal ou RTOS / Linux embarqué. Les deux mondes ont leurs propres outils, leurs propres contraintes. Mais la même ISA de base, les mêmes compilateurs, les mêmes conventions d'appel. Passer de l'un à l'autre n'est pas un saut dans le vide.
Ainsi on les trouvent tous les deux couplés au sein du même SoC avec un Cortex-A pour le noyau et un Cortex-M en tant que co-processeur pour exécuter les vérifications de sécurité ou offloader des firmware Autosar par exmple. Cela sera détaillé plus loin, il s'agit de l'architecture hétérogène AMP (Asymmetric Multiprocessing)
Avant ARM Cortex-M, la gestion des interruptions sur microcontrôleur existait mais était plus primitive: registres spéciaux, priorités figées ou inexistantes.
Le NVIC du Cortex-M améliore tout. Jusqu'à 240 interruptions avec priorité configurable par registre. La sauvegarde du contexte (registres R0-R3, R12, LR, PC, xPSR) est faite automatiquement par le matériel à l'entrée de l'ISR. Le compilateur C n'a plus à gérer de cas particulier, les ISR sont "normales". La préemption entre interruptions est gérée matériellement selon les priorités configurées.
Pour un ingénieur venant du monde AVR ou PIC comme ce fût mon cas c'est un choc de confort. On écrit des ISR en C propre, on configure les priorités dans un registre, et le hardware fait le reste.
Petit détail de l'histoire: la raison architecturale pour laquelle les registres empilés sont exactement ces 8-là et pas les autres n’est pas arbitraire, c’est lié à l’ABI ARM et à la latence d’interruption !
ARM a très tôt compris que sur les systèmes embarqués, la mémoire est rare et chère. Le jeu d'instructions Thumb (1994) encode les instructions les plus fréquentes sur 16 bits au lieu de 32 bits, réduisant la taille du code de 30 à 40% sans perte significative de performance sur les bus 16 bits de l'époque.
Thumb-2 (2003) raffine l'idée: un mix d'instructions 16 et 32 bits dans le même flux d'exécution, sans changer de mode. Le compilateur choisit automatiquement l'encodage optimal. Sur Cortex-M, c'est le seul mode disponible et il est très efficace.
Concrètement pour le développeur: moins de flash nécessaire pour le même programme donc des MCU moins chers pour le même produit. Sur une série industrielle, ça compte.
Une MMU (Memory Management Unit) complète telle qu'on la trouve sur les Cortex-A pour faire tourner Linux est trop coûteuse à ajouter au silicium des microcontrôleurs: elle nécessite des circuits qui vont prendre trop la place au regard des autres.
Presque tous les Cortex-M3 et supérieurs intègrent une MPU (Memory Protection Unit) qui est un compromis ingénieux: sans translation d'adresses virtuelles, elle permet quand même de définir des régions mémoire avec des droits d'accès (lecture seule, lecture-écriture, exécution interdite, accès privilégié uniquement). Un débordement de pile ou un accès à une région interdite depuis une tâche RTOS lève un MemManage fault au lieu de corrompre silencieusement la mémoire. C'est pas une MMU mais ça permet d'avoir quand même beaucoup de ses bénéfices sans le coût d'implémentation !
Pour les projets avec un RTOS (FreeRTOS, Zephyr, ThreadX) la MPU permet d'isoler les tâches entre elles. C'est un outil de fiabilité redoutable, encore sous-exploité dans beaucoup de projets.
Sur les Cortex-M33, M35P et supérieurs, l'extension TrustZone-M crée deux mondes d'exécution isolés matériellement: Secure et Non-Secure. Le code sécurisé (gestion des clés, authentification, démarrage vérifié) tourne dans le monde Secure et ne peut pas être atteint par le code applicatif, même en cas de compromission complète de ce dernier.
C'est une réponse directe aux exigences croissantes de sécurité dans l'IoT: PSA (Platform Security Architecture) d'ARM, IEC 62443 (qui encourage cet usage sans l'imposer malgré tout) Sans TrustZone, implémenter un stockage de clés résistant aux attaques logicielles sur microcontrôleur nécessite un composant externe (secure element). Avec TrustZone, c'est dans le SoC principal. C'est donc un gain d'argent sur le produit fini et un gain de temps car le logiciel existe déjà et est éprouvé rendant l'usage plus simple.
Sur les Cortex-A, ARM a inventé l'architecture big.LITTLE en 2011: des cœurs hautes performances (big, type Cortex-A15) associés à des cœurs haute efficacité (LITTLE, type Cortex-A7) dans le même SoC. Le scheduler du noyau Linux (ou Android) route les tâches vers les bons cœurs selon la charge.
Pour l'embarqué Linux (gateways industrielles, caméras intelligentes, boîtiers de contrôle automobile), c'est une révolution: on peut maintenir un système réactif avec une faible consommation au repos, et mobiliser de la puissance brute sur demande, sans changer de SoC.
La famille STM32 de STMicroelectronics couvre un spectre impressionnant: du STM32F0 (Cortex-M0, 48 MHz, quelques centimes) au STM32H7 (Cortex-M7, 480 MHz). Ecosystème logiciel mature (HAL, CubeMX, TouchGFX), disponibilité mondiale, documentation exhaustive. C'est probablement le microcontrôleur le plus utilisé en prototypage professionnel et en petites séries aujourd'hui.
Nordic Semiconductor a bâti ses SoC nRF52 (Cortex-M4) et nRF53 (Cortex-M33 + Cortex-M33 dédié radio) autour de la connectivité: BLE, Zigbee, Thread, Matter. Le nRF5340 embarque deux cœurs M33: l'un pour l'application, l'autre exclusivement pour la pile radio. Une séparation élégante qui simplifie les certifications radio et la sécurité. Incontournable pour l'IoT basse consommation.
NXP propose des SoC qui combinent Cortex-A (Linux) et Cortex-M (temps réel) dans le même package. L'iMX8M Plus embarque quatre Cortex-A53, un Cortex-M7, un NPU et un GPU. L'iMX93 ajoute deux cœurs Cortex-A55 et un Cortex-M33 avec TrustZone.
C'est le paradigme du SoC hétérogène: Linux gère l'interface homme-machine, la connectivité, l'IA légère ; le Cortex-M gère le temps réel strict, les périphériques bas niveau, le safe state en cas de crash Linux. Les deux communiquent via RPMsg ou mémoire partagée. Une architecture de plus en plus commune dans l'industrie et l'automobile.
Le BCM2712 embarque quatre Cortex-A76 à 2,4 GHz. Ce n'est pas qu'un jouet: c'est une plateforme Linux sérieuse qui a remplacé de nombreux petits serveurs industriels et systèmes industriel: il suffit de voir toutes utilisation par les industriels des Compute Module de Raspberry Pi. La disponibilité et le prix en font un choix rationnel pour les petites séries et le prototypage de systèmes Linux embarqués.
AWS Graviton, Apple M1/M4, Microsoft Cobalt, Google Axion: ARM a aussi conquis le datacenter. C'est une bonne nouvelle pour l'embarqué - les investissements colossaux dans les outils, compilateurs et distributions Linux ARM n'en sont que plus robustes.
Le Cortex-M85 (2022) intègre les extensions Helium (MVE ; M-profile Vector Extension): des instructions SIMD vectorielles sur 128 bits, conçues pour accélérer le traitement de signal et l'inférence de réseaux de neurones directement sur MCU. Un Cortex-M85 peut exécuter des modèles TensorFlow Lite Micro significativement plus vite qu'un Cortex-M7, sans co-processeur externe et avec quelques milliwatts seulement.
C'est l'IA at the edge au sens propre du terme: pas dans le cloud, pas dans une gateway, directement dans le capteur.
ARM a refondu ses cœurs avec le Cortex-X925 et le Cortex-A725 (2024). Issus de la microarchitecture Blackhawk le gain en efficacité énergétique par rapport à la génération précédente avoisine 15-20% à performances égales. Pour l'embarqué Linux hautes performances (vision industrielle, robotique, véhicules autonomes) c'est donc moins de problèmes thermiques et des batteries plus petites.
Il serait malhonnête de parler d'ARM sans mentionner RISC-V. Cette architecture open source et libre de droits gagne du terrain dans les microcontrôleurs basse consommation (ESP32-C3/C6 d'Espressif). Même si ARM reste très en avance sur l'écosystème logiciel et la maturité des outils, RISC-V est une pression saine qui pousse ARM à rester compétitif sur ses prix de licence. C'est une bonne chose pour tous les utilisateurs.
Pour un développeur de logiciel embarqué, ARM n'est pas une option parmi d'autres: c'est le terrain de jeu quotidien. Que l'on programme un microcontrôleur en bare-metal ou que l'on porte un BSP Linux sur une gateway industrielle.
Sa force n'est pas seulement technique. C'est l'écosystème: les compilateurs matures, les RTOS portés et optimisés, les HAL des fabricants, les debuggers JTAG/SWD universels, les millions de pages de documentation et de discussions sur les forums. C'est le fait que les compétences acquises sur un STM32 sont directement utiles sur un nRF52, une iMX8 ou encore un Raspberry Pi.
Maîtriser ARM en profondeur (le NVIC, la MPU, TrustZone, les niveaux de privilège EL0/EL1/EL2/EL3 en ARMv8, l'architecture big.LITTLE, les subtilités du pipeline Cortex-M) c'est investir dans des compétences qui resteront pertinentes pour longtemps.
Et si RISC-V ou une autre architecture vient un jour le bousculer, ce sera en s'inspirant de ce qu'ARM a réussi: la simplicité et la cohérence au service de la performance.