Aktuelle Teilprojekte: MQTT, Fastled mit SPI und Audio ohne Task

Software
1

@Joe91 hat sich in der letzten Zeit viel Arbeit gemacht und irgendwie müssen wir das jetzt mal in gescheite Bahnen lenken und testen. Vieles davon dürfte in Musiktitel hüpft während des Abspielens vor, spielt weiter bis zum Titelende und stoppt dann dokumentiert sein, aber ich habe ehrlich gesagt den Überblick verloren.

Es geht, @Joe91 korrigiere mich gerne, um drei Dinge:

a) Die MQTT-Topics werden ab sofort dynamisch generiert
Das bedeutet, dass die Topics weiterhin die aktuelle Struktur haben, jedoch in settings.h nicht mehr ausformuliert sind. Dort findet man nur noch den Rumpf:

Topics
Topics1180×1270 240 KB

Der Zusammenbau erfolgt in mqtt.cpp, wobei der mittlere Teil von zB „Cmnd/ESPuino/Sleep“ dynamisch bestimmt wird. D.h. es wird die „MQTT-ClientId“ aus dem Webinterface verwendet.

@Joe91 Ich glaube DEVICE_HOSTNAME macht an dieser Stelle so keinen Sinn mehr, weil das wird nur erstmalig ausgelesen und dann nicht mehr, sobald es im NVS liegt. Mein Vorschlag wäre, das in der settings.h rauszunehmen und stattdessen die Mac-Adresse mit reinzubringen (irgendwie so ESPuino_MAC). @JHB hatte das auch mal vorgeschlagen: Neues Namensschema für MQTT - #22 von JHB. Dann ist es zumindest erstmal unique und kollidiert nicht mit anderen ESPuinos. Ich für meinen Teil würde diese ID gerne im Topic erstmal drin lassen. Das ist auf jeden Fall straight forward. Wer das anders haben will, der soll es sich halt umprogrammieren. Langfristig wollen wir die Topics aber eh im Webinterface machen und dann werden auch diejenigen glücklich werden, die das anders haben wollen.
@DexXxter007 Ich habe deinen PR zugemacht - aus dem Grund, den @Joe91 dort auch kommentiert hat.

b) Der Audiotask ist nicht mehr in einem eigenen Task und die Cmnd-Queue ist entfernt
@Joe91 Vielleicht kannst du ein paar Worte noch dazu sagen. Also was so die Vor- und Nachteile in deinem Testing waren.

c) Fastled mit SPI
War hier beschrieben: Musiktitel hüpft während des Abspielens vor, spielt weiter bis zum Titelende und stoppt dann - #83 von Joe91

@Joe91 Ich habe GitHub - Joe91/ESPuino at more_flexible_mqtt ausgecheckt und habe dich so verstanden, dass da quasi alles integriert ist. Getestet habe ich das Ganze erstmal nur auf meiner Complete (die von vor >2j). Dabei ist mir übrigens aufgefallen mit dem letzten dev-Stand, dass ich die Probleme mit dem Neopixel-Geblinke nicht nachstellen konnte. Also möglicherweise hat das mit der Sandwich-Konstruktion der mini4L auch zu tun. Ich muss das die Tage nochmal auf einer mini4L testen.

Hier aber nun meine Ergebnisse:

  • MQTT war ok soweit
  • Upload war auf dem aktuellen dev 511 kB/s zu jetzt (mit nun nicht mehr deaktiviertem LED-Task) 454 kB/s. Das ist jeweils der Mittelwert aus drei Tests.
  • Mit parallel laufendem mp3 mit 320 kBit/s, das hat mich beeindruckt, waren es immer noch 370 kB/s. Ich glaube es wurde nicht 100 Prozent fehlerfrei abgespielt, aber wenn, dann waren es nur ganz wenig Fehler.
  • Webradio hat funktioniert (nur eines mit 192 kBit/s getestet per http)
  • Neopixel war ok, keine Fehler
  • Aktuell Showstopper für mich, dass ich bei vielen mp3s Probleme mit Neustarts direkt beim Aufruf hatte:

