I²C-Ansteuerung

	Wer hat sich nicht schon beim Routing der vielen Leiterbahnen komplizierter paralleler Bussyteme verzweifelt gefragt, wieviele Drahtbrücken und Überkreuzungen beim Löten wirklich zumutbar sind? Wieso der Platz auf der Platine schon wieder jedes vernünftige Maß sprengt? Weshalb der Controller irgendwie niemals genug IO-Ports zu haben scheint? Ein modernes, serielles Bussystem wie der I2C-Bus kann diese Mißstände ebenso elegant wie bequem abstellen.
Allgemeines
	I2C ist eine Abkürzung für Inter-IC bus. Dies beschreibt auch schon den Einsatzzweck des Busses: die Verbindung von Integrierten Schaltkreisen (Integrated Circuits). Der I2C-Bus wurde bereits vor etwa 20 Jahren von Philips entwickelt. Ziel war ein hierarchisches Bussystem (Master-Slave Architektur) für geringe Datenraten, an das sich bei geringstem Verdrahtungsaufwand mehrere IC's anschließen lassen. Damit bei diesen IC's auf teure Komponenten wie Quarze oder Takterzeuger verzichtet werden konnte, sollte der Bus den Takt übertragen. I2C findet sich heute bereits in einer Vielzahl von wirklich praktischen IC's wie EEPROM's, Busextendern oder LED-Treibern, etlichen für Bastler weniger interessanten	Bausteinen wie Videotext-Decodern oder Audio-Steuerchips sowie auf dem Motherboard jedes modernen PC als Systembus, an den Komponenten für's Systemmanagement wie Lüfterdrehzahlmesser und Temperaturüberwachung angeschlossen sind. Da der Busmaster, also der Initiator einer I2C-Übertragung, den Takt mit übermittelt, sind die Datenraten variabel. Allzuviel sollte man auch nicht erwarten, da I2C nicht für hohes Datenaufkommen, sondern primär für eine einfache Handhabung entworfen wurde. Bei größeren seriellen EEPROM's beispielsweise sind 400kHz Bustakt als Maximum üblich. Da immer etwas 'Verschnitt' anfällt, kann man realistisch mit etwa 30kByte/s rechnen. Im folgenden Text soll erläutert werden, wie man mit einem 8051-kompatiblen Controller als Master den I2C-Bus ansteuern kann. Für Informationen über die elektrische Charakteristik, Multimaster-Betrieb oder die Implementierung eines I2C-Slaves sei auf die Bibliographie am Ende dieser Seite verwiesen. zurück zum Anfang
Verdrahtung
	Der I2C-Bus basiert auf zwei Leitungen: SCL transportiert das Taktsignal. Dieses wird ausschließlich vom Busmaster erzeugt und von den angeschlossenen Chips gelesen, die Übertragungsrichtung ist daher eindeutig festgelegt. SDA überträgt die Datenbits. Über diesen Anschluss senden sowohl Master als auch Slave ihre Daten. Der oder die empfangenden Chips müssen dabei SDA jeweils auf High-Potential legen.	Der Zustand des auf SDA angelegten Datenbits darf nur wechseln, während SCL=0 ist. Bei SCL=1 sind die angelegten Daten grundsätzlich gültig. Dies ist unabhängig davon, ob der Master sendet und der Slave empfängt, oder umgekehrt. Die Ausnahme von der Regel bilden spezielle Steuerkommandos, die auf einem Wechsel auf der Datenleitung während SCL=1 basieren und immer vom Master gesendet werden. zurück zum Anfang
Buszustände
	Im Grundzustand sind SCL und SDA high. Will der Master eine Abfrage an ein Device senden, so beginnt er immer mit einer START-Condition. Dabei wird SDA von High nach Low gesetzt, während SCL High ist. Anschließend wird SCL auf Low gesetzt. Solange SCL Low ist, darf sich der Zustand von SDA ändern. Daher kann in diesem Zustand der Sender ein Datenbit auf den Bus geben, welches vom Empfänger interpretiert wird, sobald SCL vom Master wieder auf High gesetzt wird. Daten werden grundsätzlich immer mit dem höchstwertigen Bit zuerst übermittelt. Nachdem 8 Bits auf diese Weise (SCL low, Datenbit auf SDA, SCL high, warten/empfangen, SCL low) übertragen wurden, folgt die Bestätigung vom Empfänger, dass diese Daten korrekt empfangen wurden. Diese ACK-Condition ist nichts weiter als ein weiteres Bit, nur mit	vertauschten Rollen: der Empfänger der 8 übermittelten Bits sendet im 9. Bit seinerseits eine 0, um den Empfang zu quittieren. Daher muss der Sender als 9. Bit einen High-Zustand auf SDA ausgeben und prüfen, ob dieser vom Empfänger auf Low gezogen wird. Stellt der Sender fest, dass kein ACK als Bestätigung erfolgt, so hat der Empfänger vielleicht einen Taktpuls verpasst, wurde zu schnell mit Daten überflutet oder ist schlicht kaputt. Die beste Verhaltensweise bei fehlendem ACK ist es, sofort eine STOP-Condition auszugeben und die Übertragung noch einmal zu versuchen. Das Ende einer I2C-Übertragung wird durch eine STOP-Condition angezeigt. Dafür setzt der Master - nur er darf eine Übertragung starten und beenden - SDA von Low nach High, solange SCL high ist. Abschließend ist der Bus wieder im Grundzustand: SCL und SDA sind high. zurück zum Anfang
