I3C : le successeur d'I²C pour capteurs embarqués haute cadence

Un seul IMU échantillonné à plusieurs kHz occupe plus de 70 pourcent d'un bus I²C Fast-mode Plus ; sur un bus I3C en mode SDR, le même capteur en prend moins de 6 pourcent. Le bus I3C (Improved Inter-Integrated Circuit), normalisé par la MIPI Alliance via la spécification I3C Basic v1.1.1, succède à I²C en apportant 12,5 Mbit/s en mode SDR et jusqu'à 25 Mbit/s en HDR-DDR, sans rupture de compatibilité avec les composants I²C existants. Pour les concepteurs qui saturent un bus I²C Fast-mode Plus à 1 MHz sur leurs capteurs MEMS multi-axes ou leurs hubs de capteurs environnementaux, I3C est aujourd'hui la voie d'évolution naturelle.

Chez AESTECHNO, avec plus de 10 ans de conception de cartes embarquées autour de microcontrôleurs STM32 et Nordic nRF, nous suivons ce protocole depuis la sortie des premiers MEMS compatibles (STMicroelectronics LSM6DSO32X, Bosch BMI323). Le nouveau bus repousse le plafond de débit d'I²C tout en réduisant la consommation grâce à sa signalisation 1,2 V / 1,8 V. Ce guide détaille l'architecture électrique, les modes de transmission, l'adressage dynamique, les interruptions in-band et les pièges de conception à anticiper.

I3C : définition et positionnement vs I²C

Le bus I3C est un protocole série deux fils normalisé par la MIPI Alliance à partir de 2016, conçu comme successeur logique d'I²C avec compatibilité descendante et débits dix à vingt fois supérieurs. La spécification publique I3C Basic v1.1.1 couvre les modes SDR, HDR-DDR et l'ensemble des Common Command Codes nécessaires à un design commercial, sans licence payante pour les intégrateurs systèmes.

Ce protocole répond à trois besoins devenus critiques : la densification des capteurs MEMS autour des microcontrôleurs, l'élimination des lignes INT dédiées qui coûtent des GPIO précieux, et la réduction de consommation d'entrée-sortie en signalisation basse tension. Le protocole est codifié par la spécification MIPI I3C Basic v1.1.1 et positionné par la MIPI Alliance comme successeur d'I²C pour les nouveaux designs capteurs.

Les différences clés avec I²C tiennent en trois points : une couche physique push-pull à 12,5 MHz (contre open-drain à 1 MHz maximum en Fast-mode Plus), un adressage dynamique qui remplace les adresses statiques 7 bits, et un jeu de commandes normalisées (CCC) qui standardise la configuration des périphériques multi-fournisseurs. Ces trois évolutions suffisent à justifier la migration sur tout nouveau design capteur haute cadence.

Architecture électrique : push-pull, 12,5 MHz, rétrocompatibilité

L'architecture électrique du protocole est fondée sur des drivers push-pull actifs qui pilotent SCL en permanence et SDA pendant les phases d'écriture maître. Ce choix rompt avec la logique open-drain d'I²C et autorise une horloge à 12,5 MHz en mode SDR avec une seule pull-up sur SDA, tout en réduisant la consommation dynamique sur un bus de capteurs typique.

Concrètement, le maître I3C pilote SCL en push-pull permanent et bascule SDA en push-pull pendant les phases où il transmet des données, en open-drain lorsqu'un esclave répond. Cette gestion dynamique de la couche physique autorise la coexistence avec des composants I²C legacy tout en montant à 12,5 MHz sur les échanges pur I3C. La signalisation recommandée est de 1,8 V, avec support optionnel 1,2 V pour les architectures basse consommation et 3,3 V pour la rétrocompatibilité avec un écosystème I²C existant.

En pratique, le dimensionnement de la pull-up unique sur SDA est plus tolérant qu'en I²C : une valeur de 1,8 kΩ à 2,2 kΩ couvre la plupart des bus mixtes jusqu'à 20 cm de trace, contre la paire 4,7 kΩ / 4,7 kΩ qui devait être recalculée en fonction de la capacitance totale en Fast-mode Plus. Pour la compatibilité CEM, nous suivons les règles IPC-2221 d'impédance contrôlée et les familles IEC 61000-4-x pour les tests ESD et burst sur les produits industriels.

