Das neue I3C-Protokoll - Würdiger I2C-Nachfolger oder viel Rauch um Nichts?

Zum Verständnis der Möglichkeiten und Grenzen müssen wir uns daran erinnern, dass der I²C-Bus erst seit dem Auslaufen der von Philips gehaltenen Patente eine komplett freie Technologie ist. Zwar hat NXP als Nachfolger der Halbleitersparte von Philips noch geistige Eigentumsrechte am Logo und dem Namen, aber sonst kann die Technologie von jedermann frei verwendet werden.

Auch wenn die Debatte um I²C vs. TWI mittlerweile so gut wie verstummt ist, finden sich im Internet, noch interessante, nach folgendem Schema aufgebaute Hinweise: „The concept behind the license fee was to insure that people who claimed they were making I2C silicon (and selling it as I2C silicon) were supporting the standard and thus helping to grow the standard.“

Diese sich mit der Erinnerung des Autors deckenden Ergebnisse zeigen, dass das Ziel von Philips immer war, durch die Erhebung der Lizenzgebühren die Lizenznehmer zu animieren, den I²C-Standard auch vollständig zu implementieren. Darunter verstand man explizit auch ein Glitch- beziehungsweise Spikefilter, das in der Vergangenheit ein häufiger Streitpunkt zwischen Philips Semiconductor und Drittherstellern war. Dieses Filter (wir kommen hierauf noch zurück) dürfte einer der Gründe sein, warum Philips einst überhaupt mit der Eintreibung von Lizenzgebühren begann. Mit dem Auslaufen der Philips-Patente war allerdings die freie Jagd eröffnet.

Die Interoperabilität von I²C-Geräten in einem I3C-Bussystem kann leider nur als Best Practice oder frommer Wunsch angesehen werden. Praktische Tests solcher Mischsysteme sind deshalb in jedem Fall erforderlich. Doch schauen wir uns zunächst an, wer oder was hinter dem I3C-Standard steckt!
 

I3C und die MIPI Alliance

Hinter dem I3C-Standard steht ein als MIPI Alliance, bezeichnetes Standardisierungsgremium, das diverse Standards für allgemeine Elektronik anbietet. Für die Mitgliedschaft fallen nicht unerhebliche Gebühren an, wie die gut versteckte Gebührenliste zeigt (Bild 1).

Im Interesse maximaler Adoption bietet das Standardisierungsgremium im Fall von I3C eine Basis-Variante der Spezifikation komplett kostenlos an. Auf dieser Website findet sich eine Liste „fortgeschrittener“ Funktionen, deren Nutzung auf jeden Fall eine Mitgliedschaft in der MIPI voraussetzt. Auf dieser Seite erfahren wir auch, dass die Abkürzung I3C für Improved Inter Integrated Circuits steht. Nach Ansicht des Autors dürfte man sich bei der Nutzung von I3C in einer kommerziellen Schaltung nur dann „Ärger“ mit der MIPI einhandeln, wenn das Interface auf die eine oder andere Art selbst realisiert wird (Stichwort FPGA oder Bit Banging). Verwenden Sie hingegen ausschließlich gekaufte Bausteine (und nutzen das I3C-Logo und den Namen nicht in der Außenwerbung), so dürften keinerlei Probleme zu erwarten sein.
 

Abschied vom Open Drain ...

Der I²C-Bus erfreut den Entwickler seit jeher mit Ärgernissen: Erstens ist immer fraglich, wo die für das Aufladen der Bus-Kapazität notwendigen Pull-Up-Widerstände untergebracht werden. Zweitens ist es im Allgemeinen nicht möglich, vom nicht-taktgenerierenden Baustein aus Interrupts auszulösen. Möchte man einem „taktschnüffelnden“ Gerät (siehe Kasten) die Möglichkeit zum Absenden von Interrupts geben, so ist bei I²C in jedem Fall eine zusätzliche Verbindung erforderlich. Hat man einige Sensoren im Feld, so geht dies auf Kosten des GPIO-Budgets beim taktemittierenden Baustein.

Nettigkeit Numero drei ist die vergleichsweise geringe Geschwindigkeit: Philips nennt (bei einer Arbeitsfrequenz von 3,4 MHz) eine Wortrate von 3 Mbps. Daraus folgt, dass die gemächliche Vorgehensweise der Transceiver zu einem hohen Energieverbrauch führt, denn wenn der Datenaustausch zwischen zwei Geräten länger dauert, können diese auch erst später in einen energiesparenden Stand-by-Modus fallen. Das Diagramm (Bild 2) der MIPI ist nach Ansicht des Autors recht glaubhaft.

Zu guter Letzt besitzen I²C-Geräte die fatale Möglichkeit, die Busteilnehmer „auf ewig“ abzuschalten. Ein entsprechendes Schaltungsdetail wie in Bild 3 findet sich in mehr als nur einem I²C-System!

