Inhaltsverzeichnis
Das Menuconfig ist das zentrale Konfigurationswerkzeug der ESP-IDF. Über diese textbasierte Oberfläche lassen sich nahezu alle Projekteinstellungen anpassen – von Compiler-Optionen, FreeRTOS-Parametern und Treiberfunktionen bis hin zu WLAN-Konfiguration, Flash-Layout und Logging.
Tiefer greifende Information sind im ESP-IDF Programming Guide – Project Configuration zu finden und unter Documentation of esp-idf-kconfig.
Die meisten wichtigen Systemeinstellungen werden nicht im Code selbst vorgenommen, sondern hier im Konfigurationsmenü. menuconfig speichert alle Optionen automatisch in der Datei sdkconfig, sodass jedes Projekt reproduzierbar und eindeutig konfiguriert bleibt.
Diese Seite bietet einen kompakten Überblick: Wie menuconfig gestartet wird, welche Bereiche für typische ESP32-Projekte relevant sind und welche Einstellungen man am Anfang wirklich braucht.
Menuconfig starten
Menuconfig wird direkt im Projektverzeichnis über die ESP-IDF-Konsole gestartet. Wir können dafür auch das ESP-IDF Terminal in VS Code verwenden. Dazu erstellen oder öffnen wir ein vorhandenes Projekt in VS Code und öffnen das ESP-IDF Terminal, in dem wir das „Open ESP-IDF Terminal“-Symbol 
in der Aktivitäts Leiste unten betätigen. Dann geben wir idf.py menuconfig ein und bestätigen mit Enter.
Das Menuconfig Startfenster öffnet sich in der Konsole.
Vieles ist schon vorkonfiguriert und das meiste kann man auch so lassen. Einiges werden wir im Verlauf aber ändern, wie z.B. das Partition Table. Default ist es auf Single factory app, not OTA eingestellt, was bedeutet, dass es nur eine Firmware Partition gibt und die App genau einmal im Flash liegt. Kein OTA bedeutet, dass es keine Over-The-Air-Update Möglichkeit gibt, Firmware also nur über USB oder JTAG aktualisiert werden kann.
Eine weitere Einstellung die wir schon einmal anpassen können ist die Flash Größe. Diese ist default auf 2 MB eingestellt, aber die meisten ESP32 Boards haben einen 4 MB Flash. Einfach unter Serial flasher config -> Flash size (2 MB) auf 4 MB einstellen.
Änderungen die hier getätigt wurden, müssen mit ’s‘ gespeichert werden. Nach Änderungen im Menuconfig, wird das Projekt beim Bauen wieder vollständig gebaut. D.h., dass der Vorgang wieder etwas länger dauert, wie beim ersten Build-Vorgang.
Alle Einstellungen im Menuconfig, findet man in der sdkconfig.h unter build\config.
Eigenes Menuconfig erstellen
Zur Erstellung eines eigenen Menüs muss unter main eine Datei Kconfig.projbuild manuell erstellt, und exakt so benannt werden (Abb 6).
Als kleines Beispiel können wir das Beispiel aus Kconfig and Kconfig.projbuild Files verwenden und in die Datei Kconfig.projbuild kopieren (Abb. 7).
Um die Änderungen sichtbar zu machen, muss das Projekt neu gebaut werden. Nach jeder Änderung an der Kconfig.projuild, wird das gesamte Projekt gebaut!
Wenn wir jetzt das Menuconfig starten, sehen wir eine Auswahlmöglichkeit, die dem Menuconfig hinzugefügt wurde (Abb. 8), das „Enable sublight drive“. „Enable sublight drive“ kann an dieser Stelle schon aktiviert und deaktiviert werden. Sonst ist jetzt noch keine weitere weitere Funktionalität vorhanden, dazu später mehr.
Einige wichtige Menuconfig Optionen und Erklärungen
CONFIG_FREERTOS_HZ (Tick Rate)
Legt fest, wie oft der FreeRTOS-Tick pro Sekunde läuft (z.B. 100 Hz = 10 ms Tick, 1000 Hz = 1 ms Tick). Das beeinflusst Zeitfunktionen wie vTaskDelay() (Auflösung) und kann Overhead erhöhen, wenn der Tick sehr hoch ist.
Praxis: Für viele Anwendungen sind 100–250 Hz völlig ok; höhere Werte nur, wenn wirklich feinere Tick-basierte Delays benötigt werden.
CONFIG_FREERTOS_UNICORE
Schaltet den Betrieb auf Single-Core um (nur ein CPU-Core wird für FreeRTOS genutzt). Das ist hilfreich für Debugging oder wenn man gezielt deterministischer werden will (weniger SMP-Komplexität). Achtung: Performance sinkt, und “Core-Pinning” verliert Bedeutung.
CONFIG_ESP_MAIN_TASK_STACK_SIZE
Stackgröße der Task, in der app_main() läuft. Wenn hier zu wenig Stack vorhanden ist, bekommt man seltsame Abstürze/Resets, besonders wenn man in app_main() viel macht (z.B. JSON, große lokale Arrays, Logging, Init-Ketten).
Praxis: Wenn komische Crashes beim Start vorkommen → diese Option checken.
CONFIG_LOG_DEFAULT_LEVEL
Globales Log-Level (Error/Warn/Info/Debug/Verbose). Höheres Log-Level ist super fürs Lernen/Debuggen, kostet aber Laufzeit und kann Timing beeinflussen (und erzeugt sehr viel Output). Praxis: Entwicklung = Debug, später runter auf Info oder Warn.
Partition Table (z.B. “Single factory app, not OTA” vs “Factory app, two OTA definitions”)
Bestimmt, wie der Flash aufgeteilt wird: App-Partition(en), OTA-Slots, NVS, SPIFFS/LittleFS usw. Praxis: Wenn man später OTA will, muss man hier frühzeitig das Layout wählen, sonst passt der Flash-Plan nicht.
sdkconfig
Das ist die “Quell-Datei” derKonfiguration: hier stehen alle CONFIG_… Werte (Textdatei im Projekt). Diese Datei gehört in Git, weil sie das Projekt reproduzierbar macht.
sdkconfig.h
Wird beim Build aus sdkconfig generiert und liegt im Build-Ordner (z.B. build/config/sdkconfig.h). Daraus kommen die #define CONFIG_... Makros, die im Code verwendet werden. Wichtig: sdkconfig.h nicht manuell ändern, weil sie beim nächsten Build überschrieben wird.
Rebuild – Warum passiert das?
Wenn menuconfig geändert wird, ändert sich sdkconfig. Viele Komponenten werden dann mit anderen #defines kompiliert (Feature an/aus, Stackgrößen, Logging, Treiberflags). Deshalb muss CMake/Build-System oft “mehr neu bauen” als bei normalem Code-Change.
Nach Änderungen in menuconfig müssen betroffene Komponenten neu kompiliert werden, weil sich Compile-Time-Konstanten (CONFIG_*) geändert haben. Dadurch wirkt ein Build nach menuconfig oft wie ein “größerer” Rebuild.
Binary
Einige menuconfig Optionen ändern nicht nur das Verhalten, sondern auch die Firmware-Größe und Speicheraufteilung (z.B. Logging, aktivierte Komponenten, Partition Table). Dadurch kann sich das erzeugte Firmware-Image messbar verändern.