Ich verspreche hier lauter Sachen, die ich mir mal anschauen möchte und schreibe sie mir nicht auf Also schreibe ich sie hier mal öffentlich runter und wenn jmd. den Eindruck hat, dass ich da was vergessen habe, was ich mal versprochen hatte, dann kann er/sie/es mich gerne korrigieren
Die Liste spiegelt nicht die Reihenfolge wieder hinsichtlich ihrer Prioritäten.
Playlist:
Beim WROVER Playlist (statt auf Heap) auf PSRAM allokokieren. Und auch generell mal schauen, ob das auch für andere Stellen gilt. Insbesondere auch JSON-Objekte.
Bei einer Playlist nicht in jedem Objekt den gesamten Pfad speichern. Stattdessem im ersten Array-Element die Anzahl der Titel (ist aktuell schon so), im zweiten den Basispfad und von drei bis n dann nur noch die Dateinamen. Zusammenfügen per strcat().
RFID:
@elmar-ops Implementierung hinsichtlich Pause testen, wenn man die RFID wegnimmt.
PN532 testen (da ist aktuell ein Pull-Request anhängig)
I2S:
Alternative I2S-Kodierung per PP-Direktive konfigurierbar machen.
Kopfhörer/Lautsprecher:
Ausgabe aktuell nur mono. PP-Direktive implementieren, die einem ermöglicht, auch Lautsprecher stereo zu schalten. Kopfhörer beim Erkennen, dass der Stecker eingesteckt ist, immer stereo abspielen.
Playlist:
Titelsprung implementieren
Ports:
Port-Expander PCA9555 implementieren
Platformio.ini:
Automatische USB-Port-Erkennung testen (wer hatte mir das nochmal geschrieben!?)
Ursprünglich habe ich das unter Mac OS auch gar nicht gebraucht. Nur irgendwann ging es nicht mehr ohne. Warum das so ist, das weiß ich ehrlich gesagt nicht
Gute Idee. Eigentlich bin ich ja eher zu faul (+oldschool) für so ein Tool. Weil idR hat das zu viel Overhead für mich. Aber bei Github ging das jetzt wirklich schnell und einfach.
Danke
Hi
nach der values.h habe ich eine weitere Idee die main.cpp zu bereinigen . Ist Eigennutz bei .
Die komplette Routine für Neopixel zu einer neopixel.h machen und die Möglichkeit für eine neopixel_custom.h ( bei mir single_led.h ) einfügen .
VG
Mir ist aufgefallen, dass der Task für den Datei-Upload und der Task, welcher von AsyncTCP verwendet wird, nicht fest auf einen Core zugeordnet sind. Eventuell gibt es hier noch Optimierungspotenzial.
Für das Core-Pinning des AsynTCP-Tasks muss ein Flag verwendet werden.
Zum Beispiel: -DCONFIG_ASYNC_TCP_RUNNING_CORE=1
Beim ESP32-S2, welcher ja nur einen Core hat, komme ich übrigens mit der SD-Karte im SPI Mode auf ca 400 kB/s (100MB Testdatei). Das entspricht ja dem Wert, welchen man beim ESP32 im MMC Mode aktuell erwarten kann.
Wäre spannend zu wissen, warum es einen so ein deutlichen Unterschied bei der SD-Karte im SPI Mode zwischen ESP32 und ESP32-S2 gibt.
Man kann es mittels xTaskCreatePinnedToCore() auch direkt pinnen. Das habe ich bei den anderen Sachen auch gemacht. @Harry Du hattest den Code für den Upload damals implementiert. Hattest den absichtlich nicht gepinnt?
Ja ist Absicht. Hatte damals mit unterschiedlichen Core Pinning und Taskprios gespielt und bin dann bei der Lösung geblieben. Die Lösung ist etwas performanter und hat glaube ich auch weniger Einfluss auf die anderen Tasks. Ganz bekomme ich den Grund nicht mehr zusammen. Ist ja schließlich schon 2 Monate her
Ich orientiere mich bei dem Vergleich gegenüber dem ESP32 an Werten, welche in der Github Readme stehen.
Upload via HTTP:
ESP32
MMC 372 kB/s (Quelle: Github)
SPI 184 kB/s (Quelle: Github)
ESP32-S2
MMC gibt es nicht
SPI 400 kB/s (100MB Testdatei)
Für mich stellt sich die Frage, ob der Geschwindigkeits-Unterscheid nur durch den anderen µC zu erklären ist oder ob es noch Optimierungspotenzial in der Software gibt.
Für den ESP32-S2 benutze ich einen aktuelleren Arduino Core, welcher auf ESP-IDF V4.2 basiert.
Ich hab leider aktuell keinen Aufbau mit einem ESP32, um einen Gegentest mit meinem Testszenario zu machen.
Der esp32 hat eine schlechte I/O Performance im Vergleich zu anderen uC. Siehe auch die Kommentare von greiman dem Ersteller der SdFat lib: ESP32 · Issue #113 · greiman/SdFat · GitHub
Ich warte noch auf ein paar Teile, dann werde ich das nochmal mit dem Lolin32 und dem aktuelleren Arduino Core (V2.0 Dev) basierend auf dem ESP IDF V4.2 testen. Eventuell wurde auch der SPI-Treiber beim ESP32 verbessert. Ich werde berichten.
Also schreibe ich sie hier mal öffentlich runter und wenn jmd. den Eindruck hat, dass ich da was vergessen habe, was ich mal versprochen hatte, dann kann er/sie/es mich gerne korrigieren 
