Hi Zusammen,
ich habe (zusammen mit @fschrempf und @tueddy ) angefangen die Led.cpp zu überarbeiten.
Hier ist der PR dazu:
Hier ein paar Änderungen:
alle Animationen sind jetzt priorisiert und nicht mehr blockierend
über die Settings.h lassen sich die mgölichen Dimmstufen für die LEDs einstellen (besonders bei weniger Pixeln super hilfreich)
einige Glitches (alle die ich bis jetzt gefunden habe ) wurden entfernt (durch neue Struktur)
die Animation des Playlist-Progress wurde überarbeitet um bei mehrfachem spulen eine kontinuierliche Animation darzustellen.
Alle Inhalte und auch die Abläufe haben wir dabei so beibehalten wie sie waren und vor allem auf die neue Struktur angepasst.
Zu den Dimmstufen:
diese bestimmen wie viele Zwischenzustände eine LED zwischen „Aus“ und „Eingestellter Helligkeit“ hat.
Wenn man keine Zwischenstufen über die Helligkeit haben möchte, kann man eine „1“ eintragen. Dann werden nur volle LEDs angesteuert.
Pause bei Webstream => Drücken der Taste zum Messen der Akkuspannung. Ich nenne es mal wie du: Glitch .
Webstream läuft => Drücken einer Taste (lang), um den ESPuino in den Schlaf zu schicken: Glitch.
Webstream läuft => Drücken einer Taste (kurz), um die Akkuspannung zu messen: Glitch.
Taste gedrückt, um Akkuspannung zu messen. Während der Anzeige wird am Drehencoder gedreht, um die Lautstärke zu ändern => Änderung der Lautstärke überschreibt die alte Anzeige der Akkuspannung nicht.
Ich habe per Zufall ein mp3 gewählt, welches 0 Bytes groß war. Führt zum Absturz aus dem LED-Task heraus. Zugegeben: Wird aktuell auch nicht 100% behandelt. Führt nicht zum Absturz, aber jedoch dazu, dass der LED-Ring dunkel bleibt, bis ein neuer Track gestartet wird .
Ich denke dazu musst du nochmal ein paar Worte sagen, damit die Leute das auch verstehen .
Wow, vielen Dank dir!
Ja, da war ich noch nicht beim Webserver .
Habe den großteil gerade noch kurz gefixed, werde das heute Abend aber noch abschließen und bisschen aufräumen.
Das mit den 0 Bytes konnte ich mir noch nicht anschauen, das mache ich dann ebenfalls heute Abend.
Dann schreibe ich auch noch was zum Dimmen…
Das mit den 0 Bytes führt irgendwie auch zu einem grundsätzlichen Problem. Ich denke, dass da kein Event geworfen wird, dass der Track fertig ist. Oder so früh, dass es wieder überschrieben wird.
Als ich eben meinen Test-ESPuino einschalten wollte, bemerkte ich, dass der von gestern Abend noch „an“ war. Vielleicht fixt man das besser so, dass man das eingangsseitig prüft, ob das File 0 Bytes groß ist. Weil das ist eigentlich keine valide Datei.
Sehr schön finde ich den jetzt sehr weichen Übergang bei Lautstärkeregelung und Playllist-Fortschritt
Beim Bluetooth-Modus scheint etwas noch nicht zu passen. Ich habe jetzt nur BT-Lautsprecher getestet, die LED blinken Blau und das auch nach dem Verbinden. Ich meine das war vorher anders? Ich teste das aber nochmal weiter die Tage.
Das mit der Bluetooth-LED scheint auf dem Master schon falsch zu sein. Im Sink-Modus findet dort aktuell keine Umschaltung statt. Werde das aber korrigieren.
if (OPMODE_BLUETOOTH_SOURCE == System_GetOperationMode()) {
if (Bluetooth_Source_Connected()) {
idleColor = CRGB::Blue;
} else {
idleColor = CRGB::BlueViolet;
}
Dass wenn das Gerät „Source“ ist auf eine „weitere Source“ geschaut wird scheint ein Fehler zu sein.
Also bei mir kommt der Fehler bei 0 Byte-LED aus dem Audioplayer:
Backtrace: 0x4009b0a9:0x3ffd4670 0x4009853a:0x3ffd46b0 0x400d3be2:0x3ffd46f0
#0 0x4009b0a9:0x3ffd4670 in compare_and_set_native at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/esp_hw_support/include/soc/compare_set.h:25
(inlined by) spinlock_acquire at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/esp_hw_support/include/soc/spinlock.h:103
(inlined by) xPortEnterCriticalTimeout at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/freertos/port/xtensa/port.c:288
#1 0x4009853a:0x3ffd46b0 in vPortEnterCritical at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/freertos/port/xtensa/include/freertos/portmacro.h:578
(inlined by) xQueueReceive at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/freertos/queue.c:1400
#2 0x400d3be2:0x3ffd46f0 in AudioPlayer_Task(void*) at src/AudioPlayer.cpp:331
Suche mal noch weiter. Vielleicht kann man das einfach fixen…
Werde das nachher noch gegen den master testen.
Nee, keine weitere Source und auch kein Fehler.
Startet man im Bluetooth Kopfhörer-Modus blinken die LED Balu-violett und wenn der Kopfhörer verbunden ist springt es auf Blau. Das Verhalten habe ich hier beschrieben.
Für den BT-Sink Modus würde das auch Sinn machen…
Ich denke das muss man on the fly fixen in AudioPlayer. D.h. FileSize muss geprüft werden. Weil in der Playlist-Generierung ist das nicht notwendigerweise ausreichend, weil wenn die Playlist gecached ist, dann würde es dran vorbeilaufen.
Ah in der Playlist habe ich es noch nich getestet mit der 0-Byte Datei. Nur als Einzeldatei.
Update: bei mir crasht es auch in der Playlist im Audioplayer:
#0 0x4010d0ca:0x3ffd2830 in Print::write(char const*) at C:/Users/Joe/.platformio/packages/framework-arduinoespressif32/cores/esp32/Print.h:67
#1 0x4010d1a5:0x3ffd2850 in Print::print(char const*) at C:/Users/Joe/.platformio/packages/framework-arduinoespressif32/cores/esp32/Print.cpp:89
#2 0x400d7e3a:0x3ffd2870 in Log_Println(char const*, unsigned char) at src/Log.cpp:29
#3 0x400d7fe1:0x3ffd2890 in Port_Write(unsigned char, bool, bool) at src/Port.cpp:83
#4 0x400d386f:0x3ffd28b0 in AudioPlayer_Cyclic() at src/AudioPlayer.cpp:277
(inlined by) AudioPlayer_Cyclic() at src/AudioPlayer.cpp:128
#5 0x400e1f60:0x3ffd28e0 in loop() at src/main.cpp:270
#6 0x40114339:0x3ffd2900 in loopTask(void*) at C:/Users/Joe/.platformio/packages/framework-arduinoespressif32/cores/esp32/main.cpp:50
Hätte einen heißen Kandidaten gefunden:
Im Audioplayer wird für den Progress durch die Filesize geteilt ohne überprüfung auf „0“…
Ich teste das mal…
Habe es gefunden! (also das mit Filesize 0) War wirklich die Division durch 0 im AudioPlayer.cpp.
Habe es nochmal gepusht. Rewind habe ich auch testen können und ich habe oben noch was zu den Dimm-States geschrieben…
Ist wieder gepusht.
Ich bin jetzt soweit mit testen durch und ziemlich zufrieden.
Bevor ich anfange weitere und andere Animationen zu schreiben würde ich diesen Stand gerne finalisieren und im master haben.
Gibt es da gerade noch Bugs / Wünsche, die ihr gerne umgesetzt hättet?
Bin auch offen für konzeptionelle Änderungswünsche
Also, also die Sachen, die ich berichtet hatte, sind gefixt.
Hatte eben beim Webstream, kurz dem nach Flashen, mal das Problem, dass das Messen der Akkuspannung mehrfach nicht funktioniert hat. Aber das kann ich gerade nicht mehr reproduzieren.
Jut, also ich werde das jetzt mal ein bisschen testen. Andere User hier hoffentlich auch
Nachtrag: Konnte es doch reproduzieren. Also wenn Webstream läuft, schlägt die Anzeige der Akkuspannung öfter mal fehl. Mitunter geht es mehrfach hintereinander (das ist die Regel), aber es kommt auch vor, dass es 2-3mal hintereinander nicht geht.
Ich bin auch generell bisschen überrascht, dass sich im Pause-Modus die LEDs bei Webradio weiterdrehen. Wie ich gestern rausgefunden habe, ist das in meinem aktuellen Master auch so. Aber ich meine ursprünglich habe ich das mal anders gewollt .
Hmm. Vielleicht hat es was mit der detektion der Impulslänge zu tun, dass stattdessen der Shutdown gestartet wird und wieder abbricht. Schaue ich mir an. Finde da bestimmt eine gute Lösung.
Das mit der Pause ändere ich gerne. Wollte erst Mal nicht so viel anpassen an den bestehenden Animationen, das ist mir aber auch aufgefallen
Nach booten
zuerst Karte mit Webradio , alles ok.
Dann Karte mit Musik , ist ok.
Dann wieder Webradio. Optisch sieht alles gut aus nur man hört nichts und die Tasten sind ohne Funktion.
Nach booten
zuerst Karte mit Musik, alles ok,
Dann Karte mit Webradio, Fehler wie oben.
) wurden entfernt (durch neue Struktur)
.
.
.