Also was mir auf jeden Fall mal positiv auffällt: Ich habe heute schon den ganzen Tag Webradio laufen und es gab noch nicht einen Aussetzer. Da hatte ich ja kürzlich in einem anderen Thread berichtet, dass es immer wieder dazu kommt und sich das durch Neuauflegen der Karte „reparieren“ lässt.
Ist jetzt auch der aktuelle DEV-Branch mit Stand von gestern Abend.
1 „Gefällt mir“
Vorweg: Prinzipiell tut es und ist auch deutlich angenehmer so!
- Ordner-Upload: Raten schwankend um die 220 KB/s herum. Immer wieder etwas langsamer, allerdings nie richtig unter 190 KB/s (ohne Änderung ca. 180 KB/s im Idle, ca. 120 KB/s mit „Musik“)
- File-Upload: startet schnell, geht dann aber auch wieder zu den Raten von oben runter (immer weiter).
- FTP-Upload: hier greift das noch nicht und wir sind weiterhin sehr langsam (ca. 130 KB/s). Sollen wir das dort auch einbauen?
- Allgemein: Wenn man den Upload (Ordner) startet, während eine Wiedergabe aktiv ist, kommt immer wieder ganz kurz was durch (Anzeige und Musik). Vermtulich wird zwischen den Files der Task kurzzeitig fortgesetzt und dann kommt es zu komischen geräuschen / kurzen Musik-Fetzen.
Also wenn es „ordentlich“ überträgt, dann habe ich brutto so 325 kB/s rum. Am Ende kommen dann so etwa 300 kB/s raus. Ist ok, aber bleibt doch deutlich hinter dem zurück, was wir inzwischen bei Arduino1 erreichen (da habe ich zwischen 400 und 500 kB/s).
Könnte Effekt haben, aber möglicherweise nicht den gleichen. Die Art und Weise, wie Daten via FTP übertragen werden, ist komplett anders (keine Ringbuffer). Im Endeffekt wird das vermutlich nicht so arg oft verwendet so dass es vermutlich „nicht so wichtig“ ist, die komplette FTP-Lib auseinander zu nehmen.
Vielen Dank für Eure Messungen, das deckt sich mit meinen Erfahrungen.
Ja der Upload ist jetzt insgesamt langsamer geworden weil das optimierte Füllen des Ringpuffers für den Bugfix entfallen musste. Also auch in Arduino 1 ist das jetzt langsamer. Aber was nutzt uns ein schneller Upload wenn die Datei nicht fehlerfrei auf der SD landet?
Vielleicht mag sich jemand an der Optimierung probieren, meine Implementierung hatte ja fehlerhafte MP3 auf der SD hinterlassen 
Dazu müsste der Ringpuffer mehr gefüllt werden um im Schreibtask größere Blöcke auf einmal zu schreiben. Man sieht das an der Ausgabe „Chunks“. Je weniger desto besser.
Dazu kommt die Lastverteilung der Upload-/Schreib-Tasks. Die war wohl zuvor ziemlich perfekt. Leider fehlt mir für Arduino 2 das Werkzeug den anteiligen CPU Verbrauch mittels vTaskGetRunTimeStats zu messen.
FTP-Upload ist ein ganz anderes paar Schuhe, hier haben wir nichts gemacht. Ich denke auch das lohnt sich kaum…
Wenn ich mit dem aktuellen dev-branch zurück auf Arduino 1.6 gehe (commit vor dem Anhalten) sind die Uploads sogar noch schlechter. Zumindest sobald sie „eingeschwungen“ sind. Dass wir FTP nicht anpassen passt für mich. Habe das nur im Vergleich halt festgestellt.
Habe mich noch nicht eingearbeitet, aber haben oder brauchen wir eine garbage-collection o.ä.?
Beobachtung ist: mit jedem weiterne Upload wird es langsamer bis zu diesem „eingeschwungenen“ Wert.
Werde das gleich nochmal mit Arduino 2 vergleichen.
Update: ist bei Arduino 2 deutlilch stabiler als bei Arduino 1. Eventuell sind wir dort etwas schneller „eingeschwungen“, dafür ist dieser Zustand aber konsistent und zuverlässig.
Bei Einzeldateien im „frischen“ Zustand erreicht man hohe Raten (500 + KB/s) ist aber halt die Frage ob das irgendeine Relevanz hat wenn es gefühlt nur solange so schnell ist bis entweder die GC aktiv werden muss oder ein anderer Zustand eintrifft…
@Joe91 Du könntest ab hier ein wenig mit Delay() spielen:
Idealfall: Kein Delay()
Ein bisschen sollte aber sein damit der andere (Web)Task auch Zeit bekommt den Ringpuffer zu füllen
Die Werte müssten getrennt für Arduino 1/2 ermittelt weil sich die Taskzeit anders verhält.
Sehr interssant.
Bis jetzt: je größer, desto schlechter 
Bei auskommentieren finde ich es bis jetzt am besten. Ich schau mir das die Tage mal noch genauer an und versuche den Code zu verstehen. Eine gute Nacht zusammen!
2 „Gefällt mir“
Hab mir jetzt auf meinem GIt account ein Fork von ESPUINO gezogen.
Meine Settings habe ich auf Arduino 2 gesetzt - denke ich jedenfalls.
Hier meine [env] section in platformio.ini
[env]
board_build.flash_mode = qio
board_build.bootloader = dio
;platform = espressif32@<=3.5.0
;platform = espressif32@<=6.0.1
platform = espressif32
;platform = https://github.com/platformio/platform-espressif32.git#feature/arduino-upstream
framework = arduino
monitor_speed = 115200
extra_scripts =
pre:gitVersion.py
pre:processHtml.py
lib_deps =
https://github.com/schreibfaul1/ESP32-audioI2S.git
https://github.com/madhephaestus/ESP32Encoder.git#22992b3
https://github.com/knolleary/pubsubclient.git#2d228f2
https://github.com/biologist79/ESP32FTPServer
https://github.com/FastLED/FastLED.git@3.5.0
https://github.com/me-no-dev/ESPAsyncWebServer.git#1d46269
https://github.com/me-no-dev/AsyncTCP.git#ca8ac5f
https://github.com/bblanchon/ArduinoJson.git#7abf875
https://github.com/pschatzmann/ESP32-A2DP.git#07550a3
https://github.com/Arduino-IRremote/Arduino-IRremote.git#ed94895
https://github.com/kkloesener/MFRC522_I2C.git#121a27e
https://github.com/miguelbalboa/rfid.git#ba72b92
https://github.com/tuniii/LogRingBuffer.git#89d7d3e
https://github.com/tueddy/PN5180-Library.git ;#01b3e48 ;activate (#01b3e48) only, if problems with reading tags
https://github.com/SZenglein/Arduino-MAX17055_Driver#a0a5418
platform_packages =
;platformio/framework-arduinoespressif32 @ https://github.com/espressif/arduino-esp32.git#1.0.6
;platformio/framework-arduinoespressif32 @ https://github.com/tuniii/arduino-esp32-v1.0.6-wt#v1.0.6-patched
;platformio/tool-esptoolpy @ ~1.30100
;framework-arduinoespressif32 @ https://github.com/espressif/arduino-esp32.git#2.0.1-RC1
LOG Auszug:
[ 351 ] Software-revision: 20230214-1
[ 351 ] Git-revision: 07485db-dirty
[ 361 ] ESP-IDF version: v4.4.2
Muss sagen, das läuft bei mir sehr stabil.
Höre den ganzen Tag total problemlos WebRadio (Ausländischer Streamer)
Das Switchen zw. den Stations ohne Geräusche und recht schnell sofort einwandfreier Sound
Werde bis auf weiteres auf Arduino 2 bleiben.
Habe auch gleich meine Änderung zur Reaktivierung der Option „PLAY_LAST_RFID_AFTER_REBOOT“ in Verbindung mit WebStreaming gemerged.
Wegen asynchronen WiFi-Connect hat das ja nicht mehr funktioniert.
Mehr dazu im Thread DEV-BRANCH
1 „Gefällt mir“
Yepp, soweit bekannt Alles funktionstüchtig.
Auf der Todo-Liste waren noch Deep-Sleep Probleme, also sofortiges Aufwachen.
Ich meine jetzt nicht das Aufwachen durch LPCD-Interrupt am Port-Expander, weil das ist noch ein generelles Problem & unabhängig von Arduino 2.
Soweit ich das testen konnte ist auch hier Alles OK (Probleme waren so irgendwo zw. Arduino 2.01-2.05).
Hat da noch wer Probleme?
Als default habe ich den dev-branch .
Eine Auffälligkeit nur zur Info:
Dass bei Arduino 2 gelegentlich eine neue IP-Adresse vergeben wird (FritzBox), kann ich bestätigen.
Hatte ich bei 1.x nie. Da bei mir aber sowohl am Handy als auch auf meinem WinRechner mDNS funktioniert, ist das ohne weitere Auswirkungen.
Das Problem kenne ich. Gefühlt ist es bisschen besser geworden.
Den Wechsel der zugewiesenen IP durch die FRITZBox konnte ich auch beobachten.
Aber nur nach Wechsel von 1 auf 2. Innerhalb der Version2 bleibt die IP dann gleich.
Ich denke mit dieser einmaligen Neuzuweisung kann man leben.
Mit dem aktuellen dev-branch bekomme ich folgenden Fehler in wolles audio lib:
assert failed: xQueueSemaphoreTake queue.c:1545 (( pxQueue ))
Backtrace: 0x4008432d:0x3ffd26d0 0x400971cd:0x3ffd26f0 0x4009ddad:0x3ffd2710 0x400981dd:0x3ffd2840 0x400f0621:0x3ffd2880 0x400d4b25:0x3ffd28a0
#0 0x4008432d:0x3ffd26d0 in panic_abort at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/esp_system/panic.c:408
#1 0x400971cd:0x3ffd26f0 in esp_system_abort at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/esp_system/esp_system.c:137
#2 0x4009ddad:0x3ffd2710 in __assert_func at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/newlib/assert.c:85
#3 0x400981dd:0x3ffd2840 in xQueueSemaphoreTake at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/freertos/queue.c:1549 (discriminator 1)
#4 0x400f0621:0x3ffd2880 in Audio::loop() at .pio/libdeps/esp32-wrover-devkitc-v4-8mb/ESP32-audioI2S-master/src/Audio.cpp:2262
#5 0x400d4b25:0x3ffd28a0 in AudioPlayer_Task(void*) at src/AudioPlayer.cpp:749
Bevor ich lange suchen muss, kann mir jemand was zu dem Fehler sagen?
Kannst du das zuverlässig reproduzieren und uns sagen was genau du gemacht hast?
Nein, ich bekomme tatsächlich bei jeder Änderung der dependency komplett unterschiedliche Fehler.
Ich vermute da ist was an der Flash-Konfiguration nicht in Ordnung (ich verwende die Voreinstellung für das 8MB board).
Kann es sein dass die Flash-Partition nicht mehr reicht? Verwendet irgendjemand ein 4MB-Board? Dort sind die Partitionen so groß wie bei mir.
Komischer Fehler, nie gesehen.
Denke nicht das es am Flash liegt. Größe nach dem Build:
RAM: [== ] 21.5% (used 70408 bytes from 327680 bytes)
Flash: [=== ] 34.3% (used 2245593 bytes from 6553600 bytes)
Evt. nimmst Du #BLUETOOTH_ENABLE einmal raus? Dann ist der Speicherverbrauch deutich kleiner:
RAM: [== ] 17.7% (used 57852 bytes from 327680 bytes)
Flash: [== ] 23.2% (used 1517461 bytes from 6553600 bytes)
Fehler tritt beim Abspielen auf? Gibt es sonst noch Schritte das nachzuvollziehen? Eine bestimmte MP3 oder Web-URL?
Ich teste gerade an einem blanken WROVER devboard an das nur eine SD-Karte angeschlossen ist. Bin noch nicht über die Initialisierung heraus gekommen.
Flash komplett erased, keine RFID angelernt und keine Musik auf der SD-Karte.
Hab zwischenzeitlich mit den dependencies und Einstellungen rumgespielt und kam bis zur SD-init bei der dann irgendein Heap-Fehler geworfen wurde.
Irgendwie ist alles kaputt, haha. 
Ja sieht so aus. Hast Du auch wirklich das richtige HAL und hier
das richtige Profil gewählt? Weil darüber bin ich auch schon gestolpert.
RFID-Leser ist angeschlossen?
Ja, hab ich alles angepasst. RFID ist wie gesagt noch nicht angeschlossen, aber danach sieht es mir auch nicht aus…
@tueddy jedenfalls war das erste Problem, das ich hatte, dass die soc_caps lib mit deinem letzten commit (update esp32encoder) nicht gefunden wurde und damit nichts kompiliert hat.
Update: ich habe nun verschiedene Konstellationen und Setups durchprobiert, von platformio in der IDE zur Kommandozeilenversion aus pip. Dazu clean builds bei denen ich den kompletten ~/.platformio und .pio Ordner gelöscht habe oder ein komplett frisch geklontes repository verwendet habe. Mein Resultat: Version 6.1.0 kompiliert zwar auch mit dem aktuellen dev-branch, führt aber immer zu einer Boot-schleife und einem LoadProhibited Fehler. Version 6.0.1 funktioniert wie erwartet, kompiliert aber nicht mit der aktuellen ESP32Encoder-Revision.
Meine Lösung ist es für’s erste Version 6.0.1 ohne den letzten PR von @tueddy zu verwenden.