Hi @elmar-ops ,
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.
Ok, falls es dann so rein kommt merge ich noch mal zu mir rüber.
Super dass jetzt alles drin ist was ich so gebraucht habe!
Danke an die vielen Coder die das Projekt unterstützen! Wahnsinn wie schnell sich dass so entwickelt hat!
Mein Sohn liebt die Box!
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?
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.
Also PAUSE_WHEN_RFID_REMOVED läuft mit dem Code von Dir jetzt gut.
Auch BT Modifikation funktioniert bei mir.
VG,
Elmar
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:
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.
Lpcd hatte ich ehrlicherweise nicht getestet.
Änderung von Core 0 auf 1 verschlimmert Alles, Audio ist stark gestört!
Änderung vTaskDelay auf 1 (mit Core 0) verbessert Audio auf gute Qualität.
Ich habe es auch ohne die Schalter PAUSE_WHEN_RFID_REMOVED und PN5180_ENABLE_LPCD probiert. Das Alles bei gleicher Konstellation/Hardware.
Es scheint so als ob PN5180 loop komplett festhängt. Werde versuchen das zu debuggen.
Gut reagiert z.B. Lautstärke/Drehregler.
Ein Wechsel auf den voherigen Stand & Alles läuft wie erwartet. Ich verwende den TTGO V18 mit ttgo_t8 build.
Vielleicht kann noch wer anderes das Problem bestätigen?
Frage mich, ob der Wrover hier irgendwie anders reagiert. Ich habe das getestet mit Webradio und habe auch extra 320 kbit/s bei mp3s dekodieren lassen. Egal, ob die Kartenerkennung aktiv war oder nicht, das hat ordentlich funktioniert. Habe es halt auf einem wroom getestet.
Ich schaue nochmal in den Code rein, ob ich da irgendwas vergessen habe…
Fehler gefunden & gelöst: Es ist war Hardwareproblem bei mir!
Ich habe in der Schleife des PN5180 die Variable stateMachine ausgegeben unnd festgestellt das sich der Task bei RFID_PN5180_NFC14443_STATE_RESET aufhängt. Der Leser hat also auf ein schlichtes Reset nicht mehr reagiert. Ich habe den Leser mit einem ca. 15cm langen Flachbandkabel verlängert. Nun einen anderen Leser direkt eingesteckt und siehe da Alles OK. Hier ein Bild der Verdrahtung:
Links der eingebaute Leser mit Flachbandkabel (Störung), rechts Leser direkt eingesteckt, dort dann Alles OK.
Moral von der Geschicht: „Keep wires short!“ oder besser löten?. Hätte das jetzt nicht gedacht…
@biologist vielleicht kannst Du das nach Deinen Problemen mit der SD-Karte in die Anleitung aufnehmen das der RFID-Leser hier ebenso empfindlich ist?
Vermutlich ist die Taktung jetzt höher als zuvor und die Leitungen können leichter übersprechen?
Das nehme ich gerne auf, danke für dein Feedback!
Ich habe bei mir JST-PH-Stecker (10 polig) und die Enden an den PN5180 gelötet. Sind aber doch auch 20cm die Leitungslänge.
Kannst im Audiotask nochmal auf 3ms stellen? Würde mich mal interessieren, ob das jetzt Teil des Problems war.
3 oder 1 macht bei mir einen Unterschied in der Soundausgabe: Bei 3ms hakt es im Audio (abgehakt), bei 1ms ist Alles OK…
Geht es es hier nur um den Wachhund? vTaskDelay(portTICK_PERIOD_MS * 1); wäre aus meiner Sicht OK…
Ja, es geht einerseits um den Wachhund. Andererseits habe ich inzwischen gelernt, dass es in Sachen Lastverteilung besser ist, wenn man hier und da mal ein Delay einbaut.
Aber 1ms ist schon ok. Ich habe das vorhin als Hotfix in einen Commit gehauen.
Danke für dein Feedback 
.
Das Thema ist erledigt.
