nachdem die Hardware jetzt fast fertig ist (danke Torsten für den tollen Service, Fotos folgen noch demnächst), beschäftige ich mich jetzt etwas mit der Software. Es ist wirklich toll was da schon alles an Aufwand reingesteckt wurde und was man mit dem ESPuino alles machen kann.
Ein Punkt der mir aufgefallen ist, ist dass die Konfiguration der Software zur Compile-Zeit über das manuelle Editieren der Header-Dateien nicht gerade das Gelbe vom Ei ist. Daher habe ich mir überlegt wie das ganze mit Kconfig (Konfigurationssystem des Linux Kernels, das aber auch sonst sehr verbreitet ist) umgesetzt werden könnten.
Ein wesentlicher Vorteil aus User-Sicht ist die Konfiguration über das klassische „menuconfig“ Menü, ohne den Code anfassen zu müssen. In einem PIO-Terminal in VSCode kann man z. B. einfach „pio run -t menuconfig“ ausführen.
Was aktuell aus meiner Sicht noch fehlt:
Grundsätzliche Zustimmung von Torsten
Migration der Board-Configs zu Kconfig
Reviews und Tests
Dokumentation
@biologist Noch eine anderes Thema: Gibt es eigentlich einen Grund warum du die PRs auf GitHub nicht via Merge in den Master-Branch holst, sondern über manuelles Cherry-Picking? Im Endeffekt ist es ja egal, aber der PR wird dann als „nicht gemerged“ geschlossen, was ein bisschen unschön (für die Statistik) und auch etwas unkonventionell wirkt.
Wenn du eine lineare Historie ohne Merge Commits im Master-Branch sicherstellen möchtest, sollte das auch über die entsprechenden Repository-Einstellungen möglich sein ohne das manuell Commits aus Feature-Branches cherry-picked werden müssen.
Ja, korrekt. Ich weiß nur nicht wie Torsten genau arbeitet und wie das bei GitHub ist, da ich hauptsächlich mit GitLab arbeite. Lokales auschecken, rebasen und fast-forward-mergen des Feature-Branches ist natürlich immer möglich. Wenn man die Repository-Einstellungen richtig setzt, sollte dieser Workflow auch komplett über die GitHub UI erledigt werden können.
Vielleicht zeigst hier mal ein paar Screenshots für die User, wie man das in Platformio so aufruft und wie das dann aussieht. Und beschreibst noch ein bisschen, welche Vorteile das brächte.
Aus meiner Sicht wäre die beste Weiterentwicklung ja, dass man alles über die GUI konfiguriert und nur noch ein uniformes Build anbietet. Das würde denjenigen helfen, die sich eigentlich nicht wirklich eine IDE installieren möchten.
Im Prinzip Gewohnheit. Ich kriege mitunter PRs, die mir Einstellungen/Files bunt hin und herwürfeln. Da habe ich mir ein Stück weit angewöhnt, dass ich das halt cherry-picke, so dass ich mir sprichwörtlich die Kirschen rauspicke .
Ich müsste mich mit den ganzen Feinheiten von git eigentlich mal mehr befassen, habe jedoch wegen ESPuino leider keine Zeit dazu .
Kann ich gerne machen. Melde mich in Kürze nochmal dazu.
Ich denke das ist eher unrealistisch, weil es bedeuten würde, dass alle Features in einem einzelnen Firmware-Binary vorhanden sein müssten. Das würde wahrscheinlich schon allein aus Gründen der Größe des verfügbaren Flashs schief gehen.
Es wäre vielleicht möglich einige der Build-Optionen in die GUI zu verschieben, damit mehr Leute ohne selbst zu kompilieren auskommen.
Und/oder man könnte sich sowas wie einen Web-Builder/Flasher überlegen. Also eine Web-App, die man über den Browser konfiguriert und dann die passende Firmware in einem Container in der Cloud baut und anschließend via WebSerial API direkt flasht.
Verstehe. Prinzipiell würde ich persönlich die Änderungen von dir als Maintainer dann direkt auf dem Feature-Branch machen. Das heißt dort die überflüssigen Commits, die nicht gemerged werden sollen wegwerfen und ggf. eigene Änderungen hinzufügen. Wenn der Feature-Branch i. O. ist kann dann gemerged werden. Gerade wenn es mal mehr als einen Maintainer geben sollte ist ein Workflow mit direktem Pushen auf master nicht mehr sinnvoll möglich.
Also dass es an irgendwas scheitern kann, das kann schon sein. Aber dass es ausgerechnet am Flash liegt, das glaube ich kaum. Ein normales Binary bewegt sich so bei 2,2 MB etwa. Selbst bei den WROOM haben wir 4 MB. Davon kann man nicht alles nutzen, aber ich glaube so 3,7 MB würden übrig bleiben. Und davon ab verwenden die meisten Leute eh den WROVER mit 16 MB.
Ja, das wäre auch eine Option. Letztlich ist zum Verschieben in die GUI schon viel viel Arbeit notwendig. Es gab ja vor ner Weile einen Vorstoß, die GUI mal „neu zu machen“, aber da passiert scheinbar nix mehr.
Das wäre natürlich nice.
Grundsätzlich sehe ich nur ohne IDE das Problem kommen, dass sich der OTA-Bug des ESP32 sehr unvorteilhaft auswirken könnte.
Ok, gut zu wissen. Dann ist das nicht so kritisch wie ich gedacht hatte. Trotzdem kann ich mir aktuell schwer vorstellen, dass ein Binary für alle Konstellationen realisierbar ist. Aber ich gebe dir recht, dass das mit Sicherheit die schönste Lösung wäre. Vielleicht braucht es da mal eine „Machbarkeitsstudie“ dazu ;).
Hm, ich hab mich damit noch nicht beschäftigt, aber das muss ja hoffentlich irgendwie in den Griff bekommen zu sein. Das scheint ja dann alle ESP32-Projekte zu betreffen, die Arduino und OTA benutzen.
Ich will mich da nicht aufdrängen. Ich wollte das nur mal hinterfragen, bzw. aufzeigen, wie ich es von anderen Open-Source-Projekten kenne und wie ich es selbst machen würde. Es gibt da wie so oft kein generelles falsch oder richtig.
Kconfig hat teilweise ein paar unschöne Einschränkungen für die man in bestimmten Sonderfällen ggf. kleine Workarounds braucht (z. B. hier).
Und hier mal ein paar Screenshots für das Konfigurationsmenü wie es bei mir in meinem Entwicklungsstand aussieht wenn man pio -t run menuconfig aufruft:
.
.
