I2C als Hausbus

Aus der Mikrocontroller.net Artikelsammlung, mit Beiträgen verschiedener Autoren (siehe Versionsgeschichte)
Wechseln zu: Navigation, Suche

Infos

Infos allgemein zu Hausbus, I²C.

Es wird oft behauptet das I²C nur für Verbindungen innerhalb einer Leiterplatte gedacht ist. Das ist sicherlich die Hauptanwendung, aber es gibt auch allseits bekannte Einsatzgebiete wo etliche Meter überbrückt werden. Bei VGA (DDC) und HDMI wird z.B. eine I²C-Bus Verbindung zur Kommunikation zwischen den Endgeräten benutzt. VGA und HDMI Kabel können (offiziell) rund 15m lang sein.

Allerdings werden für diesen Einsatz oftmals auch spezielle Treiber Bausteine eingesetzt, die eine höhere Buskapazität vertragen, verbesserten ESD Schutz haben, die Pegel übersetzen (z.B. 3,3 auf 5V), Hot-Plug-fähig sind, etc. Als Beispiel sei hier der PCA9507 (NXP) aufgeführt, der einige dieser Eigenschaften besitzt.

Vorteile

Man kann Slave Bausteine "von der Stange" kaufen, ohne sich Gedanken über Protokoll und Adressierung zu machen. Denn das ist bereits schon implementiert. Alternativ kann man aber auch eigene Slaves bauen und an den Bus hängen. Dafür haben viele µC schon eine Hardware I²C Schnittstelle integriert. Wobei man aber auch recht einfach eine I²C Schnittstelle in Software nachbilden kann.

I²C Bausteine sind reine State-Machines. Somit sind viele von Hause aus recht Stromsparend. Der PCA9554 benötigt z.B. nur 250nA im "Standby-Mode" (keine Kommunikation).

Bei I²C gibt der Master den Takt (SCL) für die Datenübertragung vor. Die Slaves benötigen im Gegensatz zu UART also keinen genauen Taktgeber (Quarz). Will man den Takt auf dem Bus verringern, so muss man das nur am Master einstellen. Die Slaves benötigen keine Änderung. So ist es auch möglich den Takt dynamisch zu variieren und z.B. wichtige Nachrichten mit geringem Takt (Störunempfindlicher) zu übertragen und andere Nachrichten mit höherem Takt.

Verkabelung

Kabellänge

I²C ist nicht als "long range" Bus entwickelt worden. Daher ist eines der Hauptprobleme bei I²C als Hausbus, dass man ohne weiteres nicht weiter als ein paar Meter kommt. Das liegt daran das die I²C Leitungen eine maximale Kapazität von 400pF nicht übersteigen dürfen, da der high-Zustand auf dem Bus nur passiv über Pull-Ups erreicht wird. Je mehr Kapazität an einer I²C-Bus Leitung hängt, desto länger braucht der Bus also um den high-Zustand zu erreichen. Das kann zu timing Problemen führen.

Es gibt zur Reichweitenerhöhung verschiedene Ansätze:

  1. Kleinerer Pull-Up
  2. Geschwindigkeitsreduktion
  3. Bustreiber
  4. Differentielle Übertragung
  5. Aktiver Pull-Up

Kleinerer Pull-Up

Da das Kernproblem darin liegt, dass der high-Zustand nur passiv erreicht wird, bietet es sich an den Pull-Up Widerstand zu verkleinern um dadurch die Zeit zu verkürzen die der Bus benötigt den high-Zustand zu erreichen.

Begrenzt wird dieses Vorhaben dadurch, dass I²C Geräte nur 3mA sinken können (Die weiter unten besprochenen Bustreiber umgehen genau dieses Problem). Bei der Berechnung der Pull-Ups muss also darauf geachtet werden, dass nicht mehr als 3mA durch einen Widerstand fließen. Eine Ausnahme stellen I²C Geräte dar, die der Fm+ (oder höher) Spezifikation entsprechen (Fm+ = Fast mode Plus). Diese sind in der Lage 30mA zu sinken.

Geschwindigkeitsreduktion

Wenn die Busgeschwindigkeit angepasst wird, sind große Strecken und umfangreiche Verzweigungen möglich. Ein 30-Meter-Bus funktioniert zum Beispiel noch mit rund 20kHz fast ohne Probleme. Bei Geschwindigkeiten um 1kHz, wurde im Forum schon von Buslängen von etlichen hundert Metern berichtet.

Bustreiber

Bustreiber haben die Aufgabe die maximale Buskapazität von 400pF zu erhöhen. Dies erreichen die Bausteine i.d.R. durch eine Steigerung des Stroms auf dem Bus. Die drei bekanntesten Bustreiber für diesen Zweck sind folgende:

  • P82B715 (3000pF, max. 100kHz)
  • P82B96 (4000pF, max. 400kHz)
  • PCA9600 (4000pF, max. 1MHz)

