Etwas sparsam der Aufrufstack, sieht ein bisschen nach Watchdog Reset aus. Verwendest Du den aktuellen Master oder DEV branch? Wurde der Kopfhörer bereits gekoppelt (Pairing)?
Hier mal noch ein längerer Auszug, aber nicht hilfreich.
N [36233] RFID-Karte erkannt: 8a-7e-e5-80
N [36233] Card type: ISO-14443
I [36237] RFID-Karte empfangen: 138126229128
ets Jul 29 2019 12:21:46
rst:0xc (SW_CPU_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:1344
load:0x40078000,len:14460
load:0x40080400,len:3652
entry 0x400805f0
E (761) esp_core_dump_flash: No core dump partition found!
E (761) esp_core_dump_flash: No core dump partition found!
I [146] Maximale Inaktivitätszeit wurde aus NVS geladen: 5 Minuten
D [196] RFID-Tags koennen jetzt gescannt werden...
N [197] Port-expander gefunden
N [199] Interrupt für Port-Expander aktiviert
I [200] Zyklus für Batteriemessung fuer Neopixel-Anzeige aus NVS geladen: 10 Minuten
I [211] Unterer Spannungslevel (Batterie) fuer Neopixel-Anzeige aus NVS geladen: 3.00V
I [223] Oberer Spannungslevel (Batterie) fuer Neopixel-Anzeige aus NVS geladen: 4.20V
I [224] Spannungslevel (Batterie) fuer Niedrig-Warnung via Neopixel aus NVS geladen: 3.40V
I [236] Spannungslevel (Batterie) fuer Kritisch-Warnung via Neopixel aus NVS geladen: 3.10V
E [239] Lautstärke vor dem letzten Shutdown wird wiederhergestellt. Dies überschreibt die Einstellung der initialen Lautstärke aus der GUI.
I [249] Initiale Lautstärke wurde aus NVS geladen: 5
I [260] Maximale Lautstärke für Lautsprecher wurde aus NVS geladen: 15
I [260] Maximale Lautstärke für Kopfhörer wurde aus NVS geladen: 1
N [271] Lautsprecher ausgeschaltet
I [271] Maximale Lautstärke wurde gesetzt auf: 1
I [335] Initiale LED-Helligkeit wurde aus NVS geladen: 50
I [335] LED-Helligkeit für Nachtmodus wurde aus NVS geladen: 0
_____ ____ ____ _
| ____| / ___| | _ \ _ _ (_) _ __ ___
| _| \__ \ | |_) | | | | | | | | '_ \ / _ \
| |___ ___) | | __/ | |_| | | | | | | | | (_) |
|_____| |____/ |_| \__,_| |_| |_| |_| \___/
Rfid-controlled musicplayer
Beim Moduswechsel Normal → Bluetooth wird immer ein Reset/Neustart ausgelöst, das ist „by design“.
Das Log sieht zunächst OK aus. Dann sollten aber die ersten BT-Scanmeldungen erscheinen. Deine Log-Ausgabe kommt direkt vom COM-Port? Weil Weblog ist im BT-Modus nicht verfügbar & enthält nach Neustart nicht die gewünschten Infos.
Das mit dem erweiterten Log finde ich gut! @thebino Evt. verwechselst du die Modi?
BT-Sink → Musik vom Handy auf den ESPuino-Lautsprecher streamen
BT-Source → Musik vom ESPuino auf einen Kopfhörer abspielen
Daher wird mit deinem Kopfhörer hier gar nix passieren. Du kannst dem BT-Modus auch entkommen, indem Du eine unbekannte Karte auflegst, CMD_TOGGLE_BLUETOOTH_SINK_MODE sollte aber auch funktionieren, wenn nicht ist es ein Bug.
Werd die nächsten Tage mal noch einen Versuch unternehmen, hab noch eine extra Platine da die erste Box ein Upgrade bekommt sobald die zweite fertig ist.
BT-Source & BT-Sink hatte ich tatsächlich anders verstanden. Werde es dann anpassen und tauschen
Es wird nun ein zusätzlicher Log-Eintrag für den geplanten Neustart ausgegeben, vielen Dank @thebino!
Der Neustart ist notwendig um den Speicher freizugeben, WiFi + Bluetooth zusammen sprengen den Speicher des ESP32…
Ich habe nochmal alle Bluetooth Modi im DEV-Zweig getestet:
Gute Nachricht: ESPuino als Lautsprecher (BT-Sink) funktioniert einwandfrei!
Schlechte Nachricht: ESPuino als Audioquelle für BT-Kopfhörer (BT-Source) hat deutliche Aussetzer. Ab und zu ist für eine halbe Sekunde kein Ton zu hören. Auch die Bedienung per Drehregler funktioniert nur sporadisch bis gar nicht.
Grund für die Aussetzer sind wohl die Neuerungen in der Audiobibliothek. Die hat neuerdings einen eigenen Task für asynchrone Wiedergabe.
Wir hatten aber schon immer einen eigenen Abspiel-Task, also haben wir jetzt eine Task im Task Situation. Wahrscheinlich kann man das nur wieder hinkriegen, wenn man den ESPuino Task „mp3play“ entfernt und das Ganze in die normale Arduino Loop() verschiebt.
Neuer Audio-I2S Task „PeriodicTask“ hier:
Bestehender ESPuino Abspiel Task „mp3play“ hier:
Ich erreiche eine bessere Bedienbarkeit (Drehgeber), wenn ich den „mp3play“ Task von Core 1 nach Core 0 verschiebe. Die Aussetzer bleiben aber.
Durch den Task im Task scheint die doppelte CPU-Zeit verbrannt zu werden.
Evt. gibt es hier einen FreeRTOS Experten der das besser erklären kann oder eine Lösung parat hat?
Gibt es Hoffnung, dass das irgendwann mal möglich sein wird, oder never ever? Wäre toll.
Ich habe dafür keine Erklärung, kann aber nur bestätigen, dass es mit dem DEV-Stand von vor einem halben Jahr noch einwandfrei ging, Wiedergabe und Drehregler. Gerade erst neue Kopfhörer für die Box angeschafft. D.h. wenn man Bluetooth Kopfhörer verwendet, sollte man derzeit nicht auf den aktuellen DEV gehen?
Es wäre schön, wenn man das Webinterface auch im Bluetooth Modus bedienen könnte. Aber ich glaube nicht, dass es möglich sein wird, WiFi & Bluetooth-Audio gleichzeitig laufen zu lassen, die teilen sich ja das Funkmodul. Vielleicht mit der neuesten ESP-IDF Version?
Die Audio Aussetzer konnte ich beheben: Der Audio/Bluetooth-Task verbraucht jetzt nicht mehr so viel Rechenzeit, dass es zu Aussetzern kommt, es war vielmehr ein fehlendes vTaskDelay(), um ein vernünftiges Task-Switching zu ermöglichen.
Außerdem wurde bisher jedes Audiosample einzeln in den Ringpuffer geschrieben. Jetzt wird der ganze Block mit einem Aufruf übertragen hier.
Frage an @wolle: Wir sind wahrscheinlich die einzigen, die diesen Callback benutzen:
Du hat recht, es sind immer 16 Bit und zwei Kanäle. Das ist seit der IDF V5… so, die I2S Einstellungen bereiten sonst nur Probleme.
Ich kann die überflüssigen Parameter gerne rausnehmen.
audio_process_i2s() wird gelegentlich für eine FFT Analyse verwendet, aber das ist selten.