Aktueller Stand ESP32-Arduino 2

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?

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

Nee hab ich dann nicht mehr gemacht. Was auf jeden Fall zu Schwankungen führt, ist ein „Delay“ im Async-Webserver. Wir füllen den RingBuffer ja mit bis 1000ms delay (falls der RingBuffer nicht frei ist). Sobald dort zu lange gewartet wird, fangen die Schwankungen an, Der Async-Webserver fängt dann scheinbar an dem Sender mitzuteilen, dass er die Daten langsamer senden soll. Macht ja auch Sinn. Ich habe versucht einen Kompromiss zu finden um den Async-Webserver nicht zu blockieren. Das kann aber stark abweisen in anderen (WLAN-)Umgebungen.

Denke ich auch.

Also es scheint wohl durch Verkleinern der i2c-PullUps deutlich besser zu werden. Ich habe zu den beiden 4.7k direkt am PE zusätzlich hinten am externen i2c-Konnektor nochmal je 10k dazugelötet, was dann rechnerisch als Parallelschaltung 3.2k bedeutet. Dann habe ich ein File abgespielt, welches etwa 74min lang war. Da hatte ich zwischendrin mal ein Event nach 17min.

Passieren tut dann Folgendes:
Normalerweise ist Port 0 auf 255 und Port 1 auf 127. In diesem Falle springt Port 0 auf 70, was Folgendes bedeutet:

100: 0 => Prev-Button gedrückt
101: 1 => unverändert
102: 1 => unverändert
103: 0 => RE-Enc-Button gedrückt
104: 0 => Button_4 gedrückt
105: 0 => Button_5 gedrückt
106: 1 => unverändert (da hängt aber auch nix dran)
107: 0 => HP_DETECT Kopfhörer eingesteckt

Das führt dann dazu, dass Port 1 sich von 127 auf 126 ändert, da der Kopfhörer deaktiviert wird (108 geht von 1 auf 0).
Das passt dann insgesamt zu meiner Vermutung, dass mehrere Buttons gedrückt werden und zudem kurz der Kopfhörer „erkannt“ wird.

Ich werde es mal testen, in dem ich 4,7k dazulöte, so dass sich 2,35k insgesamt ergeben. Ansonsten mal schauen, ob man das vielleicht auch sinnvoll debouncen kann, so dass einzelne Ausreißer nichts „anrichten“.

Bei mir läuft es häufig mehrere 10 min ohne Event. Ist glaub wirklich nicht direkt Hardware sondern irgendwas anderes noch…

Ich habe als Workaround mal einen rudimentären Debounce eingefügt, der einzelne Events „übersieht“. Der greift nach 10s Uptime.

Zum Test muss der aktuelle Code von Port_ExpanderHandler() durch mein Code-Snippet ersetzt werden. Bei mir lokal funktioniert das. D.h. statt „Ghost-Events“ sieht man jetzt nur noch „Verify set!“ im Logging.

Vielleicht können das mal 2-3 Leute verifizieren, die vorher von dem Problem betroffen waren.

1 „Gefällt mir“

Ich habe seit Arduino >1.0.6 Probleme und leider bin ich wahrscheinlich der Einzige auf der Welt. Das liegt an dem auf meinen Boards verwendetem ON/OFF-Controller LTC2954-1. Trotzdem müßte es eigentlich bei allen Boards passieren nur merkt man es nicht.
Zur Erklärung:
Mit dem LTC2954-1 schalte ich den LDO Ein/Aus.

