Architectures processeur pour l'embarqué¶

Le choix de l'architecture processeur détermine non seulement la performance, mais aussi l'écosystème d'outils, les bibliothèques disponibles et la longévité du projet — autant de critères aussi importants que la fréquence d'horloge.

La famille ARM Cortex : l'architecture dominante du marché¶

ARM ne fabrique pas de processeurs — ARM vend des licences d'architectures IP que les fondeurs (STMicroelectronics, Nordic, NXP, TI...) intègrent dans leurs microcontrôleurs. Cette stratégie a conduit à une domination du marché embarqué estimée à plus de 95 % des MCU vendus.

La famille Cortex se divise en trois branches selon l'application :

• Cortex-M : microcontrôleurs (embarqué, IoT, temps réel)
• Cortex-R : temps réel dur certifié (automobile, stockage)
• Cortex-A : applications (Linux, Android, SBC)

Pour l'IoT, Cortex-M et Cortex-A sont les deux branches pertinentes.

Cortex-M : la hiérarchie des microcontrôleurs¶

graph LR
    M0["Cortex-M0\nARMv6-M\n12 000 portes\nultra low-cost"] --> M0P["Cortex-M0+\nARMv6-M\n+ pipeline 2 étages\n+ MPU optionnel"]
    M0P --> M3["Cortex-M3\nARMv7-M\nThumb-2 complet\nMultiplier 1 cycle"]
    M3 --> M4["Cortex-M4\nARMv7E-M\n+ FPU simple précision\n+ instructions DSP\nSIMD 32 bits"]
    M4 --> M7["Cortex-M7\nARMv7E-M\n+ FPU double précision\n+ TCM (0 wait-state)\n+ cache I/D optionnel"]
    M7 --> M33["Cortex-M33\nARMv8-M\n+ TrustZone\n+ FPU optionnel\nSuccesseur M3/M4"]
    M33 --> M55["Cortex-M55\nARMv8.1-M\n+ Helium (MVE)\nML/DSP vectorisé"]

Tableau comparatif Cortex-M par sous-famille¶

Cortex-A : quand Linux devient nécessaire¶

Le Cortex-A est conçu pour faire tourner des OS à mémoire virtuelle (Linux, Android). Il introduit la MMU (Memory Management Unit), les caches multi-niveaux et le multicoeur.

Le Cortex-A35 est l'option la plus adaptée à l'IoT industriel quand Linux est requis : sa consommation peut descendre sous 200 mW tout en supportant un OS complet.

SoC hétérogènes : Cortex-M + Cortex-A sur le même die¶

Les SoC hétérogènes associent un ou plusieurs cœurs Cortex-A (application) avec un ou plusieurs Cortex-M (temps réel) sur le même package. Cette combinaison est idéale pour les gateway IoT :

• NXP i.MX RT1170 : Cortex-M7 @ 1 GHz + Cortex-M4 @ 400 MHz — pas de Cortex-A, mais des performances Cortex-A dans un enveloppe Cortex-M.
• STM32MP1 : Cortex-A7 dual @ 800 MHz + Cortex-M4 @ 209 MHz — Linux sur A7, temps réel sur M4.
• NXP i.MX 8M Plus : Cortex-A53 quad @ 1,8 GHz + Cortex-M7 @ 800 MHz + NPU ML @ 2,3 TOPS.

Le modèle de programmation est dit AMP (Asymmetric Multi-Processing) : chaque cœur exécute son propre OS ou firmware, la communication inter-cœurs s'effectue via la mémoire partagée et des mécanismes de signalisation (RPMsg / OpenAMP).

graph LR
    A["Cortex-A7 (Linux)<br/>Réseau, OTA, HMI<br/>Interface cloud<br/>Node-RED, Python"] <-->|RPMsg / shared memory| B["Cortex-M4 (FreeRTOS)<br/>Acquisition capteurs<br/>Contrôle actionneurs<br/>Protocoles temps réel"]

RISC-V : l'architecture ouverte qui monte¶

RISC-V est un jeu d'instructions libre (ISA open-source), développé initialement à l'UC Berkeley. Contrairement à ARM, aucune licence n'est requise pour implémenter RISC-V — ce qui attire les fondeurs souhaitant s'affranchir des royalties ARM.

Architecture RISC-V dans l'IoT¶

flowchart TD
    RV["RISC-V ISA\n(open standard)"] --> RV32I["RV32I\n32 bits base integer\nMinimal viable CPU"]
    RV32I --> EXT["Extensions optionnelles"]
    EXT --> M["M — Multiplication/Division\nhardware"]
    EXT --> C["C — Compressed (16-bit)\n-25% taille code"]
    EXT --> F["F/D — Float (32/64 bits)\nFPU hardware"]
    EXT --> P["P — DSP SIMD\npackaged instructions"]
    EXT --> V["V — Vector\nHPC et ML"]
    RV32I --> IMPL["Implémentations MCU IoT"]
    IMPL --> ESP32C3["ESP32-C3\n(Espressif)\n160 MHz, Wi-Fi + BLE"]
    IMPL --> GD32VF103["GD32VF103\n(GigaDevice)\nCompatible STM32F103"]
    IMPL --> CH32V["CH32V series\n(WCH)\nUltra low-cost"]

