Grundsätzlich gibt es dazu schon einen weiteren Thread: Umstieg auf ESP32-Arduino 2.x. Den ich habe jedoch nicht eröffnet und insofern gehört mir nicht der erste Kommentar, den ich jedoch gerne fortlaufend aktualisieren möchte. Das hole ich hiermit nun nach.
Um was geht’s?
Nativ wird ein ESP32 eigentlich mit dem IDF-Framework programmiert. Da Arduino jedoch sehr beliebt ist, gibt es hierfür gewissermaßen einen „Adapter“, der alles in die Arduino-Welt hebt. Diesen hat man vor einiger Zeit von der Version 1.x auf die Version 2.x gehoben. Intern hat sich damit tatsächlich auch Vieles verändert, weil man von der IDF-Version 3.x auf 4.x geschwenkt ist.
Wie kann man das mit ESPuino testen?
Zuerstmal weise ich darauf hin, dass ESPuino auf ESP32-Arduino2 experimentell ist. Man kann jedoch bis dato (Stand 10/2022) beliebig hin- und herwechseln, so dass man sich nichts kaputtmacht bei einem Wechsel. Garantieren kann ich das nicht, aber ich hatte bisher noch keine Probleme.
Um einen Wechsel zwischen ESP32-Arduino 1 auf 2 vorzunehmen, bedarf es nur kleiner Änderungen in der platformio.ini. Will man diese wieder zurücknehmen, dann kehrt man die Schritte einfach wieder um.
platform = espressif32@<=3.5.0 mit einem ‚;‘ auskommentieren und dafür das ‚;‘ zwei Zeilen tiefer vor espressif32 wegnehmen.
Die nachfolgende Zeile mit einem ‚;‘ davor auskommentieren:
Nun auf Build and Upload gehen, so dass das gesamte Projekt neu kompiliert und hochgeladen wird.
Was habe ich davon?
Grundsätzlich erstmal nix. Es warten dort (Stand 10/2022) keinerlei neue Funktionen auf dich. Es wurde allerdings schon berichtet, dass der Wechel auf ESP32-Arduino2 Störgeräusche mindern könnte. Davon ab freue ich mich aber natürlich dennoch über Tests, da ESPuino früher oder später auf ESP32-Arduino2 wird wechseln müssen.
Bekannte Probleme
(Stand 12.10.2023)
#
Beschreibung
Status
Kritikalität
1
In Kombination mit der mini-Platine, auf der ein Port-Expander verbaut ist, gibt es das Problem, dass der ESP32 nicht im Deepsleep bleibt sondern stattdessen sofort wieder aufwacht. Das Problem tritt aber offenbar nicht bei allen Port-Expandern auf, sondern (mindestens) nur bei PD9555. Bei PCA9555 scheint es das Problem wohl nicht zu geben.
Erledigt
(Blocker) wenn man einen Port-Expander verbaut hat, mit dem dieses Problem auftritt. Tritt bei der Mini 4L nicht auf.
2
Jeder zweite WLAN-Verbindungsversuch scheitert und muss durch ESPuino automatisch neu initiiert werden. WLAN-Verbindung klappt schlussendlich, kostet aber ein paar Sekunden Zeit. Grundsätzlich ist das Problem nicht komplett neu und trat auch schon unter ESP32-Arduino1 auf, aber dort hatte man es zuletzt gut im Griff.
Gefixt mit beschriebenem Workaround, den es schon für ESP32-Arduino1 gab.
(Unkritisch)
3
Der WLAN-Durchsatz beim Webtransfer schwankt stark und bleibt hinter den Spitzenwerten von ESP32-Arduino1 zurück.
Erledigt, inzwischen bis zu 700 kB/s möglich mittels „Arduino als Komponente“.
(Kritisch) wenn man Webtransfer für größere Datenmengen einsetzt.
4
In Kombination mit einer Fritzbox (7490) bekommt der ESP32 (mitunter? öfter?) neue IP-Adressen zugewiesen. Das trat bei ESP32-Arduino1 nie auf.
Nicht untersucht
(Kritisch) wenn man mit IPs und nicht mit Hostnamen arbeitet.
5
Es kommt vereinzelt zu „Ghost-Events“ über den Port-Expander. D.h. scheinbar werden Tasten gedrückt oder der Kopfhörer eingesteckt, was jedoch gar nicht der Fall ist.
Habe versuchsweise auch mal auf Arduino 2 umgestellt und mir ist folgendes aufgefallen:
positiv: Die Störgeräusche (Knackser, …) bei Wechsel der Quelle bzw. aktuelles PlayFile oder Webradio Station sind fast zur Gänze eliminiert.
neutral: NAch Wechsel habe ich eine andere IP von DHCP Fritzbox zugewiesen bekommen. Diese war dann aber wieder stabil (Bei mir wird automatisch WLAN über Nacht ausgeschalten)
negativ: Webradio Streaming ist bei einzelnen Stationen die gelegentlich Aussetzer haben dann deutlich schlechter. Dauert einige Zeit bis halbwegs ein mehr oder weniger störungsfreies Hören möglich ist.
Ich hab wieder auf 1 zurückgestellt.
Wäre interessant, ob sich das nur in meinem Setup so verhält.
Setup:
ESP32 mini (AZ_delivery)
Aktuellste Source
Fritzbox 7590
Unter Arduino1 kriegt man das ganz gut adressiert, wenn man in der Platformio.ini hinter https://github.com/schreibfaul1/ESP32-audioI2S noch #b2b5312 schreibt. Damit läuft dann allerdings das Streamen auf BT-Kopfhörer nicht mehr.
Ist diese zusätzliche Eingabe/Parameter „#b2b5312“ irgendwo dokumentiert und was verändert sich dabei, oder stehe ich jetzt ganz einfach auf dem Schlauch?
Nur für mein Verständnis - Vielen Dank!
Wenn man die Software mittels git in das git-Repository eincheckt (commit), so erzeugt man damit automatisch eine commit-id.
Wenn du dir jetzt zur besagten Lib mal die History anschaust, dann siehst du, dass genannte ID zu einem Commit vom 17.8.2022 gehört.
Anders gesagt: Platformio wird damit angewiesen, Wolles Lib mit einem Stand vom 17.8 zu verwenden.
So kannst du dann auch die andere Softwarestände durchprobieren und schauen, ob die für dich besser passen.
Zur Info, heute wurde Arduino 2.0.6 veröffentlicht:
Ob das die bekannten Probleme mit Arduino 2.x löst konnte ich noch nicht testen. Ich warte ab bis PlatformIO sein Arduino-Package nachgezogen hat. Vielleicht gibt es ja schon Early-Birds hier
Die Bugfix-Liste liest sich schon beachtlich. Meine Probleme mit jedem 2.x Release betreffen vor allem unzuverlässige WiFi Verbindung und schlechterer Datendurchsatz. Auch das Einfrieren der Pins für LPCD klappte bislang nicht. Mal schauen wie es mit diesem Release aussieht…
Alles komipliert ohne Probleme & beim Start wird im Log dann
ESP-IDF version: v4.4.3
angezeigt
Mein erster Eindruck:
Web-Upload. Teils schlechte Performance, teils schnellerer Upload als 1.0.6 (>400Kb/s). Keine Ahnung woran es liegt, kann es hier nicht sicher reproduzieren?
OTA-Upload deutlich schneller
Nach wie vor jede 2. WLAN-Verbindung macht Probleme (FRITZBox 7590). Klappt dann aber nach einiger Zeit. Jetzt auch eine entsprechende Ausgabe:
[ 5057 ] Verbindung zum WLAN nicht möglich. Nächster Versuch...
[ 5089][E][WiFiGeneric.cpp:1166] mode(): Could not set mode! 12289
[ 5089][E][WiFiSTA.cpp:299] begin(): STA enable failed!
[ 7582 ] Aktuelle IP: 192.168.178.64
Aufruf an die Early-Birds, wer will testen? Wäre fein wenn das noch jemand gegenprüfen lönnte…
Könnte auch sein das hier meine Frau ab und an die Leitung für „Insta“ verstopft und die Messergebnisse verfälscht
Kann ich so bestätigen. „Spiele“ gerade noch mit den RingBuffer Settings, aber sobald man glaubt, dass man gute Settings gefunden hat, bricht die Übertragung beim x. Versuch plötzlich ein.
Nicht getestet.
Das hab’ ich tatsächlich gar nicht. Habe jetzt auch zum ersten Mal die 2er Version probiert. Verbindung ist sofort da.
Ich habe allerdings auch keine Fritz-Box!
Haben nur die Fritz-Boxen das Problem?
Habt ihr einen Repeater an der Fritz-Box? Habe in einem ESPHome Issue einen entsprechenden Hinweis gefunden…
So, habe wieder eine Debug-Hardware (zwar noch kein RFID-Reader, läuft aber auch so schon ganz gut )…
Habe jetzt auch mal diese Version gestartet und kann das WLAN-Problem nicht nachstellen. Ist sofort ohne erneuten Versuch verbunden. Habe auch eine FritzBox (6660 Cable). Werde mal noch weiter auf der Version testen… [ 357 ] ESP-IDF version: v4.4.3
Werde ich mir morgen Mal genauer anschauen. War heute Abend nur auf dem Webserver ohne Dateiübertragung, das war aber alles sehr stabil. Ist bei OTA immernoch der Bug, dass man danach nicht mehr per USB flashen kann?
Genau, das gilt es auch noch zu testen. Verwende hier kein OTA sondern habe einfach nur mal die aktuelle Binary hochgeladen um die Geschwindigkeit zu testen. Und die war deutlich besser.
Evt. findet sich noch ein Tester der unter dem OTA-Bug leidet, z.B @compactflash
Bis auf den Upload funktioniert die Version sehr gut bei mir.
Ich habe in den letzten Tagen noch viel experimentiert. Das Problem ist, dass es wirklich nicht zuverlässig reproduzierbar ist. Ich erreiche zuverlässig > 400kB und nach zwei reboots falle ich zurück auf 200 kB.
Mir ist allerdings aufgefallen, dass sich die Verwendung von PSRAM geändert hat. CONFIG_SPIRAM_USE_MALLOC=y
„wild guess“: Wenn bestimmte Speicherbereiche im PSRAM ausgelagert werden, wird es langsam. Wir hatten früher schon probiert, den RingBuffer für den Upload in den PSRAM zu legen. Das ist super langsam.
@tueddy verwendest Du ein Board mit PSRAM? Wenn ja, könntest Du mal versuchen ohne PSRAM-Support zu kompilieren?
...Hilft leider auch nicht.
Bei einem meiner Boards kann ich mit der Arduiono 2 firmware nicht mehr in den deep-sleep. Leider ist das die Hardware der Kids :-/ . Bei der anderen funktioniert es. Eigentlicih sollten die Boards identisch sein.
Mal schauen ob ich das bei Gelegenheit bisschen debuggen kann…
Es ist immer: [ 559 ] Wakeup caused by push-button
Das steht auch im ersten Post unter den bekannten Problemen. Interessant finde ich jedoch, dass es mit einem der beiden geht. Besitzen beide Boards einen Port-Expander von NXP?
Das, das funktioniert, auf jedenfall. Das andere will ich gerade nicht ausbauen. Da der Zeitliche Abstand eher kurz war zwischen den beiden Bestellungen hätte ich eigentlich die selbe Hardware erwaretet, aber das kannst du vielleicht am ehesten sagen …
Das ist ja echt total nervig. Ist es noch aktuell, dass das noch niemand untersucht hat?
Welche Port-Expander versendest du üblicherweise?
.
