@Joe91 kannst Du Deine Erfahrungen/Probleme hier noch ein wenig weiter auftrennen/präzisieren?
Weil LPCD und Arduino 2 sind ja erstmal zwei paar Schuhe - Kann mir jetzt nicht wirklich vorstellen warum sich die Leseempfindlichkeit in 1.0.6 anders verhält als in 2.0.6.Am Ende wirft der PN5180 einen IRQ wenn sich eine Karte im Feld befindet. In 2.0.3/2.0.4 gab es wohl einen Bug mit dem Einfrieren der Pins, da wachte der ESPuino sofort wieder auf. Für 2.0.6 kann ich das testen wenn die neue Hardware da ist (Danke an Chef-Papa!)
10mm Holz? Ist die normale Kartenerkennung OK? Man könnte auch im Holz eine Aussparung auf wenige mm runterfräsen…
Welche Settings hast Du angepasst? Für den RC522 gibt es ja einen Wert für die Verstärkung (Gain), beim PN5180 regelt sich das ja automatisch ein. 5V anstelle von 3.3V am 5V-Pin macht Sinn und hast Du bestimmt schon gemacht.
Für LPCD gibt es viele Parameter, ich setze sie hier. Die sind schon ein bisschen magic . Meinst Du diese Einstellungen mit „Settings“?
Am Besten hier weiter mit Erfahrungen/Bugs für die noch experimentelle Arduino 2.x Version, sonst gern im LPCD Thread…
Vielleicht noch eine Randnotiz: Mein ESPuino wollte auf 2.x auch erst nicht in den Deepsleep. Ich hatte dann aus Verzweiflung mal alle Stromquellen abgesteckt und wieder dran… seither macht er das. Hört sich wirklich verrückt an - hat aber geholfen.
Vielen Dank für den Hinweis! Werde ich wohl auch so versuchen
Aktuell teste ich noch auf der zweiten Hardware und sehe dort wirklich keine Einschränkungne bezüglich Arduino 2. @tueddy : Ja, diese Eintellungen habe ich gesehen und damit auch schon gespielt (und mit anderen). Alles nicht ganz ideal, auch dass hierbei jedes mal im EEPROM geschrieben wird, für Testzwecke aber sehr hilfreich…
Es wurde zwischendurch mal gesagt, dass LPCD nicht unter Arduino 2 läuft. Das ist definitiv nicht der Fall. Sieht soweit wirklich gut aus. Dass man beim PN5180 endlos viele Einstellungen verändern kann ist natürlich nicht hilfreich . Deine Einstellungen passen aber ziemlich gut, wenn man einen sehr geringen Abstand und kein Metall in der Nähe hat.
Werde ich bald nochmal sehr viel tiefer mit dem PN5180 befassen und dann hoffentlich paar mehr Erkenntnisse bekommen. Bei der anderen Hardware liegen die Probleme vermutlich an den vorhandenen Befestigungsschrauben, die dann den LPCD triggern…
Also das läuft auf jeden Fall. Ich hab’s jetzt mit der neuen 4Layer-mini erfolgreich getestet. Dort klappt der Deepsleep mit und ohne LPCD und das sowas auf Arduino 1 und 2. Zumindest war das jetzt bei zwei Boards der Fall, die ich getestet habe.
Vermutlich ist es sinnvoll mittelfristig auf dem master auf 2.x umzusteigen, damit mehr Leute die Fehler dort finden und diese Version dann immer noch stabiler wird .
Zumindest jetzt wo der Stand dort wirklich solide wirkt…
Also einen Fehler habe ich im Betrieb gefunden: Und zwar gibt es irgendwie Probleme bei der Kopfhörererkennung. D.h. es läuft erstmal alles normal, aber vielleicht so alle 60 bis 120 s (unregelmäßig) blinkt mal kurz der LED-Ring auf und die Musik geht ganz kurz aus. Wenn ich dann ins Log schaue, dann steht dort, dass CMD 0 nicht erlaubt ist und gleichzeitig kommt es zu einem (manchmal auch mehreren) Event(s), die aussehen, als ob man den Kopfhörer eingesteckt hätte. Gehe ich auf Arduino 1 zurück, dann ist dieses Problem wieder weg.
Da muss ich vielleicht nochmal durch meinen Code schauen, ob ich da was falsch mache oder ob das ein ESP32-Arduino-Bug ist.
Das war so bis Arduino 2.0.5, Einfrieren der PINs war fehlerhaft und weckte den Leser gleich wieder auf. Das scheint jetzt mit 2.0.6 behoben. Bzgl. unzuverlässiger Verbindung habe ich jetzt zwei Wochen getestet. Nachdem ich in der FRITZBox die WLAN-Sicherheit von „WPA 3 & WPA 2“ auf „WPA 2“ umgestellt habe funktioniert die WLAN-Verbindung wie gewünscht und auch sehr schnell.
Also wir können zwei Dinge von der Liste streichen:
LPCD funktioniert
WLAN Verbindung klappt zuverlässig
@Joe91 für’s Testen! Und nochmal die Frage, hast Du 5V am 5V Pin des PN5180 anliegen? Weil das verbessert die Lesereichweite…
Ja, du hast recht. Habe bis jetzt fast nur mit Lautsprecher getestet, aber bei den Kopfhörern ist tatsächlich irgendwas noch arg komisch. Neben dem Phänomen von dir habe ich auch konstante Geräusche abhängig von SD-Kartenzugriff drauf (zumindest wirkt der Zusammenhang so). Die fallen allerdings bei lauter Musik nicht mehr auf. Auf Arduino 1.6 sind die Geräusche zwar auch vorhanden, allerdings gefühlt weniger penetrant…
Besonders gut zu hören, wenn die Lautstärke auf 0 gestellt wird. Sobald pausiert wird, ist es wieder ruhig. Allerdings doch nicht immer, sondern nur von Zeit zu Zeit.
Update: passiert auch beim Lautsprecher:
[ 319795 ] Ein Karten-Modifikator existiert nicht vom Typ 0 !
[ 320005 ] 30 Sekunden nach vorne gesprungen
[ 320246 ] info : stream ready
Nachdem mir @biologist am Wochenende neue Hardware zur Verfügung gestellt hat (Vielen Dank dafür!) konnte ich jetzt auch ein wenig testen:
Test-Hardware ist die neue grüne Mini Layer-4 Platine mit Kopfhörer Klinke (Nachfolger der blauen D32-Pro mit SD-MMC & Portexpander). Als Dev Board habe ich den D32-Pro drin, der D32 FePo spinnt noch ein wenig evt. wg. meines USB-C Kabels/Anschluss.
Getestet habe ich mit offiziellen Release Arduino 2.0.6 & aktuellen ESPuino master. Ich verwende kein MQTT.
Ergebnisse:
Keine Störgeräusche, weder im Lautsprecher- noch im Kopfhörer Betrieb. Auch keine Falschmeldungen wie gemeldet Modifier 0 oder HP_DETECT. Also Alles fein!
Das Einzige was ich hier bemerkt habe das über Klinke die Kanäle nich gleich laut sind. Also links mehr als rechts, nur minimal, aber hörbar. Verwende ich den Kopfhörer über Bluetooth (der kann BT oder Klinke) sind die Kanäle balanciert. Könnte ein Problem mit der Kopfhörer-Platine zu sein, evt. aber hat das Klinkenkabel auch eine Macke.
Gibt es noch Dinge um Euer Knackseln zu reprodzieren?
Gut, es ist halt letztlich so, dass das Sandwich-Design mit Kopfhörerplatine irgendwo auch ein Kompromiss ist. Also speziell auf dem Develboard ist schon arg wenig Platz und im Prinzip müsste man auf dem Konnektor zur Kopfhörerplatine zwischen den Signalleitungen auch jeweils GND zur Schirmung mitführen. Aber aus meiner Sicht war das bisher dennoch im Rahmen mit Störgeräuschen und insbesondere die 4 Layer haben jetzt auch nochmal was gebracht. Nur einmal, bei der ersten Iteration meiner Complete (vor ein paar Wochen), war es wirklich (für mich) in einem Rahmen, wo ich gesagt habe: Das geht so nicht. Bei der Zweiten habe ich dann mit 4 Layern gearbeitet und alles auch räumlich fein separiert. Da waren Störgeräusche „quasi weg“, d.h. man musste die Lautstärke auf 0 drehen und wirklich sehr genau hören. Aber deine Beobachtung deckt sich auf jeden Fall mit meiner: Das korreliert mit SD, weil bei Webradio ist es weg.
Ja das geht so ein bisschen in die Richtung wie meine Typ 0-Events. Ich weiß nicht, ob man unbeschaltete Port-Expander-Eingänge nicht vielleicht auch mit einem externen PullUp versehen sollte. Im Datasheet steht davon auf jeden Fall nix. Und mit Arduino1 gab’s da auch nie Probleme.
Spannend wäre es halt nochmal mit der FePo-Platine. Da ist halt mit dem TP5000 ein Schaltregler drauf, während der D32 pro einen Linearregler hat.
Aber ansonsten freut es mit zu hören, dass die 4 Layer läuft. Die Sache mit der unterschiedlichen Kopfhörerlautstärke kann ich hier übrigens nicht nachvollziehen.
[ 319795 ] Ein Karten-Modifikator existiert nicht vom Typ 0 !
[ 320005 ] 30 Sekunden nach vorne gesprungen
Wenn ich das richtig verstehe werden in 2.0.6 sporadisch Kommandos/Tastendrücke über den Port-Expander ausgelöst. Glaube nicht das es ein Hardware Problem (Pullup) ist, in 1.0.6 funktioniert ja Alles wie gewünscht.
Problem müsste dann in port.cpp liegen?
Bin da jetzt nicht so im Code drin aber so als Idee: Das wird über I2C TwoWire angesteuert, evt. hat sich die Taktfrequenz oder Interrupt-Handling in 2.0.6 geändert oder ist buggy.
Was mir auffällt das nirgends Wire.begin() oder Wire.setClock() aufgerufen wird. Soll das nicht oder muss das nicht sein?
Glückwunsch, das sind ja gute Nachrichten! Upload >=500KB/s das wäre jetzt mal ein echter Gewinn, werde das auf jeden Fall die nächsten Tage mal testen.
Zu Deinen Änderungen:
TCP-Task auf Core 1
Das Festpinnen auf einen festen Core hatte meine ich @tuniii schon mehrfach vorgeschlagen und macht Sinn wg. Reproduzierbarkeit. In meinen Tests war der Webserver/TCP Thread immer auf Core1, festpinnen schadet aber bestimmt nicht.
FileUpload Task auf Core 0
Also Verteilung der Last auf beide Cores? Läuft WiFi nicht auf Core0? Hätte das jetzt nicht als Gewinn erwartet…
RingBuffer verkleinert
Der eigene Task mit Ringbuffer hat einen deutlichen Geschwindigkeitsvorteil in 1.0.6 gebracht, bei 2.0.6 teils schlechtere Performance. Hast Du mal einen Test komplett ohne einen eigenen Task gemacht? Bei mir war das oft schneller. Leider häufige Schwankungen, genaue Aussage schwierig…
Upload-Prozedur ohne Prüfung auf Buffer-Füllstand
Ich habe ja extra den Füllstand geprüft um einen möglichst großen Datenblock auf SD zu schreiben. In 2.0.6 scheint SD Schreiben einen eigenen Cache zu haben, da wird das wohl überflüssig…
Audio- und LED Task werden pausiert
Guter Ansatz, macht auch keinen Sinn beim Upload noch was anderes machen zu wollen. Ich denke damit könnte jeder leben…
Laut Doku wird, wenn man keine Frequenz übergibt, die Standard-Frequenz benutzt. Ich habe aber jetzt mal aus Spaß in Port_Init() direkt nach dem #idef ein i2cBusTwo.begin(); eingetragen und hatte tatsächlich in zwei Titeln, die ich abgespielt habe, keine Probleme. Habe es dann nochmal auskommentiert und es hat knapp 6min gedauert, bis der Fehler wieder kam - war direkt 2mal hintereinander.
Verstehen tue ich das erlich gesagt nicht . Ich werde es mal noch ein bisschen weitertesten.
Sicher nicht, aber es gibt zumindest keine Aktion, die auf HP_DETECT wirken könnte. Also Hardware wird’s vermutlich nicht sein, weil es läuft ja mit 1.0.6 ordentlich.
Aber es gibt ja auch noch CMD_NOTHING, was gesendet wird. Also entweder schlummert da irgendwo ein Fehler im Code oder es wird (warum auch immer) eine Multi-Button-Aktion ausgelöst. Weil alle Einzeltasten (0 bis 5) sind sowohl in kurz als auch mit lang mit Aktionen belegt in der settings.h.
Könnte es auch was mit einer „race-condition“ zu tun haben, dass während der Port-Expander per I2C abgefragt wird diese Kommunikation von einem anderen Task / Zugriff unterbrochen werden kann und dann entsprechend ein ungültiger Wert ausgelesen wurde?
Hmm, mal brainstormen…
Die Funktion Port_ExpanderHandler() wird zyklisch aufgerufen und liest, sofern ein Interrupt geworfen wurden, die beiden Register aus:
Das Ganze (2x 1 Byte) wird dann in ein Array geschrieben:
Jedes Byte repräsentiert einen Port und ein Port besteht aus acht Pins. D.h. über ein Byte ist der binäre Zustand aller acht Pins darstellbar.
Über Port_Read() kann man dann alle Pins einzeln auslesen. D.h. diese Funktion arbeitet nach außen wie digitalRead() über die Pseudo-GPIOs 100 bis 107 bzw. 108 bis 115 und greift dabei intern auf das zuvor genannte Array zu. D.h. es macht (aus Zeitgründen) keinen eigenen i2c-Zugriff sondern verlässt sich darauf, dass die Daten, die im Array stehen, aktuell sind.
Und so werden ausgelesen:
Buttons 1-5
Drehencoder-Button
HP_DETECT
ggf. RFID_IRQ
Schreibenden Zugriff (per Default sind alle Pins Input - das muss aktiv konfigurieren pro Pin) gibt’s nur für
GPIO_PA_EN
GPIO_HP_EN (das nutzt das mini-Board nicht)
POWER
Es gibt eine Abhängigkeit: Wenn HP_DETECT getriggert wird, dann hat das schreibenden Einfluss auf GPIO_PA_EN (und GPIO_HP_EN).
Wenn ich mir den Fehler da oben anschaue, dann passiert vermutlich in Port 0 beim Auslesen ein Fehler: Da alle Tasten mit definierten Aktionen belegt sind und nur Multi-Button-Aktionen mit CMD_NOTHING, werden wohl mind. zwei Tasten gleichzeitig als gedrückt erkannt. Und mehr noch: Scheinbar auch HP_DETECT (gehört auch zu Port 0) und das triggert dann kurzzeitig das Abschalten des Lautsprechers.
Ansätze:
Vielleicht muss ich die Bitmaske pro Port einfach mal seriell ausgeben lassen wenn sie sich ändert. Also dass ich mal sehe, was da alles drinsteht.
Mit dem Oszi mal das Taktsignal anschauen. Vielleicht bräuchte es ja kleinere PullUps (kleinerer Widerstand => mehr PullUp), da der kapazitive Belag durch Pinheader und i2c-Buchse ggf. zu groß ist.
Ich habe mitunter Serienwiderstände (22 / 33R) gesehen - habe ich noch nie getestet.
An der externen i2c-Buchse ist normalerweise nix angeschlossen. Mir ist unklar, ob es in diesem Falle dort nicht eigentlich Terminierungswiderstände bräuchte.
Letztes Jahr im Sommer habe ich mal einen PR zum Thema thread safe i2c bekommen. Aber mit nur einem i2c-Device am Bus sehe ich bei meinem Problem gerade nicht, wie mir das weiterhelfen könnte.
Es kommt glaub tatsächlich vom PortExpander. Bei mir wird wohl der Button gButtons[5].isPressed getriggert… Debug: Buttons: 0, 0, 0, 0, 0, 1[ 2310844 ] Ein Karten-Modifikator existiert nicht vom Typ 0 ! Debug: Buttons: 0, 0, 0, 0, 0, 1[ 2311064 ] 30 Sekunden nach vorne gesprungen
magic 
. Deine Einstellungen passen aber ziemlich gut, wenn man einen sehr geringen Abstand und kein Metall in der Nähe hat.
für’s Testen! Und nochmal die Frage, hast Du 5V am 5V Pin des PN5180 anliegen? Weil das verbessert die Lesereichweite…
Experten hier?
. Ich werde es mal noch ein bisschen weitertesten.