I²C, für englisch Inter-Integrated Circuit, im Deutschen gesprochen als I-Quadrat-C oder englisch I-Squared-C (ˈaɪ skwɛərd ˈsiː) oder I-2-C (ˈaɪ tuː ˈsiː), ist ein 1982 von Philips Semiconductors (heute NXP Semiconductors) entwickelter serieller Datenbus, der sich zwischenzeitlich zu einem weithin akzeptierten Industriestandard entwickelt hat. Er wird hauptsächlich geräteintern für die Kommunikation zwischen verschiedenen Schaltungsteilen benutzt, z. B. innerhalb eines Fernsehgerätes oder zwischen einem Controller und Peripherie-ICs.

Der Bus wurde 1982 von Philips eingeführt zur geräteinternen Kommunikation zwischen ICs in z. B. CD-Spielern und Fernsehgeräten. Dazu wurde die Mikrocontroller-Familie MAB8400 entwickelt, die einen I²C-Bus-Controller enthielt. Die erste standardisierte Spezifikation 1.0 wurde 1992 veröffentlicht. Diese ergänzte den ursprünglichen Standard mit 100 kbit/s um einen neuen „schnellen“ Modus (Fast-mode) mit 400 kbit/s und erweiterte den Adressraum um einen 10-Bit-Modus, so dass statt der ursprünglichen 112 Knoten seitdem bis zu 1136 unterstützt werden.

Seit Mitte der 1990er Jahre wird I²C auch von einigen Wettbewerbern zur Bezeichnung von Philips-kompatiblen I²C-Systemen verwendet, darunter Siemens AG (später Infineon Technologies AG), NEC, STMicroelectronics, Motorola (später Freescale, heute auch NXP), Intersil etc. Bis zum Jahr 1998 wurde I²C in mehr als 1000 verschiedenen IC-Typen implementiert und an 50 Firmen lizenziert.^[1]

Atmel führte aus lizenzrechtlichen Gründen die heute auch von einigen anderen Herstellern verwendete Bezeichnung TWI (Two-Wire-Interface, englisch für Zweidraht-Schnittstelle)^{[Anm. 1]} ein; technisch sind TWI und I²C praktisch^{[Anm. 2]} identisch.^[2] Allerdings ist das ursprüngliche Patent am 1. Oktober 2006 ausgelaufen, so dass keine Lizenzgebühren für die Benutzung von I²C mehr anfallen. I²C ist auch kein eingetragenes Markenzeichen von NXP Semiconductors, Markenschutz besteht lediglich für das Logo.

Mit Version 2.0 aus dem Jahr 1998 kam ein „Hochgeschwindigkeitsmodus“ (Hs-mode) mit max. 3,4 Mbit/s dazu, wobei die Strom- und Spannungsanforderungen in diesem Modus gesenkt wurden. Version 3.0 von 2007 führte einen weiteren Modus „Fast-mode Plus“ (Fm+) mit bis zu 1 Mbit/s ein, der im Gegensatz zum Hs-mode dasselbe Protokoll verwendet wie die 100- und 400-kbit/s-Modi.

Im Jahr 2012 wurde mit der Spezifikation Version 4 ein noch schnellerer Modus „Ultra Fast-mode“ (Ufm) eingeführt, der unidirektionale Übertragungsraten bis zu 5 Mbit/s unterstützt. Einige Fehler wurden mit der Version 5 im selben Jahr bzw. der Version 6 im April 2014 korrigiert.^[3]

Im Jahr 2021 wurden in der gesamten Spezifikation die Begriffe „Master“ und „Slave“ (englisch für Herr und Sklave) ersetzt durch „Controller“ bzw. „Target“ (englisch für Steuereinheit bzw. Ziel). Damit sollen die früheren Ausdrücke vermieden und gleichzeitig die Wortwahl an den teilweise rückwärtskompatiblen I3C-Bus („Improved Inter Integrated Circuit“-Bus) der MIPI Alliance angeglichen werden.^[1]

I²C ist als Master-Slave-Bus konzipiert. Ein Datentransfer wird immer durch einen Master (Controller) initiiert; der über eine Adresse angesprochene Slave (Target) reagiert darauf. Mehrere Controller sind möglich (Multi-Controller-Betrieb). Wenn im Multi-Controller-Betrieb ein Controller-Baustein auch als Target arbeitet, kann ein anderer Controller direkt mit ihm kommunizieren, indem er ihn als Target anspricht.

