Ja das mit SDFat hatte ich gesehen. Hatte gestern deine Lib jedoch nicht aktualisiert und daher sind mir da keine Probleme aufgefallen.
Wie auch immer: Dann sollte es jetzt ja wieder laufen 
@kkloesener ist jetzt auch hier habe ich eben durch Zufall gesehen. Er hat damals meine Vorarbeiten zum ESP32-A1S verwendet und sie in meinen Hauptzweig integriert.
Herzlich willkommen
1 „Gefällt mir“
Ich habe es endlich auch hierhin geschafft Kinder und so 
Dann auch endlich mal den aktuellen Stand des Projektes auf dem Board bei mir wieder zum Laufen gebracht. Meine verwendeten Libraries sind teilweise auch aktualisiert worden, um die korrekte Verwendung der TwoWire-Lib zu ermöglichen, wenn noch mehr I2C Geräte dazukommen sollen, also z.B. ein Touch-Board(Adafruit MPR121) oder auch ein OLED.
Das Touchboard steht bei mir als nächstes auf der ToDo-Liste.
Ich freue mich schon auf viele neue Ideen hier aus dem Forum 
@kkloesener Auf meinem Board habe ich den SPI Kartenleser durch einen mit I2C ersetzt. Dazu habe ich Deine Lib benutzt, funktioniert prima, danke dafür. Und nun habe ich GPIOs für zwei Tasten frei 
schön zu hören @Wolle
ich habe gerade noch einen neuen Commit der Lib’s und des aktuellen Codes gemacht inklusive Merge-Request, da im aktuellen Code von @biologist nicht alles ganz rund ist für den Betrieb mit RFID via I2C.
Jetzt stürze ich mich auf die Implementierung der Touchbutton
@kkloesener ist habe das gemerged. Zwei Punkte:
a) Was bedeuten eigentlich die Nummern 198 und 199 in der Config? Ich habe mich da bisher nicht drum geschert, aber jetzt würde ich es gerne wissen
b) Die Libs für i2c und spi beeinflussen sich irgendwie. Also aktuell lässt sich das für SPI z.B. nicht kompilieren, weil die SPI-Lib nie geladen wird. Kopiere ich sie jedoch von Hand rein, dann knallt es beim Kompilieren anderweitig. Ist jetzt die Frage, ob sich das lösen lässt. Du hattest ja ein Flag in die platformio.ini aufgenommen, welches ich kürzlich entfernt hatte. Irgendwie sind das aber beides keine gescheiten Lösungen. Also bei der alten Lösung wurde es einfach gesetzt und die Config übergangen. Jetzt wird die Config nicht mehr übergangen, aber man kann es nicht mehr kompilieren mit SPI. Also wenn das nicht zu vereinen ist, dann muss man den Benutzer irgendwie besser drauf hinweisen denke ich.
Vielleicht hat ja wer Ideen.
Das ist auch auf meiner TODO-Liste. Mit Interrupt und aufwachen aus dem Deep-Sleep.
EDIT: eventuell lässt sich auch ein Bit der dynamischen Button-konfiguration dafür benutzen, ob Touch verwendet wird?!
zu a) Das sind auch nur Platzhalter.
zu b) habe ich gerade mal geprüft und ich denke es liegt daran, dass die Library zwar einen anderen Dateinamen hat, aber dennoch intern als MFRC522 benannt ist. Und bei gleicher HAL müssten je nach gesetzten Flags unterschiedliche Libs geladen werden. Die absolut sauberste Lösung wäre, wenn es nur eine Lib für beide Kommunikationsprotokolle gäbe. So könnte auch für andere Boards variable alles verwendet werden.
Das würde ich mir am Wochenende mal ansehen, ob ich das implementiert bekomme.
EDIT: Als Zwischenlösung wäre ggf. anzudenken in der platform.io die lib_deps alle wieder global zu pflegen. Dort ist ja weitestgehend alles redundant, bis auf ESP32-A1S. Aber selbst die zusätzlichen Librarys sollten bei den anderen Boards nicht stören.
1 „Gefällt mir“
Hallo @Wolle, auch wenn Du jetzt auf den I2C Kartenleser umgestiegen bist, hier noch eine Frage zur SPI Anbindung. Ich hatte ja Deine GPIOs bei mir so übernommen:
//SPI Version
#define RFID_SCK 12
#define RFID_MISO 13
#define RFID_MOSI 22
#define RFID_CS 5
Das klappt nun auch alles (… und jetzt auch mit zwei Tastern, über die „gekaperten“ GPIOs 4 und 36), jedoch macht das Kabel des Encoders einen ziemlich „Spagat“: Zwei Leitungen zu GPIO 12 und 13 am JTAG Anschluss und GPIO 5 und 22 bei den herausgeführten Pins. Ich hatte jetzt mal stumpf versucht, GPIO 12 und 13 für die zwei Buttons zu verwenden, und GPIO 19 und 21 für den Drehencoder zu nutzen (RFID_SCK und RFID_MISO). Das klappte nicht - es kam einfach kein Sound „hinten raus“, wobei der restliche Output über den Monitor-Port unverdächtig aussah. Bevor ich jetzt die endgültigen Stecker crimpe wollte ich nur schnell nochmal nachhören, ob man nicht doch die kompletten Drehencoder-Leitungen an die rausgeführten Pins (GPIO 21, 22, 19, 23, 18, 5) anbinden kann.
Johannes
Hallo Johannes, schön zu hören wenn alles gut funktioniert. Bei dem Drehenkoder hatte ich zum Anfang eigenartige Effekte festgestellt. Je nach Drehposition liegen an CLK und DT entweder Vcc oder Masse an. Das bedeutet mal funktioniert es und mal nicht. Ich habe mich für die GPIOs 18 und 19 entschieden, das ist unkritisch. Pin 12 und 13 sind mit dem SPI Kartenleser gut verbunden. Wenn Du den Drehencoder an GPIO 4,12 oder 13 anschließt kann es sein, dass die SD Karte nicht richtig initialisiert wird.
GPIO4 kann für einen Button verwendet werden, es muss halt ein Draht angelötet werden.
vG Wolle
So, ich habe gestern die ESPuino Box auf Basis des ESP A1S fertiggestellt. Die Anbindung des RFID Kartenlesers RC522 erfolgt über SPI. Um die Stecker auf der Platinenseite einigermaßen sinnvoll zusammenzuführen, habe ich mich auf folgende Belegung festgelegt (linke Spalte GPIO, rechte Spalte die Konstanten aus der settings-espa1s.h):
Die Play/Pause Taste fehlt, diese Funktion wird durch den kurzen Druck auf den Encoder abgebildet. Das passte ganz gut, da ich alles in ein CubieKid Gehäuse (CubieKid - a cute MP3 player box by db3jhf - Thingiverse) eingebaut habe, und dort eh recht wenig Platz auf der Oberseite ist und der Encoder nun zwischen den beiden verbliebenen Tastern gelandet ist.
Hier noch ein paar Notizen:
- Das Loch für den mittleren Button musste ich mit einer Plastikkarte verkleinern, so dass der Drehencoder dort halt gefunden hat. (Anmerkung: Ich habe das Gehäuse nicht selber mit einem Lasercutter hergestellt, sondern die Holzteile fertig geschnitten bei Watterott gekauft. Sonst hätte man das Loch für den Drehencoder sowie eine Aussparung für die Neopixel-Leiste natürlich direkt berücksichtigen können).
- GND und 3,3 V für den Encoder hole ich von der Unterseite der Platine, da nicht genügend Pins GND und die Spannung herausführen.
- GPIO 4 lässt sich ja ganz gut über den zweiten Pin von oben vom SD card reader abgreifen. Das hatte @biologist weiter oben ja schon auf einem Foto gezeigt.
- GPIO 36 lässt sich sehr gut an dem Kontakt des (ausgelöteten) R55 abgreifen; siehe Foto.
- Wie @Wolle empfohlen hatte, habe ich in PlayAudio noch das Erzwingen von Mono und das Anheben der Tiefe eingebaut:
#ifdef PLAY_MONO
audio.forceMono(true);
audio.setTone(3,0,0);
#endif
- Der Strom zu den Komponenten (z.B. den Neopixel) wird ja vom Board nicht abgeschaltet. Beim aktuellen Stand leuchteten auch im Deepsleep einige LEDs weiter. Hier fehlte noch das true bei der FastLED.clear(), das bewirkt, dass die Werte auch an die LEDs rausgeschrieben werden (siehe https://github.com/FastLED/FastLED/blob/b5874b588ade1d2639925e4e9719fa7d3c9d9e94/src/FastLED.h#L504)
if (gotoSleep) { // If deepsleep is planned, turn off LEDs first in order to avoid LEDs still glowing when ESP32 is in deepsleep
if (!turnedOffLeds) {
FastLED.clear(true);
turnedOffLeds = true;
}
- Die Einbindung der 8 LEDs der Neopixel-Leiste in das Gehäuse setzte eine kleine Modifikation mit einem Stechbeitel voraus. Dann ließ sich das prima integrieren.
- Als Akku setze ich eine 18650 Industriezelle (2600 mAh, mit Schutzschaltung) ein. Diese wird von dem Laderegler auf dem Board mit > 1 A geladen. Der Ladestrom reduziert sich mit der Zeit. Das klappt also schon mal gut. Die Zelle passt schön schlank noch neben das Board.
- Ein offener Punkt ist, ob man irgendwie an die Spannung der Batterie herankommt. Hier bin ich für einen Hinweis dankbar.
Insgesamt bin ich jetzt recht zufrieden. Der ursprüngliche Ansatz, Lötarbeit einzusparen, da auf dem Board ja schon Verstärker, Laderegler und SD-Kartenleser enthalten sind relativiert sich durch die Frickelei die Widerstände auszulöten und vor allem die Drähte für GPIO 4 und 36 anzulöten. Und Platz zu finden für einen entsprechenden neuen Stecker. Hier lohnt es sich wohl, auf die I2C Anbindung für Kartenleser und Port Expander zu setzen. Ich werde diese Box jetzt aber mal so lassen wie sie ist. Keine Zeit - Kinder und so…
Danke nochmal für die vielen Hinweise oben, ohne die ich nicht ans Ziel gekommen wäre.
PS: Meine kleinen Modifikationen finden sich im Fork https://github.com/jpellenz/ESPuino, der aber wahrscheinlich nicht weiter gepflegt wird.
2 „Gefällt mir“
Das ist halt ein Punkt, den ich auch schon öfter angemerkt habe. Also gefühlt ist man fast am Ziel, aber so in der Praxis sieht es etwas anders aus 
Aber danke für deine Ausführungen. Speziell die Sache mit der LED-Abschaltung werde ich bei mir dann auch einbauen. Und in Sachen mono/stereo habe ich ja eh noch einen Punkt offen.
Ich denke am universellsten kommt man raus, wenn man SD_MMC benutzt und via i2c den Port-Expander und RFID-Reader dranhängt. Da müsste man mit den GPIOs „spielend“ hinkommen.
Auch in Richtung eigene Platine ist das meiner Meinung nach ein guter Ansatz. Auf die Platine (oder besser Schaltplan) kommt dann RFID, Encoder, Buttons, DAC, … und alles per I2S und I2C angebunden. Dann kann man sehr individuell ein DEV-Board verwenden oder einen ESP32 direkt. Bei diesem Board hier lässt man entsprechend den DAC weg.
leider benötigt der PN5180 SPI und zusätzliche Pins, so dass nach SD_MMC, PN5180 & Port-Expander selbst bei einem anderen DEV-Board nicht mehr viele Pins übrig bleiben (beim ESP32-A1S ist’s sowieso zu knapp) .
Mit SingleSPI kann man noch etwas rausholen und ich habe mir mal angeschaut, was nötig wäre, um den Rotary-Encoder an den Port-Expander anzuschließen.
Touch-Buttons und LEDs wären nämlich auch cool.
Mit dem PN5180 muss man mal schauen. Ich hatte ja demletzt schon gesagt (nachdem Wolle das gewissermaßen losgetreten hat), dass der RC522 offenbar besser performt, wenn man ihn aus dem Task rausnimmt. Möglicherweise macht das den PN5180 ein Stück weit überflüssig. Ich denke ich muss das mal im ESPuino meines Sohnes testen.
Eigentlich hätte ich das auch schon hochgeladen - die Änderung ist nicht so arg komplex. Nur ist die Laufzeit vom PN5180 zu lange, wenn ich das aus dem Task raushole. Hatte bisher aber noch keine Muße, da tiefer einzusteigen.
Für LPCD (Low Power Card Detection) und für iCode SLIX-L Tags ist der PN5180 noch im Vorteil.
Das war hinter „ein Stück weit“ verklausuliert, hehe. Ja, wenn man das braucht, dann ist es natürlich alternativlos. Ich mag den PN5180 ja auch 
Ich habe das Thema mit den doppelten Librarys jetzt so gelöst, dass die von mir angepasste MFRC522_I2C verwendet und es somit keine Probleme bei gleichzeitiger referenzierung auf die RFID Library gibt.
Dafür muss in der platformio.ini der Pfad angepasst werden: GitHub - kkloesener/MFRC522_I2C
Jut, dann werde ich das mal testen. Wobei testen heißt, dass ich nur schauen kann, ob es sich kompilieren lässt. Einen i2c-RFID-Leser habe ich nicht hier.
@jpellenz Hab mir gerade die Fotos angesehen, das ist gut geworden! Die Neopixels mit „FastLED.clear(true);“ ausschalten habe ich auch gemacht
vG Wolle