RISC-V vs ARM Cortex-M : comparaison pratique¶

RISC-V est à prendre au sérieux pour les nouveaux projets, notamment avec l'ESP32-C3/C6 d'Espressif qui offre Wi-Fi + BLE à moins de 1 € en volume avec un écosystème (ESP-IDF) de qualité industrielle.

Jeux d'instructions : ce qui change concrètement¶

Thumb-2 (ARM Cortex-M)¶

Le jeu d'instructions Thumb-2 est un mélange d'instructions 16 bits et 32 bits. Les instructions 16 bits réduisent la taille du code d'environ 25–30 % par rapport au jeu ARM 32 bits classique — crucial quand la Flash est limitée à 256 Ko.

Avec un compilateur moderne (GCC arm-none-eabi, Clang), Thumb-2 est transparent pour le développeur : la sélection des encodages est automatique. L'impact se mesure sur le binaire final.

Extensions DSP (Cortex-M4/M7)¶

Les extensions SIMD DSP du Cortex-M4 permettent d'exécuter des opérations sur des données de 8 ou 16 bits emballées dans un registre 32 bits. Exemple : UADD8 additionne quatre paires d'octets en un cycle.

Impact concret sur un filtre FIR 32 taps :

• Cortex-M3 (sans DSP) : ~32 cycles par échantillon
• Cortex-M4 (avec SIMD) : ~8 cycles par échantillon

Pour une fréquence d'échantillonnage audio de 48 kHz, c'est la différence entre 1,5 MHz requis et 384 kHz requis — ce qui change complètement le budget énergétique.

Pipeline simplifié Cortex-M4¶

flowchart LR
    IF["Fetch\n(F)\nLecture\nFlash/TCM"] --> ID["Decode\n(D)\nDécodage\ninstruction"]
    ID --> EX["Execute\n(E)\nALU / FPU\nMult-Acc DSP"]
    EX --> MA["Memory\nAccess\n(M)\nLoad/Store\nSRAM"]
    MA --> WB["Write Back\n(W)\nÉcriture\nregistres"]

    BPU["Branch\nPredictor\n(1 bit)"] -.-> IF
    FPU["FPU\n(SP float)\nlatence 1–14 cy"] -.-> EX
    MPU["MPU\n(8 régions)"] -.-> MA

Le pipeline à 5 étages du Cortex-M4 atteint généralement 1,25 DMIPS/MHz (Dhrystone). Pour une application embarquée typique, les accès mémoire (Flash avec wait states) sont le facteur limitant, pas la puissance de calcul pure.

Toolchain et écosystème : critères souvent négligés¶

Choisir une architecture processeur, c'est aussi choisir un écosystème d'outils pour toute la durée de vie du produit — souvent 10 à 15 ans.

Toolchains de compilation¶

Débogage matériel¶

Le choix de l'interface de débogage matériel conditionne la vitesse de développement. ARM propose deux standards :

• SWD (Serial Wire Debug) : 2 fils (SWDIO + SWDCLK), suffisant pour la majorité des cas. Disponible sur tous les Cortex-M.
• JTAG : 5 fils, nécessaire pour le débogage multicoeur (SoC hétérogènes) et certaines fonctionnalités avancées (ETM — Embedded Trace Macrocell).

Les sondes les plus répandues dans l'industrie :

Environnements de développement intégrés (IDE)¶

Ce qu'il faut retenir¶

• La famille Cortex-M domine le marché IoT avec une hiérarchie claire : M0/M0+ pour l'ultra low-cost, M4 pour le traitement signal, M7 pour les gateway embarquées, M33 pour la sécurité TrustZone.
• Le Cortex-A est nécessaire uniquement quand Linux ou un OS à mémoire virtuelle est requis — son surcoût en énergie et en complexité est significatif.
• RISC-V (ESP32-C3/C6) est une alternative sérieuse pour les nouveaux projets Wi-Fi/BLE, avec un écosystème qui mûrit rapidement.
• Les extensions DSP du Cortex-M4 peuvent réduire la charge de traitement signal d'un facteur 4, changeant complètement le dimensionnement énergétique.
• Choisir une architecture, c'est choisir un écosystème d'outils pour 5 à 10 ans — la maturité du toolchain et du support RTOS compte autant que les MHz.

Chapitre suivant : Bare-metal, RTOS et Linux embarqué — quel modèle d'exécution pour votre architecture ?