Auf keinen Fall wenn hier noch Probleme bestehen & die sind ja bekannt. Und am Ende entscheidet das Papa, weil die Probleme fallen dann im Zweifel auf ihn zurüclk
Bin aber auch dabei erstmal noch einen weiteren Branch dafür anzulegen.
Nicht im ESPuino-Reposity, wer soll zusätzlich einen DEV-DEV-Branch testen & warten? Bringt es voran & macht es rund, wir sind gespannt, berichtet gern hier.
Wünsche Euch ein schönes langes Wochenende mit Euren Kids & der Familie!
Ich würde hier auch ein zweigleisiges Vorgehen vorschlagen:
Für jetzt ist der Gewinn von 200 Byte IRAM sicherlich eine Lösung, ich befürchte aber, dass das auf lange Sicht kein Stabiles vorgehen sein wird. Das bedeutet, dass wir bei dem nächsten Feature im IRAM (und sei es nur ein Interrupt-Handler) wieder am Start stehen.
Auch mit einer Branch eine aktiven Projekt (wie FastLED) ist es „meh“. Solche Branches sehe ich immer als problematisch an, da diese dann up-to-date gehalten werden müssen (was mit Aufwand verbunden ist und ich zumindest bin faul 
).
Da musst du aufpassen, eine Interrupt Funktion im Flash hat einige Anforderungen an das System, die erfüllt werden müssen. Interrupts nicht im IRAM werden zB deaktiviert, wenn die Caches deaktiviert sind (das zB bei einem Schreibzugriff auf dem Flash → NVS write zB der Fall ist).
Die Funktionen in FastLED füttern das RMT-Modul mit den Daten, die es auf den WS2812 Pin rausjagt. Wenn die Funktionen nicht im IRAM liegen, kann es aufgrund des Caches zu Verzögerungen kommen und der RMT leer laufen → flackern oder falsche Farben bei langen LED-Ketten.
Bei unserem System wahrscheinlich nur ein theoretisches Problem, ich habe aber zB schon Projekte mit knapp 300 LEDs / Strip aufgesetzt, da sieht man sowas mit dem freien Auge 
.
1A, ich habe die Branch mal ausgecheckt und werde es testen , sobeld das Build durch ist, werde ich berichten.
Eine Idee wäre es für den Start die default config von Arduino als Absprungsbasis zu nehmen und da alle Änderungen einzupflegen.
Damit haben wir dann nicht das Problem, dass unsere Version der IDF nicht laufen will.
Bin da ganz bei dir
Hinweis: Ich habe in dem Branch gerade noch eingebaut, dass die Target-Files automatisch gelöscht werden wenn Änderungen vorgenommen wurden. Dadurch muss man eigentlich auf nichts mehr achten und kann fröhlich an den Einstellungen in der sdkconfig.default drehen…
Ich meine @fschrempf hat genau diese Config verwendet um es zum Laufen zu bekommen und dann über die menuconfig diese nochmal neu geparsed. Kann ich aber nochmal überprüfen…
Schön, dass da jemand meine Meinung teilt. Exakt diese Argumente habe ich oben bereits versucht zum Ausdruck zu bringen. 
Genau. Das deckt sich ebenfalls mit dem was ich oben geschrieben habe:
Genau das habe ich gemacht. Daher sollte das Resultat (bis auf kleinere Unterschiede durch verschiedene ESP-IDF Versionen?) das selbe sein wie bisher.
Die besprochenen kurzfristigen Änderungen sind jetzt im DEV-Branch verfügbar.
In der Platform.ini ist das angepasste FS rausgeflogen da jetzt in 2.0.8 offiziell enthalten.
Die Biliotheken FastLED, RC522 & RC522-I2C (benutzt die ein Mensch auf diesem Planet?) sind zunächst geforkt mit Verweis auf die ursprüngliche Version. Wenn das überflüssig wird das dann entsprechend geändert/zurückgenommen.
Mir ist jetzt noch ein kleiner Bug aufgefallen:
Der Code kompiliert nicht mehr wenn kein RFID-Reader definiert ist. Das könnte der Fall sein wenn man ohne Leser testet oder für Leute die das Programm als reinen Webplayer verwenden.
Zum Pausieren der Tasks beim Web-Upload werden jetzt die Methoden Led_TaskPause()/Led_TaskResume() und Rfid_TaskPause()/Rfid_TaskResume() anstelle direkter Zugriff auf die Task-Handles verwendet.
Wäre fein wenn noch jemand drüberschaut:
Kann es sein, dass der dev-Branch nun nicht mehr mit dem Target ESP32-S3 kompiliert?
Ich bekomme mindestens diese 3 Fehler (ENABLE_BLUETOOTH natürlich auskommentiert):
.pio/libdeps/esp32-s3-devkitc-1/ESP32-A2DP/src/BluetoothA2DPSink.cpp:248:53: error: 'FUNC_GPIO0_CLK_OUT1' was not declared in this scope
.pio/libdeps/esp32-s3-devkitc-1/ESP32-A2DP/src/BluetoothA2DPSink.cpp:252:53: error: 'FUNC_U0TXD_CLK_OUT3' was not declared in this scope
.pio/libdeps/esp32-s3-devkitc-1/ESP32-A2DP/src/BluetoothA2DPSink.cpp:1255:33: error: 'I2S_MODE_DAC_BUILT_IN' was not declared in this scope
Hi @kkF , ja der ESP32-S3 hat kein ja lieder kein Classic-Bluetooth, also streamen auf den ESPuino bzw. BT-Kopfhörer ist mit diesem Chip eider nicht möglich. Trotzdem sollte es kompilieren.
Ich kann das Profil [env:esp32-s3-devkitc-1] erfolgreich kompilieren, dazu muss die A2DP-Bibliothek zus. auskommentiert werden. Klappt es dann?
; https://github.com/pschatzmann/ESP32-A2DP.git#5f87ad2
Ah, vielen Dank. Dann klappt es tatsächlich.
Um mal einen DEV-Branch Zwischenstand zu geben, habe ich mal alles, was hier bereits fertig ist, so aufgeschrieben, als müsste ich es jemandem verkaufen. Dann wird aus jedem Bugfix ein Feature 
:
Verbesserungen:
Fehlerkorrekturen:
Code-Optimierungen:
Abgekündigt:
Bekannte Probleme:
Fehlt noch was?
Wow, danke @tueddy !
Ich hatte gestern auf einem ganz frischen ESP32 (habe ich für eine Bestellung gelötet) ein Problem mit dem DEV-Branch. Ich war leider ziemlich in Eile und hab’s mir leider nicht in die Zwischenablage gelegt. Aber es gab sporadische Neustarts was irgendwie in diese Richtung ging: Move to CRGBArray and CRGBSets · biologist79/ESPuino@cfdac70 · GitHub. Also irgendwelcher Neopixel-Kram.
Ich schau mal, ob ich das nochmal nachgestellt kriege. Ins WLAN bin ich auch nicht gekommen, so dass ich dann final doch wieder den Master-Branch geflasht habe. Wobei das auch nicht weiter wild ist, weil das flashe ich bei Bestellungen immer drauf.
Dieser behobene Bug oder habe ich das überlesen?
@joker Danke ist notiert!
@biologist Wenn da etwas reproduzierbar ist dann her damit. Die Umstellung CRGBArray → CRGBSets ist ja recht neu, da können auch mal neue Fehler auftreten. Aber dafür ist der DEV-Branch ja da…
Beides habe ich auch festgestellt , kann es aber noch nicht gezielt nachstellen. Deshalb werde ich auch das nächste Update kommende Woche bei meiner Enkelin mit dem Master machen, obwohl ich gerne das
hätte.
Habe mal mit „Erase Flash“ Alles zurückgesetzt und dann die WLAN-Zugangsdaten neu eingegeben. Hat auf Anhieb geklappt.
Was halt strange ist: Der ESP32 war nagelneu. Also lediglich einmal mit DEV geflasht.
Ich schaue mal, ob ich das nochmal nachstellen kann. Mit Arduino2 habe ich allerdings „traditionell“ schon immer mehr Probleme mit WLAN gehabt.
Im Bluetooth Lautsprechermodus hatte sich ein Fehler eingeschlichen der zum Crash führt.
Bitte einmal drüberschauen oder besser- Testen. Wenn es grünes Licht gibt würde ich das zeitnah übernehmen:
Durch die ganzen merge-commits ist das auf Github eher unübersichtlich.
Habe dein Branch aber gerade in meinen Branch gemerged und damit kurz Bluetooth-Wiedergabe so wie das normale Abspielen und das hin und her wechseln zwischen BT und WLAN getestet.
Da ich keine Bluetooth-Lautsprecher hier habe konnte ich diesen Modus nicht testen.
Von den Diffs her passt es aber (ist ja wirklich sehr überschaubar)…
Ich hätte da noch einen alternativen Vorschlag (allerdings noch ungetestet): Bluetooth.cpp: Fix logging crash in sink mode · fschrempf/ESPuino@0c6c64e · GitHub.
@fschrempf Oh, das ist nice. Commit funktioniert auf der aktuellen dev, kann aber nur die Sink-Seite esten. Sehe aber kein Grund, wieso Source sich anders verhalten sollte.