N [295198] Modus: Einzelner Track
I [295204] info : Closing audio file „02_Fussball-Profi2.mp3“
N [295205] Neue Playlist mit 1 Titel(n) empfangen
D [295206] Free heap: 146628
I [295237] info : buffers freed, free Heap: 146320 bytes
I [295244] info : Reading file: „/mp3/01 - Crackdown.mp3“
I [295255] info : MP3Decoder has been initialized, free Heap: 122308 bytes , free stack 5308 DWORDs
N [295260] ‚/mp3/01 - Crackdown.mp3‘ wird abgespielt (1 von 1)
D [295635] no cover image for SD-card audio
I [295757] info : Content-Length: 11820753
I [295757] info : ID3 framesSize: 74268
I [295757] info : ID3 version: 2.3
I [295774] info : ID3 normal frames
I [295804] id3data : Title: Crackdown
I [295832] id3data : Artist: Marcus Intalex, Spirit
I [295856] id3data : Album: Crackdown
I [295882] id3data : ContentType: Dance & DJ
I [295906] id3data : Composer: Marcus Kaye
I [295931] id3data : Conductor:
I [295956] id3data : Track: 1/1
I [295982] id3data : Year: 2021
I [296006] id3data : Band: Marcus Intalex, Spirit
I [296056] id3data : Copyright: Metalheadz Ltd
I [296082] id3data : PartOfSet: 1/1
I [296212] info : Audio-Length: 11746485
CORRUPT HEAP: Bad tail at 0x3f8df260. Expected 0xbaad5678 got 0x00000000
assert failed: multi_heap_free multi_heap_poisoning.c:279 (head != NULL)

Backtrace: 0x40084a74:0x3ffb1da0 0x4008dab5:0x3ffb1dc0 0x4009193d:0x3ffb1de0 0x4009060f:0x3ffb1f20 0x4008514f:0x3ffb1f40 0x4009196d:0x3ffb1f60 0x4010127a:0x3ffb1f80 0x40102028:0x3ffb2100 0x40102556:0x3ffb2120 0x40108447:0x3ffb2170 0x400d3aed:0x3ffb21a0 0x400d4b2c:0x3ffb2230 0x400ee553:0x3ffb2250 0x4014b8c8:0x3ffb2270 0x4008de86:0x3ffb2290
#0 0x40084a74 in panic_abort at /Users/torsten/.platformio/packages/framework-espidf@src-b1208ff3612f5ed4a85e916decb6f42c/components/esp_system/panic.c:454
#1 0x4008dab5 in esp_system_abort at /Users/torsten/.platformio/packages/framework-espidf@src-b1208ff3612f5ed4a85e916decb6f42c/components/esp_system/port/esp_system_chip.c:87
#2 0x4009193d in __assert_func at /Users/torsten/.platformio/packages/framework-espidf@src-b1208ff3612f5ed4a85e916decb6f42c/components/newlib/assert.c:80
#3 0x4009060f in multi_heap_free at /Users/torsten/.platformio/packages/framework-espidf@src-b1208ff3612f5ed4a85e916decb6f42c/components/heap/multi_heap_poisoning.c:279 (discriminator 1)
#4 0x4008514f in heap_caps_free at /Users/torsten/.platformio/packages/framework-espidf@src-b1208ff3612f5ed4a85e916decb6f42c/components/heap/heap_caps_base.c:75
#5 0x4009196d in free at /Users/torsten/.platformio/packages/framework-espidf@src-b1208ff3612f5ed4a85e916decb6f42c/components/newlib/heap.c:39
#6 0x4010127a in PsramDeleter::operator()(void*) const at .pio/libdeps/complete/ESP32-audioI2S/src/psram_unique_ptr.hpp:18
(inlined by) std::__uniq_ptr_impl<char, PsramDeleter>::reset(char*) at /Users/torsten/.platformio/packages/toolchain-xtensa-esp-elf/xtensa-esp-elf/include/c++/14.2.0/bits/unique_ptr.h:205
(inlined by) std::unique_ptr<char, PsramDeleter>::reset(char*) at /Users/torsten/.platformio/packages/toolchain-xtensa-esp-elf/xtensa-esp-elf/include/c++/14.2.0/bits/unique_ptr.h:503
(inlined by) ps_ptr::reset() at .pio/libdeps/complete/ESP32-audioI2S/src/psram_unique_ptr.hpp:951
(inlined by) Audio::read_ID3_Header(unsigned char*, unsigned int) at .pio/libdeps/complete/ESP32-audioI2S/src/Audio.cpp:1958
#7 0x40102028 in Audio::readAudioHeader(unsigned long) at .pio/libdeps/complete/ESP32-audioI2S/src/Audio.cpp:1255 (discriminator 1)
#8 0x40102556 in Audio::processLocalFile() at .pio/libdeps/complete/ESP32-audioI2S/src/Audio.cpp:3375 (discriminator 1)
#9 0x40108447 in Audio::loop() at .pio/libdeps/complete/ESP32-audioI2S/src/Audio.cpp:2561
#10 0x400d3aed in AudioPlayer_Loop() at src/AudioPlayer.cpp:891
#11 0x400d4b2c in AudioPlayer_Cyclic() at src/AudioPlayer.cpp:246
#12 0x400ee553 in loop() at src/main.cpp:234
#13 0x4014b8c8 in loopTask(void*) at /Users/torsten/.platformio/packages/framework-arduinoespressif32-src-6738aaddd9fb901216d5f60e093380b6/cores/esp32/main.cpp:74
#14 0x4008de86 in vPortTaskWrapper at /Users/torsten/.platformio/packages/framework-espidf@src-b1208ff3612f5ed4a85e916decb6f42c/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:139

