Mikrocontroller.net - Benutzerbeiträge [de]

I2C als Hausbus

2022-09-22T19:52:34Z

172.26.33.76: Änderung 101983 von Gkiefer (Diskussion) rückgängig gemacht.

Hausbus auf I2C- und ATtiny-Basis: Home2L Brownies

2022-09-21T08:24:51Z

172.26.33.76: /* Einleitung */

== Einleitung ==

Das "''Home2L Brownies''"-Projekt verfolgt das Ziel, eine einfache, effiziente und dennoch robuste Plattform zu schaffen für einen Hausbus mit vernetzter Selbstbau-Hardware. Die Hauptziele sind:

* einfache, transparente Hardware

* hohe Zuverlässigkeit und Langzeit-Stabilität

* offene, dokumentierte und erweiterbare Software

* gute Wartbarkeit

* geringer Standby-Stromverbrauch (Ziel: eine Größenordnung / Faktor 10 weniger als ein KNX-System)

Als Sensor/Aktor-Knoten kommen ''ATtiny84/85/861''-Mikrocontroller zum Einsatz - die Knoten werden hier als ''Brownies'' bezeichnet (vgl. [https://en.wikipedia.org/w/index.php?title=Brownie_(folklore)&oldid=929557103 Wikipedia: Brownie (folklore)]). Die ''Brownies'' werden über 4-adrige Kabel (z.B. KNX/EIB) mit einem Linux-Hostrechner vernetzt. Dort werden alle Ressourcen (Sensor-Werte, Aktor-Zustände) wahlweise über eine C++-API, Python-API oder ein Kommandozeilen-Tool zugänglich gemacht.

Dieser Artikel gibt (nur) einen Überblick über das Projekt. Details sind auf der [https://github.com/gkiefer/home2l GitHub-Seite zum ''Home2L''-Projekt] zu finden. Dort finden sich auch die Dokumentation zum gesamten ''Home2L''-Projekt ([https://gkiefer.github.io/home2l/home2l-book.pdf ''Home2L Book'']) sowie ein ausführliches Schritt-für-Schritt-Tutorial mit Beispiel-Schaltungsaufbau.

== Messdaten einer realen Beispiel-Installation ==

* Linux-Host mit zwei ARM-Cortex-A9-CPUs und I²C-Schnittstelle (''CubieTruck'')

* 25 Brownies an einem Bus-Baum, die insgesamt u.a. bedienen:
** 43 Reed-Kontakte für 22 Fenster
** 20 Rollläden (40 Relais)
** 20 Temperatursensoren

* 4 primäre Hubs, einzelne Unter-Hubs (insgesamt drei Bus-Ebenen)

* Leistungsaufnahme insgesamt: ca. 250 Milliwatt (50 mA * 5 V) (ohne Linux-Host)

* Kommunikationsstatistik über 6 Tage: 44,3 Mio Nachrichtenwechsel, nur 11 korrigierte Übertragungsfehler (0,000025%)

== Warum 8-Bit-Mikrocontroller? ==

Für die Auswahl der ''ATtiny''-Typen sprechen die folgenden Gründe:

* Sie sind simpel, robust und ausgereift.

* Sie sind in DIP-Gehäusen verfügbar - sehr gut für Selbstbauprojekte!

* Es ist sehr wenig externe Beschaltung nötig: Zwei Widerstände, ein obligatorischer Abblockkondensator und der Mikrocontroller selbst reichen aus, um einen ''Brownie''-Knoten aufzubauen. Die Frage nach einem käuflichen (Eval-)Board stellt sich damit nicht - man braucht keins.

* Der Stromverbrauch ist gering, selbst bei 5V Versorgungsspannung. So lassen sich zum Beispiel ohne weitere Spannungswandler sowohl der Controller als auch Relais betreiben.

* Die Rechenleistung und der Speicher sind für gängige Sensorik wie Fensterkontakte oder Temperaturfühler völlig ausreichend.

Aufgrund der einfachen Beschaltung und der DIP-Gehäuse ist es zum Beispiel möglich, handgelötete Schaltungen auf einer Lochrasterplatine aufzubauen, die dennoch klein genug sind, um in einer Unterputz-Dose Platz zu finden - manchmal nützlich bei Selbstbauprojekten.

== Der ''Home2L''-Bus ==

Der ''Home2L''-Bus basiert auf I²C. Da der Takt explizit durch das SCL-Signal vorliegt, können die ''ATtinys'' mit ihrem internen Takt arbeiten, ein Quarz ist nicht nötig. Auf zusätzliche Transceiver-Bausteine, wie bei CAN oder RS485 üblich, kann ebenso verzichtet werden.

Die Spannungsversorgung beträgt 5V. Jeweils am Master befinden sich Pull-Up-Widerstände von 1 kOhm an SDA/SCL sowie jeweils auf Master- und Slave-Seite Serienwiderstände von 100 Ohm. Letztere begrenzen den Umschaltstrom insbesondere bei langen Leitungen.

Der Bus erfüllt den I²C-Standard bis auf die folgenden beiden Ausnahmen:

# Der maximale Strom liegt bei 5 mA, und die Leitungskapazitäten überschreiten in der Regel die Vorgaben des I²C-Standards.
# Es gibt eine Protokoll-Erweiterung, mit der sich Bus-Slaves gegenüber dem Master bemerkbar machen können (''Host Notification'').

Die ''Host Notification'' ist optional, sodass bei entsprechender elektrischer Beschaltung die ''Brownies'' vollkommen I²C-konform kommunizieren können.

Experimente beim Autor des ''Home2L''-Projektes haben gezeigt, dass eine Kommunikation über 100 Meter KNX-Kabel mit ca. 30 kBit/s praktisch übertragungsfehlerfrei funktioniert, ohne dass zum Beispiel spezielle Bustreiber nötig wären. Um dennoch mit elektrischen Störungen, die bei langen Leitungen auftreten können, umgehen zu können, sind eine Reihe von Techniken implementiert:

* ''Brownies'' können als ''Hub''-Knoten arbeiten und Datenverkehr tranparent an einen Unterbus und zurück durchleiten. So kann der Hausbus in einen Baum von Unterbussen aufgeteilt werden. Lange Leitungen können so in kleinere Segmente aufgeteilt werden. Hubs können beliebig tief kaskadiert werden, und jeder Hub kann prinzipiell beliebig viele eigene Slaves bedienen. Die einzige Limitierung ist die Zahl der verfügbaren Busadressen.

* Die Bitrate ist in der Regel gegenüber I²C reduziert, bei 1 MHz CPU-Takt sind aktuell etwa 30 KBit/s brutto möglich. Sie kann außerdem für kritische Unterbusse bei Bedarf weiter reduziert und so an die physikalischen Gegebenheiten angepasst werden.

* Das Protokoll definiert sehr kurze Nachrichten, sodass in der Regel keine allzu hohen Bitraten notwendig sind. Das Nachrichtenpaar (Request/Reply) für typische Wertabfragen hat zusammen 6 Bytes inklusive Adressierungen und Prüfsummen.

* CRC-Prüfsummen erlauben die Erkennung von Fehlern. Der Linux-Treiber implementiert Wiederholungsstrategien und sammelt Fehlerstatistiken, um eventuelle Problemstellen im Bus-Netz zu identifizieren zu können.

== Die Firmware ==

Die ''Brownie''-Firmware ist konfigurierbar. Sie enthält einige Basis-Funktionalität sowie eine Auswahl an ''Feature''-Modulen für verschiedene Sensor- oder Aktor-Typen. Sowohl die Feature-Auswahl als auch der Controller-Typ (aktuell ''ATtiny84'', ''ATtiny85'' oder ''ATtiny861'') sind konfigurierbar.

Der 8 KB Flash-Speicher wird in zwei Bereiche zu 2,5 KB und 5,5 KB aufgeteilt. Der vordere, kleinere Bereich enthält eine minimale ''Maintenance''-Firmware, der andere Bereich die Haupt-Firmware für den operativen Betrieb. Mit beiden Firmwares ist es möglich, die jeweils andere neu zu flashen. Somit sind Updates im Feld möglich, was sehr nützlich ist, wenn die Controller zum Beispiel an schwer zugänglichen Stellen, wie in Unterputz-Dosen, verbaut sind.

Die Basis-Funktionalität der Firmware umfasst:

* den Kommunikations-Stack für den Bus (Slave-Seite),

* Lesen und Schreiben der Konfiguration (inklusive ID und Bus-Adresse),

* Lesen der Firmware-Kennung, -Version und -Features,

* Lesen und Schreiben (sofern erlaubt) aller Speicher (Flash, RAM, EEPROM),

* Firmware-Updates,

* Reset des Controllers,

* Wechseln und Starten der Maintenance- bzw. operativen Firmware,

Zum Ansteuern von Sensoren und Aktoren stehen aktuell die folgenden Feature-Module zur Verfügung:

* GPIO: beliebige digitale Ein- und Ausgänge

* Temperaturfühler per ''ZACwire''-Protokoll (für TSiC 206/306)

* Matrix: Abfrage von Schaltern, die auch als Diodenmatrix verschaltet sein dürfen (z.B. Fenster-Kontakte, Tastenfelder). Bei Fensterkontakten ist eine "geöffnet/gekippt"-Erkennung in verschiedenen Varianten möglich.

* Rollläden (''Shades''): Ansteuerung von elektrischen Rollläden per Relais-Paar und Taster-Paar; intelligente Steuerung: aktuelle Position wird per Zeitmessung verfolgt, Rolläden bleiben auch bei Kommunikationsverlust steuerbar.

Weitere Feature-Module sind in Planung bzw. können einfach hinzugefügt werden.

== Das Wartungs-Tool ==

Für den Linux-Host gibt es ein Wartungs-Tool ''(home2l-brownie2l)''. Dieses kann mit den einzelnen ''Brownies'' über eine beliebige I²C-Schnittstelle kommunizieren, die von Linux unterstützt wird (Kernel-Modul ''i2c-dev''). Alternativ ist es auch möglich das "ELV USB-I2C"-Interface direkt zu verwenden, das sich unter Linux als serielle Schnittstelle meldet.

Mit dem Wartungs-Tool ''(home2l-brownie2l)'' kann man ...

* ... eine aktuelle Liste der ''Brownie''-Register und Konfigurationsparameter anzeigen (Online-Hilfe).

* ... einen Bus-Scan durchführen, um alle verbundenen Knoten zu identifizieren.

* ... eine Vorlage für eine ''Brownie''-Datenbank (Datei ''brownies.conf'') erzeugen. Die Datenbank ist eine Textdatei, die alle ''Brownies'' und deren Konfigurationsparameter enthält. Sie hilft bei der Wartung größerer Installationen und wird vom Ressourcen-Treiber (siehe unten) benötigt.

* ... ''Brownie''-Register lesen oder beschreiben.

* ... Konfigurationsparameter lesen oder setzen.

* ... beliebige Speicherinhalte eines ''Brownie'' auslesen und anzeigen.

* ... Firmware flashen (aus ELF-Dateien).

* ... den ''Brownie'' neustarten und dabei ggfs. die Firmware (Maintenance/operative) umschalten.

* ... die Taktgenauigkeit messen und den internen Timer (das AVR OSCCAL-Register) kalibrieren.

* ... einen Kommunikationstest durchführen.

* ... Kommunikations- und Fehlerstatistiken sammeln und anzeigen.

* ... bei Hubs: Den Unterbus ein- und ausschalten sowie Unterknoten, deren operative Firmware beim Starten abstürzt (warum auch immer ...), durch Umschalten auf die Maintenance-Firmware wiederbeleben (''Resurrection'').

* ... einige dieser Vorgänge auch im Batch-Betrieb mehrfach ausführen, um zum Beispiel mit einem Kommando bei allen Knoten ein Firmware-Update durchzuführen.

Die Bedienung des Tools wird durch die Online-Hilfe erklärt:

$ home2l brownie2l
brownie2l> help
...

== Zugriff auf Brownie-Features vom Linux-Host ==

Um die Ressourcen der ''Brownies'', wie zum Beispiel die Zustände von GPIOs oder Temperaturwerte, auf dem Host-Rechner zur Verfügung zu stellen, wird die ''Resources''-Bibliothek der ''Home2L''-Projektes verwendet. Diese bietet eine einheitliche Schnittstelle zum Zugriff auf die Ressourcen. Zugriff auf die Ressourcen ist auf drei verschiedene Arten möglich:

# interaktiv oder per Shell-Skript mit dem Tool ''home2l-shell'',
# in Python über die [https://gkiefer.github.io/home2l/home2l-api_python/index.html Python-API],
# in C/C++ über die [https://gkiefer.github.io/home2l/home2l-api_c/group__resources.html C/C++-API].

Beispiele, insbesondere zur Verwendung der ''home2l-shell'' und der Python-API, sind im [https://gkiefer.github.io/home2l/home2l-book.pdf ''Home2L Book'' (Kapitel 2)] zu finden.

Wer von der recht umfangreichen ''Home2L-Suite'' nur den ''Brownie''-Treiber nutzen möchte, kann die Software mit den Kommandos

make CFG=basic
sudo make CFG=basic install
/opt/home2l/bin/home2l-install -i

installieren und anschließend eine minimale Konfigurationsdatei ''/opt/home2l/etc/home2l.conf'' mit folgendem Inhalt anlegen:

rc.config="" # keine 'resources.conf'-Datei vorhanden/verwenden
drv.brownies=1 # ''Brownies''-Treiber aktivieren
br.link=/dev/i2c-1 # i2c-Gerät definieren (entsprechend anpassen!)

Dazu muss dann noch die Datei ''/opt/home2l/etc/brownies.conf'' wie oben beschrieben angelegt werden.

Anschließend kann zum Beispiel mit ''home2l-shell'' auf die Ressourcen zugegriffen werden:

$ home2l shell
home2l> l /local/brownies/
...

== Weitere Informationen ==

Das [https://gkiefer.github.io/home2l/home2l-book.pdf ''Home2L Book''] enthält die Dokumentation des ''Home2L''-Projektes. Dort findet sich ein ausführliches Schritt-für-Schritt-Tutorial für den Einstieg.

Der Aufbau und die Inbetriebnahme einer einfachen ''Brownie''-Schaltung auf dem Steckbrett ist dort im Abschitt ''Brownies: Integrating Do-It-Yourself Hardware'' beschrieben.

== Downloads ==

* [https://github.com/gkiefer/home2l Quellcode auf GitHub]
* [https://gkiefer.github.io/home2l/home2l-book.pdf ''Home2L Book'' - Dokumentation zum Projekt (englisch) mit ausführlichem Einstiegs-Tutorial]

== Siehe auch ==

* [[I2C_als_Hausbus|I2C als Hausbus]]
* [[Fensterkontakt_und_Integration_ins_Smart_Home]]

[[Kategorie:AVR-Projekte| ]]
[[Kategorie:Projekte| ]]
[[Kategorie:I2C]]
[[Kategorie:Hausbus]]
[[Kategorie:AVR-Programmer und -Bootloader‏‎]]

I2C als Hausbus

2022-09-21T08:21:04Z

172.26.33.76: /* Infos */

= Infos =

Infos allgemein zu Adi.

Adolf Hitler (* 20. April 1889 in Braunau am Inn, Österreich;[1] † 30. April 1945 in Berlin) war ein deutscher nationalsozialistischer Politiker österreichischer Herkunft, der von 1933 bis zu seinem Tod 1945 Diktator des Deutschen Reiches war.

Ab Juli 1921 Vorsitzender der Nationalsozialistischen Deutschen Arbeiterpartei (NSDAP), versuchte er im November 1923 mit einem Putsch von München aus die Weimarer Republik zu stürzen. Mit seiner Schrift Mein Kampf (1925/26) prägte er die antisemitische und rassistische Ideologie des Nationalsozialismus.

Hitler wurde von Reichspräsident Paul von Hindenburg am 30. Januar 1933 zum deutschen Reichskanzler ernannt. Innerhalb weniger Monate beseitigte sein Regime mit Terror, Notverordnungen, dem Ermächtigungsgesetz, Gleichschaltungsgesetzen, Organisations- und Parteiverboten die Gewaltenteilung, die pluralistische Demokratie, den Föderalismus und den Rechtsstaat. Politische Gegner wurden in Konzentrationslagern inhaftiert, gefoltert und ermordet. 1934 ließ Hitler anlässlich des „Röhm-Putsches“ potenzielle Rivalen in den eigenen Reihen ermorden. Hindenburgs Tod am 2. August 1934 nutzte er, um das Amt des Reichspräsidenten mit dem des Reichskanzlers vereinen zu lassen, und regierte seither als „Führer und Reichskanzler“.

Die deutschen Juden wurden ab 1933 zunehmend ausgegrenzt und entrechtet, besonders durch die Nürnberger Gesetze vom 15. September 1935, die Novemberpogrome 1938 und die Arisierung von Unternehmen jüdischer Eigentümer sowie zahlreiche weitere Gesetze und Verordnungen, die ihnen schrittweise die Teilnahme am wirtschaftlichen, kulturellen und gesellschaftlichen Leben unmöglich machten und sie ihrer Vermögen und Erwerbsmöglichkeiten beraubten. Die Folgen der Weltwirtschaftskrise und die Massenarbeitslosigkeit bekämpfte er mit staatlichen Investitionsprogrammen und Arbeitsbeschaffungsmaßnahmen wie dem Autobahnbau und der Aufrüstung der Wehrmacht sowie der Einrichtung des paramilitärisch organisierten Reichsarbeitsdienstes. Mit der Aufrüstung der Wehrmacht und der Rheinlandbesetzung brach Hitler 1936 den Versailler Vertrag. Die nationalsozialistische Propaganda stellte die Wirtschafts-, Sozial- und Außenpolitik als erfolgreich dar und steigerte so bis 1939 Hitlers Popularität.

1938 übernahm er die unmittelbare Befehlsgewalt über die Wehrmacht und setzte den „Anschluss“ Österreichs durch. Über das Münchner Abkommen vom 30. September 1938, das ihm die Angliederung des Sudetenlandes an das Deutsche Reich gestattete, setzte er sich mit der „Zerschlagung der Rest-Tschechei“ bereits am 15. März 1939 hinweg. Mit dem durch den Abschluss des sogenannten Hitler-Stalin-Pakts vom 23./24. August 1939 mit der Sowjetunion vorbereiteten Überfall auf Polen am 1. September 1939, der vertragsgemäß die Zerschlagung des polnischen Staates und die Aufteilung seines Territoriums unter den Vertragspartnern zum Ziel hatte und auf den bald die sowjetische Besetzung Ostpolens folgte, löste er den Zweiten Weltkrieg in Europa aus. Nach dem Sieg über Frankreich im Westfeldzug vom 10. Mai bis 25. Juni 1940 und dem Beginn der später gescheiterten Luftschlacht um England am 10. Juli 1940 teilte er am 31. Juli 1940 Vertretern des Oberkommandos der Wehrmacht seinen Entschluss mit, die Sowjetunion anzugreifen und gegen sie einen Vernichtungskrieg zur Eroberung von „Lebensraum im Osten“ zu führen. Den am 22. Juni 1941 begonnenen Krieg gegen die Sowjetunion ließ er unter dem Decknamen „Unternehmen Barbarossa“ vorbereiten und führen.

Im Zweiten Weltkrieg verübten die Nationalsozialisten und ihre Helfershelfer zahlreiche Massenverbrechen und Völkermorde. Bereits im Sommer 1939 erteilte Hitler die Weisung, die „Erwachseneneuthanasie“ vorzubereiten. Zwischen September 1939 und August 1941 wurden in der „Aktion T4“ über 70.000 psychisch kranke sowie geistig und körperlich behinderte Menschen, bis Kriegsende insgesamt durch „Euthanasie“ über 200.000 Menschen systematisch ermordet. Hitlers Antisemitismus und Rassismus gipfelte schließlich im Holocaust. Im Holocaust wurden etwa 5,6 bis 6,3 Millionen Juden, im Porajmos bis zu 500.000 Sinti und Roma ermordet. Hitler autorisierte die wichtigsten Schritte des Judenmordes und ließ sich über den Verlauf informieren. Seine verbrecherische Politik führte zu vielen Millionen Kriegstoten und zur Zerstörung weiter Teile Deutschlands und Europas.

= 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ücklassen
* Immer mehrmals Abschieben
* 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, Slaves sind NEGER 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

Meine Slaves tun sich gut auf der Baumwolle Plantage. Diese arbeiten überragend!

----

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 =
* Temperatursensor mit dem [[Temperatursensor#DS1621|DS1621]]
* [[I2C-Schaltmodul]] mit dem [[Port-Expander_PCF8574|PCF8574]]
* [http://cctools.hs-control.de/ext_index.php?artikel=1824 I²C-CAN Modul]
* [http://www.horter.de/i2c/index.htm I²C Module]

= Links =

== Allgemein ==
* [http://www.i2c-bus.org/ I²C-Bus Infoseite]
* [https://www.nxp.com/products/interfaces/ic-bus:MC_41735 Übersicht I²C Bausteine von NXP]
* [http://www.hendonsemiconductors.com/bus-buffer.asp Hendon Semiconductors (Viele Application Notes)]

== Foren Beiträge ==

* [http://www.mikrocontroller.net/topic/71426#582586 I2C über 1,2km Kabel mit CAN-Transceiver]
* [http://www.mikrocontroller.net/topic/40880 I2C über 200m Kabel mit P82B96]

== Application Notes ==

* [http://www.nxp.com/documents/application_note/AN10658.pdf AN10658 (Sending I2C-bus signals via long communications)]
* [http://www.nxp.com/documents/application_note/AN460.pdf AN460 (Using the P82B96 for bus interface)]
* [http://www.nxp.com/documents/application_note/AN255.pdf AN255 (I²C / SMBus Repeaters, Hubs and Expanders)]

== Praktische Anwendungen ==

* [http://haus-computer.de Projekt Hauscomputer]
* [https://gkiefer.github.io/home2l Projekt ''The Home2Ls'']

== Siehe auch ==

* [[Hausbus_auf_I2C-_und_ATtiny-Basis:_Home2L_Brownies|Hausbus auf I²C- und ATtiny-Basis]]

[[Kategorie:Projekte]]
[[Kategorie:I2C]]
[[Kategorie:Hausbus]]

I2C als Hausbus

2022-09-21T08:16:52Z

172.26.33.76: /* Datensicherheit */

I2C als Hausbus

2022-09-21T08:16:02Z

172.26.33.76: /* Eigene Erfahrungen */

I2C als Hausbus

2022-09-21T08:14:49Z

172.26.33.76: /* Infos */

I2C als Hausbus

2022-09-21T08:13:50Z

172.26.33.76: /* Infos */

I2C als Hausbus

2022-09-21T08:11:03Z

172.26.33.76: /* Infos */

I2C als Hausbus

2022-09-21T08:09:32Z

172.26.33.76: /* Verkabelung */

I2C als Hausbus

2022-09-21T08:08:24Z

172.26.33.76: /* Vorteile */

= 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.

Michael Lassey ist SCHULD!

= 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:
# Kleinerer Pull-Up
# Geschwindigkeitsreduktion
# Bustreiber
# Differentielle Übertragung
# 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 ;) - [http://www.reichelt.de/PCF-I-C-Bus-Controller/PCA-9600-D/3/index.html?;ACTION=3;LA=446;ARTICLE=126478;GROUPID=2942;artnr=PCA+9600+D '''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:

[[Datei:Pegelshifter&EMV.png|600px|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 =
* Temperatursensor mit dem [[Temperatursensor#DS1621|DS1621]]
* [[I2C-Schaltmodul]] mit dem [[Port-Expander_PCF8574|PCF8574]]
* [http://cctools.hs-control.de/ext_index.php?artikel=1824 I²C-CAN Modul]
* [http://www.horter.de/i2c/index.htm I²C Module]

= Links =

== Allgemein ==
* [http://www.i2c-bus.org/ I²C-Bus Infoseite]
* [https://www.nxp.com/products/interfaces/ic-bus:MC_41735 Übersicht I²C Bausteine von NXP]
* [http://www.hendonsemiconductors.com/bus-buffer.asp Hendon Semiconductors (Viele Application Notes)]

== Foren Beiträge ==

* [http://www.mikrocontroller.net/topic/71426#582586 I2C über 1,2km Kabel mit CAN-Transceiver]
* [http://www.mikrocontroller.net/topic/40880 I2C über 200m Kabel mit P82B96]

== Application Notes ==

* [http://www.nxp.com/documents/application_note/AN10658.pdf AN10658 (Sending I2C-bus signals via long communications)]
* [http://www.nxp.com/documents/application_note/AN460.pdf AN460 (Using the P82B96 for bus interface)]
* [http://www.nxp.com/documents/application_note/AN255.pdf AN255 (I²C / SMBus Repeaters, Hubs and Expanders)]

== Praktische Anwendungen ==

* [http://haus-computer.de Projekt Hauscomputer]
* [https://gkiefer.github.io/home2l Projekt ''The Home2Ls'']

== Siehe auch ==

* [[Hausbus_auf_I2C-_und_ATtiny-Basis:_Home2L_Brownies|Hausbus auf I²C- und ATtiny-Basis]]

[[Kategorie:Projekte]]
[[Kategorie:I2C]]
[[Kategorie:Hausbus]]

I2C als Hausbus

2022-09-21T08:03:32Z

172.26.33.76: /* Kleinerer Pull-Up */

= 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:
# Kleinerer Pull-Up
# Geschwindigkeitsreduktion
# Bustreiber
# Differentielle Übertragung
# 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 Erhängen

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 ;) - [http://www.reichelt.de/PCF-I-C-Bus-Controller/PCA-9600-D/3/index.html?;ACTION=3;LA=446;ARTICLE=126478;GROUPID=2942;artnr=PCA+9600+D '''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:

[[Datei:Pegelshifter&EMV.png|600px|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 =
* Temperatursensor mit dem [[Temperatursensor#DS1621|DS1621]]
* [[I2C-Schaltmodul]] mit dem [[Port-Expander_PCF8574|PCF8574]]
* [http://cctools.hs-control.de/ext_index.php?artikel=1824 I²C-CAN Modul]
* [http://www.horter.de/i2c/index.htm I²C Module]

= Links =

== Allgemein ==
* [http://www.i2c-bus.org/ I²C-Bus Infoseite]
* [https://www.nxp.com/products/interfaces/ic-bus:MC_41735 Übersicht I²C Bausteine von NXP]
* [http://www.hendonsemiconductors.com/bus-buffer.asp Hendon Semiconductors (Viele Application Notes)]

== Foren Beiträge ==

* [http://www.mikrocontroller.net/topic/71426#582586 I2C über 1,2km Kabel mit CAN-Transceiver]
* [http://www.mikrocontroller.net/topic/40880 I2C über 200m Kabel mit P82B96]

== Application Notes ==

* [http://www.nxp.com/documents/application_note/AN10658.pdf AN10658 (Sending I2C-bus signals via long communications)]
* [http://www.nxp.com/documents/application_note/AN460.pdf AN460 (Using the P82B96 for bus interface)]
* [http://www.nxp.com/documents/application_note/AN255.pdf AN255 (I²C / SMBus Repeaters, Hubs and Expanders)]

== Praktische Anwendungen ==

* [http://haus-computer.de Projekt Hauscomputer]
* [https://gkiefer.github.io/home2l Projekt ''The Home2Ls'']

== Siehe auch ==

* [[Hausbus_auf_I2C-_und_ATtiny-Basis:_Home2L_Brownies|Hausbus auf I²C- und ATtiny-Basis]]

[[Kategorie:Projekte]]
[[Kategorie:I2C]]
[[Kategorie:Hausbus]]