Forum: Mikrocontroller und Digitale Elektronik IIC Bus trennen

Suche 'mal nach dem P82B96 (Philips IIC-Busextender) und sieh Dir das
Beispiel im Datenblatt bzw. App.Notes an.

Hallo

Nicht schlecht.
Jetzt muß ich nur noch eine Quelle auftreiben, wo er billiger als 4,40
Euro ist.
Hat jemand eine Idee.
Es geht um 20 Stück.

Gruß

Wenn Du die Teile beruflich brauchst, zahl den Preis und suche nicht
'stundenlang' weiter.

Es gäbe noch die Möglichkeit, den Master mit vier Portpins zu
realisieren und dort galvanisch zu trennen. Pro SDA und SCL werden je
zwei verwendet, indem der eine nur Ausgang und der andere nur Eingang
ist. Ist ein Eingang auf '0', weiß der Master, ob er selber die
Ursache dafür ist, oder der Slave aktiv ist.
Aber wie gesagt, Zeit ist Geld: löse Dein Problem damit, wovon Du am
meisten hast. :-)

Galvanische Trennung für I2C geht auch mit Optokopplern, die Elektor
hatte mal einen Vorschlag. Ich hänge die .pdf mal dran.

Gruß

Sehr interessante Schaltung, muß ich auch mal nachbauen.
Eine Schaltung, die ich schon getestet und für gut befunden habe, ist
die folgende:
http://www.ping.be/~ping0751/i2cfaq/i2cqa3.htm

Wenn es nur um die Verstärkung, nicht aber die galvanische Trennung
geht, dann kann man einen Booster mit einem Operationsverstärker, einem
Transistor und einigen Widerständen aufbauen. Eleganter, aber teurer,
sind natürlich die o.g. Booster-Chips.

Möchte ja nicht der Spielverderber sein, aber die Elektorschaltung ist
die absolute Bastellösung.
Jeder, der mit Optokopplern mit Darlingtonausgang Erfahrungen gesammelt
hat, weiß, daß das IIc-Bus Timing damit (3k9 Pullup) nicht eingehalten
werden kann.
Wenn's funktioniert: gut; wenn's sporadische Aussetzer gibt (z.B. Bus
bleibt hängen), auch gut. Das kann man von dieser Schaltung schließlich
erwarten.

Timingprobleme über Optokoppler habe ich gerade hinter mir! Und zwar bei
bescheidenen 128 kbit/s!

Da lohnt es sich, die Datenblätter der Optokoppler ganz genau zu lesen,
bevor man sich entscheidet. Der von einem Kollegen gewählte hatte zwar
eine akzeptable Nennverzögerung, aber eine beeindruckende Streuung bis
zum Maxwert von stolzen 6 µs! Bei den Prototypen ist natürlich nie
etwas aufgefallen, aber in der Serie schlagen die Ausreißer dann zu
...

Und wenn man einen geeigneten Optokoppler gefunden hat (Schnell,
sparsam und günstig: wähle zwei davon), dann über die Widerstände das
Timing optimieren: beim Clock-Optokoppler die Verzögerung der fallenden
Flanke (ruhig auf Kosten der steigenden Flanke) runterdrücken, während
beim Lesen in der anderen Richtung beide Flanken gleich schnell sein
sollten.

Ähm - sorry - aber 128 kBit/s sind alles andere als bescheiden... Zwar
wurde der I²C-Bus auf 400 kHz aufgeblasen (es gibt wohl auch eine noch
schnellere Spezifikation im Mbit-Bereich), aber man sollte doch mal
sehen, wozu der I²C-Bus eigentlich entwickelt wurde. In meinen
Anwendungen (Ein- und Ausgabe) komme ich selten auf mehr als 20
kBit/s.
Die galvanische Trennung vom I²C-Bus ist auch nicht trivial - gerade
wegen der bidirektionalen Signale. Aber die von mir oben verlinkte
Schaltung habe ich bis 10kHz getestet (mit ordinären 814) und da liefs
prima. Die Schaltung bleibt auch nicht hängen. Bei der
Elektor-Schaltung kann ichs nicht sagen. Wesentlich mehr als 10-20 kHz
würde ich auch nicht erwarten, da gibts dann bessere Lösungen als den
I²C. Der I²C wird ja teilweise vergewaltigt, und dann wird sich
gewundert, daß es nicht funktioniert.
@Michael: Hast Du eine bessere Lösung?

@thkais:

Die Vorgaben für Anstiegszeit sind <1µs und Abstieg <0,3µs! Wenn's mit
langsameren Flanken funktioniert, gut; muß aber nicht, insbesondere wenn
man die Hardware IIC-Schnittstellen von µCs verwendet.

Als erstes würde ich nach einer App.Note von Philips suchen; die haben
IIC erfunden.
Ein schnellerer Optopokkler wäre der PC900, noch schneller 6N137 o.ä..

Optopokkler: völlig neuartige Bauteile :-)

Neee, daß es schnellere Optokoppler gibt, ist mir schon bekannt. Es geht
um die prinzipielle Lösung des Problems: I²C galvanisch entkoppeln.
Da geistern einige Schaltungen im Netz herum, aber eben auch sehr viele
fehlerhafte, die dann z.B. auch das berüchtigte "hängen" verursachen,
wenn z.B. ein Slave den CLK runterzieht.

"Da geistern einige Schaltungen im Netz herum,..."

Das zeigt ja, daß die Sache problematisch ist. Wie gesagt, Applikation
von Philips suchen und verwenden; 'die' müssen wissen, wie es geht.
Ggf. müssen auch andere Bausteine verwendet werden.

Auf der anderen Seite müßte man prüfen, ob der IIC-Bus der Anwendung
auch gerecht wird. Als Inter-IC-Bus ist er entwickelt worden, um auf
Leiterplatten bzw. Geräteebene ICs untereinander zu verbinden.
Anwendungen, die längere Leitungen oder galv. Trennung erfordern, waren
nicht Entwicklungsziel, sondern sind nachträglich 'aufgesetzt'
worden.

Da Wolf, wie er oben schreibt, nur Singlemaster-Betrieb benötigt,
bieten sich andere Verfahren an, bei denen die galv. Trennung keine
Probleme macht. Ich persönlich nehme gerne UARTs mit
Multiprozessorprotokoll. Selbst, wenn das anzusteuernde Slave-IC nur
mit IIC läuft, würde ein ('S oder Tiny)2313 zur Protokollanpassung auf
Slaveseite den Hardwareaufwand nicht nennenswert steigern. Mit AVR und
UART kann man auch einige 100kbit Übertragungsrate hinbekommen, wenn es
überhaupt gefordert ist.
Letztlich kennen wir das Problem von Wolf nicht, um Alternativen
anzubieten, die er vielleicht auch garnicht braucht.

Wenn man sich den P82B96 genauer ansieht, sieht man auch die
Feinheiten, die Philips beachtet. Der Ausgang '0'-Pegel ist typ.
750mV, der Eingangs '0'-Pegel dagegen typ. 650mV. Es sind eben nicht
irgendetwas um 0,x Volt !
Das mit diskreter Hardware nachzuahmen ist aufwendig und m.E. auch
unsinnig, gerade auch bei o.g. Stückzahl und Preis.