Im Diagramm rechts sind drei Geräte eingezeichnet. I²C benötigt zwei Signalleitungen: Takt- (SCL = Serial Clock) und Datenleitung (SDA = Serial Data). Beide liegen mit den Pull-up-Widerständen R_P an der Versorgungsspannung V_DD. Sämtliche daran angeschlossene Geräte haben Open-Collector-Ausgänge, was zusammen mit den Pull-up-Widerständen eine Wired-AND-Schaltung ergibt. Der High-Pegel soll mindestens 0,7 × V_DD betragen, und der Low-Pegel soll bei höchstens 0,3 × V_DD liegen. Die im Bild nicht eingezeichneten Serienwiderstände R_S an den Eingängen der Geräte sind optional und werden als Schutzwiderstände verwendet. Der I²C-Bus arbeitet mit positiver Logik, d. h. ein High-Pegel auf der Datenleitung entspricht einer logischen „1“, der Low-Pegel einer „0“.

Der Bustakt wird immer vom Controller ausgegeben. Das Taktsignal liegt nicht ständig an, sondern nur während der Datenübertragung. Für die verschiedenen Modi ist jeweils ein maximal erlaubter Bustakt vorgegeben. In der Regel können aber auch beliebig langsamere Taktraten verwendet werden, falls diese vom Controller-Interface unterstützt werden. Einige ICs (z. B. Analog-Digital-Umsetzer) benötigen jedoch eine bestimmte minimale Taktfrequenz, um ordnungsgemäß zu funktionieren.

Wenn das Target mehr Zeit benötigt, als durch den Takt des Controllers vorgegeben ist, kann er zwischen der Übertragung einzelner Bytes die Taktleitung auf „low“ halten (Clock-Stretching) und so den Controller bremsen. In der Spezifikation einiger Target-Bausteine wird explizit erklärt, dass sie kein Clock Stretching anwenden. Dementsprechend gibt es auch Bustreiber-Bausteine, die so ausgelegt sind, dass sie das Taktsignal nur in eine Richtung übertragen können.^[4]

Daten (Einzelbits) sind nur gültig, wenn sich ihr logischer Pegel während einer Clock-High-Phase nicht ändert. Ausnahmen sind das Start-, Stop- und Repeated-Start-Signal. Das Start-Signal ist eine fallende Flanke auf SDA, während SCL high ist, das Stop-Signal ist eine steigende Flanke auf SDA, während SCL high ist. Repeated-Start sieht genauso aus wie das Start-Signal.

Eine Dateneinheit besteht aus 8 Datenbits = 1 Oktett (welche protokollbedingt entweder als Wert oder als Adresse interpretiert werden) und einem ACK-Bit. Dieses Bestätigungsbit (Acknowledge) wird vom Target durch einen Low-Pegel auf der Datenleitung während der neunten Takt-High-Phase (welche nach wie vor vom Controller generiert wird) und als NACK (für engl. not acknowledge) durch einen High-Pegel signalisiert. Das Target muss den Low-Pegel an der Datenleitung anlegen, bevor SCL auf high geht, andernfalls lesen weitere eventuelle Teilnehmer ein Start-Signal.

Eine Standard-I²C-Adresse ist das erste vom Controller gesendete Byte, wobei die ersten sieben Bit die eigentliche Adresse darstellen und das achte Bit (R/W-Bit) dem Target mitteilt, ob er Daten vom Controller empfangen soll (Low: Schreibzugriff) oder Daten an den Controller zu übertragen hat (High: Lesezugriff). I²C nutzt daher einen Adressraum von 7 Bit, was bis zu 112 Knoten auf einem Bus erlaubt (16 der 128 möglichen Adressen sind für Sonderzwecke reserviert).

Jedes I²C-fähige IC hat eine (üblicherweise vom Hersteller) festgelegte Adresse, von der in der Regel eine modellabhängige Anzahl der untersten Bits (LSB) über spezielle Eingangspins des ICs individuell konfiguriert werden können. Hierdurch wird es möglich, mehrere ICs dieses Typs am selben I²C-Bus zu betreiben, ohne dass es zu Adresskonflikten kommt. Lassen sich Adresskonflikte nicht vermeiden, so müssen die entsprechenden ICs mit getrennten I²C-Bussen angesteuert oder temporär vom Bus getrennt werden.

Wegen Adressknappheit wurde später eine 10-Bit-Adressierung eingeführt. Sie ist abwärtskompatibel zum 7-Bit-Standard durch Nutzung von 4 der 16 reservierten Adressen. Beide Adressierungsarten sind gleichzeitig verwendbar, was bis zu 1136 Knoten auf einem Bus erlaubt.

