Einige Leute wünschen sich ja schon seit langem das Feature, dass die Musik aufhören soll zu spielen, wenn die Karte runtergenommen wird. Dass ich das schon so lange vor mir herschiebe hat u.a. auch damit zu tun, dass die Lib des RC522 an dieser Stelle irgendwie reichlich seltsam ist. Probiert hatte ich es vor Ewigkeiten mal, es dann aber wieder sein gelassen.
Auszug aus meinem Code:
Es gibt diese zwei Methoden PICC_IsNewCardPresent und PICC_ReadCardSerial() - das passt soweit. Nur lässt sich damit alleine leider nicht verlässlich sagen, ob eine Karte aufliegt oder nicht. Ich habe mir dann mal im Nachbarforum angeschaut, wie das dort gemacht wird. Da wird im Anschluss noch ein Dummy-Read gemacht und ein Block ausgelesen. Ist das nicht mehr möglich, ist die Karte weg. Ich hatte hier nur das Problem, dass das z.B. nicht funktioniert hat, wenn man die Karte direkt auf den Kartenleser gelegt hat. D.h. es waren mehrere cm Abstand notwendig. Weiß nicht, ob man hier mit Gain experimentieren muss, aber das kann es ja eigentlich nicht sein.
Wie auch immer: Vielleicht ist ja jmd. hier, der sich mit dem Teil besser auskennt als ich es tue. Für den PN5180 habe ich das Feature schon implementiert - das hat wie erwartet funktioniert.
Ok, danke für den Hinweis
In deinem Code steht Since wireless communication is voodoo we'll give it a few retries before the card is gone
Das trifft es ganz gut beim RC522
Ja, also ich wäre nicht ganz bös’ drum, wenn das jmd. implementieren möchte. Aber ich schaue mir das nochmal genauer an in deinem Code.
ich hab jetzt noch mal einen Merge auf meinen Fork gemacht und das ganze neu implementiert.
Ich habe versucht mich an der PAUSE_WHEN_RFID_REMOVED des PN5180 zu halten.
Ist natürlich nicht ganz vergleichbar. Ich habe den RFID wieder in einen eigenen Task ausgelagert, da der Check in einer Schleife läuft und ich den Rest der Anwendung nicht beeinflussen wollte.
Es wäre toll wenn das ganze mal jemand prüft der mehr Ahnung hat als ich
Und ein Merge in den Master wäre mal schön
Hallo @elmar-ops,
willkommen zurück
Funktioniert das mit der Erkennung denn zuverlässig? Ich hatte mir deinen Code, als ich das mit dem PN5180 angeschaut habe, auch angesehen, muss aber zugeben, dass ich ihn nicht so ganz verstanden habe, was da passiert. Vielleicht kannst du ihn grob mal kommentieren?
In Anbetracht der Tatsache, dass sich doch einige Leute das Feature wünschen und du dir auch die Arbeit gemacht hast, das zu homogenisieren, werde ich mir das auch genauer anschauen und wenn das passt natürlich in den Master aufnehmen.
Tja, ob ich es nicht doch wieder in einen Task reinnehmen sollte, müsste ich mal überlegen. Die Durchlaufzeiten werden schon einigermaßen negativ beeinflusst. Wobei das eher für den PN5180 gilt; beim RC522 hält es sich ja einigermaßen in Grenzen.
Noch ne zweite Frage: Braucht’s wirklich 5000 als Stacksize? Ich weiß den Wert nicht mehr, den ich damals verwendet habe, aber ich meine, dass es weniger war.
5000 war erst mal copy paste
2048 funktioniert bei mir.
Wie es genau funktioniert ist eine gute Frage… wichtig ist die while Schleife die endlos solange läuft
bis die Karte removed wird, der Rest ist vergleich ob die Selbe oder eine Andere Karte aufgelegt wurde.
Was genau in der while Schleife passiert ist voodoo und hab ich auch nur so kopiert (Detect card removal. · Issue #188 · miguelbalboa/rfid · GitHub)
toll, Danke Dir! Ich wollte schon länger bei mir den Stand auf die neuste Version von @biologist ziehen, war aber immer zu träge. Das meiste funktioniert ja und der Hauptbenutzer stört sich an bugs weniger als ich…
Werde die Tage mal deinen aktuellen Stand auf den Espuino ziehen und ein wenig testen.
Also das sieht tatsächlich recht gut aus. Werde es noch ein bisschen testen.
Auf dem Wege habe ich auch noch gelernt, dass man sich mittels uxTaskGetStackHighWaterMark(NULL) im Task anzeigen lassen kann, wieviel vom Stack noch frei ist. Ich habe die Stacksize jetzt mal auf 1536 reduziert und aktuell sind damit noch 92 Bytes frei. Mit 1472 habe ich, wenn ich wild Karten gewechselt habe, mitunter Neustarts provoziert. 1536 scheint aber zu passen.
Ich hatte den RFID Task im BT mode nicht gestartet.
Braucht man evtl. für die Modification card BT.
Aber auch wenn ich den Task enable scannt er im BT mode nicht, Speicher?
Ich lass das bei mir erst mal so, schalte BT über Buttons.
Stimmt, BT fehlt noch. Das hatte ich gestern Abend nicht mehr ausprobiert, aber ich erinnere mich daran, dass der opmode für „normal“ im Code stand.
Werde es mal testen. Brauchen tut man es auf jeden Fall, sonst kommt man da nicht mehr raus, wenn man es im Button-Layout nicht definiert hat. Ggf muss man hier den Code anpassen, weil sowas wie automatisch Pause macht ja keinen Sinn, zumal der Audioprozess dann eh nicht läuft.
Aber das muss ich mir für den pn5180 dann auch nochmal ansehen, das hatte ich nicht explizit bedacht.
Doch, das klappt - habe es eben mal probiert. Man darf die Karte aber halt nicht liegen lassen. Tut man das, dann wechselt der ESPuino ständig den Modus hin und her. Das ist aber ok aus meiner Sicht.
So, ich habe jetzt mal noch ein bisschen in der Mittagspause rumprobiert. Statt diesmal sofort einen Commit rauszuhauen, würde ich euch (insbesondere @elmar-ops) bitten, mal Folgendes zu testen… das wäre so mein Lösungsentwurf:
Was ist zu tun?
Link öffnen und auf raw klicken. Leider hat es das Code-Layout offenbar etwas zerrissen, aber das soll jetzt erstmal nicht weiter stören.
Per Copy’n’Paste den Code rausholen und in eure rfidMfrc522.cpp kopieren. Wenn ihr euch mit GIT nicht so gut auskennt, macht vorher von der alten Datei per Copy’n’Paste am besten ein Backup in eine andere Datei außerhalb des Repositories. Wenn eure Tests fertig sind, dann bügelt ihr per Copy’n’Paste einfach wieder drüber, so dass der alte Zustand der rfidMfrc522.cpp wieder hergestellt ist. Damit erspart ihr euch etwaige merge-Fragen von git, sobald ich den Code in das Repository eingecheckt habe und ihr euren Code damit synchronisiert.
Die Zeilen, in denen „rfidTagRemoved“ und „rfidTagReapplied“ steht, mittels „//“ auskommentieren, da ihr sonst in Kompilierfehler lauft.
Code kompilieren und hochladen.
In settings.h mal mit und ohne der Option PAUSE_WHEN_RFID_REMOVED testen. (Natürlich immer wieder neu kompilieren und hochladen im Anschluss).
Würde mich über Feedback freuen - von mehreren Usern. In einem fertigen Gehäuse denke/befürchte ich, dass man ein bisschen mit Gain spielen muss, damit es passt. Könnte allerdings auch Gehäuse geben, in denen das mehr schlecht als recht funktioniert.
Also Feedback einerseits, ob die Bestandsfunktion (ohne PAUSE_WHEN_RFID_REMOVED) gescheit funktioniert. Und natürlich auch, ob PAUSE_WHEN_RFID_REMOVED arbeitet wie beabsichtigt. Bei Letztgenanntem rechne ich damit, dass man hier und da noch ein bisschen tunen muss.
Ich habe das eben mal im ESPuino meines Sohnes getestet. Aus meiner Sicht funktionieren beide „Zweige“ ordentlich, daher habe ich es jetzt in einen Commit gesteckt:
Also ich werde den PN5180 auch definitiv wieder aus der Loop rausholen und ihn in einen Task stecken. Der Drehencoder reagiert dann auch wieder viel dynamischer.
Ich habe mal einen Test gemacht: In main.cpp einen Counter gesetzt, der in loop() bei jedem Durchlauf um 1 inkrementiert wird. Wenn er 2000 erreicht hat, wird eine Ausgabe gemacht. Das Ganze im Leerlauf, direkt ab dem Start.
Mit PN5180 in der Loop: ca. nach 63s => 31.5 ms/Durchlauf
Mit PN5180 im Task: ca nach 14s => 7ms/Durchlauf
In Abzug bringen muss man dann noch das absichtlich herbeigeführte Delay von 5ms in loop(). Dann wären wir also bei 26.5 ms zu 2ms. Das ist einfach mal krass.
Ich muss allerdings noch ein bisschen mit den Task-Prioritäten „spielen“. Denn durch den zusätzlichen Task komme ich bei SD_MMC nur noch auf ca. 325 kB/s im Upload, das sind knapp 20 kB/s weniger als ohne Task.
@jpellenz / @tueddy
Ich habe eben mal einen Commit hochgeladen, der den PN5180 wieder in den Task zurück bringt. Die Reaktion des Drehencoders z.B. ist jetzt wieder deutlich besser. Aus meiner Sicht ist die Reaktionszeit des PN5180 auch weiterhin super; das war ja vorher so ein bisschen ein Kritikpunkt, dass der scheinbar etwas träge reagiert hat.
Vielleicht könnt ihr das mal testen, wenn ihr Zeit habt. Gerne auch jmd. anderes, aber bei euch beiden weiß ich, dass ihr den Reader verwendet
Ich habe den letzten Stand getestet SD_MMC + PN5180 mit den Schaltern PAUSE_WHEN_RFID_REMOVED & PN5180_ENABLE_LPCD, bekomme hier aber schlechteres Verhalten:
Kartenerkennung läuft deutlich schlechter als vorher (Nur noch sporadisch)
Kratzen/Stottern in der Soundausgabe
Wechsel in den Schlafmodus akiviert teils LPCD nicht. Der Leser scheint im Task zu hängen und kann für LPCD nicht initialisiert werden. Man sieht dies an der Ausgabe Firmware 0.0 :
ws[/ws][1] pong[0]:
ws[/ws][1] text-message[24]: ping
Gehe jetzt in Deep Sleep!
Firmware version=0.0
This PN5180 firmware does not work with LPCD! use firmware >= 4.0
deep-sleep, good night.......
Kann das noch jemand bestätigen? Evt. habe ich hier ja auch etwas übersehen…
Seltsam, dass ich diese Probleme nicht hatte.
Kannst du mal den Task des pn5180 auf den anderen Core pinnen.
Ansonsten habe ich in Audio.cpp ein vtaskdelay mit 3ms eingetragen. Vielleicht kannst das mal auf 1ms reduzieren.
