Espressif: ESP-IDF 5.0 erschienen

[Tam H. (Firma: Tamoggemon Holding k.s.) (tamhanna)]

Die auf der Espressif-Entwicklerkonferenz angekündigte fünfte Version der hauseigenen Programmierumgebung IDF ist soeben erschienen. Espressif verspricht Unterstützung für neue Chiptypen und – im Allgemeinen – Abwärtskompatibilität mit vorhandenem Code.

So wenig Änderungen wie möglich, so viele wie nötig

Espressif verspricht in der Ankündigung, in der neuen Version so wenig Änderungen wie möglich durchzuführen und die Abwärtskompatibilität so weit wie irgendwie möglich zu wahren:

ESP-IDF v5.0 is a major update for ESP-IDF v4.x. Release v5.0 is mostly compatible with apps written for ESP-IDF v4.x, but there are some breaking changes . . . and removal of deprecated functionality which will require code changes when updating projects. Release v5.0 is the latest stable release at the time of writing.

Die wahrscheinlich wichtigste Neuerung ist Unterstützung für ESP32-C2 und ESP-H2 – zweiterer ist derzeit allerdings nur im Betazustand implementiert. Lohn der Mühen ist ausserdem, dass mit IDF 5.0 – siehe auch Abbildung – ein komplett neuer Supportzeitraum zu laufen beginnt.

(Bildquelle: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/versions.html)

Mehr Modularisierung

Wie schon auf der Entwicklerkonferenz angekündigt, versucht Espressif Entwickler durch Auslagerung häufig verwendeter Bibliotheken zur Verwendung des Komponentensystems zu animieren. Wirklich abgekündigt wird dabei nur die seit IDF 4.0 als deprecated markierte tcpip_adapter, die anderen folgenden Bibliotheken sind fortan als Komponenten zu beziehen:

libsodium
    • cbor
    • jsmn
    • esp_modem
    • nghttp
    • mdns
    • esp_websocket_client
    • asio
    • freemodbus
    • sh2lib
    • expat
    • coap
    • esp-cryptoauthlib
    • qrcode
    • tjpgd
    • esp_serial_slave_link
    • tinyusb

Angemerkt sei, dass in den einzelnen Treibern einige als deprecated markierte Methoden verschwinden – dabei handelt es sich meist aber, siehe weiter unten, um Streamliningmassnahmen. Im Hintergrund führte Espressif ausserdem einige Bug Fixes durch, und stellte eine neue Version des FreeRTOS-Kernels zur Verfügung, die auf der Variante “Included FreeRTOS SMP Kernel (upstream AWS version)” basierte. Nutzer der WLAN-APIs dürfen sich außerdem auf die folgenden neuen Funktionen freuen:

802.11r (Fast BSS Transition)
        ◦ PMF support for softAP
        ◦ WPS registrar support in softAP
        ◦ WPA3 OWE support for station
        ◦ WPA3 SAE H2E support for station

Upgrades der Toolchain

Die bisher verwendete Version von GCC – 8.4.0 – wurde nun durch  GCC 11.2.0 ersetzt. Ob diverser Verbesserungen am Compiler ist im Rahmen dieser Umstellung mitunter mit zusätzlichen Warnungen zu rechnen. Außerdem wird das alte, auf make basierende Buildsystem nicht mehr unterstützt. Weitere Informationen zur Umstellung vorhandener Projekte finden sich unter https://docs.espressif.com/projects/esp-idf/en/v5.0/esp32/migration-guides/release-5.x/build-system.html. Wichtig ist ausserdem, dass die Namen von Kommandozeilenparametern “synchronisiert” werden – aus efuse_common_table wird beispielsweise efuse-common-table.

Privatisierung systemnaher APIs