ELF file SHA256: ddf098565
E (10148) esp_core_dump_flash: Core dump flash config is corrupted! CRC=0x7bd5c66f instead of 0x0
E (10156) esp_core_dump_elf: Elf write init failed!
E (10161) esp_core_dump_common: Core dump write failed with error=-1
Rebooting…
ets Jul 29 2019 12:21:46

Ich wollte dann ein „Full Clean“ machen, bin aber im Bauprozess in einen Fehler gelaufen, der glaube ich aktuell auch unseren Bauprozess auf GitHub verhindert:

[25/25] idf (5.4.1)
– DEBUG: Use esp-modbus component folder: /Users/torsten/Development/Platformio/Projects/ESPuino/managed_components/espressif__esp-modbus.
– Configuring incomplete, errors occurred!

fatal: not a git repository (or any of the parent directories): .git
CMake Error at /Users/torsten/.platformio/packages/framework-espidf@src-b1208ff3612f5ed4a85e916decb6f42c/tools/cmake/component.cmake:254 (message):
Traceback (most recent call last):

File „“, line 198, in _run_module_as_main
File „“, line 88, in _run_code
File „/Users/torsten/.platformio/penv/.espidf-5.4.1/lib/python3.11/site-packages/idf_component_manager/prepare_components/main.py“, line 6, in
main()
File „/Users/torsten/.platformio/penv/.espidf-5.4.1/lib/python3.11/site-packages/idf_component_manager/prepare_components/prepare.py“, line 130, in main
args.func(args)
File „/Users/torsten/.platformio/penv/.espidf-5.4.1/lib/python3.11/site-packages/idf_component_manager/prepare_components/prepare.py“, line 41, in inject_requirements
).inject_requirements(
^^^^^^^^^^^^^^^^^^^^
File „/Users/torsten/.platformio/penv/.espidf-5.4.1/lib/python3.11/site-packages/idf_component_manager/core.py“, line 98, in wrapper
return func(self, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File „/Users/torsten/.platformio/penv/.espidf-5.4.1/lib/python3.11/site-packages/idf_component_manager/core.py“, line 835, in inject_requirements
requirements = requirements_manager.load()
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File „/Users/torsten/.platformio/penv/.espidf-5.4.1/lib/python3.11/site-packages/idf_component_manager/cmake_component_requirements.py“, line 95, in load
with open(self.path, encoding=‚utf-8‘) as f:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

FileNotFoundError: [Errno 2] No such file or directory:
‚/Users/torsten/Development/Platformio/Projects/ESPuino/.pio/build/complete/component_requires.temp.cmake‘

Call Stack (most recent call first):
/Users/torsten/.platformio/packages/framework-espidf@src-b1208ff3612f5ed4a85e916de
cb6f42c/tools/cmake/build.cmake:644 (__component_get_requirements)
/Users/torsten/.platformio/packages/framework-espidf@src-b1208ff3612f5ed4a85e916decb6f42c/tools/cmake/project.cmake:717 (idf_build_process)
CMakeLists.txt:3 (project)

@tueddy In den Fehler bist du auch gelaufen, oder?
@Joe91 Hattest du da keine Probleme mit?

4 „Gefällt mir“
2

Achso: Mir geht’s hier drum, dass sich ein paar Leute an der Diskussion beteiligen und wir das in ein Stadium überführen, dass das bald in den dev-Zweig integriert werden kann. Oder eben nicht, wenn schwerwiegende Probleme weiterhin auch in Zukunft auftreten.

3

Find ich sehr gut und wäre dabei! Muss das mal vom @Joe91 testen. Hätte ja auch Auswirkungen auf die Home Assistant Integration :wink: aber ich denke eher im positiven Sinne da es vieles vereinfachen würde.

Ich hatte mit @Joe91 schon deswegen Kontakt und würde da mal anknüpfen vielleicht im engen Austausch mit ihm!?

4

Also das letzte Problem habe ich bei mir lokal gelöst:
Da fehlt das python-Modul „rich“. Habe das lokal bei mir in einem Userverzeichnis/.platformio nachinstalliert mittels

python3/bin/python3 -m pip install rich

Dann konnte ich das Projekt bauen.
Aber so ganz verstanden habe ich es nicht. Also man kann, wenn man dieses Modul nicht hat, den Fehler triggern, „full clean“ ausführt und, wenn nötig, in .pio/build das komplette Verzeichnis löscht, wo für das ausgewählte env drin gebaut wird. Bricht der Bauprozess ab, wegen des bekannten Fehlers, dann kann man ihn jedoch wieder starten und danach läuft’s durch!?

Also die Frage ist, wie wir dieses Modul in unseren Bauprozess integriert bekommen. Hab’s eben versucht, aber hat nicht geklappt. Bin jetzt mal im :bed:.

5

Vielen Dank dir!
Die Audio-Probleme kamen in die neue Audio-Lib rein, weshalb ich diese auf zumindest einem Branch wieder reverted habe, leider war der Mqtt-Branch noch davon betroffen. Habe ich auch dort korrigiert. Hier ist der Issue dazu:

zu 1) Mqtt:

  • finde den Vorschlag von @JHB von hier gut: Neues Namensschema für MQTT - #22 von JHB
    Wenn das allgemeine Zustimmung findet, könnte man das auf diesem Branch noch mit einbauen und wäre glaub sehr gut und komfortabel für die Zukunft aufgestellt.
  • Zusätzlich habe ich jetzt auf dem Mqtt-branch noch den Zustand „PlayPause“ ausgegeben, da das uns eine deutlich schönere Integration in z.B. Home-Assistant o.ä. ermöglicht. Aber auch dieser Punkt ist zur Diskussion :slight_smile: …

zu 2) Audio-Task auflösen:

  • war ursprünglich ja der Wunsch von @Wolle und ist bezüglich dem Overhead des Tasks und der Queues auch wirklich Sinnvoll, da es uns zusammen mit der jetzt neuen Verteilung der Tasks auf die Cores viel Luft für die Zukunft gibt und zeitgleich den Audio-Teil sauber vom Rest trennt und somit deutlich robuster machen sollte, und bei mir auch nachhalitg die Audio-Probleme gelöst hat.
  • Zusätzliche Optionen wie das parallele Uploaden und Abspielen und den LED-Task nicht mehr anzuhalten sind zur Diskussion (ich bevorzuge klar den Fall, dass alles unengeschränkt weiterläuft und man dafür etwas langsamer uploaden kann, das ist aber Geschmacksache).
  • Die Aufteilung auf einen „dreckigen Core“ und einen „sauberen Core“, auf welchem nur noch der Arduiono-Loop-Taks und der Audio-Task läuft halte ich für eine sehr gute und zukunftsfähige Lösung, bei der wir nicht bei jeder Änderung wieder über die Tasks nachdenken müssen sondern pauschal einfach alles neue auf Core 0 packen können, ohne dass wir dadurch negativ im Kern unserer Funktkionen einbüsen / verschlechtern. Durch nur noch ein Delay im Loop-Task (war mal eine Lösung für die LEDs das aufzuteilen), gewinnen wir zusätzlich noch ordentlich Luft.

