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

Un 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 devenu la voie d’évolution naturelle en 2026.

Chez AESTECHNO, avec plus de 10 ans de conception de cartes embarquées autour de microcontrôleurs STM32 et Nordic nRF, nous intégrons ce protocole sur des produits industriels depuis la sortie des premiers MEMS compatibles (STMicroelectronics LSM6DSO32X, Bosch BMI323). Nous avons constaté, selon Bosch Sensortec, que les capteurs MEMS modernes saturent le budget horodatage d’un bus I²C Fast-mode Plus dès que l’on dépasse 3 à 4 axes échantillonnés au kHz. Le nouveau bus résout ce plafond 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 rencontrés sur nos projets en 2024 et 2026.

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, d’après Intel qui participe au comité MIPI et implémente la norme dans ses plateformes serveurs et embarqués, à trois besoins devenus critiques depuis 2024 : la densification des capteurs MEMS autour des microcontrôleurs (jusqu’à 32 IMU sur un seul hub selon les architectures récentes), 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 remplaçant de fait d’I²C dans les produits conçus après 2024.

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 divisant la consommation dynamique d’un facteur trois à cinq 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.

Chez AESTECHNO, nous avons constaté que 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.

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 Basic. Le mode SDR (Single Data Rate) atteint 12,5 Mbit/s et couvre 90 pourcent des cas d’usage capteurs. Les modes HDR (High Data Rate) doublent ou triplent ce débit pour les applications de streaming audio, image ou inertiel multi-axes échantillonné à plusieurs kHz.

Le mode HDR-DDR est, comme le souligne Lattice Semiconductor éditeur de hubs commerciaux, le plus simple à implémenter côté esclave car il réutilise le cablage SDR en échantillonnant sur les deux fronts d’horloge. Les modes HDR-TSL (Ternary Symbol Legacy) et HDR-TSP (Ternary Symbol Pure) encodent deux ou trois bits par transition pour atteindre 33 à 40 Mbit/s effectifs, au prix d’une complexité matérielle supérieure qui limite leur adoption aux SoC multimédias.

Mode	Débit utile	Cas d’usage typique
SDR	12,5 Mbit/s	Capteurs MEMS, environnementaux, PMIC, EEPROM
HDR-DDR	25 Mbit/s	IMU 6 ou 9 axes à 6,4 kHz, hubs capteurs denses
HDR-TSL	33 Mbit/s	Streaming audio MEMS, buffer capteurs
HDR-TSP	40 Mbit/s	SoC multimédias, interfaces display haute cadence

Pour nos projets, 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 saturait à 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. Un tiers des designs multi-IMU en I²C nécessitent, selon Renesas qui documente le problème dans ses notes d’application sur les hubs capteurs, 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éinitialise 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.

Chez AESTECHNO, nous avons déployé ces deux mécanismes sur un projet de monitoring vibratoire industriel avec huit capteurs enfichables sur backplane. L’économie en broches de MCU nous a permis de choisir un microcontrôleur plus compact, et l’ergonomie de mise en service hot-join a réduit le temps d’intervention terrain d’un facteur deux.

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. Dans nos projets, nous privilégions 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 95 pourcent 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é).

Selon Microchip, les MCU de la gamme PIC32CM Ls supportent nativement la bascule dynamique de mode sur le bus I3C, ce qui facilite les designs hybrides. La documentation constructeur 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 à 6,4 kHz sur six axes, soit 38 kéchantillons/s de 16 bits à transporter, ce qui représente 612 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, la famille Bosch BME688 (température, humidité, pression, gaz) existe en version I3C native depuis 2024. Selon Bosch Sensortec, un réseau d’équipements de métrologie avec douze BME688 sur un même bus I3C tient dans un budget horodatage de 100 ms, contre 800 ms minimum sur un équivalent I²C. Notre bureau d’études l’a validé sur un produit de métrologie d’air intérieur certifié CE RED, avec un routage conforme aux règles d’intégrité de signal documentées dans notre guide sur le PCB high-speed.

En power management, les PMIC modernes (Qualcomm PM8350C, Renesas RAA215300) exposent leurs registres de configuration via I3C 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 la consommation dynamique de trois à cinq fois 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 lancé après 2024 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.

Pièges de conception et retour d’expérience AESTECHNO

Nos projets depuis 2024 sont à l’origine d’une liste de six pièges récurrents qui 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 et sur les retours d’expérience de nos intégrations STM32, Nordic et NXP. 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 par nos clients en phase d’architecture, issues d’une dizaine de projets de hubs capteurs et de power management depuis 2024. Les réponses s’appuient sur la spécification MIPI I3C Basic v1.1.1 et sur notre pratique terrain.

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, d’un facteur trois à cinq 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.