Alle drei Typen haben ihre Vor- und Nachteile. Wobei der PCA9600 als Nachfolger vom P82B96 angesehen werden kann und im Prinzip nur Vorteile gegenüber dem P82B96 hat (Abgesehen vom Preis und der Beschaffbarkeit ;) - PCA9600 Gibts nun bei Reichelt!)

Der Hauptunterschied zwischen P82B96 und PCA9600 sind die Spannungspegel an der Sx/Sy Seite des ICs. Der P82B96 kann diese Pins bei einem low-Signal nicht weiter als 0,88V nach unten ziehen (I²C kompatibel, nicht TTL kompatibel). Der verbesserte PCA9600 kann bis auf 0,74V herunter ziehen (I²C und TTL kompatibel). Des weiteren hat der PCA weniger Laufzeitverzögerung und ist bis zu 1MHz Bustakt spezifiziert.

Der P82B96 (und PCA9600) verhindert eine Rückkopplung indem er an seinen Sx/Sy Eingängen ein low bei 0,65V erkennt, ein low selber aber nur mit 0,88V ausgeben kann. Informationen die über die T/R Seite kommen, werden also von einem zweiten, parallelgeschalteten, Bustreiber des gleichen Typs nicht weitergeleitet. Im Gegensatz zum P82B715 können die ICs verschiedene Busspannungen "übersetzen". Die gepufferte Seite kann also mit einer anderen Busspannung betrieben werden als die Sx/Sy Seite.

P82B96 und PCA9600 können statisch 30mA treiben. In der Application Note AN10216 (Seite 46) wird von NXP geschrieben das mittels externer Transistoren der Strom noch weiter erhöht werden kann. Bei 30kHz wird eine mögliche Gesamtlänge von 1km angegeben.

Recht einfach aufgebaut ist der P82B715. Intern arbeitet nur ein Stromsensor, der auf der gepufferten Seite mittels Transistors den Strom bei low Pegel erhöht. Er hat somit nicht die Probleme mit bestimmten Spannungspegeln wie die P82B96 und PCA9600 ICs. Dafür muss beim P82B715 auch die ungepufferte Seite zur Gesamtbuslast mit einbezogen werden. Auch ist es nicht möglich die gepufferte Seite mit anderer Spannung zu bertreiben. Auf der gepufferten Seite (LDA/LCL) besitzt der P82B715 nur jeweils einen Pin für jede Busleitung. Applikationen die getrennte TX und RX Pins benötigen, sind mit dem P82B715 also nicht möglich.

Differentielle Übertragung

In Kombintation mit einem Bustreiber wie dem P82B96, ist es möglich die I²C Bus Signale über RS-485 oder CAN physikalisch zu "tunneln" (PHY Layer).

Dabei werden die TX und RX Leitungen des I²C Bustreibers mit den TX und RX Leitungen des RS-485 oder CAN Treibers verbunden. Für SDA und SCL werden hierfür auf dem Übertragungskabel also insgesamt vier Leitungen benötigt.

NXP hat mit den P82B485/P82B486 auch Treiber angekündigt, die den I²C-Bus direkt auf RS485 übersetzen.

Aktiver Pull-Up

Linear Technology bietet einige ICs wie den LTC1694 an, der den passiven low-high Wechsel des I²C-Bus durch eine Stromquelle beschleunigt.

Topologie

Über die günstigste Topologie (Stern, Bus,..) ist bisher nichts bekannt.

Störsicherheit/EMV

Bei der Nutzung als Feldbus müssen die Busteilnehmer sowohl gegen Störungen und Überspannung geschützt werden (induktive/kapazitive Einkopplungen), als auch Maßnahmen getroffen werden gegen zu große Störabstrahlung des Busses in die Umwelt. Wesentlich ist dabei die Begrenzung des maximalen Spannungsanstieges dU/dT auf allen Busleitungen und der Schutz vor Spannungsspitzen. Dazu gibt es folgende Möglichkeiten:

  • Verwendung abgeschirmter und/oder verdrillter Leitungen mit zentraler Erdung
  • Überspannungsschutz bei den Busteilnehmern - durch Schottkydioden zwischen SDA/SCL gegen Masse und VCC unmittelbar an den Slaves und Serienwiderstände in den Datenleitungen in der Anbindung zum Bus (typ. 50 … 200 Ohm)
  • Passive Pi-Filter an allen Busteilnehmern, abgestimmt auf die höchste Übertragungsrate

Eine effektive Variante zum Schutz vor Überspannung, Spannungsausfall beim Slave und zugleich Pegelanpassung:

