ich erstelle gerade einen eigenen Treiber für einen SHT31. Natürlich möchte ich die eleganteste Lösung haben. Treiber einbinden, Adresse definieren und fertig.
Grundsätzlich funktioniert alles, Kommunikation funktioniert, Mapping auch, sogar Diagnose wenn Teilnehmer nicht mehr antwortet -> _iState wird zurückgesetzt!
Jetzt habe ich nur folgendes Problem: Wenn ich den Sensor vom Bus trenne und wieder verbinde, braucht der Sensor einige Zeit bis dieser wieder verfügbar ist. Läßt sich relativ leicht via i2cdetect ermitteln. Jedoch sendet meine Libary den Befehl für den SHT31 um den Status auszulesen. Irgendwie scheint der PI den Sensor zu finden, jedoch hängt sich der komplette I2C Bus auf. Während diesem Fehler werden auch keine anderen TN mittels i2cdetect gefunden.
Es vermittelt den Eindruck das der SHT31 noch nicht richtig initialisert ist und ich den WriteBefehl sende und damit kommt es zum Crash. Wenn die Funktion i2cdetect den Teilnehmer wieder findet, dann funktioniert auch der WriteBefehl problemlos.
Gibt es eine Möglichkeit den Bus nach Teilnehmern zu durchsuchen? Bestimmte Funktionen konnte ich mit itfNode herausfinden, aber z.b. die Adressliste welche Teilnehmer am Bus dran hängen bringt mich gerade zum verzweifeln.
Ziel sollte sein, wenn Teilnehmer getrennt wird, das dieser nach Verfügbarkeit sich wieder selbstständig initialisiert, aber erst wenn der Master auch sagt Teilnehmer ist verfügbar.
Danke für eure Hilfe
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
eigentlich funktioniert das, ich weiß nur nicht ob du i2cdedect parallel zu codesys nutzt. Da weiß ich nicht ob das kollidiert.
In meiner Biliothek https://github.com/stefandreyer/I2C-Multiplex
nutze ich das und das funktioniert soweit. Ich werte die Rückgaben der read und write Funktionen aus um festzustellen, ob der Teilnehmer vorhanden ist. Schaus dir doch mal an, vielleicht möchtest du deinen SHT 31 dort mit integrieren?
Grüße Stefan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2018-08-26
Originally created by: *michi
Hi Stefan,
Mit Funktion Read/Write und keine Rückgabewerte realisiere ich den Timeout. Das funktioniert bei meinen anderen Kleinprojekten auch recht problemlos.
Den ursprünglichen Fehler, dass es mir den kompletten I2C Bus zusammenhaut habe ich auch finden können. Schuld war die Zykluszeit des Masters. Habe diesen relativ schnell eingestellt auf 4ms, der Sensor SHT31 verträgt diese Geschwindigkeit nicht. Mit einer Verzögerung zwischen Read/Write Befehl klappt das ganze problemlos. Auch meine gewünschte Reconnect Funktion. Das sich das ganze aber so auswirkt hätte ich auch nicht erwartet. Ich habe dir mal die Screenshots angehängt wie sich der Fehler dann äußert.
Danke trotzdem für deine Hilfe
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
bei mir läuft der i2cbus in einen eigenem Task und das freilaufen. Dabei muss man natürlich die vorgaben der Slaves beachten, ob die zwischen read und write einen Verzögerung brauchen. Bei mit Funktioniert das bis jetzt ganz zuverlässig, wenn einer mal nicht antwortet, wird so lange versucht bis er wieder da ist und neu initialisiert.
Grüße Stefan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Originally created by: *michi
Hallo zusammen,
ich erstelle gerade einen eigenen Treiber für einen SHT31. Natürlich möchte ich die eleganteste Lösung haben. Treiber einbinden, Adresse definieren und fertig.
Grundsätzlich funktioniert alles, Kommunikation funktioniert, Mapping auch, sogar Diagnose wenn Teilnehmer nicht mehr antwortet -> _iState wird zurückgesetzt!
Jetzt habe ich nur folgendes Problem: Wenn ich den Sensor vom Bus trenne und wieder verbinde, braucht der Sensor einige Zeit bis dieser wieder verfügbar ist. Läßt sich relativ leicht via i2cdetect ermitteln. Jedoch sendet meine Libary den Befehl für den SHT31 um den Status auszulesen. Irgendwie scheint der PI den Sensor zu finden, jedoch hängt sich der komplette I2C Bus auf. Während diesem Fehler werden auch keine anderen TN mittels i2cdetect gefunden.
Es vermittelt den Eindruck das der SHT31 noch nicht richtig initialisert ist und ich den WriteBefehl sende und damit kommt es zum Crash. Wenn die Funktion i2cdetect den Teilnehmer wieder findet, dann funktioniert auch der WriteBefehl problemlos.
Gibt es eine Möglichkeit den Bus nach Teilnehmern zu durchsuchen? Bestimmte Funktionen konnte ich mit itfNode herausfinden, aber z.b. die Adressliste welche Teilnehmer am Bus dran hängen bringt mich gerade zum verzweifeln.
Ziel sollte sein, wenn Teilnehmer getrennt wird, das dieser nach Verfügbarkeit sich wieder selbstständig initialisiert, aber erst wenn der Master auch sagt Teilnehmer ist verfügbar.
Danke für eure Hilfe
Hallo Michi,
eigentlich funktioniert das, ich weiß nur nicht ob du i2cdedect parallel zu codesys nutzt. Da weiß ich nicht ob das kollidiert.
In meiner Biliothek
https://github.com/stefandreyer/I2C-Multiplex
nutze ich das und das funktioniert soweit. Ich werte die Rückgaben der read und write Funktionen aus um festzustellen, ob der Teilnehmer vorhanden ist. Schaus dir doch mal an, vielleicht möchtest du deinen SHT 31 dort mit integrieren?
Grüße Stefan
Originally created by: *michi
Hi Stefan,
Mit Funktion Read/Write und keine Rückgabewerte realisiere ich den Timeout. Das funktioniert bei meinen anderen Kleinprojekten auch recht problemlos.
Den ursprünglichen Fehler, dass es mir den kompletten I2C Bus zusammenhaut habe ich auch finden können. Schuld war die Zykluszeit des Masters. Habe diesen relativ schnell eingestellt auf 4ms, der Sensor SHT31 verträgt diese Geschwindigkeit nicht. Mit einer Verzögerung zwischen Read/Write Befehl klappt das ganze problemlos. Auch meine gewünschte Reconnect Funktion. Das sich das ganze aber so auswirkt hätte ich auch nicht erwartet. Ich habe dir mal die Screenshots angehängt wie sich der Fehler dann äußert.
Danke trotzdem für deine Hilfe
Hallo Michi,
bei mir läuft der i2cbus in einen eigenem Task und das freilaufen. Dabei muss man natürlich die vorgaben der Slaves beachten, ob die zwischen read und write einen Verzögerung brauchen. Bei mit Funktioniert das bis jetzt ganz zuverlässig, wenn einer mal nicht antwortet, wird so lange versucht bis er wieder da ist und neu initialisiert.
Grüße Stefan