Aktueller Stand ESP32-Arduino 2

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.

Ich teste hier mit dem aktuellen Release 2.0.6, einer 64GB formatierten SD-Karte mit SD_MMC und dem Board mit PE (lolin_d32_pro_sdmmc_pe):

  • Die 64GB Karte schnurrt hier wie ein Kätzchen, Lese/Schreibzugriffe sind schneller als in 1.0.6
  • Deep-Sleep auf dem Rotary-Button läuft einwandfrei, lange drücken = schlafen, kurz drücken = aufwachen
  • LPCD kann ich hier nicht testen da mein Testboard etwas älter ist und keinen echten GPIO frei hat

@fetzerch Kannst Du einmal schauen ob die Probleme bei Dir noch bestehen? In 2.0.2/2.0.3 gab es zumindest einige Bugs bei SD Zugriff…

1 „Gefällt mir“

Das klingt gut, ja kann ich gerne in den nächsten Tagen mal machen. :+1:

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.

@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_wand:magic :magic_wand:. 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…

Grüße
Dirk

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.

1 „Gefällt mir“

Vielen Dank für den Hinweis! Werde ich wohl auch so versuchen :smiley:
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 :slight_smile: . 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…

1 „Gefällt mir“

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 :slight_smile: .
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 :+1: 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

ganz komich ^^

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?

https://espressif-docs.readthedocs-hosted.com/projects/arduino-esp32/en/latest/api/i2c.html#basic-usage

Zugegeben, habe NULL Ahnung bei (Two)Wire :sunglasses: Experten hier?

Noch einmal zum Thema Upload.

Ich habe mit folgenden Änderungen zuverlässig >= 500 kB/s

  • TCP-Task auf Core 1
  • FileUpload Task auf Core 0
  • RingBuffer verkleinert
  • Upload-Prozedur ohne Prüfung auf Buffer-Füllstand
  • Audio- und LED Task werden pausiert
    • Die Auswirkung ist nicht so auffällig, aber es gibt weniger Ausreisser.

Getestet habe ich per CURL Kommando und jeweils 25 Uploads gemacht. Nach jedem Upload einen Reboot vom ESP.

Bin ganz happy damit. Vielleicht mag’ mal jemand testen:

3 „Gefällt mir“

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…

So oder so, wenn das klappt schenke ich Dir ein :kiss:

1 „Gefällt mir“

Das begin wird hier aufgerufen:

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 :thinking:. Ich werde es mal noch ein bisschen weitertesten.

Ok, eben kam es auch mit dem „Fix“. Hat aber > 15min gedauert.

So sieht das bei mir aus:

[1004327 ] Ein Karten-Modifikator existiert nicht vom Typ 0 !
[ 1004332 ] Lautsprecher ausgeschaltet
[ 1004333 ] Maximale Lautstärke wurde gesetzt auf: 11
[ 1004333 ] Ein Karten-Modifikator existiert nicht vom Typ 0 !
[ 1005336 ] Lautsprecher eingeschaltet
[ 1005343 ] Maximale Lautstärke wurde gesetzt auf: 21
[ 1020054 ] RSSI: -46 dBm
[ 1080063 ] RSSI: -44 dBm
[ 1140066 ] RSSI: -49 dBm
[ 1200068 ] RSSI: -47 dBm
[ 1210033 ] Aktuelle Batteriespannung: 4.04 V
[ 1210047 ] Aktuelle Batterieladung: 86.64 %
[ 1260068 ] RSSI: -47 dBm
[ 1320069 ] RSSI: -46 dBm
[ 1380077 ] RSSI: -46 dBm
[ 1410459 ] Ein Karten-Modifikator existiert nicht vom Typ 0 !
[ 1410464 ] Lautsprecher ausgeschaltet
[ 1410465 ] Maximale Lautstärke wurde gesetzt auf: 11
[ 1410465 ] Ein Karten-Modifikator existiert nicht vom Typ 0 !
[ 1411466 ] Lautsprecher eingeschaltet
[ 1411474 ] Maximale Lautstärke wurde gesetzt auf: 21
[ 1440082 ] RSSI: -43 dBm
[ 1465665 ] Ein Karten-Modifikator existiert nicht vom Typ 0 !
[ 1465670 ] Lautsprecher ausgeschaltet
[ 1465671 ] Maximale Lautstärke wurde gesetzt auf: 11
[ 1465671 ] Ein Karten-Modifikator existiert nicht vom Typ 0 !
[ 1466674 ] Lautsprecher eingeschaltet
[ 1466675 ] Maximale Lautstärke wurde gesetzt auf: 21

Sind wir sicher, dass es über den Portexpander reinkommt?