Ich habe da ein Problem mit I2C via Optokoppler(OK). Konkret möchte ich über OK mit einem MCP23017 quatschen. Dem MCP "Daten" schicken funktioniert auch, was nicht klappt ist der Weg vom MCP zum Mikrocontroller. Ohne die OK funktioniert alles wie erwartet. Wenn ich die Signale (vgl. Screenshots) richtig interpretieren dann bekomme ich das NACK nicht zurück. Ich weiß nur nicht warum? Die Schaltung basiert auf die AN4 von Vishay (Optical Isolator for I2C Bus System), statt der dort beschriebenen VOH-Optokoppler verwende ich lediglich die Optokoppler HCPL-2611. Ganz offensichtlich geht lediglich der SDA-Pfad vom MCP zum Mikrocontroller nicht aber ich steig noch nicht dahinter warum. Kann jemand vielleicht erkennen wo der Hase im Pfeffer begraben ist? I2C_Optokoppler.png ist der Schaltplan wie die Schaltung auf dem Steckbrett aufgebaut ist. OKs, Widerstände, Kapazitäten und Dioden dimensioniert wie im Schaltplan angegeben. Die Oszilogramme zeigen jeweils SDA, gemessen am MCP. Es wurde hier stets das Register 0x14 gesetzt bzw. gelesen, zuvor wurde Register 0x00 auf 254 gesetzt: Setzen_uC.BMP zeigt das Oszilogram beim Setzen wenn der MCP direkt am Mikrocontroller hängt Lesen_uC.BMP zeigt das Oszilogram beim Lesen wenn der MCP direkt am Mikrocontroller hängt. (Ich bekomme auch den Erwartungswert!) Setzen_OK.BMP zeigt das Oszilogram beim Setzen wenn der MCP am Optokoppler hängt Lesen_OK.BMP zeigt das Oszilogram beim Lesen wenn der MCP am Optokoppler hängt, ich bekomme einen I2C-Fehler, und zwar dass kein NACK kam (was man auch im Oszilogram sieht, das NACK fehlt). Wie gesagt, das Setzen funktioniert. Ich kann, wie hier im Beispiel angegeben, gezielt GPA0 wie gewünscht auf High oder Low setzen. Mir fehlt aber das Lesen des MCPs da ich später nicht nur den MCP setzen will sondern auch Portpins auf ihren Zustand auslesen möchte.
Angehängte Dateien:
-
I2C_Optokoppler.png
73 KB -
Setzen_uC.BMP
220 KB -
Lesen_uC.BMP
220 KB -
Setzen_OK.BMP
220 KB -
Lesen_OK.BMP
220 KB
Angehängte Dateien:
-
Setzen_OK.BMP
220 KB
Kleiner Edit: Das im Eröffnungpost gezeigte "Setzen_OK.BMP" ist ein von mir falsch benanntes "Lesen_OK.BMP". Da hab ich mich vertan in der Bezeichnung der Bilder. Hier im Anhang nun das richtige "Setzen_OK.BMP".
Nimm doch einfach den ADUM1250 ARZ. https://www.reichelt.de/de/de/digitaler-i2c-isolator-2-kanal-3-0--5-5-v-150-ns-so-8-adum-1250-arz-p185562.html?r=1
Schaltplan: sollte nicht der Ausgang von U11 (irgendwie) auf SDA gehen?
S. L. schrieb: > Schaltplan: sollte nicht der Ausgang von U11 (irgendwie) auf SDA gehen? Oh man, na klar. Warum geht der denn auf SCL? Werd ich gleich morgen mal erproben aber du hast völlig recht. Peter D. schrieb: > Nimm doch einfach den ADUM1250 ARZ. > > https://www.reichelt.de/de/de/digitaler-i2c-isolator-2-kanal-3-0--5-5-v-150-ns-so-8-adum-1250-arz-p185562.html?r=1 Das wäre durchaus auch eine Lösung. Kam bisher nicht in betracht weil der Lagerbestand vom ADUM1250 0 ist und der Lagerbestand vom HCPL-2611 >100 ;)
:
Bearbeitet durch User
M. K. schrieb: > Oh man, na klar. Warum geht der denn auf SCL? Schaltpläne werden deutlich übersichtlicher, wenn man Powersymbole benutzt und nur die Signale verdrahtet.
Ich steige da nicht durch. SDA interpretiere ich als Daten. Da es bidirektional ist, müssten da doch 2 Optokoppler angeschlossen sein? Oder habe ich da etwas falsch verstanden? Theoretisch müssten trotzdem an Clock auch 2 Optokoppler liegen, da ein I2C Client ja die Möglichkeit des Clock-Stretching hat. https://www.prodigytechno.com/i2c-clock-stretching#:~:text=Clock%20Stretching%20in%20I2C%20Protocol,the%20slave%20device%20is%20swamped.
Peter schrieb: > Theoretisch müssten trotzdem an Clock auch 2 Optokoppler liegen, da ein > I2C Client ja die Möglichkeit des Clock-Stretching hat. Glück gehabt, der MCP23017 ist ein dummer Slave, d.h. kein MC intern. Lt. DB ist SCL = Input only.
Peter D. schrieb: > Schaltpläne werden deutlich übersichtlicher, wenn man Powersymbole > benutzt und nur die Signale verdrahtet. Richtig, aber sooo unüberlichtlich ists ja nun wirklich nicht und es hätte meinen Fehler nicht verhindert. Peter schrieb: > Theoretisch müssten trotzdem an Clock auch 2 Optokoppler liegen, da ein > I2C Client ja die Möglichkeit des Clock-Stretching hat. Ja, wenn man Clock-Stretching braucht braucht man 4 OKs, hab ich aber bisher noch nie gebraucht und auch der MCP23017 kann kein Clock-Stretching. Um es mit Peters Worten zu sagen: Ich hab bisher immer nur dumme Slaves benutzt. ;)
Peter schrieb: > Theoretisch müssten trotzdem an Clock auch 2 Optokoppler liegen, da ein > I2C Client ja die Möglichkeit des Clock-Stretching hat. Praktisch gibt es aber auch den ADuM1251 mit unidirektional SCL1→SCL2, damit Clock-Störungen nicht den ganzen Bus kaputt machen.
Clemens L. schrieb: > Praktisch gibt es aber auch den ADuM1251 mit unidirektional SCL1→SCL2, > damit Clock-Störungen nicht den ganzen Bus kaputt machen. Lösungen gibt es sicher viele, ich denke auch dass die ADUMs nicht die Einzigen sind. Wie oben schon gesagt wurde die OK-Lösung präferiert weil die OKs, im Gegensatz zu den vorgeschlagenen ADUMs (die sicher nicht schlecht sind) im Hause sind.
M. K. schrieb: > Ich habe da ein Problem mit I2C via Optokoppler(OK). Konkret > möchte ich über OK mit einem MCP23017 quatschen. > .. > Lesen_OK.BMP zeigt das Oszilogram beim Lesen wenn der MCP am Optokoppler > hängt, ich bekomme einen I2C-Fehler, und zwar dass kein NACK kam (was > man auch im Oszilogram sieht, das NACK fehlt). Hallo, wie soll das funktionieren? I2C sendet nach dem Startbit die Adresse für den Slave, gefolgt von dem R/W Bit. Danach erwartet der Master ein ACK, erzeugt vom Slave durch ziehen der SDA-Leitung auf „L“. Dieses ACK erwartet der Master auch nach senden eines Datenpaketes. Kommt das nicht sendet der Master nicht weiter. Wie soll das in Deiner Schaltung mit den OK funktionieren? Peter D. schrieb: > Peter schrieb: >> Theoretisch müssten trotzdem an Clock auch 2 Optokoppler liegen, da ein >> I2C Client ja die Möglichkeit des Clock-Stretching hat. > > Glück gehabt, der MCP23017 ist ein dummer Slave, d.h. kein MC intern. > Lt. DB ist SCL = Input only. Ja, aber er kann Daten an den uC (Master) senden. Und dafür müssen die I2C-Parameter eingehalten werden. @TO Weshalb die Optokoppler?
Jörg R. schrieb: > Weshalb die Optokoppler? Optokoppler nimmt man, wenn man eine Potentialtrennung braucht. > Wie soll das in Deiner Schaltung mit den OK funktionieren? Lies die besagte AN04: - https://www.vishay.com/docs/84901/opticalisolatorfoti2cvussystem.pdf Mir ist da zu viel analoges Gebastel und Pegeltricksereien drin. Deshalb hätte ich hier den MCP23S17 mit SPI-Schnitte genommen.
Lothar M. schrieb: > Jörg R. schrieb: >> Weshalb die Optokoppler? > Optokoppler nimmt man, wenn man eine Potentialtrennung braucht. Die Frage ist ob die notwendig ist. Es gibt hier oft genug Schaltungen in denen keine galvanische Trennung stattfindet, und trotzdem werden OK benutzt. Bestes Beispiel sind die Billig-Relais auf Platine aus Fernost. OK verbaut und meistens nicht notwendig. Aber, um Deine Antwort zu ergänzen..OK können auch zur Pegelanpassung eingesetzt werden. >> Wie soll das in Deiner Schaltung mit den OK funktionieren? > Lies die besagte AN04: > - https://www.vishay.com/docs/84901/opticalisolatorfoti2cvussystem.pdf Ok, danke für den Link.
:
Bearbeitet durch User
Jörg R. schrieb: > Hallo, > > wie soll das funktionieren? I2C sendet nach dem Startbit die Adresse für > den Slave, gefolgt von dem R/W Bit. Danach erwartet der Master ein ACK, > erzeugt vom Slave durch ziehen der SDA-Leitung auf „L“. Dieses ACK > erwartet der Master auch nach senden eines Datenpaketes. Kommt das nicht > sendet der Master nicht weiter. Wie soll das in Deiner Schaltung mit den > OK funktionieren? Das Problem wurde bereits gelöst, den SDA-Weg vom Slave zum Master hatte ich auf SCL des Masters geführt statt auf SDA. Obwohl ich das gestern mehrfach überprüft hatte. Warum ich es erst nach Hinweis von S.L. (sldt) gesehen habe und nicht eher vermag ich nicht zu sagen > @TO > Weshalb die Optokoppler? Weil das eine Anforderung des Projektes ist. Das Gerät, dass durch den MCP gesteuert wird, soll und muss floaten können. Es ist hier ein ähnliches Ding wie beim Funkschau-Netzteil wo der Regler auf der positiven Ausgangsspannung schwimmt nur dass es hier nicht um 0-30V geht sondern das Potential, auf dem wir mit schwimmen, einige 100 V weit weg ist. Ich hätte also entweder jedem GPIO des MCPs einen OK spendieren können oder aber ich trenne die Kommunikation zum MCP. Ich musste mich zwischen 16 OKs oder 3 OKs entscheiden, die Wahl fiel mir dann doch recht leicht. Und ja, es gäbe sicher noch andere Lösungen. Jörg R. schrieb: >> Jörg R. schrieb: >>> Weshalb die Optokoppler? >> Optokoppler nimmt man, wenn man eine Potentialtrennung braucht. > > Die Frage ist ob die notwendig ist. Das steht hier halt nicht zur Debatte. Zur Lösung des Problems gibt es sicher viele Wege, den den ich wählte ist sicher nicht der Einzige und ich wage nicht zu bewerten, ob das der beste Weg ist. Für mich ist es der Beste weil es 1. funktioniert und 2. ich alle benötigten Komponenten im Überfluss im Hause habe.
Thread beobachten
Seitenaufteilung abschalten
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.