Ä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 .
.