ich suche nach einer Lösung für eine galvanische Trennung des I2C Busses.
Dazu habe ich bisher mehrere Schaltungsvorschläge finden können, die zum
Teil recht interessant sind, wie
http://www.esacademy.com/faq/i2c/q_and_a/faq/i2cqa3.htm
die aber wohl recht langsam ist.
Dann 2 Schaltungen in Elektro Sommerheften, davon haelt sich eine bei weitem
nicht an die Specs, die andere ist ein reines Bauteile-Grab.
Philips selbst empfiehlt eine sehr kompakte Loesung basierend auf dem
P82B96, diesen habe ich bisher jedoch nur bei einem Versand in DE für fast
5 EUR finden können, was ich fuer zu teuer halte.
Weder bei Buerklin, Reichelt, Schuricht, Schukat und Farnell konnte ich das
Teil entdecken. Gibt es dazu vielleicht eine second source?
Oder gibt es eine einfache Loesung, die galvanische Trennung so
hinzubekommen, dass sie auf der Busseite die Spezifikationen erfüllt, aus
Standardbauteilen besteht und min 100kHz schafft?
(zum Controller hin duerften die Spezifikationen ruhig grosszuegig ausgelegt
werden)
Danke
Daniel
--
.~. Daniel Schramm Phone: +49 231 6108112 Mail:daniel....@gmx.de
/V\ Bruehlweg 36 Mobile:+49 178 8839848 ICQ: 35816985
// \\ 44379 Dortmund Fax: +49 231 96989961 WWW: pinguin.sauerland.de
/( )\ Germany
^`~'^
> ich suche nach einer Lösung für eine galvanische Trennung des I2C Busses.
> Dazu habe ich bisher mehrere Schaltungsvorschläge finden können, die zum
> Teil recht interessant sind, wie
> http://www.esacademy.com/faq/i2c/q_and_a/faq/i2cqa3.htm
> die aber wohl recht langsam ist.
.... Problem ist, ich weiß jetzt nicht genau, was du trennen willst.
Einen Schaltplan für eine Galvanische Trennung eines COM-Ports vom
PC kann ich dir allerdings mailen oder hier als Link reinsetzen, wenn
du möchtest. Die Lösung geht über Optokoppler und bis zu 9600 Baud.
Diese Schaltung habe ich hier selber kürzlich auf einem Steckbrett zum
Laufen gebracht, daher könnte ich dafür garantieren, dass sie gut
funktioniert ;)
lg,
Markus - http://gronoworx.dyndns.org
> ich suche nach einer Lösung für eine galvanische Trennung
> des I2C Busses.
> ...
Das Problem liegt in der bidirektionalität beider Signale,
und daß die außerdem noch Open-Collector sein müssen.
Die sauberste Lösung dürfte in der Tat der Philips-Baustein
sein. "Bessere" Schaltungen sind mir auch noch nicht
untergekommen.
...was vielleicht daran liegt, das I2C eigentlich nur ein
Board-Level Interface ist, wo normalerweise keine Trennung
gebraucht wird.
Also erlaube die Frage, warum mußt Du I2C galvanisch trennen?
Und: ginge nicht auch eine andere (ggf. nicht standardisierte)
Schnittstelle, für die die Trennung leichter realisierbar ist?
Was befindet sich denn auf den beiden Seiten am I2C-Bus?
--
Dipl.-Ing. Tilmann Reh
Autometer GmbH Siegen - Elektronik nach Maß.
http://www.autometer.de
>> ich suche nach einer Lösung für eine galvanische Trennung des
>> I2C Busses.
> ...
>
> .... Problem ist, ich weiß jetzt nicht genau, was du trennen willst.
Hat er doch exakt geschrieben.
> Einen Schaltplan für eine Galvanische Trennung eines COM-Ports vom
> PC kann ich dir allerdings mailen oder hier als Link reinsetzen, wenn
> du möchtest. Die Lösung geht über Optokoppler und bis zu 9600 Baud.
>
> Diese Schaltung habe ich hier selber kürzlich auf einem Steckbrett zum
> Laufen gebracht, daher könnte ich dafür garantieren, dass sie gut
> funktioniert ;)
Das wird ihm kaum helfen: lies mal nach, was I2C ist.
> > .... Problem ist, ich weiß jetzt nicht genau, was du trennen willst.
> Hat er doch exakt geschrieben.
> Das wird ihm kaum helfen: lies mal nach, was I2C ist.
ok
> Philips selbst empfiehlt eine sehr kompakte Loesung basierend auf dem
> P82B96, diesen habe ich bisher jedoch nur bei einem Versand in DE für fast
> 5 EUR finden können, was ich fuer zu teuer halte.
> Weder bei Buerklin, Reichelt, Schuricht, Schukat und Farnell konnte ich das
> Teil entdecken.
Spoerle hat den P82B96 in SO-8 auf Lager.
Gruß Dieter
> Daniel Schramm schrieb:
>
>> ich suche nach einer Lösung für eine galvanische Trennung
>> des I2C Busses.
>> ...
>
> Das Problem liegt in der bidirektionalität beider Signale,
> und daß die außerdem noch Open-Collector sein müssen.
das ist schon klar.
> Die sauberste Lösung dürfte in der Tat der Philips-Baustein
> sein. "Bessere" Schaltungen sind mir auch noch nicht
> untergekommen.
Gibt es sowas nicht auch von anderen Herstellern, Phillips ist doch nicht
der einzige Hersteller für I2C-Komponenten. Die Suche ist nur etwas
umstaendlich, wenn jeder Hersteller den Bus anders bezeichnet.
>> Die sauberste Lösung dürfte in der Tat der Philips-Baustein
>> sein. "Bessere" Schaltungen sind mir auch noch nicht
>> untergekommen.
>
> Gibt es sowas nicht auch von anderen Herstellern, Philips ist doch nicht
> der einzige Hersteller für I2C-Komponenten. Die Suche ist nur etwas
> umstaendlich, wenn jeder Hersteller den Bus anders bezeichnet.
Philips ist aber der Erfinder von I2C, und auch der
Lizenzgeber für die anderen Halbleiter-Hersteller.
Ich gehe mal davon aus, daß (auch aufgrund des eigentlichen
Verwendungszweckes von I2C) der Bedarf an solchen Sonderchips
so gering ist, daß kein anderer Hersteller einsteigt.
Philips dagegen muß, als "Eigentümer" der Methode, eher auch
solche Chips bereitstellen - selbst wenn es sich vielleicht
nicht immer rechnet.
MfG JRD
> Das Problem liegt in der bidirektionalität beider Signale,
Es gibt da noch div. andere Probleme. I2C an sich ist ja
schon nicht ganz unkritisch, insb. was Kapazitäten und
Serienwiderstände betrifft.
> Die sauberste Lösung dürfte in der Tat der Philips-Baustein
> sein. "Bessere" Schaltungen sind mir auch noch nicht
> untergekommen.
Es gibt kommerzielle Lösungen für sowas, die auch mit
hohen Geschwindigkeiten arbeiten. Mehr Infos bei Bedarf
per E-Mail.
> ...was vielleicht daran liegt, das I2C eigentlich nur ein
> Board-Level Interface ist, wo normalerweise keine Trennung
> gebraucht wird.
Das ist die Theorie. In extrem vielen Produkten stecken
I2C EEPROMs/Flash ICs. Wie die in der Fertigung beschrieben
werden, darfst Du raten :-).
> Also erlaube die Frage, warum mußt Du I2C galvanisch trennen?
Kann gerade in Produktionsumgebungen sehr interessant
sein.
Gruß, Marco
--
E-Mail: mb-news-b<ät>linuxhaven.de
Deutsches Linux HOWTO Projekt: http://www.linuxhaven.de
> Philips ist aber der Erfinder von I2C, und auch der
> Lizenzgeber für die anderen Halbleiter-Hersteller.
Es gibt aber eine "kompatible" Variante, den SMBus.
> Philips dagegen muß, als "Eigentümer" der Methode, eher auch
> solche Chips bereitstellen - selbst wenn es sich vielleicht
> nicht immer rechnet.
Davon würde ich eher nicht ausgehen.
cu, Marco
Daniel Schramm <dan...@pinguin.sauerland.de> schrieb in im Newsbeitrag:
40fe...@olaf.komtel.net...
> ich suche nach einer Lösung für eine galvanische Trennung des I2C Busses.
>
ob es bei I2C funktioniert hab' ich nicht getestet (glaub' ich aber
schon!) - probier's einfach mal aus:
Für meine eigenen Baugruppen setze ich auch einen bidirektionalen Bus auf
Open-Collector-Basis ein. Für längere Strecken (über 20m) gibts einen
Repeater. Den könnte man wohl auch für die DATA-Leitung des I2C einsetzen
und mit Optokopplern galvanisch trennen. (Die CLK-Leitung des I2C ist ja
i.A. unkritisch, da nur unidirektional)
Unter www.Holtermann-Modellbahntechnik.de/grafik/BM_01.BMP findest Du eine
Handskizze des Schaltplans. Nur so als ungetestete Idee ;-) Vielleicht
hilft's Dir ja
weiter.
Viele Grüße
Klaus
--
Holtermann Elektronik
www.Holtermann-Modellbahntechnik.de
www.MoBaSchaZ.de
> Es gibt da noch div. andere Probleme. I2C an sich ist ja
> schon nicht ganz unkritisch, insb. was Kapazitäten und
> Serienwiderstände betrifft.
Schon klar. Aber für die Verwendung von Optokopplern stellt
die Art der Signale das Hauptproblem dar.
>> Die sauberste Lösung dürfte in der Tat der Philips-Baustein
>> sein. "Bessere" Schaltungen sind mir auch noch nicht
>> untergekommen.
>
> Es gibt kommerzielle Lösungen für sowas, die auch mit
> hohen Geschwindigkeiten arbeiten. Mehr Infos bei Bedarf
> per E-Mail.
Sind das Designs, die sich in eigene Schaltungen einarbeiten
lassen, oder fertige Produkte zur Schnittstellentrennung?
(Infos sind auf jeden Fall willkommen.)
>> ...was vielleicht daran liegt, das I2C eigentlich nur ein
>> Board-Level Interface ist, wo normalerweise keine Trennung
>> gebraucht wird.
>
> Das ist die Theorie. In extrem vielen Produkten stecken
> I2C EEPROMs/Flash ICs. Wie die in der Fertigung beschrieben
> werden, darfst Du raten :-).
Das ist kein Gegenargument, sondern Bestätigung. Im Produkt
selbst ist das ein Board-Level Interface. Bei der Fertigung
muß man einmal von außen daran - dort darf man aber ungleich
höheren Aufwand treiben, die Fertigungsstrecke gibt es nur
einmal (oder wenigstens nur in kleinsten Stückzahlen).
Das Interface selbst wurde als BLI konzipiert. Daß man es
mit (erheblichem) zusätzlichen Aufwand auch als externe
Schnittstelle nutzen kann, ist eine andere Sache.
>> Also erlaube die Frage, warum mußt Du I2C galvanisch trennen?
>
> Kann gerade in Produktionsumgebungen sehr interessant
> sein.
Siehe oben. In diesen Fällen kann man i.d.R. relativ teure
Trennmodule kaufen und einfach einsetzen.
Daniels Frage hörte sich aber eher so an, als ob er was
in eine eigene Schaltung eindesignen wollte.
Daniel?
Die Clk-Leitung ist _NICHT_ unidirektional. Jeder Slave, dem es zu schnell
geht, kann die
Clock-Low-Phase durch Aktivieren seines open-collector-Treibers verlängern.
(I2C spec, Kapitel 8.2 und 8.3, auf dem Philips-Server)
Philips hat auch eine Application Note zum Puffern des I2C-Bus. Die
Quintessenz ist, dass es
seriös nicht geht. Entweder muss man mit Spikes leben oder man muss sich mit
Pegeln
wie "ziemlich low" und "ganz toll low" anfreunden.
Für mich geht beides nicht.
Gruß, Gerhard
|> Die Clk-Leitung ist _NICHT_ unidirektional. Jeder Slave, dem es zu schnell
|> geht, kann die
|> Clock-Low-Phase durch Aktivieren seines open-collector-Treibers verlängern.
|> (I2C spec, Kapitel 8.2 und 8.3, auf dem Philips-Server)
Die I2C-Devices, die das machen, kann man aber an einer Hand abzählen...
Der OP hat sein Einsatzgebiet nicht erwähnt, wenn man das genauer wüsste, würde
es helfen. Hängen da "nur" ein paar Eproms oder PLLs dran oder _muss_ das ein
full-featured Bus sein?
--
Georg Acher, ac...@in.tum.de
http://wwwbode.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
> Sind das Designs, die sich in eigene Schaltungen einarbeiten
> lassen, oder fertige Produkte zur Schnittstellentrennung?
> (Infos sind auf jeden Fall willkommen.)
Fertige Produkte, die sicherlich auch in OEM-Versionen
verfügbar wären. Infos bei Bedarf bitte per E-Mail, da
ich hier keine Werbung posten möchte.
> Das ist kein Gegenargument, sondern Bestätigung. Im Produkt
> selbst ist das ein Board-Level Interface.
Anderes Beispiel: DDC bei Monitoren (ist ein I2C EEPROM
im Monitor).
> Bei der Fertigung
> muß man einmal von außen daran - dort darf man aber ungleich
> höheren Aufwand treiben, die Fertigungsstrecke gibt es nur
> einmal (oder wenigstens nur in kleinsten Stückzahlen).
Wäre schön, wenn das in der Praxis so gemacht würde :-).
> Das Interface selbst wurde als BLI konzipiert. Daß man es
> mit (erheblichem) zusätzlichen Aufwand auch als externe
> Schnittstelle nutzen kann, ist eine andere Sache.
Das ist richtig, leider vergessen das sehr viele Anwender und
wundern sich dann über Probleme. Komisch, daß I2C über 10m
Kabel in einer EMV-verseuchten Umgebung nicht geht. Und da
die oberen Schichten sehr oft leider keine Fehlersicherungs-
schichten enthalten (außer vielleicht PEC bei SMB), sind
Probleme vorprogrammiert.
cu, Marco
>> Sind das Designs, die sich in eigene Schaltungen einarbeiten
>> lassen, oder fertige Produkte zur Schnittstellentrennung?
>> (Infos sind auf jeden Fall willkommen.)
>
> Fertige Produkte, die sicherlich auch in OEM-Versionen
> verfügbar wären. Infos bei Bedarf bitte per E-Mail, da
> ich hier keine Werbung posten möchte.
Danke, gerne. Meine Absenderadresse ist gültig.
>> Das Interface selbst wurde als BLI konzipiert. Daß man es
>> mit (erheblichem) zusätzlichen Aufwand auch als externe
>> Schnittstelle nutzen kann, ist eine andere Sache.
>
> Das ist richtig, leider vergessen das sehr viele Anwender und
> wundern sich dann über Probleme. Komisch, daß I2C über 10m
> Kabel in einer EMV-verseuchten Umgebung nicht geht. Und da
> die oberen Schichten sehr oft leider keine Fehlersicherungs-
> schichten enthalten (außer vielleicht PEC bei SMB), sind
> Probleme vorprogrammiert.
Ack. Aber versuche das mal dem Kaufmann zu erklären, der den
Preisunterschied zwischen I2C und einem Feldbus gesehen hat...