Aufgrund dieser verschiedenen Facetten, ist das hier vermutlich der größte Brocken, auch wenn ich die Änderungen sehr überschaubar finde.

Zu 3) LEDs:
Das ist ja leider kein neues Thema, sondern kam immer wieder hoch (auch in der Vergangenheit), wurde jetzt aber unter Arduino 3 leider nochmal sehr viel schlechter, da dort die RMT-Treiber von Espressiv umgebaut wurden. Ich wollte hier jetzt nicht einfach nur wieder eine Lösung, sondern was möglich robustes und zukunftsicheres:

  • Fast-Led bietet die Möglichkeit die LEDs auf dem ESP auch per SPI anzusteuern, was ich auch in der Vergangenheit schon auf anderen CPUs genutzt habe und immer sehr stabil war.
  • Damit das möglich ist, mussen in FastLED ein paar Anpassungen rein, diese sind dort jetzt aber im master
  • Ein Bug auf Seiten von espressiv hat hier auch zu problemen geführt, mit dem „Hack“ sind wir hier jetzt aber deutlich besser dran und brauchen auch weniger CPU-Last für den Task, da wir nicht abwarten bis alles übertragen wurde.

Diese Lösung unterscheidet sich von allen vorherigen dadurch, dass es jetzt völlig egal ist, wie und wie oft der LED-Task unterbrochen wird oder auf welchem Core er läuft, was uns die Vorteile von der neuen Task-Aufteilung die ich unter 2) beschrieben habe erst ermöglicht. Da die RFID-Reader auf die andere noch verfügbare SPI-Schnittstelle gehen, sollte das kein Konflikt sien, habe bei mir aber nur den PN5180 und konnte deshalb den anderen Reader nicht testen.

