Hier mal ein schnell zusammengeflickter Commit mit den wesentlichen Änderungen. Ist nicht besonders viel. Allerdings übersetzt das so auch noch nicht ganz. Offenbar gibt es noch ein paar Warnings in den Libs, die jetzt als Errors behandelt werden. Wahrscheinlich muss man da noch an den Compiler-Flags schrauben.
In der sdkconfig.defaults können die vom Default abweichenden Optionen für ESP-IDF eingetragen werden. Mit pio run -t menuconfig kann man das Konfigurationsmenü für ESP-IDF aufrufen.
Ich habe mal geschaut, was so wie viel Speicher verbraucht:
| Module | Size | Comment |
|---|---|---|
| esp-components | 62,0k | Da ist alles von FreeRTOS Funktionen bis HAL drin |
| libc | 11,2k | Die newlib library von gcc |
| WiFi+BT phy | 9,1k | WiFi phy Treiber (davon ~1k für BT) |
| ESPuino | 0,9k | Hier kommt das Meiste von ESP32RMTController |
| binary-blob | 31k | Funktionen aus Binary-Blobs von esp-idf, empirisch* ermittelt sind 27k von Bluetooth |
| Rest | 9,5k | Namenslose symbole, die von elf-size-analyse nicht erkannt werden Bug #4 |
Hier die unbearbeitete Ausgabe: unfiltered_output.zip (38,5 KB)
Wenn ihr das nachstellen möchtet, in Platformio Terminal elf-size-analyze installieren: python -m pip install elf-size-analyze. Danach mit folgender Commandozeile aufrufen:
elf-size-analyze.exe -S7 --no-color --toolchain-triplet=C:\Users\[username]\.platformio\packages\toolchain-xtensa-esp32\bin\xtensa-esp32-elf- .\.pio\build\[target]\firmware.elf >elf-size.txt
Wichtig ist, dass ihr den Pfad zu der xtensa Toolchain angibt (--toolchain-triplet, der Pfad im Beispiel ist für Arduino2) und natürlich die elf, die ihr analysieren wollt. -S7 begrenzt die detailierte Ausgabe auf iram0.text.
Als Ausgabe empfehle ich txt ohne Farben (--no-color) und dann mit notepad++ anschauen. HTML ist ein wenig buggy und JSON habe ich noch nicht ausprobiert.
*: Ich habe zwei elf verglichen, eines mit und eines ohne Bluetooth. Vor allem bei dem Binary blob (in elf-size.txt alles unter „?“) gibt es da ein Unterschied von 27k (31k vs 3,5k).
Vielen Dank dir! Sieht doch etwas komplexer aus.
Bin heute Abend jetzt leider nicht mehr dazu gekommen. Melde mich aber sobald ich es am Laufen habe und die Verbessungen des iram der Flags jeweils auflisten und testen kann.
Einen guten Wochenstart euch!
Vielen Dank dafür!! Sehr interessant.
Wenn wir also das Flag " CONFIG_FREERTOS_PLACE_FUNCTIONS_INTO_FLASH" zum Laufen bekommen hätten wir auf einen Schlag wieder viel Platz 
.
Vielleicht reichen aber ja auch die kleineren Änderungen wie die Erhöhung der minimalen Version o.ä.
Also das mit dem Compiler-Flags ist bisschen nervig ^^.
Irgendjemand setzt irgendwo versteckt immer das „-Werror=all“. Vermutlich kommen dadurch auch wenn man die entsprechenden Warnings deaktiviert trotzdem alle als Fehler durch.
Wenn man die entsprechenden drei Stellen händisch korrigiert hängt man allerdings beim Linken:
.platformio\packages\framework-espidf\components\freertos\port/port_common.c:137: undefined reference to `app_main'
Ich suche mal weiter. Das mit den Flags in der sdkconfig.default klappt bei mir auf jeden Fall schon mal nicht. Die scheinen entweder ignoriert zu werden oder von den jeweilig anderen Files überschrieben zu werden…
Komm hier gerade echt nicht mehr weiter. Muss diese Woche auch beruflich viel machen, hoffe aber am Wochenende nochmal Zeit zu finden da den einen oder anderen Zusammenhang herauszufinden.
Sobald ich weiß wer diese Config-Files mit hoheit von wo überschreibt sollte man nochmal ein ganzes Stück weiter kommen…
Hallo @laszloh
Danke für die ausführliche Antwort. Die Punkte sind mir alle bekannt , ich war über 40 Jahre Servicetechniker im Kommunikationsbereich. Die Werte habe ich nicht erträumt . Ich habe die letzten Tage mehrmals versucht es nochmals so nachzustellen . Es ist mir nicht mehr geglückt. Unterschiedliche Hardware und verschiedene Codes ausgetestet. Immer ok. Die maximalen Abweichungen bewegen sich in der 2. Stelle hinter dem Komma, also etwa 10-20 mV. Sowohl im Webfrontend als auch im Monitor. Das ist ok und führt nicht zu fehlerhaften Anzeigen des Neopixel bei LiFePo4 oder gar Abschaltung. Aber die ersten Messungen waren halt anders, und leider weiß ich nicht warum.
Danke nochmals , und sorry das du dafür Zeit aufwenden musstest.
VG
So, um das Ganze hier ein wenig zu beschleunigen (*), habe ich @tueddy Schreibzugriff auf mein Repository gegeben. Er kennt ESPuino schon seit den Anfängen und damit die ganze Historie. Ich bin 100% überzeugt, dass das gut funktionieren wird.
@tueddy An dieser Stelle nochmal vielen Dank für deine ganze Zeit, die du in ESPuino steckst!
Ansonsten natürlich einen großen Dank an den Rest hier. Ich find’s schön, dass sich das Ganze auch auf kommunikativer Basis inzwischen selbst trägt. Früher habe ich immer geschaut, dass ich das Ganze hier regelmäßig selbst befeuere, da ich die Befürchtung hatte, dass hier sonst zu wenig los ist und das Projekt damit früher oder später einschläft. Inzwischen ist das jedoch nicht mehr notwendig 
.
(*) Ich bin aktuell zu sehr mit anderen Dingen beschäftigt, so dass mir die Zeit zum Testen (zum Entwickeln eh) fehlt - manchmal auch (ganz ehrlich) die Lust. Um die Hardware werde ich mich natürlich weiterhin kümmern. Da ist es aktuell relativ ruhig, aber speziell kurz nach der Osterzeit gab’s doch einiges an Arbeit für mich. Es war sogar eine Bestellung aus Saudi Arabien (!) dabei. Das war jetzt das erste Mal, dass mich jmd. kontaktiert hat, der kein Deutsch spricht.
@biologist Vielen Dank für das Vertrauen!
Bin mir sicher das wir das Projekt voranbringen können, gerade auch weil die Diskussionskultur hier im Forum so gut funktioniert.
Ich würde Euch bitten jetzt nicht gleich Feature XYZ rauszuballern. Ich sehe das genauso wie Torsten neue Dinge hier zunächst vorzustellen und zu diskutieren. Fokus zunächst auf Bugfixing & Verbesserungen.
Wir starten mit Remove PROGMEM and supporting macros #229 von @laszloh , Vielen Dank für Deinen Beitrag!
Zum Thema Bugs:
Mir fehlt in der Kategorie SOFTWARE die Unterkategorie „BUG Reports“ oder sinngemäße Bezeichnung.
Wenn jemand glaubt, einen Bug entdeckt zu haben, dann sollte das m. M. nach in einer eigenen Kategorie gesammelt werden können. Bei der Auflistung der Beiträge wäre dann ein Status interessant wie:
oder englisch
Ich habe hier vor einer Weile die Kategorie „Fehlersuche“ angelegt. Das habe ich jetzt mal umbenannt in „Bugreports / Fehlersuche“. Flags kriegt man darüber jetzt nicht abgebildet, wobei man ja aber zumindest für gefixt halt „Lösung“ anklicken kann.
Das ist halt einfach ein Forum hier und kein Bugtracker. Wenn man das in ganz klassisch möchte, dann kann man das via GitHub machen.
Wie ist eigentlich der Prozess, damit ein Bugfix oder Feature den Weg vom Dev in den Master geht?
Irgendwann wenn der dev sehr stabil läuft und genügend Features hinzugekommen sind, wird dieser in den Master gemerged…
Man könnte Schlagwörter (Tags) dafür nutzen.
Im Discourse Forum machen sie das zum Beispiel bei den Feature Requests. Die bekommen dann ein „completed“
Ich komme gerade einfach nicht weiter mit dem iram und kann deshalb auch leider den dev-branch nicht mehr verweden. Hätte jemand Interesse / Zeit für einen direkten Austausch zu dem Thema? Oder sollen wir ein separates Thema erstellen?
Ich steige gerade einfach noch nicht durch bei dieser ganzen Platformio config und bekomme das nicht in vielen Versionen nicht gelinkt…
Der Punkt ist halt, dass da vor allem der Fix für den Ringbuffer drin ist. Das muss halt schon demnächst mal in den Master rein. Von daher wäre ich dafür, dass abseits dessen, was jetzt schon PR ist, erstmal nix dazukommt und man anstrebt, das im Mai mal zu mergen. Der Schwerpunkt sollte stattdessen sein, dass dev überhaupt mal wieder normal kompilierbar wird.
Ist jetzt nicht so ganz handlich, aber wäre eine Option.
Hab’s mal aktiviert und diesem Thread mal ein Schlagwort gegeben.
Edit: Mir ist nur ehrlich gesagt unklar, wie die da den grünen Haken hinkriegen. Das klappt hier irgendwie nicht.
Ja, das habe ich auch schon gesehen und das Plugin installiert. Aber verstanden habe ich’s noch nicht, wie ich da jetzt zB nen grünen Haken reinkriege.
Ich deaktiviere momentan einfach Bluetooth, weil ich das nicht brauche. Da könnte man auch mal drüber nachdenken ob man das standardmäßig deaktiviert.
Ansonsten habe ich gerade nicht so viel Zeit damit zu experimentieren. Aber ich habe es zumindest mit ein paar kleinen Änderungen geschafft den Branch für „Arduino as IDF Component“ soweit zu bekommen, dass er bis auf den IRAM Speicherüberlauf baut. Allerdings ist der Überlauf jetzt plötzlich ~12 KiB. Das heißt da ist in der Konstellation jetzt irgendwas drin was davor nicht drin war.
@Joe91 Vielleicht bringt dich das irgendwie weiter!?
Vielen Dank dir. Ja an diesen Punkt bin ich auch schon etwas überrascht gekommen ^^.
Das mit dem Bluetooth ist ein guter Quickfix. Werde das wohl auch erstmal so machen…