... bringt Verbesserungen in der I3C-Welt

Die erste Änderung von I3C ist, dass sowohl SCL als auch SDA in den meisten Fällen im Push-Pull-Betrieb arbeiten. SCL ist dabei immer ein Push-Pull-Pin, während der SDA-Pin in manchen Zuständen auch in den Open-Drain-Betrieb wechselt. Zur Vermeidung diverser Probleme bei der Platzierung der Pull-Up-Widerstände gibt der Standard an dieser Stelle vor, dass diese stets im taktgenerierenden Gerät unterzubringen sind.

Wichtig ist dabei, dass SCL immer (Sonderfälle wollen wir an dieser Stelle auslassen) und ausschließlich vom taktgenerierenden Element gesteuert wird. Sofern sich mehrere potentielle Taktgeneratoren in einem Bus befinden, obliegt das Schalten des SCL-Pins dem Taktgenerator, der im aktuellen Zustand aktiv ist.

Das im klassischen I²C-Bus mögliche Clock Stretching durch den Slave wird in der Spezifikation von I3C nicht unterstützt. Deshalb ist der Betrieb solcher Bausteine in einem gemischten Bus nicht möglich. Andererseits sind dem Autor in der Praxis nur höchst wenige Anwendungsfälle des Clock Stretchings bekannt.

Mit dieser Vereinfachung geht auch eine Vereinfachung der I/O-Pins auf Seiten der Mikrocontroller beziehungsweise der Taktgeneratoren einher. Während I²C wegen des in der Einleitung schon erwähnten 50-ns-Spike-Filters dedizierte GPIOs benötigen, setzt die MIPI-Spezifikation gewöhnliche GPIO-Pins voraus, die nur zum Treiben von 4 mA Strom befähigt sein müssen. In der Spezifikation ist explizit auch angeführt, dass die im Fall von I²C oft „haarigen“ Spikefilter nicht erforderlich sind.
 

Der Lohn der Schnelligkeit

Im nächsten Schritt wollen wir uns der eigentlichen Signalform zuwenden. Das in diesem Artikel schon mehrfach erwähnte Glitchfilter kommt auch bei I3C insofern zum Einsatz, als das SCL-Signal in einem I3C-Bus nicht mehr wie bei I²C ein Tastverhältnis von 50 % aufweist. Die High-Periode ist stattdessen mit kürzer als 45 ns deklariert (Bild 4), was logischerweise dazu führt, dass ein mit dem Standard konformer implementierter I²C-Chip mit diesen Wellenformen nichts anzufangen weiß.
 

Nach dem Eintreffen einer solchen „unsichtbaren“ SCL-Transaktion kann der Taktgenerator seinen SDA-Pin beziehungsweise die SDA-Leitung ebenfalls in den Push-Pull-Modus umschalten und die Arbeitsfrequenz des Busses auf bis zu 12,5 MHz erhöhen. In einem derartigen Volllast-Betrieb wird laut MIPI-I3C-Spezifikation eine Übertragungsrate von bis zu 12,5 Mbps erreicht.

Höhere Übertragungsraten erreicht I3C in einem der drei HDR-Modi (High Data Rate), die allerdings nur in den zwei Sonderfällen verwendet werden dürfen, nämlich einerseits im als Pure I3C Bus bezeichneten Bus-System, das ausschließlich aus I3C-Bausteinen besteht, andererseits im so genannten Mixed Fast Bus, an den auch I²C-Bausteine angeschlossen sein dürfen, die dann allerdings - Sie hätten es fast erraten - eine spezifikationsgemäße Implementierung des Glitchfilters aufweisen müssen.

Die HDR-Modi werden durch eine spezielle Sequenz aus SCL-Pulsen bei in Ruhe befindlicher SDA-Leitung eingeleitet. Der einfachste Modus ist HDR-DDR, der bis zu 25 Mbps erreicht. Der Trick dabei ist, dass jede Flanke des SCL-Signals einen gültigen Trigger zur Entgegennahme von Informationen darstellt. Der Modus HDR-TSP (dahinter verbirgt sich Ternary Symbol Pure) erreicht gut 30 Mbps. Hier wird eine simultane Übertragung von Informationen unter Nutzung der Pins SCL und SDA erreicht. Mit HDR-TSL (kurz für Ternary Symbol Legacy-inclusive-bus mode) steht noch ein Sonderregime zur Verfügung, das TSP für Mixed-Busse bekömmlicher macht.
 

Automatische Adresszuweisung

