Der zweite Tag der Espressif DevCon 2022 begann mit der Vorstellung von ESP_IDF 5.0. Welche Neuigkeiten für Nutzer besonders wichtig sind, und was es sonst an nennenswerten Ereignissen zu sehen gab, berichten wir in diesem Round-Up.
Befreiungsschlag 5.0.
Angelsächsische Literatur im Bereich der Software-Architektur beschreibt Software-Systeme als „Würfel aus ballistischem Gel“, der bei jeder Änderung gewirbelt wird und irgendwann zusammenbricht.
Der Release von 5.0 bietet dem Espressif die Möglichkeit an, gravierende Änderungen durchzuführen – besonders wichtig erachtete man wie gezeigt die Umstellung des Datentyp von time_t.
(Bildquelle: alle Espressif.)
Die mit Abstand „wichtigste“ Neuerung auf architekturaler Sicht ist dabei die Einführung eines an Microsoft NuGet erinnernden Paket-Verwaltungssystems: viele Komponenten wie die in der Abbildung gezeigten sind fortan nicht mehr direkt Teil von ESP_IDF, sondern „extern“ und über einen dedizierten Befehl nachladbar.
Obwohl dies für den Elektroniker Mehrarbeit darstellt, ist es für das Ökosystem – zumindest nach Ansicht des Autors – unterm Strich ein Gewinn: durch die „Reduzierung Anführungszeichen des Umfangs von IDF kann das Produkt leichter gewartet werden.
Eine weitere „Optimierung“ betrifft die Organisation von Headerdateien. Hier sei explizit auch das Korrigieren von Tippfehlern erwähnt – das Verschwinden des Tippfehlers würde ja zu einer „Änderung“ im vom Endanwender-Entwickler erzeugten Code führen, und ist nach den Regeln des Semantic Versioning nicht zulässig.
Eine weitere „Optimierung“ kümmert sich um die Integer-Größen, die ja auf RISC-V-Kernen und auf XTENSA-Kernen wie in der Abbildung gezeigt unterschiedlich ausfallen.
Eine weitere Umstellung freut die Pythonisten – das bisher verwendete und auf CMake basierende Buildsystem steht in 5.0 nicht mehr zur Verfügung. Außerdem gibt es auch hier eine Bereinigung der Komponenten-Beziehungen, um implizite dependencies nach Maßgabe der Möglichkeiten auszuschalten.
Außerdem rüttelt Espressif am API-Design. Innerhalb von IDF 5.0 gilt allerdings, dass sich Entwickler diese Änderung verweigern können – wichtig ist in diesem Fall nur, dass MSR-Software pro Peripheriegerät nur entweder den alten oder aber den neuen Treiber verwenden darf.
Zu guter letzt gibt es einige weitere Bereinigungen zur Erhöhnung der Konsistenz.
Erweiterungen und Anpassungen der Toolchain.
Die in IDF 5.0 durchgeführten Änderungen sind nicht als Ärgernis oder Bevormundung der Entwicklerschaft vorgesehen, sondern ermöglichen Espressif das Anbieten neuer Komfortfunktionen.
Am lustigsten ist mit Sicherheit die Möglichkeit, nun auch Pfade zu benutzen, die Leerzeichen aufweisen-insbesondere ein Entgegenkommen an Windows-Nutzer. Das Installations-Werkzeug kann ab sofort unbenötigte Komponenten auslassen-lustig ist, dass der Sprecher hier explizit PYTest als Paradebeispiel erwähnte.
Interessant war außerdem auch noch, dass man – siehe beispielsweise die Abbildung – darauf hinwies, dass bald neue Chips aus dem Hause Espressif zu erwarten sind.
NuGet a la Espressif!
Eine der nach Ansicht des Autors wichtigsten, von der Entwicklerschaft aber viel zu wenig geschätzten, Erweiterungen des.net-Frameworks war die Einführung der Komponentenverwaltung NuGet. Mit dem Paketmanager bietet Esüressif Entwickler nun ein ähnliches Werkzeug an, dessen Nutzung-kurz-wie in der Abbildung gezeigt erfolgt. Component Manager stand übrigens schon in den Versionen 4.3 und 4.4 zur Verfügung, ist in 5.0 aber erstmals integrale Komponente.
Espressif intendiert, dass Entwickler das System auch zur Erzeugung eigener Komponenten heranziehen – ein gut 30-minütiger Vortrag erklärte, wie Make-, Konfigurations- und sonstige Dateien aufzubauen sind.
Ein „primäres“ Ärgernis, das Espressif antizipiert, sind – siehe Abbildung – Namenskollisionen, die durch die Ordnerstrukturen entstehen.
Die Einführung der Komponenten-Verwaltung ist aus Sicht von Espressif auch sonst kein Selbstzweck. Das beste Beispiel hierfür ist das Board Support Package-System, über das Anbieter vorgefertigte Evaluationsboard ihr P. T. Nutzern fortan „direkt“ und schlüsselfertig Defines und andere Elemente anbieten können.
Erweiterungen in Richtung des Webs.
Die auf RainMaker basierende Cloud-Komponente im Hause Espressif wurde am vorigen Tag schon ausreichend gewürdigt. Diesmal spendierte man einen Vortrag, in dem es um die Erweiterung eines kommerziellen Deployments mit hauseigener Logik geht. Dazu stellt Espressif drei Interfaces zur Verfügung, die in der Abbildung aufgelistet sind.
Interessant war dabei ein Diagramm, das die „Verteilung“ der Event-Verarbeitung über die diversen AWS-Primitiva illustriert.
Von Espressif war ein Vortrag zur ULP im Angebot, der detaillierte Informationen über Stromverbrauch und Co anbietet. Zur Erinnerung: die ULP ist ein „zusätzlicher Coprozessor“ des ESP32-SoC, der zwar einen stark reduzierten Funktionsumfang aufweist, dafür aber auch einen sehr geringen Energieverbrauch mitbringt.
Interessant ist, dass Espressif den Funktionsumfang der ULP zu erweitern gedenkt – unter anderem ist das Hinzufügen von RTC-I2C-Optionen geplant. Hierbei handelte es sich-die Vortragenden betonten dies mehrfach explizit – allerdings um Informationen auf Basis einer Vorschauvariante des Produkts, weshalb die in der Abbildung gezeigten Funktionen nicht zum Festlegen von strategischen Entscheidungen herangezogen werden sollten.
Im Bereich Cloud gab es dann außerdem noch eine Drittanbieter-Vortrag von Toit – das Unternehmen ist darauf spezialisiert, Microservice-VMs für Embedded-Systeme anzubieten, die wir unter https://www.mikrocontroller.net/topic/525438 bereits erwähnt haben.
Toolchain im Fokus!
Der nächste Block des zweiten Tages kümmerte sich dann um alles, was im Bereich Entwickler-Toolchain im ESP32-Ökosystem kreucht und fleucht.
Als erstes sprach Espressif dabei über die Testing-Engine, die der normale ESP32-Entwickler nur allzu oft „nur“ in Form einer zusätzlichen Datei im Projektskelett wiederfindet.
Interessant ist hier, dass die Unit Testing-Systeme auch in der Lage sind, „externe“ ESP 32-Hardware in die Tests einzuspannen. Als Werkzeug der Wahl kommt dabei ein Raspberry Pi zum Einsatz, der die Rolle des Testrunners übernimmt.
Interessant ist daran auch, dass das eigentliche Bereitstellen der Toolchain durch Integration in GitHub erfolgt-ganz analog zum auf AWS basierenden RainMaker ist Espressif gewillt, eine Hand in das Ökosystem zu strecken.
Der Vortrag zu idf.py – das Pythonskript tritt ja, wie weiter oben angewählt, die „Nachfolge“ von Make an – ging unter anderem auf Tricks ein, wie man „Verbindungsfehler aller Herren Arten“ bekämpfen kann.
Ein weiterer „lustiger“ Aspekt ist die Möglichkeit, die Toolchain für die Kompilation fortan per docker-Container und eventuell sogar in der Cloud zu hosten – Espressif bewirbt dies vor allem damit, dass Entwickler so reproduzierbar die selben Build-Ergebnisse erhalten.
Es gibt nicht nur Rust!
Über die Frage, ob sich C++ für die Embedded-Entwicklung auszahlt, lassen sich ganze Konferenzen füllen. Während Espressif am ersten Tag der Devcon den Fokus vor allem auf Rust legte, gab es im zweiten Tag eine Präsentation, die die „Möglichkeiten und Grenzen“ der Nutzung von C++ am ESP 32 Illustrierte.
Sehr interessant waren beispielsweise die „Analysen“ für die durch die Nutzung von Exceptions entstehenden Mehrkosten im Ressourcenbereich.
In nicht allzu ferner Zukunft plant Espressif außerdem, wie in der Abbildung gezeigten C++-Support in eine eigene Komponente auszulagern und zusätzliche C++-Wrapperklassen zur Verfügung zu stellen.
Ein weiterer interessanter Vortrag wendete sich der Frage zu, „wie“ man FAT mit Wear Levelling ausstattet und welche „Unterstützungswerkzeuge“ Espressif in diesem Bereich anbietet.
Der eigentliche Vortrag der Arduino-Gruppe beschränkte sich dann auf eine Vorstellung der diversen „neuen“ Ökosystem-Elemente. Sehr interessant empfand der Autor, dass mehr als 70 % der in der Arduino-Bibliotheksverwaltung befindlichen Angebote den ESP32 unterstützen.
Microsoft trug ebenfalls eine Gruppe von Vorträgen bei, die sich im Allgemeinen um die Nutzung von Azure zur „Verwaltung“ eines ESP32-Geschwader drehten.
Zuerst erschienen bei Mikrocontroller.net News
Quelle:
