Hallo zusammen, in der Vergangenheit eher stiller Mitleser, möchte ich nun doch eine Frage zum I2C Bus stellen. Ich baue mir eine Lichtsteuerung auf und verwende hierfür einen Arduino Nano Every in der Bedieneinheit und einen Arduino UNO in der Steuereinheit für die LEDs. Da beide Einheiten für einen I2C-Bus räumlich viel zu weit voneinander entfernt sind, setze ich eine kleine Elektronik ein, die mir den physical Layer des I2C auf CAN übersetzt; d.h. das Protokoll ist weiterhin I2C. Die Elektronik folgt dem Prinzip, wie es hier https://www.ti.com/tool/TIDA-060013 dargestellt wird. Auf der Website ist der Schaltplan verlinkt; auch ich verwende den buffer P82B96 (https://www.nxp.com/docs/en/data-sheet/P82B96.pdf). Anstelle der TI CAN Tranceiver verwende ich den MCP2561 (http://ww1.microchip.com/downloads/en/devicedoc/20005167c.pdf). Das ganze sieht dann wie beigefügt aus (Ausschnitt aus der Gesamtschaltung, I2CtoCAN.JPG), wobei im Bild natürlich nur ein Teil zu sehen, da das ganze nochmal auf der anderen Seite der CAN-Verbindung aufgebaut sein muss. So weit, so schön. Beim Test habe ich nun einen dritten(?) logischen Pegel entdeckt, mit dem ich schlicht nichts anzufangen weiß. Dazu drei Bilder mit folgenden Signalen: Master: SCL (gelb) und SDA (grün), kurz SCL_M und SDA_M Slave: SCL (blau) und SDA (lila), kurz SCL_S und SDA_S SDS00047.png: Der Master sendet ein Byte zum Slave, deutlich ist auf SDA_M und SDA_S ein dritter Pegel von etwa 0.8V zu erkennen. SDS00048.png: Der Master requested vom Slave das gerade gesendete Byte wieder zurück zu senden. Widerum ist der dritte Pegel von etwa 0.8V zu erkennen. SDS00046.png: Messung des dritten Pegels. Auch die Signale SCL_M und SCL_S zeigen diesen dritten Pegel. Dieser dritte Pegel wird erst durch den Anschluss der I2C zu CAN Umsetzung sichtbar, d.h. bei entferntem P82B96 auf der Master-Seite sehen die I2C-Signale aus wie sie aussehen sollen: zwei logische Pegel bzw. zwei Spannungsniveaus. Kann mir jemand im Verständnis weiterhelfen? Muss das so sein? Und falls ja, ist dieser 0.8V-Pegel da wo er hingehört? Ich habe zwar den Eindruck habe, dass hinter den gemessenen Verläufen (--> SDS00047 und SDS00048) eine gewisse Systematik liegt, aber das kann ja trotzdem alles falsch sein ... Ich danke für erhellende Worte!
Sebastian S. schrieb: > Auch die Signale SCL_M und SCL_S zeigen diesen dritten Pegel. Das werden wohl unterschiedliche Low-Pegel sein, einmal vom Master und einmal vom Slave
Sebastian S. schrieb: > So weit, so schön. Ich steige bei dem vielen Text nicht durch. Das Kommunikationsmittel unter Elektronikern sind Schaltpläne. Zeig doch mal deinen Schaltplan. So einen, wo man erkennt, wie du da welche Dinger miteinander verbunden und versorgt hast. Wolfgang schrieb: > Das werden wohl unterschiedliche Low-Pegel sein, einmal vom Master und > einmal vom Slave Masse nur übers E-Werk verbunden?
:
Bearbeitet durch Moderator
Sebastian S. schrieb: > Der Master sendet ein Byte zum Slave, deutlich ist auf SDA_M und SDA_S > ein dritter Pegel von etwa 0.8V zu erkennen. Der P82B96 braucht ein höheres Low, um die Richtung zu erkennen. Ansonsten würde nach einmal Low, der Bus auf ewig Low bleiben, da Low dominant ist. Ein Low am TXD des CAN Transceivers ergibt automatisch ein Low an RXD.
:
Bearbeitet durch User
Peter D. schrieb: > Der P82B96 braucht ein höheres Low, um die Richtung zu erkennen. Die 800mV stehen da genau so im Datenblatt... ;-)
Lothar M. schrieb: > Masse nur übers E-Werk verbunden? Nein. Masse läuft mit den CAN-Bus Signalen mit (wie im Schaltplan am RJ45-Stecker sichtbar) und damit sind Master und Slave masse-seitig miteinander verbunden. Peter D. schrieb: > Der P82B96 braucht ein höheres Low, um die Richtung zu erkennen. > Ansonsten würde nach einmal Low, der Bus auf ewig Low bleiben, da Low > dominant ist. > Ein Low am TXD des CAN Transceivers ergibt automatisch ein Low an RXD. In die Richtung ging meine Vermutung, also das dieses zweite low eher mit der Richtung der Daten zu tun hat (Master --> Slave oder eben umgekehrt). Nur konnte ich nirgends Infos dazu finden. Lothar M. schrieb: > Peter D. schrieb: >> Der P82B96 braucht ein höheres Low, um die Richtung zu erkennen. > Die 800mV stehen da genau so im Datenblatt... ;-) Äh, ja, stimmt, da steht was von logischen Pegeln für "output logic LOW level" und "Input logic switching threshold voltages". Ich habe die allerdings eher als Schwellwerte verstanden, weniger dass die tatsächlich aktiv(!) so eingestellt werden ...
Sebastian S. schrieb: > Da beide Einheiten für einen I2C-Bus räumlich viel zu weit voneinander > entfernt sind, setze ich eine kleine Elektronik ein, die mir den > physical Layer des I2C auf CAN übersetzt; d.h. das Protokoll ist > weiterhin I2C. Warum so ein Aufwand für eine Lösung, welche so nicht funktioniert? Warum soll es CAN sein? Sind die Leitungswege zu lang? Wie viele Slaves gibt es? Als Option könnte man auch RS-232 oder RS-485 nehmen. Ich habe eine ähnliche Steuerung auch über CAN realisiert. Nur bin ich einfach mit der UART des µC auf CAN-Treiber (MCP2551) gegangen und habe mir ein simples Protokoll mit Kollisionserkennung geschrieben. Die genormten CAN-TRX haben halt den Vorteil, dass ich mich um den "physical layer" nicht kümmern muss und ohne Probleme den Bus verlängern kann um zusätzliche Komponenten dran zu hängen. Diese Lösung läuft in der störungsverseuchten Umgebung eines Feuerwehrhauses seit über 10 Jahren absolut problemlos.
Jens schrieb: > Warum so ein Aufwand für eine Lösung, welche so nicht funktioniert? Oh. Vielleicht habe ich das nicht deutlich genug gemacht: es funktioniert. Nur eben mit diesen zwei low-Pegeln, die mir völlig fremd waren. Jens schrieb: > Warum soll es CAN sein? Sind die Leitungswege zu lang? Wie viele Slaves > gibt es? Als Option könnte man auch RS-232 oder RS-485 nehmen. 1) Weil ich I2C von der Uni kenne 2) Weil ich CAN von der Arbeit kenne 3) Zwei Slaves, vielleicht noch ein dritter. Der dann aber eine I2C-Schnittstelle hat. 4) RS232 und RS485 kenne ich gar nicht Der dritte Slave (I2C) bräuchte für die UART/RSxxx-Lösung eine µP; und eben ein Protokoll (was ich nicht habe und auch nicht "erfinden" möchte). Mit der oben gezeigten Schaltung geht alles in HW; ist also eine Lösung für µP-lose Anbindung eines I2C-Peripheriebausteines für größere Entfernungen. Und LAN-Kabel und RJ45-Stecker reichen auch. Daher ... ;-)
:
Bearbeitet durch User
Warum überhaupt so kompliziert? Schau dir mal den LT3960 an. Der macht eigentlich nichts anderes aber in einem IC. I2C rein, physischer CAN Layer raus. Auf der Gegenseite wieder so ein Käfer zum decodieren und fertig. Was heute auch nicht ganz unwichtig ist: Der ist beschaffbar aktuell...
Den LT3960 kannte ich nicht. Sehr schönes Teil! Doch, oje, etwas ausserhalb meiner Lötfähigkeiten und Infrastruktur. Diese Pad da auf der Unterseite bekomme ich leider nicht hin, bzw., um ehrlich zu sein, ich fange nach langer Elektronik-Abstinenz erst wieder an und da muss ich das mit SMD überhaupt erst noch üben ... und dann gleich ein MSSOP, oje, ... dennoch, danke für den Tipp!
Naja, der lässt sich eigentlich recht gut mit Heißluft löten. Da reicht schon eine Station für um die 60-80€.
Sebastian S. schrieb: > Doch, oje, etwas ausserhalb meiner Lötfähigkeiten und Infrastruktur. Das Gehäuse hat ja sogar noch Pins. Christian B. schrieb: > Naja, der lässt sich eigentlich recht gut mit Heißluft löten. Das braucht es gar nicht: wenn man zum Thermal Pad hin eine größere Durchkontaktierung setzt, dann lötet man das Ding einfach von der anderen Seite "durch die Platine" hindurch.
Bitte 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.