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
2
• cbor
3
• jsmn
4
• esp_modem
5
• nghttp
6
• mdns
7
• esp_websocket_client
8
• asio
9
• freemodbus
10
• sh2lib
11
• expat
12
• coap
13
• esp–cryptoauthlib
14
• qrcode
15
• tjpgd
16
• esp_serial_slave_link
17
• 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)
2
◦ PMF support for softAP
3
◦ WPS registrar support in softAP
4
◦ WPA3 OWE support for station
5
◦ 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.
Zuerst erschienen bei Mikrocontroller.net News
Quelle: Read More