Sur les autres bus MIPI que nous intégrons (D-PHY, C-PHY, M-PHY pour les interfaces caméra et display), nous validons les eye diagrams et les paramètres de timing avec un oscilloscope Tektronix équipé de la suite TekExpress MIPI, conforme aux spécifications MIPI Alliance. Cette instrumentation interne pré-qualifie les liaisons haute vitesse avant toute itération de fabrication, et limite les allers-retours en laboratoire accrédité aux campagnes de certification finale.

Modes de transmission : SDR, HDR-DDR, HDR-TSL/TSP

Le protocole est structuré autour de quatre modes de transmission codifiés dans la spécification MIPI I3C complète (I3C Basic v1.1.1 ne reprend que SDR et les modes HDR-DDR et HDR-BT). Le mode SDR (Single Data Rate) atteint 12,5 Mbit/s et couvre la grande majorité des cas d'usage capteurs. Les modes HDR (High Data Rate) doublent ce débit ou plus pour les applications de streaming audio, image ou inertiel multi-axes échantillonné à plusieurs kHz.

Le mode HDR-DDR est le plus simple à implémenter côté esclave car il réutilise le câblage SDR en échantillonnant sur les deux fronts d'horloge. Les modes HDR-TSL (Ternary Symbol Legacy) et HDR-TSP (Ternary Symbol Pure) encodent plusieurs bits par transition pour dépasser 30 Mbit/s, au prix d'une complexité matérielle supérieure qui limite leur adoption aux SoC multimédias.

En pratique, le mode SDR couvre largement les besoins industriels : un bus SDR à 10 MHz transporte sans peine huit IMU à 1 kHz (accéléromètre, gyroscope, magnétomètre sur trois axes chacun), alors qu'un bus I²C Fast-mode Plus équivalent sature à trois IMU avec un budget temporel serré. Le passage en HDR-DDR reste réservé aux architectures de sensor fusion à très haute cadence (6,4 kHz et plus sur 32 canaux).

Adressage dynamique et Common Command Codes (CCC)

L'adressage dynamique consiste à remplacer les adresses I²C figées en usine par une assignation orchestrée au démarrage par le maître, via la procédure ENTDAA (Enter Dynamic Address Assignment). Chaque périphérique reçoit une adresse 7 bits unique négociée selon son PID (Provisioned ID) 48 bits, ce qui élimine les conflits récurrents entre capteurs partageant la même adresse statique.

Dans le catalogue MEMS de STMicroelectronics, les accéléromètres LIS2DW12 et LSM6DSO partagent historiquement les adresses 0x18/0x19 et 0x6A/0x6B. Au-delà de deux capteurs identiques sur le même bus, un design I²C doit passer par un multiplexeur TCA9548A ou un respin de PCB pour contourner ces collisions. Le nouveau protocole résout définitivement le problème : peu importe combien de composants identiques cohabitent, chacun reçoit son adresse dynamique à l'initialisation du bus.

Les Common Command Codes (CCC) standardisent la configuration cross-vendor. Parmi les CCC les plus utilisés en pratique :

• ENTDAA : déclenche l'assignation dynamique d'adresse sur le bus.
• RSTDAA : réinitialisé toutes les adresses dynamiques (utile avant reconfiguration).
• SETDASA : assigne une adresse dynamique à partir d'une adresse statique I²C existante (migration).
• ENEC / DISEC : active ou désactive les événements asynchrones (IBI, hot-join) par esclave.
• GETCAPS : remonte les capacités déclarées d'un périphérique (HDR, IBI, taux max).
• SETMWL / SETMRL : négocie les tailles de buffer d'écriture et de lecture.

D'après notre expérience sur des designs de hubs capteurs industriels, la discipline CCC évite des journées de debug : un composant I3C correctement provisionné via GETCAPS se configure depuis le firmware sans besoin de driver propriétaire. Les stacks modernes comme Zephyr RTOS exposent ces CCC directement via leur API I3C, ce qui facilite la portabilité entre STM32, Nordic nRF et NXP i.MX RT.

In-Band Interrupts (IBI) et hot-join

Les In-Band Interrupts (IBI) sont un mécanisme qui permet de signaler un événement au maître sans ligne INT physique dédiée, l'esclave prenant brièvement le contrôle du bus pour émettre un message d'interruption. Cette fonctionnalité libère des broches GPIO précieuses sur les microcontrôleurs et simplifie considérablement le routage PCB d'un hub capteurs multi-IMU.

