Ja ok, ist noch nicht so lange her sehe ich gerade. Also verbaut habe ich schon PD9555 und PCA9555 (NXP). In den letzten Monaten allerdings nur noch NXP.
Also ich hab’s mir nicht angeschaut. Es gab mal ein Problem mit der Kopfhörerplatine beim Abschalten. Da war es so, dass HP_DETECT beim Abschalten halt seine Spannung ändert, da der Kopfhörerplatine die Versorgungsspannung beim Abschalten ja quasi geklaut wird. Das habe ich behoben, indem ich HP_DETECT vor dem Runterfahren auf Ausgang umkonfiguriere. Weil alle Pins, die als Ausgang konfiguriert sind am Port-Expander, können nicht dazu führen, dass Interrupts geworfen werden, die dann eben den ESP32 aufwecken.
Okay. Das heißt bei der letzten Bestellung (vor ca. zwei Monaten oder so) war es vermutlich doch nicht der NXP. Ich schau, dass ich die Box bald mal nochmal öffne und zerlege und das überprüfe.
Wäre interessant ob es die Hardware des Port-Expanders oder ein Signal am Portexpander ist, dass das triggert.
Kommen noch andere Signale in Frage, z.B. auch nicht verbundene?
Also gehst du aktuell davon aus, dass beide Geräte den selben Port-Expander haben. Spannend!
Ich habe auf beiden Geräten die selbe Konfiguration: JP 4 offen um den IRQ vom Reader auf pin 32 zu bekommen (wie bereits an anderen stellen besprochen). Allerdings ist dort wo es funktioneirt noch kein RFID-Reader verbunden.
Ich schaue mir hoffentlich morgen Abend die Platine der Kids nochmal an und geb dir Bescheid ob ich da einen Unterschied finde.
Aber so richitg Hardware kann es ja eigentlich fast nicht sein, wenn das erst bei Arduino 2.x auftritt…
@Joe91 also Dein Board wacht in Arduino 2.0.6 von allein auf? Dann könnte es dieses Problem sein?
Wenn LPCD verwendet wird werden die Pin-Zustände vor dem Deep-Sleep eingefroren und nur auf den IRQ des PN5180 gewartet. Ich konnte das hier leider noch nicht testen, steht aber die nächste Tage an.
Tritt das Problem bei deaktivierten LPCD noch auf?
Vielen Dank dir! Schaue ich mir Mal an.
Bin noch bei deaktivierem LPCD. Das kommt erst im nächsten Schritt, da ich für meine Test-Hardware noch keinen RFID-Reader habe (ist noch unterwegs)…
Melde mich nochmal wenn ich bisschen weiter bin damit.
Mit nur WPA2 bekomme ich immer zuverlässige Verbindung & viel schnelleren Verbindungsaufbau.
Jetzt erreiche ich auch 400-500 KB/s Upload. Deutlich schneller als 1.0.6. Auch den teilweisen Einbruch der Upload-Geschwindigkeit auf 200 KB/s kann ich nachvollziehen.
Insgesamt läuft das jetzt sehr stabil. Die Ringbuffer Implementierung scheint für 2.0.6 weniger zu greifen da das Schreiben auf SD-Karte schneller geworden ist. Hast Du da noch Verbesserungen erzielen können z.B. mit Puffergröße?
Leider noch nicht. Meine Test-Hardware hat leider aufgegeben und ich muss erst einmal für Ersatz sorgen
Ich hatte zum Testen mal den RingBuffer / das Schreiben auf die SD komplett rausgenommen um zu sehen, wie der reine WiFi Durchsatz ist. Da scheint es besser zu sein, aber auch dort schwankt es. Ich sehe in Wireshark sehr viele „Update TCP Window“ was die Schwankung erklären würde.
Mir ist allerdings noch unklar, wie man das ändern könnte.
Die aktuellen Einstellungen sind für die meisten Anwendungen vermutlich ja auch ziemlich gut. Nur wenn man halt sehr große Daten verarbeiten möchte, bricht die Datenrate ein.
Es gibt hier ja jede Menge Infos dazu: Wi-Fi Driver - ESP32 - — ESP-IDF Programming Guide latest documentation aber dadurch entstehen viele Abhängigkeiten, die ich noch nicht durchblicke…
Ich hatte zum Testen mal den RingBuffer / das Schreiben auf die SD komplett rausgenommen um zu sehen, wie der reine WiFi Durchsatz ist.
So ähnlich habe ich das auch gemacht: Zunächst ein separates Minimalprojekt mit ESPAsyncWebserver & SD_MMC Karte. Darin zwei Upload-Methoden, mit und ohne Ringpuffer/Task. Ich kann das Testprojekt hier gern mal zur Verfügung stellen…
Die Uploadrate so 400-500 KB/s, also Top!
Nach einigen Hardware/Software Resets dann plötzlich nur 200 KB/s. Nach einigen weiteren Resets wieder hohe Geschwindigkeit. Der Upload mit Task/Ringbuffer nur minimal schneller, teilweise auch gleiche Geschwindigkeit. Das erkläre ich mir mit der verbesserten SD-Schreibgeschwindigkeit. Da hat das gepufferte Schreiben nicht mehr so Auswirkungen.
Die Upload Dateigröße scheint keine Rolle zu spielen, ob 1MB oder 10MB.
Für den schwankenden Wifi-Durchsatz habe ich dann noch verschiedene Dinge probiert:
Wifi.setStaticBuffers auf true/false → Verlangsamt den Upload. Ohne Aufruf ist es besser
Wifi.setLightSpeed(false) → Keine Auswirkungen
Das bringt Alles keine Änderungen. Komisch das sich das ab und an nach einem Reset anders verhält. So als ob sich das Wifi beim Start unterschiedlich eingrooved…
@Christian die Wifi-Parameter ändern bedeutet Neukompilieren mit Arduino-Lib-Builder, hast Du das vor?
Der Task der TCP-Lib ist keinem Core zugeordnet. Das könnte eine Mögliche Ursache sein.
Vom Header der Lib:
//If core is not defined, then we are running in Arduino or PIO
#ifndef CONFIG_ASYNC_TCP_RUNNING_CORE
#define CONFIG_ASYNC_TCP_RUNNING_CORE -1 //any available core
#define CONFIG_ASYNC_TCP_USE_WDT 1 //if enabled, adds between 33us and 200us per event
#endif
Deshalb dachte ich an Speicherzuweisung. Das mit den unterschiedlichen Cores hatte ich auch schon probiert und in der plantform.ini zusätzlich -DCONFIG_ASYNC_TCP_RUNNING_CORE=1 gesetzt. Core 0 hatte ich nicht probiert und ich habe es auch nicht sauber genug getestet / abgegrenzt - würde ich dann noch einmal probieren, wenn die neue Hardware da ist. CONFIG_ASYNC_TCP_USE_WDT 1 hatte ich auch nicht auf dem Schirm.
Ja, das hatte ich schon gemacht, um bei er 2.0.6 auch wieder die beiden Funktionen vTaskGetRunTimeStats und vTaskList nutzen zu können. @tuniii hatte das hier mal gezeigt: RFID mit oder ohne Task - #19 von tuniii
Der Portexpander war wirklich auf beiden Platinen identisch (NXP PCA9555). Keine Ahnung warum der deepsleep einmal nicht funktioniert. Aber da scheint generell irgendein HW-Issue auf dem einen Board zu sein. Man schafft es immer wieder in einen Modus zu kommen, wo die SD Karte nicht erkannt wird.
Werde das am Donnerstag weiter untersuchen…
Hast du da ggf. ne Karte mit mehr als 32 GB drin?
Ich hatte vor ner Weile ein Board von einem User hier, der hatte mir eine 64 GB-Karte mitgeschickt. Und damit gab es tatsächlich solche Probleme, die es mit 32 GB nicht gab. Warum weiß ich nicht - vielleicht yet another ESP32-Bug. Es lag auch nicht an seinem Board - ich konnte das auch mit anderer Hardware nachstellen.
Ja, es ist ursprünglich eine 64 GB Karte gewesen, habe sie aber auf 32 GB formatiert.
Hatte davor eine 2GB Karte drin, die hat aber ebenfalls diese Probleme, nur traten sie dort häufiger auf . Auf der neuen Hardware scheint es aber bis jetzt nicht aufzutreten. Alles bisschen komisch da die Boards eigentlich identisch sind ^^.
Kann man des ESP komplett zurücksetzen? Werde wohl auch mal bisschen mit Kreuz-Tausch-Versuchen arbeiten…
Gibt es bestimmte SD-Karten-Empfehlungen ?
Ich verwende 32 GB Sandisk.
Komplett zurücksetzen geht mit „Erase Flash“.
Nachtrag: Sehe eben erst, dass ich ja im Arduino 2-Thread schreibe. Also meine Aussagen mit SD bezogen sich auf Arduino 1. Mit 2 habe ich das so ausgiebig nicht getestet im Vergleich.
Der user mit dem Problem mit der 64GB SD-Karte war ich. Und ich hatte zum Testen auch mal die Arduino Version 2 geflasht, mit dem gleichen Ergebnis. Bin dann aber auch wieder zurück zur v1, weil der Deepsleep nicht funktioniert hatte. (der Vollständigkeit: LPCD nutze ich nicht)
Das Problem mit der SD-Karte tritt bei mir aber eigentlich nur nach dem Flashen auf und ich kann den ESPuino nach ein paar Sekunden dann wieder per Tastendruck aus dem Deepsleep holen, insofern kann ich damit leben.
Also auch LPCD scheint zu funktionieren. Allerdings nur wenn der Tag direkt auf den Reader aufgelegt wird. Ohne Modifikation der Settings klappt es mit 10 mm Gehäuse nicht zuverlässig.
. Auf der neuen Hardware scheint es aber bis jetzt nicht aufzutreten. Alles bisschen komisch da die Boards eigentlich identisch sind ^^.