Konfiguration via Kconfig

Hallo zusammen,

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.

Wen das interessiert kann sich ja mal diesen Entwurf anschauen: Migrate compile-time configuration to Kconfig by fschrempf · Pull Request #187 · biologist79/ESPuino · GitHub. In der Beschreibung des PRs stehen noch ein paar Details und Argumente zu den Änderungen.

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.

Danke und viele Grüße
Frieder

1 „Gefällt mir“

sollte das nicht mit Rebase + Fast Forward funzen? (also die lineare Main)

Aber cool das mit der KConfig :wave: :+1:

+1 für kconfig !

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 :slight_smile:.
Ich müsste mich mit den ganzen Feinheiten von git eigentlich mal mehr befassen, habe jedoch wegen ESPuino leider keine Zeit dazu :woman_shrugging:.

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.

Ich werde mal schauen, was sich machen lässt.

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.

Ja, es mangelt an Zeit im Moment. Zweites Kind ist da, Jobwechsel, Druck vom Doktorvater… Ich habe es aber nicht abgeschrieben, nur momentan pausiert.

Also hier mal die Punkte, die aus meiner Sicht für Kconfig sprechen:

  • Komfortablere und weniger fehleranfällige Konfiguration der Build-Optionen.
  • Verifizierung von Benutzereingaben, Ein-/Ausblenden von Optionen.
  • Config ist im Code einfacher lesbar und erweiterbar.
  • Saubere Trennung zwischen den Optionen, die der User verändern soll und „internen“ Makros im Code.
  • Gutes Mittel zur Vermeidung von doppelten Macros in verschiedenen Headern.
  • Config Header und PlatformIO Override werden automatisch erzeugt.
  • Kconfig scheint relativ alternativlos zu sein, wenn man nach einem Standard für Build-Configs sucht.

Nachteile:

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:

Und hier als Alternative das GUI Tool (pio -t run guiconfig):

4 „Gefällt mir“