Adressierung
	Wie Eingangs erwähnt, ist der I2C-Bus für den Anschluss vieler I2C-Slaves konzipiert. Damit dies reibungslos funktioniert, muss jeder I2C-Chip genau wissen, welche Daten für ihn bestimmt sind und welche einem anderen Empfänger zugedacht sind. Dazu wird folgender Mechanismus genutzt: Jeder I2C-Chiptyp besitzt eine im Chip hart verdrahtete 4 Bit-Adresse. Desweiteren hat jeder I2C-Chip bis zu 3 Adresspins, die mit einer beliebigen Adresse belegt werden können. Damit lassen sich an jeden I2C-Bus bis zu 8 Chips mit gleicher Deviceadresse bei 16 möglichen verschiedenen Deviceadressen anschließen und unterscheiden, beispielsweise 8 Busextender, 8 EEPROM's und 8 LED-Treiberbausteine. Allerdings haben nicht alle Chips wirklich nach aussen geführte Adresspins. Es gibt auch einige EEPROM's mit intern fest verschalteten Adressen, obwohl die Adresspins nach aussen geführt sind - wahrscheinlich um Pinkompatibitlität zu den EEPROM's anderer Hersteller herbeizuführen. Ebenfalls zu bekommen sind an sonsten baugleiche Chips mit verschiedenen fest einprogrammierten Adressen. Beispielsweise sind die I/O-Expander PCF8574 und PCF8574A völlig identisch - bis auf eine unterschiedliche Deviceadresse. So lassen sich an einem Bus 16 I/O-Expander anschließen und nicht nur 8. Daher ist ein Blick in das genaue Datenblatt des Chips unbedingt anzuraten, Datenblätter von baugleichen Typen unterschiedlicher Hersteller genügen nicht.	Und so wird der Adressierungsmechanismus beim I2C-Bus eingesetzt: Unmittelbar nach dem Senden der Start-Condition wird ein Steuerbyte mit einem weiter unten beschriebenen Aufbau übertragen, das von allen am Bus lauschenden Slaves ausgewertet wird. Die 4 höchstwertigen und daher zuerst gesendeten Bits enthalten die fest eingebrannte Device-Adresse. Adressen gebräuchlicher Chips könnten aus der Tabelle oder aus ihren Datenblättern entnommen werden. Daraufhin folgen drei Adressbits, die den Adresspins am Chip entsprechen. Besitzt der Chip weniger als drei Adresspins, so sind die überzähligen Bits in der Regel 0. Das letzte und niederwertigste Bit muss eine 1 für nun folgende Leseoperationen bzw. eine 0 für Schreiboperationen enthalten. Nun kommt die nach jedem gesendeten Byte fällige ACK-Condition. Alle am Bus hängenden I2C-Devices wissen jetzt, ob die bis zur den Buszyklus abschließenden Stop-Condition gesendeten Daten für sie bestimmt sind oder nicht. zurück zum Anfang
Einige oft benutzte I2C-Devices
	Chip Beschreibung Device-Adresse prog. Adressen PCF8573 Uhrenbaustein mit Alarm und Spannungswächter 1101 4 PCF8583 Uhrenbaustein mit 240 Byte RAM 1010 2 PCF8570 256 Byte Low Voltage-SRAM 1010 8 24C01 bis 24C512 Serielle EEPROM's Die Nummer hinter dem 'C' entspricht der Kapazität in Kilobit 1010 0 bis 8 PCF8575 16 Bit I/O-Erweiterung 0100 8 PCF8574 8 Bit I/O-Erweiterung 0100 8 PCF8574A 8 Bit I/O-Erweiterung 0111 8 SAA1064 LED-Treiber für 4x8 LED's bzw. 4 x 7seg. Anzeigen mit Dezimalpunkt. 0111 4 PCF8591 AD-Wandler 1001 8 Die meisten hier aufgeführten I2C-IC's stammen von Philips. Ausnahme sind die EEPROM's, die auch von anderen Herstellern bezogen werden können, beispielsweise von Atmel, Motorola oder ST. Da der Code zum Erzeugen der I2C-Signale recht einfach ist und nur aus ein paar setb/clr/nop/rlc/mov-Befehlen besteht, wurde an dieser Stelle auf ein Beispiel verzichtet. Als solches kann der Code-Generator dienen, der in der neuesten Version auch I2C-Primitives erzeugen kann, oder der dessen Code zugrundeliegende I2C-Treiber von Atmel.
Bibliographie
	http://www.e-online.de/public/borchers/i2c/main.htm     Der I2C-Bus von Manuel Borchers, e-online.de http://www.ping.be/~ping0751/i2cindex.htm     I2C-Faq http://www.semiconductors.philips.com/i2c/facts/index.html     Philips I2C-Seiten