Schaltplan

Datensicherheit

Von Hause aus ist bei I²C keine Checksumme o.ä. vorgesehen. Einzelne Bytes werden nur mit einem ACK bestätigt.

Man muss also eigene Konzepte entwickeln um sicherzugehen, dass Daten korrekt gesendet und empfangen wurden.

Einige Möglichkeiten wären:

  • Geschriebene Daten zurücklesen
  • Daten immer mehrmals schreiben/lesen
  • Wenn man µC als Slave programmiert, kann man eine Checksumme als zusätzliches Byte mitübertragen

Ein weiteres Problem ist, dass Slaves sowohl das SDA Datensignal, als auch das SCL Taktsignal (Clock-Stretching) dauerhaft auf "Low" ziehen können, was den Totalausfall des Busses zur Folge hat. Das kann z.B. beim Ausfall der Stromversorgung eines Slaves auftreten, es sind aber auch Schaltkreise bekannt, die diese Fehlfunktion bei längerem Betrieb zeigen (z.B. LM75). Die Auswirkungen eines lokalen Stromausfalls begrenzt ein klassischer Pegelshifter mit MOSFET, zwischen Bus und Slave geschaltet, bereits zuverlässig. Das Erlauben von Clock-Stretching ist generell ein Problem, da das Bus-Timing und somit die Reaktion des Gesamtsystems in Echtzeit nicht mehr garantiert werden können.

Adressierung

Wie viele Adressen einzelne I²C Bausteine haben, ist unterschiedlich. In der Regel sind 1-8 Adressen möglich. Es gibt aber auch (neuere) Bausteine die bis zu 64 mögliche Adressen haben. Somit kann es also sein, das man evt. Probleme bekommt wenn man mehrere Bausteine des selben Typs einsetzen will.

In dieser Hinsicht ist der PCA9501 I/O Expander Baustein recht interessant. Er bietet als einer der wenigen älteren Bausteine bis zu 64 mögliche Adressen. Zudem hat er ein integriertes EEPROM (256 Byte) und ist somit für Hausbus Anwendungen gut geeignet.

Eine andere Lösung dieses Problems ist die Verwendung von I²C Multiplexern- bzw. Switches. Wie z.B. den PCA9544. Dieser Baustein kann einzelne Busabschnitte bei Bedarf abtrennen, so das man in den einzelnen Abschnitten identische Adressen verwenden kann.

Eigene Erfahrungen

Vor einigen Jahren war ich als Servicetechniker bei einer Geräteinstallation im Einsatz, bei der die laut Datenblatt möglichen Längen bei weitem überschritten wurden. Ab 12m ging nix mehr. Der Grund war aber nicht der I²C-Bus, sondern die Spannungsversorgung der entfernten Geräte. Die Masseleitung war auch 12m lang, und der Stromverbrauch der Geräte hat den Massepegel soweit angehoben, dass der I²C-Bus nicht mehr funktioniert hat. Mit einer dickeren Masseleitung hat's sofort wieder funktioniert.

Die Kabel sind (bezüglich der gemeinsamen Masse) eine Kette über differentiell kleiner Widerstände parallel geschaltener differentiell kleiner Kondensatoren. Durch einen Pegel-Wechsel müssen all diese kleinen Kondensatoren über die Widerstände umgeladen werden. Folge ist eine deutlich kleinere Ausbreitungs-Geschwindigkeit des Signals und ein geringerer Spannungs-Anstieg an den Anschlüssen der Geräte. Zu der Kapazität der Kabel kommt vor allem noch die Kapazität der Geräte. Im I²C-Standard von Philips ist diese Kapazität auf 400pF limitiert. Im access.bus-Standard (welcher für Computer-Komponenten und Peripherie entwickelt wurde) ist diese Kapazität auf 1000pF beschränkt. Vgl. Ausbreitungsgeschwindigkeiten, Kapazitäten bei anderen Bus-Systemen wie USB, SATA, RS485

Habe ein I2C Netzwerk im Haus, sternfoermig und Reihe gemischt, vielleicht 40m alles zusammen, bei 70kHz mit P82B715 an allen Knoten, CAT5 Kabel, laeuft einwandfrei. Musst natuerlich Fehlererkennung (NACK) etc Routinen vorhalten.

Habe bei meinem I2C-Hausbus eine Kabellänge von ca. 120m. Auch sternförmig und reihe gemischt. Taktfrequenz 96kHz, jedes der 22 Module ist mit einem P82B715 ausgestattet. Den Pull-up Widerstand von SDA und SCL habe ich auf 180 Ohm verringert. Läuft fehlerfrei seit ca. 15 Jahren. Verwendetes Kabel für SCL, SDA: 2x0,14mm², geschirmt. Spannungsversorgung +/-15V und Interrupt: 5x1,5².