Der Beginn einer Übertragung wird mit dem Start-Signal vom Controller angezeigt, dann folgt die Adresse. Diese wird durch das ACK-Bit vom entsprechenden Target bestätigt. Abhängig vom R/W-Bit werden nun Daten byteweise geschrieben (Daten an Target) oder gelesen (Daten vom Target). Das ACK beim Schreiben wird vom Target gesendet und beim Lesen vom Controller. Das letzte Byte eines Lesezugriffs wird vom Controller mit einem NACK quittiert, um das Ende der Übertragung anzuzeigen. Eine Übertragung wird durch das Stop-Signal beendet. Alternativ kann auch ein Repeated-Start am Beginn einer erneuten Übertragung gesendet werden, ohne die vorhergehende Übertragung mit einem Stop-Signal zu beenden.

Alle Bytes werden dabei „Most Significant Bit First“ übertragen.

Für den High-Speed-Mode wird zuerst im Fast oder Standard Mode ein Master-Code geschickt, bevor auf die erhöhte Frequenz umgeschaltet wird. Dadurch wird zum einen der High-Speed-Mode signalisiert, zum anderen haben nicht High-Speed-taugliche Busteilnehmer die Chance, innerhalb ihrer Spezifikation zu erkennen, dass sie nicht angesprochen wurden. Im Multi-Controller-Betrieb muss jeder Buscontroller einen eigenen Master-Code benutzen. So ist sichergestellt, dass die Busarbitrierung (s. u.) abgeschlossen ist, bevor in den High-Speed-Mode gewechselt wird.

Die Arbitrierung (Zugriffsregelung auf den Bus) ist durch die Spezifikation geregelt: Der Bus ist zwischen Start- und Stoppsignal belegt. Bus-Controller müssen daher immer auf Start- und Stoppsignale achten, um den Überblick über den Busstatus zu behalten. So können sie warten, bis der Bus frei ist, sollte (evtl. unvorhergesehen) eine Übertragung anstehen.

Sollten mehrere Bus-Controller gleichzeitig mit einer Transaktion starten wollen, so sehen sie den Bus als frei an und starten gleichzeitig mit der Übertragung. Sind die Controller unterschiedlich schnell, erfolgt die Übertragung nun zunächst so schnell, wie der langsamste der beteiligten Bus-Controller arbeitet, da das Taktsignal eines langsameren Bus-Controllers per Clock-Stretching die schnelleren ausbremst. Alle Bus-Controller lauschen auf die von ihnen selbst gesendeten Daten. In dem Augenblick, wenn ein Bus-Controller eine „0“ und ein anderer eine „1“ übertragen will, nimmt die Bus-Leitung (aufgrund der Wired-And-Schaltung aller Busteilnehmer) „0“-Pegel an. Gemäß dem I²C-Protokoll verlieren in diesem Augenblick die Bus-Controller mit der „1“ den Bus, ziehen sich zurück und warten auf das Stoppsignal, um dann ihr Glück erneut zu versuchen. Die anderen Bus-Controller machen weiter, bis schließlich nur noch einer übrigbleibt. Sollte ein unterlegener Bus-Controller-Baustein auch Target-Dienste anbieten, muss er allerdings gleichzeitig darauf achten, ob der gewinnende Bus-Controller ihn gerade ansprechen will und daher gerade dabei ist, ihn zu adressieren.

Das Verfahren geht so weit, dass gar keine Arbitrierung stattfindet, wenn mehrere Bus-Controller zufällig – über mehrere Bytes hinweg von Anfang bis zum Abschluss ihrer jeweiligen Transaktionen hinweg – identische Daten an denselben Target-Baustein senden: Die betreffenden Bus-Controller merken nichts voneinander – eventuelles Clock-Stretching durch einen langsameren Controller ist gemäß Protokoll nicht von Clock-Stretching durch das Target zu unterscheiden; der angesprochene Target-Baustein kommuniziert mit den betreffenden Bus-Controllern gleichzeitig, ohne dass es von den Beteiligten bemerkt wird. Diese Tatsache ist zu berücksichtigen, und ihr muss, sofern sie sich störend auswirken könnte, anderweitig Abhilfe geschaffen werden.

