Danke erstmal für das Verlinken dieser Lib. Die Funktionsweise sieht mal interessant aus.
Ja ich denke, da laufen inzwischen einfach zu viele Sachen auf dem ESPuino und somit ist loop() einfach nicht mehr schnell genug. Aber die aktuelle Encoder-Behandlung läuft auch schon über Interrupts.
Wem galt diese Frage? Demletzt hatte hier jmd. dieses Problem und dann lag es daran, dass GPIOs doppelt vergeben waren.
@RC522 & SPI nach Deep Sleep:
Das war an niemanden spezifisch gerichtet. Über SPI sind natürlich die MISO,MOSI, SCK pins die selben wie bei der uSD. CS ist natürlich anders.
Es funzt ja auch vor dem Deep-Sleep. Vielleicht wird der SPI-Bus resetted oder eine referenz geht flöten nach dem aufwecken? Wie gesagt, hab noch nicht hingekuckt.
edit: Hab mir das schnell mal angeschaut. Beim schlafengehen passiert garnix in meinem Fall. Weder für die SD, noch für RFID. Vielleicht fehlt also nur ein weiterer Reset für den RC522 vor dem Init?
edit2: Nein, der antwortet brav, und hört auch auf Kommandos. Beim Init passiert ja ohnedies ein Soft-Reset. Ich hab bemerkt dass im RFID_Cycle() der Aufruf PICC_IsNewCardPresent() nach dem deepsleep immer false zurückgibt.
Hier funktioniert auch deep sleep mit der selben Hardware mit ESP-IDF und dem RC522 sauber. Hier hatte ich Gelegentlich Probleme mit der uSD-Karte. Aber das Problem sehe ich hier nicht. Immerhin. 
@ Rotary:
Also im Code den ich habe sehe ich für den Rotary-Encoder nichts mit Interrupts. Beim Port Expander schon. Auch wenn ich das direkt handle, tut es nicht richtig. Der Code hat eine etwas andere State-Table, aber im Prinzip sollte das nach ein paar Drehungen egal sein.
Ich werde da mal weiter testen.
Grundsätzlich freut es mich aber schon, dass der ESPuino mit diesem Board funktioniert! Das Web-Interface und einige andere Features sind schon sehr praktisch!
Also mit eigenem Interrupt und Task hat es leider nicht funktionert. Dabei ist alles analog zu meinem Code der ESP-IDF. Schade.
PlatformIO tut wohl zu viel im Hintergrund, die Loop() ist definitiv viel zu langsam. Vielleicht gibts da irgendwo einen Stack Overflow, aber da gibts doch eine Exception bzw. einen crash mit entsprechendem Dump dazu. Oder wurde auch das in PIO deaktiviert? Wie sieht es mit den Hardware Watchdogs aus…? Laufen die? Also wird da was abgewürgt wenn ein Task zu lange läuft?
Sorry, ich bin da etwas planlos. Die grosse Suche im Internet hat auch nicht wirklich was gebracht… 
Arduino meinst du, oder? Platformio hat damit nix zu tun. Tja, es ist halt so, dass inzwischen doch einige Sachen laufen. Besonders lang werden die Delays, wenn man den PN5180 verwendet (trotz State-Machine). Speziell die RFID-Sachen sind bis vor ein paar Monaten in Tasks gelaufen. Der PN5180 reagiert gefühlt jedoch besser, wenn er nicht im Task läuft. Deswegen sind RC522/PN5180 inzwischen aus den Tasks befreit und laufen in der main-loop.
Ich habe keine Watchdogs deaktiviert. Überwacht werden Tasks auf jeden Fall. Beispiel:
Läuft ein Task viel zu schnell aufgrund einer klassischen Endlosschleife, dann nimmt sie so viel Rechenzeit in Anspruch, dass der Rest gegen die Wand fährt. Beim Audiotask ist, so lange Musik dekodiert wird, alles gut. Drückst du jedoch Pause, dann läuft der Task so schnell, dass der WDT ziemlich schnell greift. Deswegen ist an der gezeigten Zeile ein Delay drin.
Was man halt noch machen kann, ist den WDT quasi zwangsweise zu „füttern“, wie hier z.B.
Aber inzwischen habe ich gelernt, dass es eigentlich besser ist, wenn möglich, mit Delays zu arbeiten. Ggf. ist der Reset an dieser Stelle auch gar nicht mehr notwendwig.
Ui, ok. Sowas sollte eigentlich hier nicht nötig sein. Das kann man vermutlich sauberer coden. Die watchdog timer verhindern ja nur, dass es zu einem deadlock oder spinlock kommt.
Tasks sind grundsätzlich besser als die main loop().
Tasks können flexibel auf die 2 Cores verteilt werden. Die loop() nicht.
Ich habe da schon einen Verdacht, warum mein Task so nicht läuft. Vielleicht komme ich dazu, das die Tage zu reparieren. Das ist leider das einzige was mich davon abhält, espuino wirklich produktiv zu verwenden.
Das Gehäuse ist so gut wie fertig…
Ich bin da für Verbesserungen völlig offen.
Dessen bin ich mir bewusst, deswegen werden die Tasks, die implementiert sind, ja auch an Cores gepinnt. Wie gesagt: Der PN5180 hat gefühlt im Task träger reagiert. Ist alles hier im Forum dokumentiert.
Also mit dem Rotary encoder über den MCP23017 verzweifle ich hier.
Ich hab jetzt einiges versucht:
Das beste was ich erreichen konnte, ist das i2c zwar funktioniert hat, aber irgendwann Fehler warf. Das „stabilste“ Verhalten ist dass ich über i2c nach zu schnellen Events nur noch 0xff lese, egal was wirklich anliegt. Das liegt wohl an der Software-Implentierung von I2C in Wire.
Mit buttons funktioniert das auslesen über die main-loop() schnell genug. Für den Rotary ist das zu langsam, hier gehen Events verloren, damit reagiert das furchtbar bzw. unbrauchbar. 
Gut, jetzt könnte ich natürlich den Rotary rauswerfen und nur mit Buttons arbeiten… Oder versuchen, den Rotary Encoder irgendwie an normale GPIOs anzubinden. Nur wird das ohne Hardware-Umbauten nicht möglich sein.
…oder möglichst viel per I2C anbinden.
Das ist für fertige Audio Boards glaube ich generell ne gute Idee. Die meisten führen I2C Pins nach außen.
Rfid geht per I2C, dann hättest Du evtl Pins für den Rotary frei.
Buttons / Powerswitch per I2C → MCP23017
Rotary per I2C I2C Encoder Mini – DuPPa
…
Aber alles Bastelaufwand 
Ja, da widme ich mich vorerst lieber der Software. Also meiner Lösung mit esp-idf.
Vielleicht ist mit arduino-esp32 2.0.0 was besser, mal sehen.
Ich hatte es demletzt mal in der platformio.ini aktiviert, bin dann aber doch in zahlreiche Fehler gestoßen. Da werde ich mal noch ne Runde warten, bis die Libs drauf angepasst sind.
Ja, hab ich gelesen. Extra Hardware wäre schon ne Mögliichkeit, aber was mich frustriert ist, dass es direkt mit der ESP-IDF ja funktioniert.
Ich widme mich wieder den fehlenden Features, und arbeite weiter direkt mit der ESP-IDF.
Also, nach längerer Pause bin ich inzwischen bei einem funktionierenden Prototypen, zwar auch mit WiFi, aber ohne web-interface.
Lokales Playback funktioniert gut, codecs werden automatisch erkannt und dekodiert etc.
Ich habe dann doch noch ein entsprechendes API von Espressif gefunden (nennt sich einfach „ESP Audio“), das sich um viele Details kümmert. Das funktioniert eigentlich sehr gut.
Deep Sleep, SD Karte und RC522 laufen auch stabil. Bei SPI konnte ich einige Heap-Fehler in meinem Code entdecken und lösen, sodass jetzt die Grundfunktionen stabil sind.
Sobald mein Gehäuse ganz fertig ist, stell ich auch mal ein Bild davon rein. 