So, ich habe die PSRAM-Anpassungen eingecheckt. Im Grunde einfach nur Wrapper-Funktionen, die prüfen, ob PSRAM verfügbar ist. Wenn ja, dann wird er genutzt. Wenn nein, dann eben der Heap.
Da ich gerade schon über den Quellcode schaue. Wie sieht es aus ein paar Knöpfe umzubenennen?
NEXT_BUTTON → BUTTON_0
PREVIOUS_BUTTON → BUTTON_1
PAUSEPLAY_BUTTON → BUTTON_2
Bei DREHENCODER_BUTTON bin ich mir nicht sicher, sollte aber auch als BUTTON_3 genannt werden. Er wird ja als solcher behandelt.
Diese Änderungen sind die Folge des dynamische Button-Layouts.
Die Änderung bricht nicht existierende Konfigurationen, wenn man dort passende #ifdefs platziert:
#ifndef BUTTON_0
#define BUTTON_0 NEXT_BUTTON
#endif
Hatte ich auch schon drüber nachgedacht. Das ist für mich grundsätzlich in Ordnung. Die Implementierung ist auch schnell gemacht, aber in Sachen Doku muss ich dafür einiges an verschiedenen Stellen anpassen.
Ich nehme das in meine ToDo-Liste auf und warte aber erstmal ab, bis @tuniii das Refactoring fertig hat.
@biologist Ich würde morgen Abend damit anfangen. Einen Teil hatte ich ja bereits schon mal gemacht. Ich muss jetzt nur schauen, ob ich es aufgrund der vielen Änderungen noch einmal frisch mache, meinen bisherigen Stand recycle kann oder eine Mischung davon. Wenn es gut läuft, sollte es dann das Wochenende darauf fertig sein. Trotzdem würde ich mal mit 2 Wochen planen.
1 „Gefällt mir“
Habe gerade auch nach längerer Zeit mal ein Update gemacht, gefühlt ist die Empfindlichkeit deutlich gestiegen. 
Hier mal die Auswertung der Tasks des aktuellen Stands direkt nach dem Hochstarten:
loopTask 119464392 48%
IDLE0 114751985 46%
IDLE1 2756974 1%
rfidhandling 2843620 1%
LED 310109 <1%
tiT 466783 <1%
mp3play 272163 <1%
Tmr Svc 40 <1%
eventTask 1411 <1%
mdns 16845 <1%
network_event 302 <1%
async_tcp 47 <1%
esp_timer 415533 <1%
wifi 3749582 1%
ipc0 10935 <1%
ipc1 116619 <1%
In der letzten Spalte sieht man die Auslastung der Tasks in Prozent. Beide CPU Cores ergeben zusammen 100%. IDLE0 läuft auf Core 0 und IDLE1 läuft auf Core1. Die loopTask läuft auf Core 1.
Man sieht, dass Core 1 am Anschlag ist und hauptsächlich loopTask drankommt.
Baut man nun ein vTaskDelay von 5ms in loopTask ein, dann sieht die Auslastung wie folgt aus:
loopTask 913621 1%
IDLE0 19059972 38%
IDLE1 23590301 47%
mp3play 60872 <1%
LED 77747 <1%
tiT 115172 <1%
rfidhandling 4348183 8%
Tmr Svc 40 <1%
ipc0 10894 <1%
mdns 10256 <1%
ipc1 117408 <1%
eventTask 1447 <1%
wifi 928554 1%
esp_timer 87458 <1%
network_event 276 <1%
async_tcp 31 <1%
Man sieht, dass der rfidhandling Task zuvor vom loopTask verdrängt wurde und ihm nun mehr CPU-Zeit zusteht. Das würde auch die bessere Empfindlichkeit für den RC522 erklären, welcher nun in loopTask abgearbeitet wird.
6 „Gefällt mir“
Cool. Mit was hast du diese Analyse gemacht?
Mittels vTaskGetRunTimeStats()?
Aber ist auf jeden Fall interessant. Das muss man sich mal unter verschiedenen Situationen anschauen:
z.B.
- Es wird ein mp3 abgespielt
- FTP-Server wird aktiviert
- Es werden Daten via FTP übertragen
- Es werden Daten via Webtransfer übertragen
- Kombinationen aus den o.G.
Ja, genau. Allerdings gibt es die Funktion im offiziellen Arduino Core nicht. Man kann aber meinen modifizierten Arduino Core zum Testen einbinden.
platform_packages =
platformio/framework-arduinoespressif32 @ https://github.com/tuniii/arduino-esp32-v1.0.6-wt#v1.0.6-patched
1 „Gefällt mir“
@biologist Wie wäre es in Zukunft noch einen Ringbuffer zum Loggen, welcher über Web erreichbar, einzubauen? Damit kann man bei Problemen immer schnell schauen, was geloggt wurde. Ich könnte da etwas aus einem anderen Projekt wiederverwenden.
2 „Gefällt mir“
Wäre ok von meiner Seite.
Hi,
Kann es sein das ich deinem Namen schonmal im Zusammenhang mit dem Wlanthermo gelesen habe?
Gruß Frank
Hi Frank,
ja dort bin ich auch aktiv.
Viele Grüße
Martin
1 „Gefällt mir“
Na toll…nun will ich so ein Thermometer haben 
1 „Gefällt mir“
Hatte vor paar Tagen bei Wolle ein issue aufgemacht, dass mit einer aktuellen Version das Abspielen stottert. Wolle hat sehr zügig einen fix geliefert. @Wolle vielen Dank nochmal! Dabei hat er noch etwas Interessantes zu den Audio loop Zeiten Hier geschrieben.
1 „Gefällt mir“
Hallo Harry, auf github wird die Version v2.0.0 (mit ESP-IDF 4.4) zum Testen angeboten. Das habe ich gemacht und festgestellt, dass der freie SRAM um 36KBytes verringert ist. Das kann ein Problem werden. Daraufhin habe ich die Speicher der Dekoder in den PSRAM verlagert. PSRAM ist langsamer, aber es funktioniert solange genug Rechenzeit vorhanden und die WLAN Verbindung schnell ist. Wenn audio.loop() in 3 Sekunden wenigstens 100 mal aufgerufen wird (~30ms/Durchlauf) läuft alles gut. Jetzt benutzen die Dekoder wieder SRAM und nur wenn das nicht möglich ist wird versucht PSRAM zu belegen. Dabei kann es mit der neuen Version passieren, dass dem Hauptprogramm dann nicht mehr viel Freiraum bleibt oder der ESP neu startet.
vG Wolle
@tuniii
Aus Neugier eine Frage zu deinem Refactoring:
Du benutzt Funktionsnamen wie z.B. AudioPlayer_Init. Wieso benutzt du da keinen Namespace?
Danke
Im Prinzip verfolgt beides den gleichen Zweck. Die Verwendung von Namespaces habe ich bisher noch nicht so oft bei Arduino-Projekten gesehen und ich bin bisher auch noch nicht auf die Idee gekommen diese zu verwenden. Liegt vermutlich daran, dass beruflich meistens nur C-Code angesagt war.
Ah ok, ich komme aus der C+±Welt. Da liegt es für mich naher.
@biologist Ich bin jetzt mit dem Refactoring durch. Es gibt noch ein paar Kleinigkeiten, aber irgendwann sollte man mal einen Cut machen. Willst du auch einen Refactoring Branch bei dir im Repo anlegen und mache einen PR gegen den Branch oder soll das direkt auf master? Ersteres würde ich bevorzugen, da man dann den Branch noch etwas mehr testen könnte.
Ich lege dafür einen Branch an. Das macht auf jeden Fall Sinn, das erstmal ausgiebig zu testen.