Soweit mal dazu :smiley: …

Den LED-PR habe ich mal komplett separat rausgezogen. Trotzdem ist es für mich eher ein Gesamtkonzept :wink: … Bei interesse kann ich auch den MQTT-PR noch separieren, der Prio nach sehe ich den Audio-Task aber wichtiger als die Mqtt-Änderungen.

Bin gespannt auf eure Rückmeldungen und Diskussionen!

5 „Gefällt mir“
6

Ja genau, ich kann im Moment den DEV mit Arduino 3.2.0 nicht compilieren.
pip install rich meldet das Modul sei schon installiert. Ich habe PIO komplett neu aufgesetzt, der Fehler bleibt. Arduino 3.1.3 dagegen funktioniert einwandfrei.
Würde hier vorschlagen noch auf Bugfix bzw. das nächste Release zu warten, kann nicht mehr lange dauern. Ich kann erst richtig testen, wenn meine Umgebung wieder läuft.

7

Zu 1) So im Nachhinein halte ich es ja für einen Fehler, dass in den MQTT-Topics immer cmnd/state vorne steht. Eigentlich wäre sowas wie (Device)/(cmnd/state)/typ logischer, aber ich meine ich habe mich damals von Tasmota inspirieren lassen.
Wie auch immer: Langfristig wollen wir die Topics im Webinterface haben, für hier und jetzt kann ich aber auf jeden Fall nachvollziehen, dass man die „Topic-Bildung“ etwas komfortabler hätte. Ob da jetzt Device- oder Hostname verwendet wird, ist mir eigentlich egal. Wichtig finde ich nur, dass wir dann DEVICE_HOSTNAME da wegnehmen. Weil das suggeriert, dass man das dort konfigurieren kann. Stattdessen wird das ja nur einmalig zum Setzen im NVS verwendet.
=> Auf jeden Fall muss dafür gesorgt werden, dass im Auslieferungszustand die Topicbildung unique ist.

Zu 2) Ja, vermutlich macht Task in Task keinen Sinn, weil das auch niemand mehr überblick kann. Wir werden von Wolle da auch wenig Support erwarten können, wenn wir das weiterhin so betreiben - im Falle der Fälle. Also ich bin offen dafür. Wie siehst du das, @tueddy?

Zu 3) Muss ich wie gesagt nochmal auf der mini4L testen. Auf der Complete hatte ich auch im dev keine Probleme, wo ich vorher Blinken gesehen hatte.

Ich fand’s tatsächlich mit den ganzen Commits auch unübersichtlich gestern. Also generell fänd ich es gut, wenn die Commit-History geradliniger wäre. Also da ist ja auch reichlich try and error drin. Weiß nicht, ob da ein Squash-Commit besser wäre oder ob man das, was man jetzt hat, nochmal aufdröselt in geordnet.

Den letzten Commit wegen der Audiolib muss ich erst noch testen.

8

Ich hatte auf dev auch das Problem mit dem fehlenden 'rich'. Ich hab herausgefunden, man muss das dann nicht einfach per pip installieren, sonder die pip aus dem /<user>/.Platformio Ordner.

9

Ja genau, das hatte ich ja oben auch geschrieben. Die Frage ist, wie man das in den Bauprozess integriert. Auf Github hat das, wie ich es gestern versucht habe, auf jeden Fall nicht geklappt. Aber ich habe auch keine Ahnung von python und die Lösung kam aus chatgpt.

10

Zusätzliches setup.bat als pre Skript das genau das macht? bzw .sh bei Mac/Linux