Dans un design I²C classique avec huit capteurs MEMS, chaque composant nécessite sa propre ligne INT, soit huit GPIO dédiés. Sur un STM32H7 en boîtier LQFP100, cela mange près de dix pourcent des broches utiles. Avec IBI, ces huit GPIO disparaissent : chaque esclave signale sa disponibilité de données, sa détection de seuil ou sa condition d'alerte directement sur SDA, via un arbitrage temporel orchestré par le maître.

Le hot-join complète le tableau. Un composant I3C peut rejoindre un bus actif en production sans cycle d'alimentation, ce qui débloque des architectures modulaires impensables en I²C : cartes filles échangeables à chaud, capteurs enfichables sur connecteurs, ou systèmes redondants avec bascule sans reboot. La procédure hot-join s'appuie sur les CCC ENEC / DISEC pour armer ou désarmer l'acceptation de nouveaux périphériques.

Coexistence I²C / I3C sur un bus partagé

Un bus I3C est compatible nativement avec des périphériques I²C legacy, à condition de respecter trois contraintes : tension de signalisation commune, pull-ups dimensionnées pour le composant le plus lent, et vitesse du bus limitée au mode Fast-mode Plus 1 MHz lorsque l'esclave I²C est adressé. Cette coexistence est codifiée par le Legacy Virtual Register (LVR) du standard MIPI.

La règle pratique : si un design mixte contient au moins un esclave I²C 3,3 V, tout le bus bascule en signalisation 3,3 V et les échanges I3C-to-I3C tombent à 12,5 MHz SDR maximum (au lieu de pouvoir exploiter HDR-DDR). À l'inverse, un bus mixte en 1,8 V nécessite des level-shifters dédiés pour les esclaves I²C 3,3 V, ce qui ajoute coût et latence. Nous recommandons deux architectures nettes :

• Bus mixte 3,3 V, SDR uniquement : simple, économique, compatible avec tous les MEMS I²C existants. Débit utile ~10 Mbit/s, suffisant pour la plupart des capteurs industriels.
• Bus I3C pur 1,8 V, HDR-DDR activé : performance maximale, adapté aux hubs capteurs haute cadence et aux applications sensor fusion. Nécessite un inventaire matériel strict (pas de composant I²C 3,3 V non isolé).

La documentation des fabricants de microcontrôleurs référence en permanence la spécification MIPI I3C Basic v1.1.1 comme base normative, et les stacks logicielles modernes respectent cette nomenclature.

Cas d'usage industriels : MEMS, capteurs, hubs

Les cas d'usage industriels d'I3C correspondent à trois familles : les hubs de capteurs MEMS inertiels pour monitoring vibratoire, les réseaux denses de capteurs environnementaux pour métrologie et qualité d'air, et les systèmes de power management qui pilotent finement des convertisseurs PMIC multi-rails. Ces trois familles partagent un besoin de bande passante supérieure à I²C sans complexité de routage SPI.

Dans le monitoring vibratoire industriel, un IMU comme le STMicroelectronics LSM6DSO32X échantillonne jusqu'à 6,66 kHz sur six axes, soit environ 40 kéchantillons/s de 16 bits à transporter, ce qui représente environ 640 kbit/s de charge pure sans protocole. Sur un bus I²C Fast-mode Plus à 1 MHz, le taux d'occupation dépasse 70 pourcent pour un seul capteur : impossible de chaîner huit IMU sans saturer. En I3C SDR à 12,5 MHz, le même capteur occupe moins de 6 pourcent du bus, et l'architecture hub à huit IMU reste confortablement sous 50 pourcent avec marge pour les IBI et la configuration.

Pour les capteurs environnementaux, l'intérêt tient surtout à la coexistence : le Bosch BME688 (température, humidité, pression, gaz), par exemple, ne dispose que d'interfaces I²C et SPI selon Bosch Sensortec ; il se place donc sur un bus mixte en esclave I²C legacy déclaré en LVR, à côté des capteurs I3C natifs. Le routage d'un tel bus suit les règles d'intégrité de signal documentées dans notre guide sur le PCB high-speed.

En power management, les PMIC qui intègrent une interface I3C exposent leurs registres de configuration par ce bus pour piloter la séquence de démarrage, la télémétrie de rails et les alertes de protection. L'IBI remplace avantageusement la traditionnelle ligne PG (Power Good) multiplexée entre rails, et le hot-join autorise des architectures avec cartes filles enfichables en production.

