I3C – No Typo – Veut être votre bus série

Vous vous souvenez des vieux disques durs avec leurs câbles plats géants ? Ils sont passés en série et maintenant les câbles d’alimentation sont bien plus épais que les câbles de données. Nous avons vu la même chose dans les appareils embarqués. De nos jours, parler entre puces a tendance à utiliser I2C ou SPI ou une variante de ceux-ci pour envoyer et recevoir des données sur une poignée de broches. Mais maintenant, il y a I3C, une norme industrielle relativement nouvelle qui gagne du terrain.

I2C et SPI sont matures mais ils ont des problèmes. I2C peut être relativement lent et SPI nécessite généralement des broches supplémentaires pour chaque appareil. En outre, la prise en charge de l’ajout et de la suppression dynamique d’appareils ou de la découverte automatique d’appareils est médiocre.

I3C, créé par l’Alliance MIPI, vise à résoudre ces problèmes. Il utilise les deux fils habituels, SCL pour l’horloge et SDA pour les données. Un appareil agit comme un contrôleur. Les autres appareils peuvent être des cibles ou des contrôleurs secondaires. Il est également rétrocompatible avec les appareils cibles I2C. Selon la façon dont vous l’implémentez, les vitesses peuvent être assez rapides avec une vitesse brute de 12,5 Mbps et l’utilisation de techniques de codage de ligne peut aller jusqu’à environ 33 Mbps.

Pas I2C

Le bus ressemble à un bus I2C typique, mais l’adressage est dynamique, à l’exception des périphériques I2C hérités qui utilisent toujours leur adresse normale. En d’autres termes, le contrôleur attribue des adresses aux appareils qu’il trouve sur le bus. Les appareils hérités ne peuvent pas utiliser l’adressage étendu. Vous pouvez également connecter des appareils sans arrêter le bus. Il existe une capacité pour les messages de diffusion, les opérations multiples et les interruptions dans la bande. Il possède également des fonctionnalités spécifiques pour les conceptions nécessitant un fonctionnement à faible consommation d’énergie. En plus de spécifier la connexion physique entre les périphériques, il existe également une spécification pour l’interface du contrôleur hôte. Cela signifie que le logiciel a une interface standard pour communiquer avec le contrôleur et le bus.

Il existe diverses façons d’augmenter le débit de données, bien que certaines exigent qu’aucun périphérique I2C hérité ne soit installé sur le bus. Par exemple, lorsque vous parlez à un appareil cible, il est possible de convenir d’utiliser un schéma à double débit de données où les données apparaissent sur les deux bords de l’horloge. Il existe également un moyen de conscrire les deux lignes pour utiliser un codage en base 3 dans un schéma d’auto-synchronisation. L’idée est que deux bits peuvent coder n’importe lequel des quatre états. A partir de chaque état, il existe trois valeurs suivantes possibles. Ainsi, chaque transition fournit une base à 3 chiffres contenant plus de données dans le même laps de temps par rapport à un schéma traditionnel.

Malheureusement, la spécification complète n’est disponible que pour les membres du MIPI. Cependant, vous pouvez télécharger la spécification de base. Ceci, malheureusement, documente un sous-ensemble de toutes les fonctionnalités disponibles. Par exemple, seuls les débits de données simples et doubles apparaissent dans la spécification publique. Cependant, les hôtes et les appareils négocieront, il est donc possible de faire coexister un appareil qui, par exemple, ne parle que SDR avec d’autres appareils qui veulent faire quelque chose de plus exotique.

Rien de simple

Si vous voulez essayer d’implémenter tout cela, c’est beaucoup plus de travail que de modifier une interface SPI. Par exemple, consultez la transaction d’allocation dynamique d’adresses sur le bus, qui contourne également les allocations statiques, y compris celles des périphériques I2C.

Transaction pour la configuration de l’adressage dynamique

La possibilité de joindre des appareils pendant que le bus est en fonctionnement est un autre problème complexe. Si vous voulez juste garder une partie d’une carte hors tension, c’est probablement assez facile. Mais si vous voulez littéralement brancher quelque chose, vous devrez trouver comment le faire sans perturber électriquement le bus en action.

Bien que la spécification publique ne soit pas tout, elle pèse tout de même près de 450 pages ! Il y a beaucoup à digérer. On ne sait pas non plus quelle est la motivation pour implémenter cela vous-même dans un logiciel. Il y a un peu un problème de dragon et d’œuf ici : la plupart des processeurs ne prennent pas en charge I3C par défaut car il n’y a pas beaucoup d’appareils qui l’utilisent. Mais jusqu’à ce qu’il y ait plus de processeurs qui le prennent en charge, pourquoi construire des appareils ?

En pratique

Ce ne sera peut-être pas le cas à l’avenir. Mais pour la plupart d’entre nous, la question est de savoir quels appareils utilisent ce protocole aujourd’hui ? Le noyau Linux dispose d’un pilote I3C et il existe quelques périphériques. NXP, par exemple, répertorie quelques produits avec I3C, avec quelques capteurs de température « à venir ». Ils proposent également plusieurs processeurs ARM avec des périphériques I3C, tels que le LPC553x. Microchip a le PIC18-Q20 qui peut servir de cible, mais pas de contrôleur. De plus, Renesas, ST, TI et une poignée d’autres fournisseurs proposent quelques dispositifs cibles I3C allant des puces IMU 6 axes aux capteurs de température. Si vous avez un analyseur logique Saleae, vous pouvez obtenir un micrologiciel qui vous aidera à lire I3C.

Analyseur logique Saleae décodant I3C avec un plugin tiers

Va-t-il s’accrocher? Peut-être. À mesure que les processeurs embarqués bon marché deviennent plus puissants, il y a moins de raisons de s’en tenir à des protocoles simples. Cependant, il y a quelque chose de gratifiant à savoir que vous pourriez écraser votre bus UART ou SPI en quelques heures de codage amusant si vous le deviez. Avec I3C, vous allez probablement compter sur un périphérique embarqué pour faire tout le gros du travail. Et puis, s’ils deviennent courants, pourquoi pas ?

François Zipponi
Je suis François Zipponi, éditorialiste pour le site 10-raisons.fr. J'ai commencé ma carrière de journaliste en 2004, et j'ai travaillé pour plusieurs médias français, dont le Monde et Libération. En 2016, j'ai rejoint 10-raisons.fr, un site innovant proposant des articles sous la forme « 10 raisons de... ». En tant qu'éditorialiste, je me suis engagé à fournir un contenu original et pertinent, abordant des sujets variés tels que la politique, l'économie, les sciences, l'histoire, etc. Je m'efforce de toujours traiter les sujets de façon objective et impartiale. Mes articles sont régulièrement partagés sur les réseaux sociaux et j'interviens dans des conférences et des tables rondes autour des thèmes abordés sur 10-raisons.fr.