Hallo Leute, Ich hatte gehofft das Problem selbst zu lösen aber nundenn, erst mal wie ist das ganze überhaupt entstanden. Ich habe hier Zuhause einen selbst aufgebauten Hausbus auf Basis von TWI/I2C Der Bus wird mit 100kHz betrieben, als Kabel dienen herkömmliche Patchkabel, über die auch die Stromversorgung der Geräte läuft (bei "Kleinverbrauchern" wie Temperatursensoren, 5V maximal 50mA). Geräte die mehr Strom benötigen, z.B. hier mein Grafikdisplay erhalten ein externes Netzteil. Und hier fängt die Problematik an. Da ich das Display nicht immer eingeschaltet habe ziehe ich das Netzteil. Das Problem dabei ist, das der AVR (ATMega32) dann die TWI-Pins auf Masse zieht, sobald keine Betriebsspannung anliegt, und damit den Bus blockiert. Um das Problem zu umgehen habe ich mich entschieden einen PCA 9515 als Zwischenglied zu nutzen. Dieser wird über den Bus mit Strom versorgt. Der Enable-Eingang ist High-Aktiv und bekommt das Signal von der Betriebsspannung des Mega32. Damit wird es möglich das Gerät von der Betriebsspannung zu trennen und der PCA wird hochohmig. Der Bus wird nicht mehr blockiert. Der PCA funktioniert aber leider nicht wie gewünscht. Lasse ich den PCA raus, funktioniert die Übertragung fehlerfrei, auch wenn über 50kByte am Stück übertragen werden. Die Probleme sind unabhängig vom Takt und der Kabellänge. Wenn allerdings gar kein Gerät am Bus betrieben wird, tritt das Problem nicht auf. Ist ein Gerät unmittelbar parallel dazu am Bus, also nicht mehr als 2m Kabellänge entfernt gibt es ebenfalls keine Probleme. An der Betriebsspannung/Signalverlauf kann ich keine erkennbaren Unterschiede messen, auch nicht im 10mV Bereich. Anbei ein paar Fotos vom Oszilloskop mit dem Signal. Es macht den Eindruck als wenn das IC mit fortschreitender Übertragung "langsamer" wird, und die Geräteseite nicht mehr richtig auf Masse ziehen kann. Ich habe bereits mehrere ICs getestet, alle zeigen identisches Verhalten. Auch habe ich die Betriebsspannung des PCA9515 auf 3,3V abgesenkt, keine Änderung. Die Schaltung die ich hier habe entspricht dem aus dem Datenblatt. Nur das der Bus (linke Seite) mit 5V statt 3,3V läuft, aber auch mit 3,3V gibt's diese Probleme. Ich hoffe das irgendjemand Vorschläge zur Problemlösung beitragen kann.
Angehängte Dateien:
Die Signalanstiegszeit bzw. Flankensteilheit beim oberen Signal ist ziemlich langsam. Versuch an der Stelle mal einen kleineren Widerstand (weniger Ohm). Eine etwas detailliertere Beschreibung der Oszi Bilder wäre noch hilfreich. Gruß Sebastian
2V/div, wie viel Zeit pro Div. vergeht ist im Dateinamen. Das obige Signal ist jeweils immer das, was vom Bus kommt. Das untere auf der Geräteseite "nach" dem PCA Ich habe als Pull-Up Widerstände für den Bus bereits 1kOhm in Verwendung. Ich Versuche später mal den Widerstand nochmals zu halbieren auf 500 Ohm. Wäre das schlechte Signal (enorme anstiegszeit) die Ursache, dann müsste es ja doch über die gesamte Übertragung Probleme geben, und nicht nur für die 2. Hälfte?
Ich würde dennoch auf das schlechte Signal mit den miserablen Anstiegszeiten tippen. Ich empfehle erst mal dort den Fehler zu suchen. Was hängt denn noch alles an dem BUS? Oder häng einfach mal alles ab bis auf die pull-ups und schau dir das Signal vom µC dann nochmals an. Signalpegel von 3.8V sind hier definitiv nicht wünschenswert. Auch wenn sie die spec der Teile gerade noch so erfüllen mögen. Im Datenblatt des PCA steht übrigens, dass der mit 3.3V versorgt werden möchte. Hat zusätzlich noch overvoltage tolerante Pins die 5V verkraften.
Hallo, die schlechten Anstiegszeiten werden durch die Gesamtkabellänge von etwa 50m verursacht. Der Bus hat eine Baumstruktur, An Geräte sind zur zeit angeschlossen: 1x Grafikdisplay (Mega 32, externes Netzteil) 1x Textdisplay (Mega8, versorgung via Bus) 5x Temperatursensoren (Tiny24, via bus) 1x 3fach Schalter (Tiny 24, via bus) Zwischendurch zum testen einiger neuer Funktionen am Root-Controller (Mega8) ein Serielles 16kBit Eeprom, i2c kompatibel (24C16). Weitere Geräte sollen folgen, entsprechend kommt noch mal höchstens 15m Kabel dazu. 100kHz ist vermutlich auch etwas extrem für diese große Kabellänge. Aber bei 50kHz gibt es die gleichen Probleme. Und weiter runter mit dem Takt möchte ich ungern, da sonst die Ansteuerung des Grafikdisplays unerträglich langsam wird. Ich habe auch schon mal 100m Kabel an dem Bus gehabt, dennoch funktionierte alles Problemlos (um die maximale Frequenz auszuloten, wo der noch funktioniert. Da fingen die Probleme bei etwa 200kHz an, das Signal war aber auch deutlich schlechter als wie es jetzt ist.) Alle Geräte funktionieren einwandfrei. Nur der PCA macht seine Probleme. Oder gibt es eine andere Möglichkeit das Problem (Twi Pins auf Masse wenn Betriebsspannung des AVR fehlt) zu umgehen. Nachtrag: Ich hab nun eine gesamtkabellänge von etwa einem Meter an dem Controller, das Signal ist nun deutlich besser (Anstiegszeiten kann ich mit dem alten schinken von Scope nicht mehr sauber messen.) der PCA scheint jetzt fehlerfrei zu funktionieren, Die Betriebsspannung des PCA habe ich mittels Dioden auf ca. 3,5V senken können. Aber das hilft mir leider wenig.
Okay das sind doch schon ein paar mehr Informationen. Leider ist I2C nicht für so lange Leitungen ausgelegt. Ist eigentlich mehr als BUS Verbindung innerhalb einer Platine gedacht oder aber über sehr kurze Strecken. Es gibt schließlich begrenzende Kapazitäten die der BUS verträgt. Beim PCA z.B. stehen 400pF als maximal zugelassene Kapazität. Da dürftest du mit deinem langen Kabel schon drüber sein. Außerdem sieht dein Signal mit den schlechten Anstiegszeiten aus wie die Ladekurve eines parasitären Kondensators, der von deinem langen Kabel dargestellt wird. Ein paar meter würde ich dem ganzen zugestehen, aber 50 ist nach meinem Geschmack definitiv zu viel. Irgendwo hab ich auch mal gelesen, dass man die Takt, Daten und Masseleitungen verdrillen sollte. So viel mal dazu. Würde dir da zu einem RS485/422 BUS raten. Ist bei weitem nicht so empfindlich und sollte die Kabellänge auch können. Alternativ könnte man mit einer Richtungsumschaltung den I2C BUS auf 485er level bringen.
Eine einfache Möglichkeit SCL und SDA vom Atmega zu trennen, falls dieser keine Versorgung hat, wäre ein bidirektionaler Buffer mit enable Pin. Aus dem Kopf raus würde ich mal einen TXB0102 vorschlagen. Ich glaube der kann sowas. Ist allerdings eher als level Translator zwischen unterschiedlichen Spannungen gedacht und geht auf der einen Seite nur bis 3.3V
Noch eine letzte Wortmeldung von mir heute. Lies dir den verlinkten Artikel durch. Da sind ähnliche Vorschläge drin wie ich sie schon aufgeführt habe. http://www.mikrocontroller.net/articles/I2C_als_Hausbus Dennoch würde ich an deiner Stelle direkt auf 485/422 umsteigen wenn du die lange Leitung unbedingt brauchst.
der PCA macht auch schon bei etwa 50cm kabellänge schlapp, vor allem bei längeren Übertragungen. Das ganze funktioniert zuverlässig, wenn der PCA nicht drin ist. So habe ich das jetzt und werde es vorerst so lassen. Muss ich halt beides Trennen, Busleitung und Netzstecker. Jetzt alle Geräte auf eine andere Technik umzustellen wäre mir viel zu viel Aufwand. zumal ich u.A. auch fertige Platinen habe. Mir ist klar das der I2C/TWI-Bus nicht für solche extremen Längen gedacht ist. Leider war es für mich die einzigste logische Wahl, als ich mit dem System angefangen habe. Der Aufwand für ein eigenes Übertragungsprotokoll wäre mir auch zu viel Aufwand.
Kann ich verstehen. Aber solltest du wieder was "längeres" vorhaben, dann lieber gleich 485/422. Kannst aber immer noch den I2C BUS mitsamt Protokoll auf 485/422 Pegel anheben das dann auf das lange Kabel geben und am Zielpunkt wieder zurück wandeln. Ein 485er Baustein wäre z.B. LTC2850. Kannst dir bei interesse ja mal ansehen.
Angehängte Dateien:
-
Screen20120815-180457.jpg
130 KB
Im Patchkabel habe ich Platz für 8 Leitungen, RS485 ist eine interessante Sache, benötige für SDA und SCL dann insgeamt 4 Leitungen wenn ich mich jetzt nicht vertan habe. Zur Zeit ist die hälfte aller Leitungen bei mir auf Masse, damit bei höherem Stromverbrauch das Massepotenzial nicht zu sehr angehoben wird (und somit "0"-Bits verloren gehen. Aber dennoch bin ich etwas verblüfft, bei welchen widrigen Umständen eine halbwegs zuverlässige Übertragung noch möglich ist... Falls ich irgendwann ein neues System aufbauen sollte, dann wird es wahrscheinlich beim i2c Bus bleiben, aber Daten und Takt über 485 "getunnelt". Wie in dem Artikel der von enan erwähnt wird. Trotzdem möchte ich mich an dieser Stelle für die Antworten bedanken. Nachtrag: Im Anhang befindet sich ein Screenshot der Weboberfläche für das System.
Der i2c-Bus ist entwickelt worden um in einem Gerät Daten ohne viel Kabel zu verteilen. Für längere Wege RS485 benutzen. Man muß sich nur das richtige Protokoll aussuchen. Es muß ja nicht gleich ein CAN-Bus sein. mfg C.Kaak
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.