Quand migrer d'I²C à I3C : critères de décision

La décision de migrer d'I²C à I3C exige l'évaluation de cinq critères objectifs. Un seul critère positif suffit rarement à justifier la bascule ; deux ou trois critères rendent la migration rentable sur le cycle de vie produit.

1. Saturation du bus I²C existant : si le taux d'occupation dépasse 50 pourcent en Fast-mode Plus 1 MHz, I3C SDR libère une marge immédiate d'un facteur 10.
2. Conflits d'adresses récurrents : plus de deux capteurs identiques imposent un multiplexeur TCA9548A en I²C, là où I3C assigne dynamiquement les adresses sans matériel additionnel.
3. Pénurie de GPIO pour lignes INT : au-delà de quatre capteurs avec interruption physique, l'économie de GPIO via IBI justifie la migration.
4. Besoin de hot-join en production : cartes filles enfichables, capteurs remplaçables, architectures modulaires imposent I3C.
5. Contrainte de consommation I/O : la signalisation push-pull 1,8 V réduit nettement la consommation dynamique par rapport à I²C 3,3 V open-drain, critique pour les produits sur batterie.

À l'inverse, conserver I²C reste pertinent pour trois cas : BOM figée imposée par un client (normes aéronautiques ou automobiles), écosystème capteurs entièrement legacy sans version I3C disponible, ou produit fin de vie où l'investissement firmware ne se justifie plus. Notre recommandation par défaut pour tout nouveau design capteurs est d'inclure I3C dans le cahier des charges, quitte à démarrer en mode SDR pur et à activer HDR-DDR lors d'une révision logicielle ultérieure.

I3C ne remplace pas tous les bus série de l'embarqué : pour les liaisons longue distance industrielles, RS-485 et Modbus RTU restent inégalés en tolérance au bruit jusqu'à 1200 m, et pour les architectures véhicule ou machine, CAN-FD selon ISO 11898-1:2024 conserve l'avantage de l'arbitrage non destructif et du déterministe temporel. I3C cible spécifiquement la zone capteurs courte distance (moins de 30 cm typiquement) où il surpasse à la fois UART, SPI et I²C en densité d'intégration. Pour un bus terrain industriel mixte capteurs et actionneurs distants, l'architecture pertinente combine I3C en local et CAN-FD ou RS-485 en lien longue portée, avec une passerelle MCU au point de jonction.

Concrètement, le choix de bus en application industrielle se cartographie ainsi : I3C pour les hubs de capteurs MEMS denses à courte portée, CAN-FD (matériel FDCAN sur STM32G4, STM32H7 ou similaire) pour la dorsale véhicule ou machine, CANopen selon CiA 301 pour l'automation industrielle de robots et de machines-outils, J1939 pour les engins lourds et utilitaires, ISO-TP (ISO 15765-2) pour les diagnostics et l'OTA en CAN, et RS-485 / Modbus RTU pour le terrain longue portée. La couche transport ISO-TP est notamment incontournable dès que le payload diagnostic dépasse les 8 octets d'une trame CAN classique. Côté futur, CAN-XL selon ISO 11898-1:2024 monte jusqu'à 10 Mbit/s et 2048 octets de payload, comblant l'écart historique entre CAN-FD et Ethernet TSN.

Pièges de conception I3C à anticiper

Six pièges récurrents méritent une attention particulière dès la phase d'architecture. La plupart sont faciles à éviter avec une checklist, mais coûtent un respin de PCB ou deux semaines de debug firmware s'ils passent en production.