Das geschieht mittels ROTARYENCODER_Button auf Pin PB des LTC2954-1. Die Ansprechzeiten sind mittels Kondensatoren einstellbar.
Zum Einschalten muss man den Button ca. 0,5 Sek. festhalten, zum Ausschalten ca. 4,5 Sek. Das Ausschalten funktioniert normalerweise durch Software mit GPIO POWER auf Pin KILL des LTC2954-1. Sollte der ESP mal „hängen“ kann man dann trotzdem durch langes betätigen des ROTARYENCODER_Button das Board Zwangsausschalten. Das hat alles bis vor etwa einem Jahr perfekt funktioniert.
Mit irgendeiner SW-Version hat mein Board nicht mehr gebootet. Das lag daran weil auf GPIO POWER beim Einschalten nach ca. 2 Sekunden ein LOW-Impuls auftrat und damit den LTC2954-1 abgeschaltet hat. @biologist hat mir empfohlen die Power.cpp im Setup zu deaktivieren und den GPIO POWER wieder im Setup zu schalten. Das hat geklappt…bis zum Sommer 2022. Dann passierte es wieder. Ich habe dann das Aktivieren GPIO POWER direkt als erstes in der Main.cpp ausgeführt. Hat geholfen und sogar der Aufruf der Power.cpp ging damit wieder. Ja, und jetzt mit neuer Arduino ist der Fehler wieder da und ich habe keine Idee mehr.
Ich bitte euch mal zu prüfen ( mit den Boards von Torsten) ob die Spannung an der Peripherie, also RFID, SD-Karte, Audio usw. etwa 2 Sekunden nach Einschalten kurz für 1 Sekunde aus geht. Kann man am Flackern der LED auf dem RC-522 sehen.
Ich benutze zum Abschalten im Moment den Pin KILL nicht mehr, habe es anders gelöst. Ich bin aber trotzdem sehr interessiert ob das bei euch auch so auftritt.

VG und danke schonmal vorab.

Hallo,

ich hab das jetzt auch mal getestet und es sieht eigentlich alles besser aus als mit Arduino-1… Nur eine Kleinigkeit ist mir bisher aufgefallen: Ich nutze DONT_ACCEPT_SAME_RFID_TWICE und prinzipiell funktioniert es zwar, aber wenn ich ne Karte auf dem Reader liegen lasse, dann greift sie irgendwann doch und zwar mit dieser Log:

[ 147540 ]  RFID-Karte erkannt: (ISO-14443) ID: 04-c0-7f-c9
                                                           [ 147543 ]  RFID-Karte empfangen: 004192127201
[ 147545 ]  Aktuelle RFID-Karte erneut aufgelegt - abgelehnt! (004192127201)
[ 151891 ]  RFID-Karte erkannt: (ISO-14443) ID: 04-c0-7f-c9
                                                           [ 151894 ]  RFID-Karte empfangen: 004192127201
[ 151896 ]  Aktuelle RFID-Karte erneut aufgelegt - abgelehnt! (004192127201)
[ 157312 ]  RFID-Karte erkannt: (ISO-14443) ID: 04-c0-7f-c9
                                                           [ 157324 ]  RFID-Karte empfangen: 004192127201
[ 157326 ]  Aktuelle RFID-Karte erneut aufgelegt - abgelehnt! (004192127201)
[ 158854 ]  RFID-Karte erkannt: (ISO-14443) ID: 04-c0-7f-c9
                                                           [ 158867 ]  RFID-Karte empfangen: 004192127201
[ 158868 ]  Aktuelle RFID-Karte erneut aufgelegt - abgelehnt! (004192127201)
[ 163533 ]  RFID-Karte erkannt: (ISO-14443) ID: 04-c0-7f-93
                                                           [ 163542 ]  RFID-Karte empfangen: 004192127147
[E][Preferences.cpp:472] getString(): nvs_get_str len fail: 004192127147 NOT_FOUND
[ 163547 ]  RFID-Karte ist im NVS nicht hinterlegt.
[ 164360 ]  RFID-Karte erkannt: (ISO-14443) ID: 04-c0-7f-c9
                                                           [ 164366 ]  RFID-Karte empfangen: 004192127201

Also die ersten 4 mal hat er sie abgelehnt, aber dann kam dieser getString() fehler und ab da hat er sie dann wieder akzeptiert und das aktuelle Lied von vorne gestartet.