Mein I2C-Hausbus hat ca. 150m Gesamtlänge, Topologie sowohl als Stern, als auch Linien gemischt. Taktfrequenz 3 kHz und weitere Optimierungen. Einheitlicher Bus mit Masse/SDA/SCL und +12V zur Stromversorgung. Läuft seit 2004 weitgehend fehlerfrei. Dokumentation im Netz (Projekt Hauscomputer).

Passende Sensoren / Module

Links

Allgemein

Foren Beiträge

Application Notes

Praktische Anwendungen

Siehe auch

Adressierung

Wie viele Adressen einzelne I²C Bausteine haben, ist unterschiedlich. In der Regel sind 1-8 Adressen möglich. Es gibt aber auch (neuere) Bausteine die bis zu 64 mögliche Adressen haben. Somit kann es also sein, das man evt. Probleme bekommt wenn man mehrere Bausteine des selben Typs einsetzen will.

In dieser Hinsicht ist der PCA9501 I/O Expander Baustein recht interessant. Er bietet als einer der wenigen älteren Bausteine bis zu 64 mögliche Adressen. Zudem hat er ein integriertes EEPROM (256 Byte) und ist somit für Hausbus Anwendungen gut geeignet.

Eine andere Lösung dieses Problems ist die Verwendung von I²C Multiplexern- bzw. Switches. Wie z.B. den PCA9544. Dieser Baustein kann einzelne Busabschnitte bei Bedarf abtrennen, so das man in den einzelnen Abschnitten identische Adressen verwenden kann.

Eigene Erfahrungen

Vor einigen Jahren war ich als Servicetechniker bei einer Geräteinstallation im Einsatz, bei der die laut Datenblatt möglichen Längen bei weitem überschritten wurden. Ab 12m ging nix mehr. Der Grund war aber nicht der I²C-Bus, sondern die Spannungsversorgung der entfernten Geräte. Die Masseleitung war auch 12m lang, und der Stromverbrauch der Geräte hat den Massepegel soweit angehoben, dass der I²C-Bus nicht mehr funktioniert hat. Mit einer dickeren Masseleitung hat's sofort wieder funktioniert.

Die Kabel sind (bezüglich der gemeinsamen Masse) eine Kette über differentiell kleiner Widerstände parallel geschaltener differentiell kleiner Kondensatoren. Durch einen Pegel-Wechsel müssen all diese kleinen Kondensatoren über die Widerstände umgeladen werden. Folge ist eine deutlich kleinere Ausbreitungs-Geschwindigkeit des Signals und ein geringerer Spannungs-Anstieg an den Anschlüssen der Geräte. Zu der Kapazität der Kabel kommt vor allem noch die Kapazität der Geräte. Im I²C-Standard von Philips ist diese Kapazität auf 400pF limitiert. Im access.bus-Standard (welcher für Computer-Komponenten und Peripherie entwickelt wurde) ist diese Kapazität auf 1000pF beschränkt. Vgl. Ausbreitungsgeschwindigkeiten, Kapazitäten bei anderen Bus-Systemen wie USB, SATA, RS485


Habe ein I2C Netzwerk im Haus, sternfoermig und Reihe gemischt, vielleicht 40m alles zusammen, bei 70kHz mit P82B715 an allen Knoten, CAT5 Kabel, laeuft einwandfrei. Musst natuerlich Fehlererkennung (NACK) etc Routinen vorhalten.

Habe bei meinem I2C-Hausbus eine Kabellänge von ca. 120m. Auch sternförmig und reihe gemischt. Taktfrequenz 96kHz, jedes der 22 Module ist mit einem P82B715 ausgestattet. Den Pull-up Widerstand von SDA und SCL habe ich auf 180 Ohm verringert. Läuft fehlerfrei seit ca. 15 Jahren. Verwendetes Kabel für SCL, SDA: 2x0,14mm², geschirmt. Spannungsversorgung +/-15V und Interrupt: 5x1,5².

Mein I2C-Hausbus hat ca. 150m Gesamtlänge, Topologie sowohl als Stern, als auch Linien gemischt. Taktfrequenz 3 kHz und weitere Optimierungen. Einheitlicher Bus mit Masse/SDA/SCL und +12V zur Stromversorgung. Läuft seit 2004 weitgehend fehlerfrei. Dokumentation im Netz (Projekt Hauscomputer).

Passende Sensoren / Module

Links

Allgemein

Foren Beiträge

Application Notes

Praktische Anwendungen

Abgerufen von „https://www.mikrocontroller.net/index.php?title=I2C_als_Hausbus&oldid=105550“