I2C to CAN to I2C: dritter logischer Pegel auf I2C?

[Sebastian S. (dsebastian)]

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!

[Wolfgang (Gast)]

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

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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?

[Peter D. (peda)]

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.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Peter D. schrieb:
> Der P82B96 braucht ein höheres Low, um die Richtung zu erkennen.
Die 800mV stehen da genau so im Datenblatt... ;-)

[Sebastian S. (dsebastian)]

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

[Jens (Gast)]

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.

[Sebastian S. (dsebastian)]

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 
... ;-)

[Christian B. (luckyfu)]

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

[Sebastian S. (dsebastian)]

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!

[Christian B. (luckyfu)]

Naja, der lässt sich eigentlich recht gut mit Heißluft löten. Da reicht 
schon eine Station für um die 60-80€.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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.