Eine Eigenschaft von I²C ist die Tatsache, dass ein Mikrocontroller ein ganzes Netzwerk an integrierten Schaltungen mit nur zwei I/O-Pins und einfacher Software kontrollieren kann. Busse dieses Typs wurden realisiert, da ein nicht unerheblicher Teil der Kosten einer integrierten Schaltung und der verwendeten Leiterplatte von der Größe des Gehäuses und der Anzahl der Pins abhängt. Ein großes IC-Gehäuse hat mehr Pins, braucht mehr Platz auf der Leiterplatte und hat mehr Verbindungen, die versagen können. All das steigert die Produktions- und Testkosten.

Obwohl langsamer als neuere Bus-Systeme, ist I²C wegen des geringen Aufwands vorteilhaft für Peripheriegeräte, die nicht schnell zu sein brauchen. Häufig wird er für die Übertragung von Steuer- und Konfigurationsdaten verwendet. Beispiele sind Lautstärkeregler, Analog-Digital- oder Digital-Analog-Wandler mit niedriger Abtastrate, Echtzeituhren, kleine, nichtflüchtige Speicher oder bidirektionale Schalter und Multiplexer. Auch elektronische Sensoren haben oft einen Analog-Digital-Wandler mit I²C-Schnittstelle integriert.

Während des Betriebes können Chips zum Bus hinzugefügt oder entfernt werden (Hot-Plugging).

I²C wird auch als Basis für ACCESS.bus und VESAs Monitordaten-Interface (Display Data Channel, kurz DDC) benutzt. Der vom Prozessorhersteller Intel für die Kommunikation von Mainboard-Komponenten definierte SMBus ist dem I²C-Bus sehr ähnlich, die meisten ICs erlauben einen Betrieb an beiden Bussen.

Große Bedeutung hatte das I²C-Protokoll in der Vergangenheit im Chipkartenbereich. Die in Deutschland bis Ende 2014 verwendete Krankenversichertenkarte war eine I²C-Karte, d. h. unter den goldenen Kontaktflächen der Chipkarte befand sich ein einfaches I²C-EEPROM, das vom Kartenleser über das I²C-Protokoll ausgelesen und beschrieben werden konnte.

Das Protokoll des I²C-Bus ist von der Definition her recht einfach, aber auch recht störanfällig^[5]. Diese Tatsache schränkt die Verwendung auf störarme Umgebungen ein, wo weder mit Übersprechen, Rauschen, EMV-Problemen noch mit Kontaktproblemen (Stecker, Buchsen) zu rechnen ist. Auch ist er ungeeignet zur Überbrückung größerer Entfernungen, wie es beispielsweise für Feldbusse typisch ist.

Der Bus kann jedoch mit speziellen Treibern auf einen höheren Strom- oder Spannungspegel umgesetzt werden, wodurch der Störabstand und die mögliche Leitungslänge steigen. Ein noch größerer Störabstand ist durch eine Umsetzung auf den physikalischen Layer des CAN-Busses möglich, der mit differentiellen Open-Collector-Signalen arbeitet. Störungen sowohl des SDA- als auch des SCL-Signals resultieren in fehlerhaft übertragenen Daten, die vor allem bei Störungen auf SDA oft nicht erkannt werden können. Lediglich bei geringen, zeitlich begrenzten Störungen, z. B. weit oberhalb der Signalfrequenz, kann das System mittels Signalverarbeitung stabiler gemacht werden.

Die eigentliche I²C-Spezifikation beinhaltet (anders als die SMBus-Spezifikation) keinen Timeout; dadurch kann es unter bestimmten Umständen dazu kommen, dass Busteilnehmer den Bus blockieren. Falls ein Target-Chip gerade die Datenleitung auf „0“ zieht, während der Controller den Transfer (beispielsweise durch einen Reset) abbricht, bleibt die Datenleitung für unbestimmte Zeit auf „0“. Somit bleibt der gesamte I²C-Bus mit allen angeschlossenen Teilnehmern (Chips) blockiert. Daher sollen im Falle eines Resets auch alle Busteilnehmer zurückgesetzt werden, ggf. durch Unterbrechen der Spannungsversorgung.^[1] Alternativ wird ein Bus clear durchgeführt: Der Controller generiert bis zu neun Taktimpulse; spätestens dann sollte die Datenleitung freigegeben sein.^[1] Selbst wenn sich der Target-Baustein noch mitten in einer Übertragung befindet und die Datenleitung nur freigegeben ist, weil er gerade eine „1“ ausgibt, wird er (bzw. dessen I²C-Komponente) durch das nächste Start-Signal zurückgesetzt.^[1] Analog Devices empfiehlt, zunächst ein Stopp-Signal zu senden.^[6]

