• Online: 3.359

Wed Jul 02 04:40:06 CEST 2008    |    BlackTM    |    Kommentare (10)    |   Stichworte: Bus, Daten, Fahrzeug, I²C, Protokoll, Spezifikation

Der I²C (Inter-IC Bus) ist ein 1980 von Philips eingeführter Standard. Zur Datenübertragung werden 2 Leitungen und Masse benötigt. Andere Hersteller nennen ihre Version davon aus Markenrechtsgründen TWI (Two Wire Interface). Die Einsatzgebiete sind natürlich überall wo man Daten mithilfe weniger Leitungen aus einfachen Komponenten übertragen möchte. So ist die Produktpalette für I²C sehr vielseitig, von Speicherbausteinen (EEPROM) über Echtzeituhren, Display Treibern bis zum Temperatursensor gibt es so einiges am Halbleitermarkt.

 

Für weitere Informationen hier weiterlesen.

 

Der I²C Bus ist ein Master-Slave Bus mit der Möglichkeit mehrere Master an einem Bus zu haben. In der Regel wird der Bus (sofern frei) durch einen Master "gestartet", danach fragt der Master eine Adresse an und der betroffene Slave liest/schreibt die geforderten Daten auf den Bus bzw. in seinen internen Speicher, die übertragenen Daten werden vom Empfänger bestätigt und der Bus wird "gestoppt" oder alternativ wird fortgesetzt. Sollten mehrere Master gleichzeitig eine Anfrage starten wollen, so fährt der Master fort, der die Arbitrierung gewinnt.

 

Das Protokoll kann recht einfach in Mikrocontrollern implementiert werden. Typische Anwendungen umfassen z.B. im PC (dort der Ableger SMBus) die Temperaturerfassung und -steuerung, Echtzeituhren (RealTimeClock) und die Steuerung von Segmentdisplays. Im automobilen Bereich wird/wurde I²C ebenfalls zur allgemeinen Kommunikation im Infotainmentbereich eingesetzt, wobei diese Bereiche langsam durch CAN oder LIN ersetzt werden (vermutlich aufgrund besserer EMV-Eigenschaften und Kosten).

 

Die Übertragungsraten sind von anfänglich 100kBit/s über 400kBit/s auf mittlerweile 3,4MBit/s angestiegen. Das stellt jedoch nur das Maximum an einem Bus dar, denn dieser muss sich dem langsamsten Teilnehmer anpassen. Die einzelnen Knoten sind also in der Lage beim Schreiben auf den Bus ihre Geschwindigkeit variabel zu gestalten und müssen keine zeitkritische Datenübertragung gewährleisten, da sie die Übertragung des nächsten Zustands "hinauszögern" können. Damit ist I²C nicht echtzeitfähig, dafür aber recht ressourcenschonend und der internen Verarbeitung von Daten werden keine zeitlichen Limits gesetzt (ausser den für einen Bus vorgesehenen, selbst festgelegten). Man kann natürlich auf die maximale Übertragungsrate kommen, wenn jede beteiligte Komponente die Geschwindigkeit halten kann. Leichte Abweichungen zwischen den Baudraten erzeugen also keine Probleme.

 

Es gibt 2 Protokollversionen, die erste mit 7 Bit und die zweite mit 10 Bit Adressen. Diese Adressen für Slaves werden vom I²C Gremium vergeben, die letzten 3 Bits sind aber durchaus auch durch den OEM konfigurierbar (ggf. auch programmierbar) um mehrere Busteilnehmer des gleichen Typs an einem Bus betreiben zu können. Bei einem selbstgestalteten Protokoll zwischen Mikrocontrollern (Master + "intelligentere" Slaves) spielt das aber kaum eine Rolle.

 

Die Länge der in einem "Frame" übertragenen Daten ist quasi unbegrenzt, lediglich Designwünsche wie Reaktionszeit auf z.B. einen Tastendruck oder die Zeit bis Erkennung von Kommunikationsausfällen begrenzt den Zeitbedarf für eine Datenübertragung. Jedes übertragene Datenbyte wird einzeln bestätigt, auf Rückfalltechniken geht die Spezifikation nicht ein, das ist also dem OEM überlassen wie ein Fehler in den Daten zu behandeln ist. Üblicherweise ist wohl eine erneute Übertragung des gesamten Pakets fällig. Höhere Protokollebenen müssen demzufolge auch die Ermittlung von Gültigkeit und Ablehnung von Daten behandeln. Es wäre z.B. möglich nach jedem Schreibbefehl gleich einen Lesebefehl anzuhängen, in dem der Empfänger den Status, eine Checksumme und/oder die geschriebenen Daten zurückgibt, so das diese verglichen werden können.

 

Wie schon angedeutet besteht I²C aus 2 Leitungen und Masse.

Die zwei Leitungen nennen sich SDA (Data) und SCL (Clock). Der SCL Leitung kommt eine besondere Funktion für die Arbitrierung zu. Die SDA-Leitung darf ihren Status (bis auf die START- und STOP-Kondition) nicht ändern während SCL High ist. Bei beiden Leitungen dominiert der Low-Zustand über den High-Zustand. Je nachdem welcher Knoten Datenbits auf der SDA-Leitung einstellt, hat immer der Empfänger per SCL Vorrang bei der Entscheidung, ob neue Daten gesendet werden dürfen (indem die Leitung noch auf Low gehalten wird, während der Sender sie "released", also auf High gesetzt, hat). Der andere Teilnehmer bemerkt dann bei Zustandswechsel der SCL-Leitung, dass er weitersenden kann.

 

Es können immer nur zwei Busteilnehmer Daten austauschen und somit auch nur Sender oder Empfänger Daten als ungültig markieren (fehlendes ACK-Bit oder Fehlerbehandlung auf höherer Protokollebene). Eine Gültigkeitsüberwachung durch das gesamte Netzwerk wie bei CAN gibt es somit nicht. Auch wäre I²C anfällig gegen Einstreuungen und zu hohe Kapazität auf den Leitungen, da das Netzwerk durch fest eingebaute Widerstände stabilisiert wird. Eine Obergrenze für Kapazität sind 300pF für ein Subnetzwerk, wodurch die Leitungslänge ohne weitere Massnahmen stark begrenzt ist. Es ist nicht so, das man im Automobilbereich die volle Leitungslänge nutzen wollte oder müsste, diese Angabe lässt allerdings einen Rückschluss auf die Störungssicherheit zu. Übertragungssysteme mit LVDS (Low-Voltage-Differential-Signal) Technologie sind da robuster.

 

Links

I²C Spezifikation alternativ hier.

Produktübersicht für Logik-ICs

 

MfG BlackTM


Deine Antwort auf "Wie funktioniert I²C? Ganz einfach!"