ESP-32S2 + OLED SPI Display ruckelt mit der Zeit

[Bohnenhans]

Hmm ich habe bei mir so ein kleines Panel gebastelt um 2 Rechner zu starten herunterzufahren, die etwas ungünstig im Büro stehen. Mit einem OLED Display (glaub 0.,96 per SPI angeschlossen) Microcontroller ist ein ESP32-S2

Nur mit der Darstellung habe ich Probleme - die wird nach einiger Zeit langsamer - siehe Video.

Allerdings bleiben die Umschaltzeiten was angezeigt wird gleich (bis auf die längere Darstellungszeit) - so dass ich nicht denke dass der Programmcode langsamer abläuft auch die Antwortzeiten des drauf laufenden Webservers bleiben - soweit messbar - gleich.

Normalerweise zeigt es das fast instant an - im "Fehlermodus" ist das fast Pixelzeilenweise.

Auch der freie Speicher bleibt auf dem gleichen Level, den lasse ich mir auch anzeigen, das war mein erster Gedanke Dem würde aber natürlich auch widersprechen dass das oft tagelang läuft - und manchmal nach 1 Std schon laggt.

Genutzt habe ich das Arduino Framework, mit nichts wirklich besonderem ausser u8x8, MQTT, und AsyncWebserver, der aber nur für Firmware Updates genutzt wird (und jetzt Debug)

Hat jemand eine Idee an was das liegen könnte?

So ist es wenn es langsam ist https://emalm.com/?v=VN1A2
So "normal" https://emalm.com/?v=4jIMC

Also ein Riesenunterschied

 

[Michael-Menten]

Starte den regelmäßig neu.

Die Ursache zu finden dauert Stunden bis Tage. Komplett neu machen mit anständigem RTOS wäre sogar schneller als den Fehler zusuchen.

 

[Bohnenhans]

ne das eigentlich keine Option (auch wenn ich es aktuell so mache ) vor allem da das recht unregelmässig aufrtitt mal über Tage gar nicht mal recht fix.

Ich hab mir mal ein paar neue Displays bestellt in der Grösse habe ich leider nichts mehr da - ich denke es könnte das Display sein - OLEDs - nicht genu die aber auch SPI - nutze ich an anderen Stellen auch mit ESP32(S2) und da gibt es nichts auffälliges.

 

[Der_Picknicker]

Naja, der S2 ist ja nur ein Single Core Chip, vielleicht dauert an manchen Stellen eine Funktion zu lange? Besonders String-Operationen sind dafür teilweise anfällig. Kannst du es mit einem S3 oder nur einem ESP32 ohne Zusatz Testen?

Bei nem Multicore Chip würde ich einen Chip nur für die Anzeige nutzen. Evtl. Mal einen GitHub issue beim Entwickler der Library aufmachen?

 

[Michael-Menten]

Dein ESP hat vermutlich ein Scheduler laufen. Wahrscheinlich kommt es manchmal zu einer erhöhten Last bei einem Prozess mit höherer Priorität. Als Folge läuft dein Task, der das Display per SPI mit Daten versorgt, nicht mehr "flüssig".
Arduino ist gut es einfach zu halten. Arduino ist nicht dafür gebaut um solche Probleme zu beheben. Daher der Ratschlag einmal komplett neu mit einem ordentlichen RTOS anfangen.

 

[Bohnenhans]

Dann würde die Funktion ja immer zu lange dauern und nicht plötzlich - ohne dass da irgendwas besonderes passiert. Es gibt zwar MQTT Abrufe - aber die Umschaltzeiten zw. dem was angezeigt wird bleiben gleich (abzüglich der Verzögerung der Darstellung )

Von aussen gibt es keine Zugriffe - der WebServer läuft nur wenn ich eine neue Firmware aufspiele.

Zumal es auch egal ist ob ich auf 240, 160 oder 80 Mhz betreibe.

 

[Michael-Menten]

Dein Problem ist, dass du aktuell eine große Blackbox hast.

Dann würde die Funktion ja immer zu lange dauern und nicht plötzlich

Das ist bereits komplex genug.
z.B. du hast einen Hintergrund-Task oder von außen getriggert der etwas Crypto braucht. Sofern dein Chip kein hardware support hat, ist dies extrem aufwendig. Alternativ hat da jemand einen blocking wait/sleep verwendet oder sonst was getrieben. s.h. blackbox
Denkbar ist auch, das zwei aufwendige Task zufällig versuchen zeitgleich zulaufen. Das könnte erklären, weshalb es unregelmäßig auftritt.

Wenn jetzt dein Task mit niedriger Priorität läuft, wird der scheduler die verfügbaren Resourcen dem problematischen Task geben und Ergebnis ist, dein Display ruckelt obwohl der Code dafür fehlerfrei ist.

 

[Der_Picknicker]

@Michael-Menten …

Du kannst mit Arduino auch Funktionen benutzen, die von FreeRTOS bereitgestellt werden. Ich entwickle mit der IDF von espressif und kann jedem Hobbyentwickler eigentlich nur davon abraten.

@Bohnenhans .. Ich würde jede Funktion 100x aufrufen, mit micros() die Zeit messen, in ein Array schreiben und dann seriell das Array ausgeben, damit lässt sich schon schnell herausfinden, wo der Schuh drückt. Hast du meinen Beitrag gelesen?
=>

Besonders String-Operationen sind dafür teilweise anfällig. Kannst du es mit einem S3 oder nur einem ESP32 ohne Zusatz Testen?

Bei nem Multicore Chip würde ich einen Chip nur für die Anzeige nutzen. Evtl. Mal einen GitHub issue beim Entwickler der Library aufmachen?

 