• Mismatch de signalisation 1,8 V / 3,3 V : mélanger un MEMS I3C 1,8 V avec un microcontrôleur 3,3 V sans level-shifter dédié cuit les protections ESD du composant sensible. Toujours vérifier la tension VIL/VIH dans la datasheet, pas seulement la compatibilité protocolaire.
• Pull-up unique mal placée : contrairement à I²C, la pull-up I3C doit être connectée au rail de signalisation effectif (1,8 V ou 3,3 V selon le mode), pas systématiquement à VCC. Une pull-up sur 3,3 V avec des esclaves 1,8 V génère des violations de spécification invisibles à l'oscilloscope classique.
• Absence de GETCAPS avant HDR-DDR : activer HDR-DDR sans vérifier que tous les esclaves du bus le supportent provoque des blocages sporadiques. La discipline est de demander GETCAPS à l'init puis de sélectionner le mode le plus rapide commun.
• Hot-join non désarmé en mode production : laisser hot-join activé en production sur un bus scellé dégrade la robustesse CEM (un événement ESD peut déclencher une tentative de join fantôme). Désarmer via DISEC après l'énumération initiale.
• Interprétation erronée des IBI priority : les IBI sont priorisées selon l'adresse dynamique, pas selon la criticité métier. Assigner les adresses basses aux capteurs critiques dès l'ENTDAA.
• Oubli du LVR (Legacy Virtual Register) pour composants mixtes : un esclave I²C legacy non déclaré en LVR est vu comme un candidat I3C, ce qui corrompt l'ENTDAA. Toujours provisionner la liste des esclaves legacy dans le driver maître.

Nous tenons à jour une checklist de revue de schéma I3C interne, alignée sur la spécification MIPI I3C Basic v1.1.1. Cette checklist est partagée en audit gratuit 30 minutes pour les projets qui passent par notre bureau d'études électronique.

FAQ : Bus I3C en Conception Électronique

Cette FAQ I3C reprend les questions récurrentes posées en phase d'architecture. Les réponses s'appuient sur la spécification MIPI I3C Basic v1.1.1.

I3C est-il vraiment compatible avec mes composants I²C existants ?
Oui, à trois conditions : tension de signalisation commune (3,3 V si vous mélangez du legacy I²C), bus en mode SDR maximum lorsqu'un esclave I²C est adressé, et déclaration du composant legacy dans le Legacy Virtual Register (LVR) du driver maître. Sous ces conditions, un bus mixte fonctionne nativement.

Quelle est la différence concrète entre I3C SDR et HDR-DDR ?
SDR échantillonne sur un seul front d'horloge à 12,5 MHz pour 12,5 Mbit/s utiles. HDR-DDR double la cadence en échantillonnant sur les deux fronts pour 25 Mbit/s. HDR-DDR demande que tous les esclaves du bus le supportent, vérifiable via le CCC GETCAPS à l'init.

Quand choisir SPI plutôt que I3C pour un capteur haute cadence ?
SPI reste préférable si vous avez un seul capteur en point-à-point à très haut débit (40 Mbit/s et plus), ou si votre microcontrôleur n'a pas de contrôleur I3C natif. I3C gagne dès que vous avez plus de deux capteurs à adresser et que vous voulez des IBI ou du hot-join.

Les microcontrôleurs STM32 supportent-ils I3C ?
Oui pour les familles STM32H5, STM32U5 et STM32H7 récentes, qui intègrent un contrôleur I3C compatible v1.1.1 avec support SDR et HDR-DDR. La HAL STMicroelectronics expose les CCC principaux, et Zephyr offre un pilote portable cross-vendor. Les anciennes familles STM32F4/F7 restent limitées à I²C.

Faut-il deux pull-ups comme en I²C ?
Non, une seule pull-up sur SDA suffit en I3C pur. SCL est piloté en push-pull actif par le maître. Si le bus est mixte avec des esclaves I²C legacy, une pull-up sur SCL peut rester utile pour garantir la rétrocompatibilité, mais ce n'est pas obligatoire sur un bus I3C natif.

I3C consomme-t-il vraiment moins que I²C ?
Oui, sur un bus typique. Les raisons : signalisation 1,8 V au lieu de 3,3 V (puissance dynamique divisée par trois pour une même capacitance), push-pull actif qui supprime les pertes résistives dans les pull-ups, et débits supérieurs qui réduisent le temps de bus actif pour un même volume de données.

Articles Connexes

Pour approfondir votre projet de communication embarquée et la conception PCB associée :

• Bus I²C : fonctionnement et bonnes pratiques : le prédécesseur d'I3C, toujours pertinent pour les designs legacy.
• Bus SPI : alternative full-duplex haute vitesse : comparatif utile avec I3C sur les capteurs MEMS point-à-point.
• Bus UART : communication série asynchrone : complète la famille des protocoles série pour produits embarqués.
• Accéléromètres MEMS : guide d'intégration : cas d'usage typique d'un bus I3C à haute cadence.
• Conception PCB high-speed : intégrité du signal sur les bus rapides, incluant I3C HDR-DDR.