Die anderen Stellen sind von tuniii. Mir ist das total klar, dass man damit solche Fehler umschiffen kann, aber irgendwas wehrt sich in mir, das so rum zu machen 
. Wie auch immer: Schön, dass es jetzt geht. Muss ich mir nur das Aufwecken noch anschauen.
Mein initiales Problem war tatsächlich nur ein Copy-Paste-Fehler im verwendeten Passwort…
Die Demo habe ich nicht ausprobiert, nachdem die Ursache gefunden war. Zum zwischenzeitlichen Debuggen musste ich noch in weiteren Dateien (redundante) #define DEBUG einfügen, sonst wollte VS Code nicht kompilieren. Außerdem hat er beim PN5180DEBUG(strerror(errorCode)); über Typeninkompatibilität geschimpft.
Von meiner Seite her ist das Thema jetzt erstmal erledigt, bis ich zum weiteren Herumspielen mit dem Deep Sleep komme. Euch allen bis dahin noch viel Erfolg!
@jpellenz @ckaotik @MusikHexe (hoffe ich habe niemand vergessen, hehe).
@tueddy hat sich LPCD für den PN5180 netterweise nochmal angeschaut und mir geschrieben, was angepasst werden muss. War nicht viel. Habe es vor einer halben Stunde eingecheckt.
Testet bitte mal, ob das jetzt so passt.
Habe den letzten Commit getestet und der ESPuino wacht auf und spielt Musik beim Auflegen der Karte.
Passt also.
Eine Kleinigkeit ist mir noch aufgefallen.
Ich kann ESPuino nicht über den Drehregler Taster wieder aufwecken. Der LPCD hat jetzt Vorrang und legt sich ohne Karte sofort wieder schlafen. Man müsste den Aufwachgrund auswerten und bei Klick auf den Taster trotzdem starten… Evt. den Taster zuerst auswerten? So ganz bin ich noch nicht im neuen Code, trotzdem finde ich das Refactoring richtig gut!! Vielen Dank an alle Beteiligten, das macht es in Zukunft einfacher!
Hat das denn vorher funktioniert? Ich muss gestehen, dass ich nach wie vor keinen kompletten Aufbau mit FW4.1 hier habe. Ich hatte das damals nur mal wild verdrahtet getestet, weiß aber nicht mehr, ob es da ging.
EDIT: Hatte nicht irgendwer hier mal mit Bitmasken diesbzgl. experimentiert?
Hehe, ja das ging mir am Anfang auch so. Aber ist top, wenn man sich mal dran gewöhnt hat.
Ja das hat vorher funktioniert. Sollte aber lösbar sein:
Rfid_WakeupCheck() prüft ob eine Karte im Feld ist. Falls nicht vorhanden wird der ESP wieder in den Schlafmodus geschickt. Das sollte aber nur passieren wenn der Aufwachgrund auch eine vorherige Änderung im RF-Feld war.
// check wakeup reason was a card detection
esp_sleep_wakeup_cause_t wakeup_reason;
wakeup_reason = esp_sleep_get_wakeup_cause();
if (wakeup_reason == ESP_SLEEP_WAKEUP_EXT1) {
esp_deep_sleep_start();
}
Ich probiere das mal aus.
1 „Gefällt mir“
Mit dieser Erweiterung klappt das Aufwecken auch wieder über Taster (main.cpp):
void setup() {
Log_Init();
Rfid_Init();
// check wakeup reason was a card detection
esp_sleep_wakeup_cause_t wakeup_reason;
wakeup_reason = esp_sleep_get_wakeup_cause();
if (wakeup_reason == ESP_SLEEP_WAKEUP_EXT1) {
Rfid_WakeupCheck();
}
System_Init();
memset(&gPlayProperties, 0, sizeof(gPlayProperties));
Die Prüfung auf Karte sollte nur erfolgen wenn der Auslöser zum Aufwecken der IRQ des Lesers war.
Ist zwar nicht so schön das in main.cpp unterzubringen aber vielleicht verständlicher zu lesen. Hoffe das geht auch ohne PR…
OK, bringe ich dann ein. Und nein, braucht keinen PR 
1 „Gefällt mir“
So, ist drin im Master.
Hallo zusammen,
Echt ein super krasses Projekt. Viel Lob an @biologist und alle beteiligten.
Ich habe alle hier beschriebenen Teile bestellt und einen Prototyp gebaut, mit Lolin32, SD_MMC, PN5180 und einem PCM5102, der über Klinke an eine JBL Go Bluetooth-Box verbunden ist. Trotz dem Kabelsalat der vielen Dupont-Kabel und meinen beschränkten Fähigkeiten funktioniert alles soweit!
Der einzige Stolperstein war übrigens, dass ich in der lolin32settings.h übersehen hatte, dass da PIN2 von einem Button belegt war, weswegen die SD_MMC nicht funktionierte.
Weiter machen und alle übrigen Funktionen realisieren will ich jetzt aber auf jeden Fall mit dem hier gezeigten PCB. Wie komme ich da am besten dran? Hat noch jemand einen davon übrig, den er mir verkaufen kann?
Ich schreibe dir eine PM 
@petershaw23 So ähnlich sieht es bei mir jetzt auch aus. Ich würde das gerne mit einem PCB aufräumen.
@biologist hast du für mich vielleicht eine Lösung. Ein einzelnes fertigen zu lassen lohnt sich ja leider nicht. 
Per PM beantwortet 
Dank @biologist habe ich nun das PCB und noch einiges an Zubehör Vielen Dank!
Kleine Anfängerfrage:
Ist es schlimm, wenn ich nicht die genauen R-Werte habe? z.B. 2k anstatt 1k, rdif1/rdif2 2x220k oder 2x100k anstatt 2x130k.
Ansonsten würde ich aus meinem Widerstands-Set jeweils 2 Stück kombinieren, oder noch mal welche bestellen.
Edit: 10k und 100k doch noch gefunden
Noch eine Frage: Kann ich die Einbaurichtung der beiden MOSFETs aus diesem Bild übernehmen?
Also 2x100k geht auf jeden Fall, das machen die bei Wemos mit Lolin D32 und Lolin D32 pro auch. Aber 220k geht vermutlich genau so.
Ja. Die Bilder passen.
1 „Gefällt mir“
ok, danke! und bei R4? Habe keinen 1k-Widerstand, aber 2k oder 680.
Dann nimm 680. Soll im Endeffekt nur den Strom begrenzen, wenn das Gate umgeladen wird. D.h. da fließt nur kurz ein Strom und dieser wird durch r4 begrenzt.
40 mA kann ein GPIO wohl liefern. D.h. bei 3.3V sollte der Widerstand dann nicht kleiner als 82 Ohm sein. Also mit 680 bist da safe .
1 „Gefällt mir“
ich habe alles zusammengebaut, ausser den RFID leser, Wenn ich einen Song über Rechtsklick abspiele, habe keinen Ton aus dem max amp an meinem 8 ohm lautsprecher. woran könnte das liegen?
die console zeigt an, dass der song abgespielt wird. lautstärke ist auch auf max.
Ich habe das Problem auch gerade, allerdings mit dem D32 pro. Dazu habe ich dieses Thema gefunden
Hast du auch einen blauen Verstärker?
ja, hab den blauen von aliexpress. Wenn ich das richtig verstanden habe, scheint das Problem zu sein, wenn zwischen SD und GND weniger als 0,16 V liegen. Dann geht der amp aus. Bei mir sind es 0,05 V.
In der settings.h #define HEADPHONE_ADJUST_ENABLE zu setzen hat auch nichts gebracht. nach wie vor kein Ton und 0,05 V an SD