[Bohnenhans]

Ich hab mir das jetzt noch nicht ganz genau angeschaut aber denke die Ausgaben über SPI werden doch sicher atomar realisiert? Da man doch die Daten in Echtzeit liefern muss.

Ja habe ich gelesen Danke Der_Picknicker.

Wenn ich nicht ganz falsch liege ist doch das "Multitaksingsystem" des ESP32 preemtiv (auch gegemnüber atomaren Systemfunktionen wie WiFi BT, IRQ Handling) weshalb man in den WatchdogReset laufen kann? Bei "grösseren" A=>D Messungen in hoher Frequenz habe ich den auch schon deaktivieren müssen - naja zumindest gemacht

Ich meine - und bin auch immer davon ausgegangen - dass auch IRQ Trigger nicht mehr funktionieren wenn man immer innerhalb einer Funktion bleibt - es also eigentlich keine Möglichkeit gibt eine laufende Funktion zu unterbrechen.

Das ja doch alles auf dem Stand des kooperativen Multitaskings ( und auch das nur im besten Fall )

 

[Der_Picknicker]

Du hast dir einen SingleCore Chips ausgesucht, der kann kein Multitasking, sobald eine Funktion etwas macht ist der Core blockiert du musst es so programmieren, dass keine Funktion den Core übermäßig blockiert.
Wenn du FreeRTOS nutzt, kannst du eine Art scheduling realisieren, aber auch hier kann nur ein Tasks aktiv sein, wenn du einen S3 oder eine. ESP32 ohne Zusatz nehmen würdest, kannst du alles was WiFi etc. auf einen Core auslagern und hast einen Core komplett frei für die Anzeige.

BTW: Du musst, den Watchdog immer mal wieder füttern, wenn’s zu lange dauert, da der ESP sonst crasht.

 

[Bohnenhans]

Wenn ich ausführe printOLED("abc"); kann doch während der Funktion PrintOLED ja nichts anderes laufen (auch keine Systemfunktionen) zu dem Zeitpunkt - erst wieder nach Rückkehr aus dieser Funktion.

Da ist doch das was preemtives Multitasking ausmacht, dass Funktionen atomar und damit RealTime fähig sind.

Im Arduino Framework übernimmt das Füttern des Frameworks den Watchdogs (denke in der loop() Funktion) nur bei sehr langen Operationen in Funktionen (die z.B. viel Realtime machen) muss man den mal füttern.

 

[Der_Picknicker]

Teste doch mal alle deine Funtkionen durch, irgendwas wird dein Code massiv ausbremsen. Ich tippe auf irgendwas mit WLAN. Nimm einfach nen Multicore-Chip, dort kannst du einem Core die Anzeige zuweisen.

Ergänzung (2. Juni 2023)

Ja, aber du beklagst dich, dass du kein Multitasking kannst, aber gleichzeitig nutzt du halt auch nur nen SingleCore Chip….

 

[Bohnenhans]

Ne ich beklage mich gar nicht, das hat Du falsch verstanden - ich will ja meistens au keinen Fall Multitasking wenn ich was mit Microcontrollern mache. Microcontroller Sachen sollen bei mir nach Möglichkeit Realtimefähig sein.

 

[Der_Picknicker]

Ja, dann kauf dir nen vernünftigen Chip, der S2 ist ne Krücke im Vergleich zum S3. Oder teste deinen Code durch und finde den Fehler.

 

[Bohnenhans]

Nun ich nutzte auch halt hin und wieder die USB Funktionalität die hat halt der S2 und der normale ESP nicht - daher kauf ich mir immer halt inzwischen nur noch die S2s.

Ich habe aber jetzt getestet und nur Text ausgeben - also sonst keine Libs ausser u8x8, keinen Code - und da hat das Display tatsächlich auch angefangen nach einer Weile (~25 min) zu laggen - hihi auf die Idee bin ich irgendwie gar nicht gekommen erst jetzt so.

Denn statt meinen Code zu testen kann ich natürlich auch testen wie verhält es sich ganz ohne meinen Code.

Manchmal denkt man einfach nicht an das einfachste - diesmal auch Display mit Reset-Pin bestellt - man weiss ja nie

 

[Der_Picknicker]

Dann kauf halt nen s3, der kann alles was der s2 kann nur besser

Aber dann kannst du ja den Fehler zumindest einkreisen - die Library

 

[Bohnenhans]

Naja ich habe jetzt erst mal noch 8 x S2 wenn die verbastelt sind dann weg werde ich mir sicher mal den S3 anschauen.

Denke/Hoffe eher das Display, die u8x8 Library wird ja zig hunderttausendfach genutzt.

Vielleicht ein thermisches Problem das sich auf auf das SPI Interface auswirkt wo sich was ein Billionstes Millimeter ausdehnt OLED Diplays geben sicher auch etwas Wärme ab.

Egal hat mir jedenfalls geholfen den Fehler einzukreisen - wer weiss ob ich sonst auf die Idee gekommen wäre das Dispaly ohne meinen Code zu testen - manchmal hängt man halt auch bei was ganz einfachem naheliegenden wo fest.

 

[Bohnenhans]

Als Ersatz habe ich mir jetzt SSD1309 geholt und bis natürlich auf die angepasste Ausgabe - hat etwas mehr Pixel - nichts am Code geändert. Und seit 3 Tagen tut das bisher ohne die Ausfälle.

Allerdings jetzt mit statt 4 Kabeln wie beim alten Display das mit 7 Kabeln angeschlossen.... Chip Select Reset etc habe ich vorher nicht am Display gar nicht rausgeführt gehabt.

Denke es war wohl ein Fehler in dem alten Display.