ESP32 FreeRTOS vTimer I2C OLED Murks

OP #6837703
Lesenswert?
• ▲
▼
Ich versuche gerade in einer vTimer CallBack Funktion einen Text auf ein 
OLED (SSD1306) zu schreiben. Leider springt mir anscheinend immer jemand 
dazwischen.

Bei Start (setup()) benutze ich zum eigentlichen Schreiben auf das OLED 
die gleiche Funktion wie auch in der vTimerCB. Solange der Scheduler 
nicht gestartet ist, ist alles gut, die Texte sind sauber und sofort da.

In der vTimerCB klappt schon das display.clearDisplay(); nicht, die 
alten Texte werden ggf. überschrieben aber nicht gelöscht. Man kann auch 
zusehen wie die einzelnen Zeilen geschrieben (verkrackelt) werden. Das 
deutet für mich darauf hin, das da immer wieder ein Prozess dazwischen 
geht und damit das Timing auf dem  I2C-Bus gestört ist, jedenfalls war 
es so, als ich das schon einmal hatte und mit dem Oszi nachgeschaut 
hatte.

Testweise habe ich alle anderen vTasks auskommentiert, die sind es 
nicht, die da dazwischen gehen. Vorher hatte ich es erfolglos mit 
vTaskSuspend und vTaskResume versucht.

Ein Einfügen von vTaskDelay(50 / portTICK_PERIOD_MS) nach jedem 
Schreiben auf das OLED hat es auch nicht gebracht.

Nächster Versuch war portENTER_CRITICAL(mux). Mir ist schon klar, das 
das eigentlich für so lange Operationen nicht gedacht ist. Natürlich hat 
gleich der "Wachhund" zugebissen.

Es ist doch eigentlich ein trivialer Vorgang, was aber mache ich falsch?

ESP32:

framework = arduino

platform = espressif32


Libs für OLED-Zugriff:

Adafruit BusIO

Adafruit SSD1306

Adafruit GFX Library

Im Hintergrund gestartet sind noch Webserver und Wifi, die haben aber 
noch nie gestört. Vorher hatte ich das ganze klassisch laufen 
(setup/loop) und da hatte ich nie solche Probleme.

Es gibt auch keinen anderen Prozess der versucht auf dem I2C-Bus 
rumzuwerkeln.

Vielleicht sind die Adafruit - Libs auch für FreeRTOS nicht geeignet, 
welche währen es dann?
OP #6838134
Lesenswert?
• ▲
▼
Vielen Dank für die vielen Vorschläge. Leider führen die nicht weiter.

Ein vTimer ist keine ISR und auch das Verschieben der Funktion von von 
einer vTimerCB in eine vTaskCB hat nichts gebracht.

Btw. In FreeRTOS gibt es keine main loop, es geschieht alles in vTasks 
oder vTimern.
OP #6838149
Lesenswert?
• ▲
▼
Lösung:
So, vermutlich habe ich eine Lösung gefunden. Ich schließe zwar immer 
noch nicht die  Adafruit Libs ganz aus, aber es scheint zu 
funktionieren.

Ich erinnerte mich dunkel, das FreeRTOS-Zeugs läuft auf Core0, also habe 
ich es versucht mit:
1
if (xTaskCreatePinnedToCore(display_CB, "Display", 10000, NULL, 30, &DisplayTask, 1) == pdPASS) {
2
...
Die 1 als letzten Parameter Pinnt die Funktion auf Core1, damit kommen 
sich wohl die Prozesse nicht mehr quer.
Sieh da, es funktioniert.
OP #6838615
Lesenswert?
• ▲
▼
Keine Ahnung warum die BusIO Lib drin ist. PlatformIO scannt und sucht 
sich alles zusammen. Falls ich den Baum richtig interpretiere, ist das 
keine Abhängigkeit von den Adafruit-Libs sondern da hängt noch ein 
LoRa-Device über SPI dran. Das Ausmisten hatte ich mir für später 
vorgenommen.

Antwort schreiben

Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt. Bitte hier nur auf die ursprüngliche Frage antworten, für neue Fragen einen neuen Beitrag erstellen.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.