Ein weiteres Ärgernis bei I²C-Systemen ist, dass die Zuweisung der Adressen der einzelnen Bauteile normalerweise „physisch“ erfolgen muss. Im Fall vieler Bauteile – der in Bild 5 gezeigte HDC2010 ist dafür ein gutes Beispiel – führt dies dazu, dass der volle im Standard angebotene Adressraum nur teilweise nutzbar ist.
 

Statt des bei I²C möglichen 10-Bit-Adressmodus bietet I3C als Ersatz eine dynamische Selbstkonfiguration an. Zudem steht mit I3C-Hot-Join ein System zur Verfügung, das ein an USB erinnerndes „Hot Plugging“ von I3C-ICs an den Bus ermöglicht.

Im Hintergrund kommt dabei ein als Address arbitration bezeichnetes Verfahren zum Einsatz, das sich um die Zuweisung von Adressen an Slaves kümmert. Hierzu enthalten I3C-Endgeräte drei Werte: Neben zwei je acht Bit langen Feldern mit Statusinformationen gibt es eine 48 Bit lange unique ID. Die Spezifikation geht dabei davon aus, dass jede der als Provisional ID bezeichneten UUIDs in einem Bus einzigartig ist.

Während des Startens des I3C-Busses muss der Taktgenerator alle im Bus befindlichen Geräte finden und ihnen die als Dynamic Address zugewiesenen Adressen zuweisen. Dabei kommt eine Vorgehensweise zum Einsatz, die an den von I²C bekannten Arbitrationsprozess erinnert: Derjenige unprovisionierte I3C-Baustein „gewinnt“, der den niedrigsten UUID-Wert aufweist. Der Taktgenerator führt mehrere Vergaberunden durch, bis alle am Bus befindlichen Geräte eine Temporary ID besitzen.
 

Adoption des Standards durch Hersteller

Besucht man die Liste von MIPI-Mitgliedern, so findet man ein Who is Who der Halbleiterhersteller; von GigaDevice über ST zu Solomon Systech: So gut wie alle einschlägigen Unternehmen sind vertreten. Vertieft man die Suche allerdings nach praktisch verfügbaren Bauteilen, so wird die Suppe schnell dünn. Bei Mouser finden sich derzeit beispielsweise nur Bauteile wie der von Dialog angebotene PI3CSW12. Bild 6 zeigt, dass sich diese Produkte durch die Bank um Multiplexing und Signalkonditionierung kümmern.

Im Hause Renesas entschied man sich mit Chips wie dem IMX3102 zunächst für eine ähnliche Vorgehensweise. Zudem findet sich im Rahmen der Ankündigung folgende Aussage: „I3C’s 12.5 MHz speeds significantly outpace current and legacy solutions, such as the I2C 1 MHz speed and analog passive quick switches.“

Sucht man nach Mikrocontrollern mit I3C-Support, so ist die Liste gar sehr kurz: NXP ist mit dem i.MX RT685 derzeit der einzige Spieler auf dem Markt. Unter der Nummer AN12796 findet sich eine Application Note, die die Software illustriert. Außerdem bietet NXP einen teilweise kostenlosen Softcore an, gibt es sogar eine Sonderlizenz für Nicht-MIPI-Mitglieder. Ist man bereit, Geld für das Softcore-IP (Intellectual Property) auszugeben, so bieten Anbieter wie Silvaco oder Arasan Chip Systems schlüsselfertige I3C-VHDL-Module an.

Displays mit I3C – in der Spezifikation nennt man diesen Anwendungsfall immer wieder – sucht der geneigte Nutzer derzeit ebenfalls vergebens. Physische Hardware liegt im Moment nur in Form einiger Accelerometer vor: Bosch bietet den BMI263 an, während STM den LSM6DSO und den Drucksensor LPS22HH ins Rennen schickt.

Interessanterweise sieht es im Bereich Software erfreulicher aus: Hier findet man eine vergleichsweise detailliert ausformulierte Beschreibung des im Linux-Kernel implementierten Interfacetreibers.
 

Wie lange wird es dauern?   

Sowohl wegen der höheren Datenrate als auch der Möglichkeit zum Abfeuern von Interrupts ohne dedizierte GPIO-Eingänge dürfte I3C über kurz oder lang Freunde in der gesamten Industrie finden. Fraglich ist allerdings, wie viel Zeit dieser Prozess in Anspruch nimmt. Da es derzeit kaum Mikrocontroller mit passender I3C-Peripherie gibt, wird nach Ansicht des Autors noch einige Zeit ins Land gehen.
 

Sie haben Fragen oder Kommentare?  

Haben Sie technische Fragen oder Kommentare zu diesem Artikel? Dann kontaktieren Sie bitte den Autor unter tamhan@tamoggemon.com oder die Elektor-Redaktion unter redaktion@elektor.de.

 
210640-02 (geplante) Veröffentlichung in Elektor März/April 2023
Übersetzung: Rolf Gerstendorf