Die MIPI Alliance hat 2014 ein I3C genanntes, zu I²C teilweise abwärtskompatibles proprietäres und markenrechtlich geschütztes Interface vorgestellt.^[7] Es wird als Nachfolger von I²C propagiert.^[8] Es enthält Erweiterungen wie eine höhere Übertragungsgeschwindigkeit (High Data Rate – HDR) und kann damit bei mittleren Geschwindigkeiten auch das Serial Peripheral Interface (SPI) ersetzen.^[8] Der I3C zugrunde liegende Standard ist bis auf eine Minimalvariante („Basic“) nicht öffentlich zugänglich und im Zugriff auf Mitglieder der MIPI Alliance beschränkt.^[9]

• SMBus: Technisch sehr ähnlicher Bus, die Bauteile sind oft kompatibel zum I²C-Bus.
• Serial Peripheral Interface: Ein weiterer serieller Bus, der aber Chip-Select-Leitungen für den Zugriff auf individuelle ICs benutzt, Totem-Pole-Ausgänge und getrennte Sende- und Empfangsleitungen aufweist.
• I²S (Inter-IC Sound): Eine Schnittstelle speziell zur Übertragung von digitalen Audiodaten
• 1-Wire: Eine serielle Schnittstelle, die mit einer Datenader auskommt, die sowohl als Stromversorgung als auch als Sende- und Empfangsleitung genutzt wird.
• Display Data Channel (DDC): Serieller Bus zur Kommunikation zwischen PC und Bildschirm, basierend auf dem I²C-Bus

• The I²C-Bus Specification and User Manual, Rev. 7.0 — 1 October 2021, archivierte Version vom nicht mehr frei verfügbaren Original, The I²C-Bus Specification and User Manual, Rev. 7.0 — 1 October 2021, (UM10204) Original-Spezifikation von NXP Semiconductors (PDF, engl.; 734 KiB)
• i2c-bus.org, Detaillierte Information zum I2C-Bus in Deutsch und Englisch
• I²C Bus and Access Bus, Darstellung der Gemeinsamkeiten und Unterschiede (englisch)
• Eine einfache verständliche Erklärung des I²C-Bus
• Einführung in I²C (hauptsächlich AVR-Beispiele)
• Die Nutzung des I²C-Interfaces am Beispiel des PIC16F876
• I2C-Slave-Adressierung mit 7-Bit-, 8-Bit- und 10-Bit

1. ↑ Gezählt werden hier nur die Signalleitungen, nicht aber die Leitung für das Bezugspotential (Masseleitung)
2. ↑ Kleine Unterschiede in der Implementierung listet beispielhaft das Datenblatt für AT32UC3A… auf Seite 220 auf.

1. ↑ ^{a b c d e} UM10204. (pdf) The I²C-Bus Specification and User Manual, Rev. 7.0 — 1 October 2021. NXP, 1. Oktober 2021, archiviert vom Original; abgerufen am 11. Februar 2023 (englisch). 
2. ↑ I²C bei mikrocontroller.net
3. ↑ NXP Semiconductors: The I²C-Bus Specification and User Manual, Rev. 6 — 4 April 2014. (Memento vom 26. April 2021 im Internet Archive) Original-Spezifikation (PDF, engl.; 1,4 MB)
4. ↑ Beispielsweise die I²C-Isolatoren ADuM1250 mit Clock-Stretching und ADuM1251 ohne Clock-Stretching
5. ↑ Arne Pahl, Stefan Dickmann: Analysis of sensor disturbances caused by IEMI. 2022, S. 159–165, doi:10.15488/12572 (uni-hannover.de [abgerufen am 18. September 2023]). 
6. ↑ Analog Devices: Implementing an I²C® Reset. (Application Note 686) (PDF, engl.)
7. ↑ R. Colin Johnson: MEMS/Sensor Interface I3C Rocks. MIPI Alliance offer improved sensor spec at MEC. EE Times, 12. November 2014, abgerufen am 2. August 2017 (englisch). 
8. ↑ ^{a b} Emmanuel T. Nana: Improved Inter Integrated Circuit (I3C) standard. New serial bus for sensor interface in mobile and electronic equipment. NXP, FTF2016 Technology Forum, 18. Mai 2016, S. 12, abgerufen am 22. August 2022. 
9. ↑ MIPI I3C and MIPI I3C Basic. MIPI Alliance, 2021, abgerufen am 25. April 2024.