Hi @Joe91 , definitiv kämpfe ich schon seit >2 Jahren mit meinen PCB´s und Störgeräuschen und habe das hier auch schon öfter angesprochen. Es trat erst mit der Umstellung auf SD_MMC auf, mit SD_SPI ist es nicht. Es ist hauptsächlich beim Booten und beim Titelwechsel hörbar. Ich habe das mit verschiedenen DAC´s probiert, MS6324, PCM5102A, PT8211. Mit dem MAX98357 passiert es seltsamerweise nicht, der Chip ist resistent.
Viel besser wurde es erst als @tueddy den SD_Zugriff beschleunigt hat. Es ist aber immer noch minimal hörbar, vor allem wenn zeitgleich das Browserfenster aktiv ist, also für mich ganz klare Zeitprobleme.
Ich verwende aus Platzgründen auch 2 Boards als Sandwich und habe beide neu in 4L erstellt. Das habe ich gemacht weil @biologist damit positive Erfahrungen gemacht hat. Und tatsächlich ist bei mir der Fehler weg wenn das Develboard in 4L ist. Mein altes Audioboard in 2L ist auch in Kombi mit dem neuen Develboard still. Mich würde brennend interessieren warum das so ist. Ich habe alles Mögliche versucht mit Kondensatoren, Feritten und Abschirmung, nichts hat geholfen. Nur ein räumliches Trennen von 3-4 cm zwischen Audioboard und Develboard, egal ob daneben oder darüber, brachte Erfolg. Ich verwende jetzt wegen LiFePo4 auch einen anderen Laderegler und anderen Spannungsregler. Ob es daran liegt oder an der zusätzlichen Abschirmung innerhalb des PCB mit GND-Plane , keine Ahnung.
@compactflash Danke für Deine Erfahrungen, deutet wohl auf Hardwareprobleme hin.
Softwareseitig könnte man einmal die Taskauslastung prüfen. Das wurde von @tuniii schonmal gemacht mit vTaskGetRunTimeStats() Diese Funktion wird stadardmässig nicht mit einkompliert aber kann hier jetzt recht leicht aktiviert werden mit diesen Flags:
Vielen Dank für diese Antworten. Nicht wirklich befriedigend diese Situation .
Werde auf jeden Fall erstmal kein 4-Layer-Board besorgen sondern davor nochmal schauen ob ich das irgendwie anders in den Griff bekomme. Da der Unterschied unüberhörbar ist für mich will ich da erstmal noch weiter dran herumspielen. Muss ja irgendeinen Zusammenhang geben.
Vielleicht gibt es ja eine einfache Lösung…
Aber der Branch / die Funktion läuft ja nicht weg …
Darin können jetzt ganz viele Einstellungen geändert werden, oder auch geänderte Einstellungen wieder geladen werden.
Über die Option „Save minimal config“ wird der Diff zu Default gespeichert. Dieser Inhalt entspricht dann dem in der sdkconfig.defaults (und kann in eben diese Datei übernommen werden).
Sobald in dieser Datei (sdkconfig.defaults) eine Änderung gemacht wurde bedeutet das, dass beim nächsten build alles neu gebaut werden muss. Das dauert deutlich länger als bis jetzt (bei mir aktuell ca. 2 min).
Natürlich können auch händisch Änderungen hinzugefügt werden, idealerweise werden diese dann aber nochmal duch „laden“ und „speichern“ entsprechend formatiert…
Soweit mal in aller kürze
Viel Spaß beim experimentieren und optimieren!
Joe
@Joe91 Sehr geil, vielen Dank!
Ja, ist ist letztlich genau das, was es für mich gebraucht hat. Ich habe WPA3 deaktiviert und habe jetzt, wenn ich aus der Web-GUI einen Restart mache, nach 1-2 Sekunden wieder meine Verbindung.
Im ersten Versuch (auf meinem Mac), als ich die Umgebung umgestellt habe, bin ich in einen Fehler gelaufen. Da musste ich noch ein Python-Modul installieren:
Hab’s getestet und es funktioniert wirklich einfach, nur die eine Zeile in der Platform.ini ändern, fein!
700KB/s Uploadrate ist auch da.
Und weniger Speicherbedarf.
Beim ersten Build komme ich mit 2 Minuten nicht aus, aber danach geht’s flott. Hhast Du einen Apple M123?
Ist Deine Konfiguration nur für ESP-32 Revision 3 oder auch für ältere Boards?
Aus meiner Sicht der richtige Schritt für die Zukunft @Joe91
Habe bei mir eben so 650 kB/s etwa gemessen. Sau cool!
Ich muss zugeben da bin ich bissl zu sehr „raus“, um das beurteilen zu können.
Ja ich denke, wenn man nicht gerade nen Apple ARM64 hat, dann wird’s ggf bissl dauern.
Was ich mich spontan frage: Bei der Sache mit den WLAN-Connect-Problemen bin ich ja nicht alleine; das haben schon mehrere Leute berichtet. Kriegen wir das irgendwie komfortabel selektierbar (àla settings.h) bei uns unter? Weil ich denke bei den sonstigen Optionen werden die wenigsten Leute aktiv was anpassen wollen.
Super! Dann am besten auch gleich die Einstellung für WPA3 in die sdkconfig.defaults mit reinnehmen, sobald es im Dev-Branch ist
Da hat die erste Modifikation nicht lange auf sich warten lassen
Mein PC ist halbwegs aktuell, auf meinem Laptop braucht es deutlich länger beim Clean-build
Aus meiner Sicht spricht nichts dagegen aus diesem Grund WPA3 generell zu deaktivieren.
Wir können sonst auch die sdkconfig.defaults abhängig von Compileflags per Script editieren, würde aber spontan nur eine Version (und im Zweifelsfall die mit den meisten Vorteilen) bevorzugen.
Man könnte aber auch mehrere Dateien ablegen und je nach Einstellung eine andere anziehen, macht die Sache aber wieder unübersichtlich…
Ich sehe das jetzt vor allem als einen Start, von dem aus wir Stück für Stück immer noch besser werden können da wir nicht mehr eingeschränkt sind sondern jetzt ganz viele Möglichkeiten offen stehen.
Kriegen wir das irgendwie komfortabel selektierbar (àla settings.h) bei uns unter?
WPA-3 macht ja Probleme, ich würde es jetzt werksseitig deaktivieren und wer es unbedingt haben will, der schaltet es dann halt ein. Das wird aber nur über die SDK-Konfiguration möglich sein. Also „Unsupported-Experten Modus“. sozusagen.
Was mir gefällt: Der Weg löst die bekannten Probleme, bringt Vorteile wie Webspeed & man kann es schrittweise einführen.
Ich habe mir das menuconfig gerade noch ein bisschen angeschaut.
ETH_USE_SPI_ETHERNET könnte auch raus. Modbus ebenfalls (komplett, alles). Und auch SPIFFs, weil wir das nicht nutzen.
Die Stelle von dir kannte ich tatsächlich noch nicht und hatte die auch nicht gefunden.
Wenn man dort die passenden Files zusammenfügt sollte es jetzt hoffentlich auf das gleiche oder ein sehr ähnliches Ergebnis kommen, das schaut ich mir aber nochmal an. .
Bin gespannt und melde mich wenn ich Ergebnisse verglichen habe.
Ziel ist aber immer gewesen auf der möglichst identischen Basis zu starten und dann von dort aus zu optimieren.
Habe den PR jetzt direkt übernommen. „espidf“ aka „Arduino als Komponente“ ist wie oben beschrieben zunächst deaktiviert und kann über eine Zeile in platform.ini umgeschaltet werden.
So können alle Interessierte an den Einstellschrauben drehen um das beste Ergebnis zu finden.
Wenn du die Ini geändert hast braucht er erstmal bisschen bis er das Projekt aktualisiert hat. Hast du bisschen gewartet und passiert was wenn du auf build drückst?
Gibt es sonst irgendwelche Fehlermeldungen?
Manchmal funktioniert es nur mit J und K statt den Pfeiltasten. Keine Ahnung woran das liegt. Bei mir war das zwischendurch auch mal so, jetzt gehen die Pfeiltasten aber wieder ganz normal…
Guter Vorschlag, habe jetzt mal SPI-Ethernet, BLE, BT-HFP & Modbus deaktiviert. Bei SPIFFS habe ich mich nicht getraut, evt. wird das nochmal eingesetzt? So sehen jetzt die Speicherwerte im Vergleich aus:
Arduino (ohne Komponente):
RAM: [=== ] 31.8% (used 104236 bytes from 327680 bytes)
Flash: [==== ] 35.2% (used 2307673 bytes from 6553600 bytes)
[ 556 ] Freier Heap-Speicher nach Setup-Routine: 109440
Arduino als Komponente bisher:
RAM: [=== ] 31.4% (used 103020 bytes from 327680 bytes)
Flash: [=== ] 34.9% (used 2289281 bytes from 6553600 bytes)
[ 565 ] Freier Heap-Speicher nach Setup-Routine: 119688
Arduino als Komponente mit o.g. Änderungen, Softwarestand 20231002-1 :
RAM: [=== ] 29.6% (used 96864 bytes from 327680 bytes)
Flash: [=== ] 30.4% (used 1992453 bytes from 6553600 bytes)
[ 580 ] Freier Heap-Speicher nach Setup-Routine: 120108
Da kann man sicher noch mehr optimieren aber Speicher ist jetzt schon ausreichend vorhanden.
Edit: Was mich wundert: Messung der Taskauslastung zur Laufzeit scheint immer aktiv zu sein:
Das ist eigentlich ein Debug-Feature & die Flags CONFIG_FREERTOS_USE_TRACE_FACILITY & CONFIG_FREERTOS_GENERATE_RUN_TIME_STATS sollten standardmässig nicht aktiv sein?
Sehr cool!
Ich halte das für sinnvoll, dass die Flags erstmal aktiv sind. Auf diese Art können wir viel besser Probleme finden und identifizieren. Sollte auch nicht viel an Performance kosten. Wenn wir dann Mal weiter sind können wir sie ja ganz einfach raus nehmen.
Über das define in der settings.h sollte aber eigentlich die Ausgabe des debug Zeug deaktiviert sein. Oder?
.
…