11

Die LED-Änderung sind jetzt bereits separiert als PR vorbereitet.

Daher mein Vorschlag: Fangen wir doch mit den LEDs an, testen und evaluieren das erstmal für sich.
Wenn das durch ist, kann ich den Audio-Task-PR nochmal als neuen und Clenen PR erstllen (mit einem oder zwei commits), wenn wir bis dahin eine Entscheidung getroffen haben, wie wir mit dem parallelen upload und Wiedergeben umgehen möchten (vor Allem eine Entscheidung Komfort vs. Upload-Speed). Ich bevorzuge den Komfort des parrallelen Uploads während der Wiedergabe, das könnten wir aber vielleicht sogar umschaltbar machen (auch wenn ein Teil davon im platformio.ini selbst ist).

Wenn dann auch das durch ist kann ich (oder jemand anderes) sich nochmal an den MQTT PR machen.

Weitere Funktionen und Erweiterungen (habe z.B. mit gleichzeitigem Webserver und Bluetooth gespielt :wink: ) werde ich erst nach den drei hier erwähnten Punkten weitermachen, da es wirklich zu viel Verschiedene Sachen sind aktuell :slight_smile: …

Bin jetzt erstmal 1,5 Wochen im Urlaub, vielleicht gibt es ja bis dahin paar Rückmeldungen :smiley: .

1 „Gefällt mir“
12

Das habe ich gestern versucht:

Aber der Build ist wieder in den gleichen Fehler gelaufen. Vielleicht ist der Weg richtig, aber die Umsetzung falsch.

13

weil wahrscheinlich das falsche pip genommen wird…

14

Macht’s einen Unterschied, ob man

pip3 …Kommando

oder

python3 -m pip …Kommando

ausführt?

Im Log bei Github (Build all boards · biologist79/ESPuino@8282d87 · GitHub) steht eigentlich auch drin (soweit ich das verstehe), dass rich installiert wurde:

Install
Install2266×314 61.4 KB

15

wie immer, it depends :wink:
(Hintergrund Python unterstützt mehrere Versionen sowohl von Python selber aus auch von den Libs über Virtual Envs, keine Ahnung wie pio das macht)

Ich würde es wie oben geschrieben mal mit der pip aus dem pio Ordner probieren

16

Also ich habe mir den Audio-Task-PR eben mal angeschaut. Dort ist nix mehr abgestürzt.
Ich habe mal Uploads durchgeführt:

  • Direkt nach dem Starten, noch nix gelaufen: 421 kB/s
  • Während ein laufender Track pausiert ist: 346 kB/s
  • Während Abspielvorgang: 321 kB/s

Wieder getestet auf der Complete. Kein MQTT aktiviert.

1 „Gefällt mir“
17

Ich behaupte das ist gar nichts was bei espuino gefixt werden müsste, sondern in dem (inoffiziellen) espressif platform package. Am einfachsten ist wohl einfach zunächst hierauf zu wechseln:
platform = https://github.com/pioarduino/platform-espressif32/releases/download/53.03.13/platform-espressif32.zip ; Arduino 3.1.3 (ESP-IDF 5.3.2)

Wenn man aber das nötige Paket unbedingt installieren will, muss man pip in der richtigen Umgebung ausführen. Ich musste auch ein wenig suchen, aber scheinbar verwendet platformio für pioarduino ein geschachteltes virtualenv. Unter Linux kann man das folgendermaßen reparieren:

Im VSCode Terminal (also bereits im venv) folgendes ausführen:

source ~/.platformio/penv/.espidf-5.4.1/bin/activate
pip install rich
18

Bei mir hat sich das Compiler-Problem mit dem neuen Arduino Release 3.2.1 erledigt:

platform = https://github.com/pioarduino/platform-espressif32/releases/download/54.03.21/platform-espressif32.zip ; Arduino 3.2.1 (ESP-IDF 5.4.2)

Könnt ihr das bestätigen?

19

Ich teste das heute Abend mal.
Danke für die Info. Muss dann auch mal den Branch ohne Audiotask testen, so dass wir hier wieder weiterkommen.

22

Also ich kann bestätigen, dass sich das ohne Probleme kompilieren lässt.
Hatte heute Morgen Probleme; vermutlich waren da irgendwelche Services irgendwo down.

Am Ende des Kompilierens kommt jetzt eine Statistik und der Flashvorgang sieht anders aus. Nice.