Hallo zusammen,
gibt es eine Möglichkeit, den Zustand dieser Displays abzufragen?
Nach einigen Tagen Laufzeit sieht mein Display plötzlich so aus (siehe Anhang).
In diesem Fall würde ich gern den ESP32 neu starten.
Hallo zusammen,
gibt es eine Möglichkeit, den Zustand dieser Displays abzufragen?
Nach einigen Tagen Laufzeit sieht mein Display plötzlich so aus (siehe Anhang).
In diesem Fall würde ich gern den ESP32 neu starten.
Hi
Bei I²C gibt Es diese Möglichkeit nicht. Hier ist die Datenrichtung, meines Wissen, nur zum Display.
Allerdings befürchte ich, daß auch beim Parallel-Betrieb (egal ob 4 oder 8 Bit) die rückgelesenen Display-Informationen durchaus den von Dir geschickten Informationen entsprechen.
Das Problem ist, daß das Display irgendwie 'aus dem Tritt' gekommen ist, eine Übertragung falsch verstanden hat und so etwas umkonfiguriert wurde, Was Du eigentlich gar nicht wolltest.
Hier hilft nur, das Display neu zu initialisieren.
Das kann der Sketch auch selber, alle x Minuten wird die Initialisierung mit rein geschoben.
So hast Du zumindest nur noch maximal die Zwischenzeit, wo Müll auf dem Display stehen kann.
MfG
Und vlt. auch mal prüfen, ob die Verbindungen, zwischen dem ESP und dem Display wirklich stabil und mit vernünftigen Kabeln / Steckern herhestellt ist. I2C (wie auch SPI) sind da recht empfindlich, was eine gute und vor allem stabile kontaktgabe anbelangt. Diese billigen billigst Dupon-Steckverbinder sind nicht immer das Gelbe vom Ei.
Treten solche Störungen trotz guter Verbindungen weiterhin auf, müsste mal der ESP oder der Sketch unter die Lupe genommen werden.. Vlt. hat aber auch das Display selbst ne Macke.
Bei mir laufen solche Displays unter wirklich nicht idealen Bedinungen schon seit Monaten absolut störungsfrei, und ohne dass ich den Arduino neu starten müsste.
LG Stefan
Gerade das wollte ich vermeiden: Jede Stunde auf Verdacht lcd.clear() und dann alle Daten neu rein schreiben.
Wäre aber immerhin eine Alternative zu dem Zeichenwirrwarr.
Meine nächste Stufe wäre sowieso über einen PIR die Hintergrundbeleuchung des Displays zu steuern, da ich nachts das Display nicht als 'Raumbeleuchtung' brauche.
PIR erkennt Bewegung->Hintergrundbeleuchtung an.
In den Zug könnte ich dann auch gleich das realisieren: lcd.clear() und alle Daten neu rein schreiben.
Irgendwie muss man bei dem ganzen Arduino Zeug im Dauerbetrieb immer eine Kröte schlucken.
freddy64:
Irgendwie muss man bei dem ganzen Arduino Zeug im Dauerbetrieb immer eine Kröte schlucken.
Nimm VIEL Ketchup!
SCNR
Gregor
@Deltaflyer
Bei mir hängen am I2C noch ein ESP8475, ein BME280 und ein BH1750.
Vielleicht kommt dadurch das Display etwas durcheinander.
Was ist ein ESP8475?
Gruß Tommy
PCF8574, sorry
das kommt davon, wenn man mit einem Auge auf das Abendessen auf dem Herd aufpassen muss.
Hi
Dein Problem wird nicht (nur) sein, daß Da sinnlose Daten stehen, Die Du einfach überschreiben kannst - Dein Problem wird sein, daß das Display die enkommenden Daten komplett anders interpretiert, als Du - hier hat Sich irgend etwas in der Konfiguration verstellt - das LCD-clear() hilft Dir hier wohl nicht.
Ein LCD-init() wohl eher.
Dir ist es halt einfach nicht möglich, auszulesen, was das Display anzeigt.
Selbst wenn Du den Speicherinhalt des Display auslesen kannst (4-/8-bit Betrieb), hat Das noch rein Gar Nichts mit der Anzeige an sich zu tun.
Wie bereits gesagt: Mit dem Port-Expander kannst Du den Inhalt nicht rücklesen - Was Dir aber eh Nichts bringt, da der Speicher-Inhalt NICHTS mit dem Display-Inhalt zu tun haben muß.
MfG
Hast Du schon mit niedrigeren Pullupwiderständen auf dem I2C BUS versucht?
Grüße Uwe
@Freddy64
Auch bei mir hängen da noch weitere Komponenten am I2C Bus. Ein NV-Ram, 2 weitere Atmega-Controler, die sich da munter über I2C unterhalten. OK, direkt aufs Display schreibt dabei nur ein eiziger Controller, die anderen, tauschen nur Comando- und Statusbytes , sowie einige Daten aus. Die dan z.T. auch aufs Display geschrieben werden.
Und, gerade wenn mehr als nur das Display am i2C läuft, ist eben auf gute Verbindungen zu achten, um Störungen zu vermeiden.
LG Stefan
p.s. Abendessen kochen, ja , das ist ne gute Idee, werd ich jetzt auch gleich machen.
@uwe
hab momentan 10k Widerstände von SDA und SCL gegen Vcc drin.
Eine Suche im Inet hat aber auch schon Empfehlungen für 4,7K in Abhängigkeit von der Leitungskapazität (<400pF) geliefert.
Könnte ich mal probieren, einfach zu den 10k noch einen 10k parallel anlöten.
Wenn es Kabel- oder Steckerprobleme geben würde, warum spinnt dann das Display nicht sofort nach dem Start des µC sondern erst nach 2, 5, 8, 11 oder 15 Stunden.
Ich füttere das Display alle 10 Minuten mit den aktuellen Sensordaten.
Läuft, läuft, läuft, läuft, ..., spinnt. Und wenn das Teil plötzlich keinen Bock mehr hat, bleiben auch mal alle 4 Zeilen leer.
DAS liegt daran, weil das Display NICHTS mehr versteht - dort hat sich etwas verstellt - sagte ich aber bereits.
freddy64:
Irgendwie muss man bei dem ganzen Arduino Zeug im Dauerbetrieb immer eine Kröte schlucken.
Kann ich so nicht behaupten. Ich habe meine fertigen Geräte am laufen, sind allerdings nur zwei, das eine seit bestimmt mehr als ein Jahr durchgehend 24 Std. am Tag laufen, ohne irgend eine neuintialisierung, das zweite läuft jeden Tag, solange mein PC in Betrieb ist, also von morgens, bis sehr spät abends. Beide mit genau diesem Display. Und ich habe bei beiden nicht nie!! irgend was gesehen, was da nicht aufs Display gehört.
Franz
PS: Am I2C Bus habe ich allerdings nicht so viel Geräte. Nur das Display und eine RC Uhr. Ansonsten an der CPU Relais und Temp. Sensoren aber nicht am I2C. Ich steuere auch mit beiden Geräten 220 Volt Geräte. Auch darüber keine Störungen.
Hallo freddy64,
wenn alles richtig verdrahtet ist, läuft I2C auch mit mehreren Slave fehlerfrei, auch über lange Zeit.
Hast du ein Levelshifter in deinem I2C-Bus eingebaut oder laufen alle Komponenten mit 3,3V, auch das Display ? Die meisten Displays haben nur 5V VCC.
Wie lang ist die Kabelverbindung deines I2C-Busses ?
Die Pullups würde ich auf 4,7k setzen, aber dabei prüfen, ob nicht noch weitere auf den Modulen verbaut sind. Dieser Fehler kann auch durch eine schlechte Kabelverbindung auftreten, das macht sich nicht sofort bemerkbar.
Ich hatte selbst schon mal einen Fehler im I2C-Ausgang eines Uno, der machte sich ähnlich bemerkbar.
(deleted)
Hab jetzt nach diesem Foreneintrag einiges umgestrickt.
PullUps von 10k auf 3,3k reduziert, I2C ClockSpeed auf 50000Hz reduziert
Scheint erst mal zu laufen.
Wenn das dann auch noch nicht hilft (werde ich in einigen Stunden sehen), kommt ein anderes Kabel für den BME280 und den BH1750 dran. Die stecken gemeinsam auf einer kleinen Platine.
Momentan habe ich da ein 3m ISDN Kabel (2x2 unshielded, untwisted) dran. Das würde ich dann gegen ein Cat5 Kabel tauschen. Das ungeschirmte Kabel könnte wie eine Antenne wirken und so den Bus stören.
@Peter-CAD-HST
hab leider keinen Ersatz mehr rumliegen, sonst wäre das auch meine erste Idee gewesen.
3m
Hmmm.....
Da frage ich mich doch wieso das nicht schon im ersten Beitrag steht.
freddy64:
Momentan habe ich da ein 3m ISDN Kabel (2x2 unshielded, untwisted) dran. Das würde ich dann gegen ein Cat5 Kabel tauschen. Das ungeschirmte Kabel könnte wie eine Antenne wirken und so den Bus stören.
Das verwendete Kabel und 3m Länge ist sicher ein Grund dafür. 3m ist schon grenzwertig.
Die kleineren Pullups lindern das ein wenig.
Leider hast du nichts zu den Levelshiftern geschrieben.