Espressif verspricht Entwicklern seit Jahr und Tag Konsistenz. Insbesondere im Fall systemnaher APIs ist dies für die Weiterentwicklung der Plattform als Ganzes oft nur wenig hilfreich – die Brownout- und TRAX-APIs sind ab Sofort als Privat deklariert, wohl um Espressif die Anpassung an neue SoCs zu erleichtern (siehe auch https://docs.espressif.com/projects/esp-idf/en/v5.0/esp32/migration-guides/release-5.x/system.html).

Korrektur von Rechtschreibfehlern und Verschlankung von Namen sowie Designpatterns

Insbesondere im Bereich der Funkstacks – Stichwort ESP_HF_CME_MEMEORY_FULL – haben sich im Laufe der Jahre einige Rechtschreibfehler angesammelt, deren Korrektur bisher aber ob der Abwärtskompatibilität nicht möglich war. Eine weitere Anpassung betrifft die Bluetooth-API, in der Methoden wie esp_bt_hf_bsir nach dem Schema esp_hf_ag_bsir umbenannt werden. Im Bereich der Peripheriegeräte (siehe https://docs.espressif.com/projects/esp-idf/en/v5.0/esp32/migration-guides/release-5.x/peripherals.html) gibt es ebenfalls einige Anpassungen. Am Wichtigsten erscheint nach einer schnellen Analyse das geänderte Anliefern von Daten über den Auslöser eines GPIO-Interrupts:

GPIO interrupt users callbacks should no longer read the GPIO interrupt status register to get the triggered GPIO’s pin number. Users should use the callback argument to determine the GPIO’s pin number instead.

Weitere Informationen und Ausblick

Der Newsaffe ist derzeit dienstlich in Bristol und kommt nicht an seinen Kundencode. Unter https://github.com/espressif/esp-idf/releases/tag/v5.0 findet sich eine detaillierte Liste der Änderungen, ein Migrationsguide findet sich unter https://docs.espressif.com/projects/esp-idf/en/v5.0/esp32/migration-guides/release-5.x/index.html. Nach einem ersten Studium der Änderungen ist – zumindest für Androidgeplagte – offensichtlich, dass sich Espressif der Verantwortung für das geistige Eigentum seiner Entwicklerschaft bewusst ist und bei Änderungen behutsam umgeht.

[Vincent H. (vinci)]

Der komplette Schritt hin zu CMake war, so wie Espressif das nutzt, 
leider vollkommen fürn Hugo. Das Buildsystem könnte ebenso Brainfuck 
sein und es würd keinen Unterschied machen...
Und jetzt, mit dem Komponentensystems wiederholt sich der ganze Spaß 
nochmal. Wozu tut man sich die Mühe an auf ein (halbwegs) 
standardisiertes System zu setzen wenn man dann sowieso alles neu 
erfindet? Espressif leidet definitiv an dem "not invented here" Syndrom. 
:/

[Stefan F. (Gast)]

Es ist schön, dass es den ESP32 und das IDF gibt. Die kontinuierliche 
Weiterentwicklung und die Verbesserungen an der Doku sind wirklich 
lobenswert. Wenn man das mal mit den Anfängen des ESP8266 vergleicht, 
hat sich die Firma massiv verbessert. Es war auch dringend nötig.

Für meine gelegentlichen Hobby-Basteleien ist mir da allerdings zu viel 
Bewegung drin.

Deswegen bin ich beim ESP8266 (unter Arduino) stecken geblieben. Der 
ESP32 wäre eventuell wegen Bluetooth attraktiv, wenn ich nicht generell 
mit Bluetooth auf Kriegsfuß stehen würde. Bei mir im Haushalt zicken 
alle Bluetooth Geräte (auch die der Kinder) nervig herum. Ich habe keine 
Lust mehr darauf. Ansonsten hatte ich noch keinen Anwendungsfall, wo ein 
ESP32 großartig besser geeignet gewesen wäre, als ein ESP8266 (kommt 
vielleicht noch). Ich hoffe, der alte Chip wird noch lange als Modul 
verfügbar sein.

[A. B. (funky)]

Espressif scheint leider nichts dergleichen wie eine Qualitätssicherung 
zu haben. Immer die gleichen Bugs in anderen Variationen. Die IDE 
Plugins sind mehr Democode der auf die Benutzer losgelassen wird. 
Andauernd andere Obskuritäten. Also wer mit IDF entwickeln will braucht 
gute Nerven und viel Zeit.

Das cmake benutzt wird find ich ja gut, aber wie schon angemerkt. Dieser 
ganze Aufsatz den dei da geschaffen haben...nunja