Hi, ich würde das jetzt erstmal noch vom Dev-Branch-Thema entkoppeln…
Können das ja dann auch wieder löschen wenn wir bisschen weiter sind.
Worum geht es:
Arduino wird aktuell vollständig als eine vorkompilierte Komponente verwendet. Das macht vieles schneller, nimmt aber jedliche Konfigurations-Möglichkeit. Da es bei uns aktuell im IRAM sehr eng ist (und auch so maches der starren Konfiguration ungeschickt ist), kam der Vorschlag zu diesem Vorgehen.
Dadurch wird das arduino-framework jetzt im projekt mit gebaut und über die sdkconfig-files und die UI (menu-config) vollständig parametrierbar.
Durch diese Möglichkeiten können z.B. alle Optionen von hier angewandt werden um IRAM zu sparen.
Hier ist der branch, auf dem das aktuell getestet wird:
Alle Konfigurationen können in die sdkconfig.default eingetragen werden.
Damit es in dieser Konfiguration baut am besten CONFIG_FREERTOS_PLACE_FUNCTIONS_INTO_FLASH=y einfügen.
Ich bin aktuell sehr zufrieden wie stabil und unkompliziert das ganze läuft.
Habe jetzt mal bisschen detailierter den Speicher im IRAM angeschaut. Vieles ist exakt identisch, manches aber auch nicht.
Auffälligste Stellen bis jetzt (in Byte):
Symbol dev-Branch component-Branch
stdio 2798 3088
time 1880 1982
machine\xtensa 1074 1160
In Summe sind ohne BT 806 Byte unterschied (ohne IRAM-Config-Optimierungen) bei identischen Rahmenbedingungen.
Hat jemand eine Idee woher diese Unterschiede kommen könnten?
Mein Ziel ist es nicht das identsich hinzubekommen, ich möchte aber schon verstehen woher die Unterschiede kommen …
@Joe91 wäre noch fein wenn Du im Eingangspost mal erklärst worum es hier eigentlich geht. Weil sonst weiß das nur jemand der sich durch 108 Post aus diesem Thread durchgekämpft hat…
Zunächst war ich sehr skeptisch ob das Ändern des Buildvorgangs nicht mit „Kanonen auf Spatzen geschossen“ ist & Alles einfach nur super-duper-langsam gebaut wird…
Habe jetzt „Arduino als Komponente“ mal ausprobiert und hier meine Ergebnisse:
Toll wie PlatformIO das integriert hat, das klappt einfach mit einem Klick auf den „build“-Schalter! Ein kompletter Build dauert zwar ca. 3 mal so lang & wirft viele Warnmeldungen, aber OK dann kocht man sich eben in der Zwischenzeit einen Kaffee. Danach ist bei Änderungen im ESPuino Code das Compilieren schnell wie gewohnt.
Die neuen notwendigen Komponenten werden automatisch von PIO geladen und Alles integriert sich gut. Bei Code-Änderung & neuem Upload ist die Geschindigkeit völlig OK, also ich finde das sehr praktikabel. Ich kann auch einfach zwischen „klassischen Arduino“ & „Arduino als Komponente“ umschalten durch ändern einer Zeile in platform.ini:
Wenn ich mit allen Features kompiliere wird der IRAM-Speicher um 708 Bytes überschritten. Die Konfigaration ist also nicht dieselbe wie das vorgefertigte Arduino-Frameowork. Auch die Web-Upload Performance ist deutlich um 100KB/s schlechter. Wie bekommen wir zunächst gleiche Bedingungen um dann zu otimieren?
Für spätere Optimierungen fallen mir schnellerer Web-Upload oder Bluetooth Optimierungen ein.
Auf jeden Fall ein Weg den man weiter verfolgen könnte…
Ja, mittlerweile ist das wirklich trivial in der Anwendung nachdem @fschrempf das mit den Configs voll zum Laufen gebracht hat.
Genau diesen Speicher-Unterschied habe ich ja im Beitrag eins weiter oben schon festgestellt, aufgrund von Krankheit aber jetzt nicht viel weiter verfolgen können.
Werde damit aber weitermachen. Letzter Stand sah für mich vor allem nach den allgemeinen Libs aus.
Daher auf diesem Branch im Moment einfach die Option CONFIG_FREERTOS_PLACE_FUNCTIONS_INTO_FLASH=y in die sdkconfig.default eintragen und nochmal bauen.
Von der Konfiguration her:
Wir sind eigentlich auf exakt dem default. Die Unterschiede sind wirklich spannend. Irgendwas ist da irgendwo noch anders.
Ich dachte vielleicht kommen die Unterschiede auch einfach nur von der verwendeten Platform-Version. In dev haben wir aktuell platform = espressif32@^6.2.0 und im Feature Branch feature/arduino-as-component nur platform = espressif32. Oder von der zugrunde liegenden sdkconfig. Ich hatte die ja aus dem master von arduino-esp32 genommen. Aber nach einem Vergleich hat sich gerade gezeigt, dass es daran nicht liegt.
Sonst habe ich gerade spontan keine Idee mehr. Werden vielleicht andere Compiler-Optionen verwendet, die eine Auswirkung auf den Speicher haben…!?
Das ist auch meine aktuelle Vermutung. Oder es werden irgendwie andere Standard-Libs angezogen die weniger optimiert sind. Zumindest sehe ich den Speicherunterschied der Symbole hauptsächlich dort.
Stellt sich die Frage: Ist dieser Unterschied wichtig???
Vorschlag:
wir stellen diesen Branch auf die selbe Platform-Version und verwenden die Option mit den RTOS-Funktionen im Flash. Von dort aus können wir als Basis die Vorschläge von @tueddy mal untersuchen.
Ich habe auf dem Branch jetzt den aktuellen dev-branch reingemerged und die RTOS-Funktionen ins Flash gelegt.
Ich kann dabei keinerlei Geschwindigkeitsunterschiede zwischen diesem Branch und dem dev-Branch beim Webupload feststellen. Bei mir war der „Arduino als Komponente“ Branch im Schnitt 5-7 KB/s schneller, das liegt aber definitiv im Berech Messfehler. Szenario war dabei immer der Upload eines ganzen Ordners mit jeweils vergleichbarer Größe.
Werde das so erstmal auf meinen Systemen verwenden und bisschen Langzeiterfahrung sammeln…
Soweit ich gelesen habe hat die Option CONFIG_FREERTOS_PLACE_FUNCTIONS_INTO_FLASH auch Auswirkungen auf die Ringbuffer, damit werden die aus dem schnellen IRAM entfernt. Von daher hätte ich erwartet das der Web-Upload langsamer wird oder der Modus Bluetooth-Kopfhörer hakelt. Aber gut, wenn das funktioniert, wunderbar!
Unser Audio-Chef Wolle hat „Arduino als Komponente“ ebenfalls umgesetzt um bessere Wifi-Download-Geschwindigkeit zu erzielen. Hier ist sein Beispiel. Vielleicht können wir uns etwas abschauen. Evt. kann @Wolle Wolle noch Erfahrungen teilen? Insbesondere würde mich interessieren ob seine Optimierungen auch einen schnelleren Webupload ermöglichen, also genau die andere Richtung?
Gerade bei Stationen mit hoher Bitrate >=256KBit/s oder geringer Kompression (FLAC, WAV) kommt es wegen der schlechten Empfangsgeschwindigkeit zu Aussetzern. Ich hatte zuerst den WiFiClient als Bremse in Verdacht. Aber IDF ohne Arduino mit dem HTTP_Client brachte keine Besserung. Durch die Anpassung der TCP Parameter habe ich eine etwa 3…4 fachen Datendurchsatz erreicht. Somit sind jetzt auch viele problematische Stationen ohne Unterbrechungen empfangbar. Die blauen Parameter habe ich im menuconfig geändert (muss nicht das wirkliche Optimum sein) Grüne kamen (irgendwie?) mit hinzu. Links original, rechts geändert:
So wie ich das verstanden habe ist der Ringbuffer immernoch im iram. Die liegen auf seperaten Configs…
Durch die Optoin CONFIG_RINGBUF_PLACE_FUNCTIONS_INTO_FLASH wird ungefähr 1K zusätzlich an iram frei.
Das sollte allerdings nichts mit dem Buffer selbst zu tun haben, das werde ich aber nochmal nachschauen…
Habe „Arduino als Komponente“ mit dem aktuellen DEV-Branch am Start und kann hin und her schalten, fein!
Leider bekomme ich ca. 100KB/s schlechtere Web-Upload Performance. Daheim & im Büro-WLAn getestet.
Auch Wolles Optimierungen wollen nicht so recht funzen. Ich ändere sdkconfig.defaults und lösche vor dem Erzeugen die automatisch erzeugte sdkconfig.lolin_d32_pro_sdmmc_pe. CONFIG_RINGBUF_PLACE_FUNCTIONS_INTO_FLASH macht da keinen Unterschied. Bedeutet aber auch das durch diese Einstellung nichts merkbar langsamer wird!
Idee wie man das lösen kann?
Danke für diese Rückmeldung! Das muss ich ich auch endlich mal hinbekommen diese Geschwindikgeitsunterschiede zu sehen. Verstehe echt nicht warum ich egal mit welchem Branch oder Hardware nicht ansatzweise auf deine Geschwindigkeiten komme (daher sehe ich leider auch den Unterschied zwischen Komponente und nicht Komponente nicht).
Werde wohl vor allem mal meine WLAN-Umgebung untersuchen…
Sobald ich da Fortschritte mache und das reproduzieren kann schaue ich mir den Geschwindikeitsunterschied an. Sonst habe ich aktuell wirklich gar keine Probleme und es läuft super stabil bei mit (seit dem letzten Post keine Probleme)…
Habe hier mal an den Einstellungen für die Performance des Web-Uploads (und auch allgemein) gespielt und komme auf diesem Branch auf fast 700 KB/s upload-speed.
Achtung:
Dieser Branch verwendet aktuell die Option „CONFIG_ESP32_REV_MIN=3“ was deutlichs IRAM spart und etwas Geschwindigkeit gibt, aber auf alten Boards nicht funktioniert.
Wer will kann gerne damit testen oder auch noch bessere Settings finden …
Habe gerade nochmal in die verschiedenen Branches geschaut, allerdings schlummert hier noch irgendwo was ziemlich komisches. Wenn man mit Kopfhörer (EDIT: 3,5 mm Klinke) Musik hört, ist diese total zerhackt.
Solange dafür die Ursache noch nicht gefunden ist, bringt es auch noch nichts das so in den dev-Branch (auch wenn auskommentiert) zu bringen…
Wer immer was herausfindet, gerne Bescheid geben …
Tritt übrigens schon auf den ganz frühen Versionen des Branches auf, also ziemlich wahrscheinlich irgendwas, was mit den default-settings von Github nicht passt…
Habe den Kopfhörer-Anschluss mit der 4Layer-Mini-Platine getestet & kann kein Knacken feststellen!
Auch nicht mit „Arduino als Komponente“. Aktueller DEV-Stand. Audio-Qualität ist gut. @Joe91 Evt. ein Hardwareproblem bei Dir?
Das ist ja spannend. Bei mir ist es vollständig weg wenn ich auf dev bin und absolut störend wenn ich auf dem Komponente - branch bin…
Ist aber vielleicht auch zu subtil um mit jedem Kopfhörer/Lied hörbar zu sein…
Vielleicht ist es auch irgendein Grenzfall, der halt erst dadurch unter bestimmten Umständen zum Tragen kommt. @tueddy : wie würdest du damit umgehen? Ich habe nur das 2L Board. Vielleicht ist das dort ein Grenzfall?
Bin mir aber ziemlich sicher, dass es nicht direkt an einem der Config-Values liegt, sondern irgendwas anderes ist…
Also das Knacken tritt nur auf wenn Du mit „Arduino als Komponente“ startest?
Haben die Flags HEADPHONE_ADJUST_ENABLE bzw. PLAY_MONO_SPEAKER Auswirkungen?
Stimmt der Pin HP_DETECT ?
…
