Komponenten und Buildsystem – Espressif DevCon 2024, Tag 2

Die Keynote des zweiten Tages bestritt traditionell Ivan Grokhotkov, der die Teilnehmerschaft – wie immer – mit einem Vortrag zum Buildsystem beehrte. Auch sonst stand Tag zwei im Zeichen der Toolchain: hier eine Liste der Neuerungen.

Keynote – Ivan Grokhotkov

Der VP of Software im Hause Espressif begann seinen Vortrag über das Buildsystem mit einer Auflistung häufiger Anfragen, mit denen er im Rahmen seiner Tätigkeit konfrontiert ist - offensichtlich ist, dass das Buildsystem von der P. T. Kundschaft in vielen Fällen nur teilweise verstanden wird. Zur Lösung dieses Problems präsentierte er unter anderem die Abbildungen, die einen Überblick des auf CMake basierenden Buildsystems gaben.

Bildquelle, alle wo nicht anders angegeben: Espressif, Screenshots durch Autor.

Interessant ist die Feststellung, dass man langfristig eine Angleichung zwischen dem hauseigenen Buildsystem und CMake plant.

Essenz des Vortrags war, dass die von Entwicklern gerne als „allgemeine Ablage“ verwendete Main-Komponente im Laufe der Arbeit mit einem Projekt „voll mit Code“ wird. Zur Lösung bietet es sich an, eine weitere Modularisierung der Codebasis durchzuführen.

Wer den Code stupide in ein anderes Verzeichnis kopiert, bekommt Konflikte mit der Abhängigkeitsverwaltung. Ursache dafür ist, dass die neue Komponente ja ihren eigenen Beziehungs- bzw. Abhängigkeits-Baum in das Projekt bringt.

Zu beachten ist außerdem, dass die Main-Komponente im Interesse der „einfacheren Handhabung“ - zumindest derzeit - mit allen anderen Komponenten interagieren darf, und keine Beziehungen deklarieren muss. Dieses Verhalten möchte man langfristig allerdings anpassen.

Die unter der URL https://igrr.github.io/edc24/1 bereitstehende Präsentation verdient auch sonst Aufmerksamkeit, weil sie in einem Cookbook-Abschnitt Tipps und Tricks zur effizienteren Nutzung des Buildsystems anbietet. In der „darauf folgenden an QA-Sessions wurde mehrfach nach Methoden gefragt, um den Kompilationsprozess zu beschleunigen.

Als „Maßnahme“ schlug der VP of Software hier -unter anderem - die Installation von CCache vor – das Buildsystem erriecht und nutzt diese Funktion automatisch, so es sie auf dem Compile-Host vorfindet.

LVGL am ESP32-P4 - Espressifs Vision für HMI.

Die gestern im Rahmen der CEO-Keynote erfolgte „Namedropping“ von LVGL wurde am zweiten Tag in Form eines vollständigen Vortrags fortgesetzt. Die Präsentation begann mit einer „Leistungsschau“ der Möglichkeiten, die neben der hohen Download-Frequenz des GUI-Stacks in GitHub auch darauf hinwies, wie viele Ökosystem-Partner bei der Realisierung von auf LVGL basierenden Systemen hilfreich sein wollen. Besonders betonte Kiss-Vamosi die gesteigerte maximale Auflösung - wer einen ESP32-P4 verwendet, „größere“ Bildschirme ansteuern. In der Praxis gilt natürlich, dass die maximale oder reale Performance immer davon abhängt, wie komplex das zur Anzeige gebrachte Layout ausfällt.

Im Rahmen des Vortrages wurde außerdem ein UI-Editor vorgeschlagen, der sich - Kiss-Vamosi betonte dies mehrfach - explizit an die Bedürfnisse von Entwicklern richtet. Sinn des Werkzeug ist, das Nachbauen von vom Designer erhaltenen GUI-Sketches zu erleichtern - wie in der Abbildung gezeigt, ist auch eine Import-Funktion für das weit verbreitete Tool Figma implementiert. Das „System“ arbeitet dabei - plangemäß - mit XML, soll aber auch C-Code exportieren können.

GMF - neues Multimedia-Framework für den ESP32.

Spätestens seit den Erfolgen mit ESP_ADF ist bewiesen, dass pipelineorientierte Multimedia-Architekturen im Embeddedbereich gut funktionieren. Mit GMF schickt Espressif eine generalisierte Variante des Produkts ins Rennen, die neben Audio-Daten auch beliebige Multimediainhalte verarbeitet.

Interessant ist, dass der Vortragende im Rahmen der Ankündigung - wie gezeigt - Vergleiche gegen ADF durchführte, die nicht unbedingt für ADF vorteilhaft ausgingen.

Exkurs: Vortrag über AI-Systeme im Embeddedbereich.

Dass Anbieter von IT-Systemen auf der Suche nach „Other Peoples Money“ das Auge Saurons auf den Embeddedbereich richten, dürfte Leser von mikrocontroller.net nicht wirklich überraschen. Mit Priyanka Mathikshara stand eine Vortragende am Start, die Informationen über den Aufbau von für den Elektronik-Bereich optimierten LLMs und ihr Training hielt. Wer an diesem Vortrag Interesse hat, sollte sich das Recording in der unten genannten URL ansehen.

Arduino plus ESP32 - oder - alles im Zeichen der Komponente.

Über die Frage, ob man sich dem Problem der ESP32-Entwicklung besser unter Nutzung des Arduino Cores oder unter Nutzung von ESP_IDF nähern sollte, lässt sich lange diskutieren. Auf der Espressif Devcon war am zweiten Tag Rodrigo Garcia zugegen, um Informationen darüber zu geben, „wie“ sich der Arduino Core in die IDF-Kompilationsumgebung integriert. Neben „allgemeinen“ Ausführungen präsentierte Garcia detaillierte Ausführungen dazu, wie die Aufteilung des Arduino-Cores sowie den Bibliotheken in die für das Espressif-Buildsystem bekömmliche Teile bewerkstelligt wurde. Ebenda fanden sich auch Ausführungen dazu, wie man die oft nur eingeschränkt verfügbaren UART-Ressourcen zwischen dem Arduino-Core, IDF und der eigentlichen Nutzerapplikation aufteilen kann. Im Rahmen der QA-Session fragte ein Teilnehmer, „unter welchen Umständen“ die Nutzung der Arduino-IDE nachteilig gegenüber der Verwendung der Arduino-Produkte als ESP_IDF-Komponente ausfiel.

Die Antwort des Vortragenden darauf war durchaus interessant: Wer die Arduino-Cores über die Arduino IDE benutzt, hat nur wenig Möglichkeiten, um den darunterliegenden Buildprozess und Elemente wie SDK-Konfiguration und Co zu modifizieren. Arbeitet der P. T. Entwickler mit dem Arduino Core als IDF-Komponente, so ist er quasi alleiniger Herr seines Schicksals.

RMT-Peripheriegerät im Fokus.

Der am gestrigen Tage vorgestellte PIO ist nicht das einzige smarte Peripheriegerät, das man der Entwicklerschaft im Hause Espressif zur Verfügung stellt. Mit dem RMT steht ein ähnliches Produkt zur Verfügung, das - ebenfalls - in einem detaillierten Vortrag vorgestellt wurde.

Neben dem mittlerweile als quasi-Standard geltenden ansteuern von WS2812B-Smart-LEDs unter Nutzung des RMT stellte man exotischere Anwendungsfälle, beispielsweise das „RTOS-sichere“ Auslesen von OneWire-Temperatursensoren vor.

Visual Studio Code-Plug-in - nicht „Out of Business“

Im Bereich der IDEs leistet sich Espressif zweigleisiges Vorgehen - neben der gestern vorgestellten und auf Eclipse basierenden Espressif IDE wird auch das Visual Studio Code-Plugin permanent erweitert. Wer seine Arbeiten lieber unter Nutzung von Microsofts quelloffener IDE durchführt, darf sich spezifisch auf die in der Abbildung gezeigten Erweiterungen freuen.

Besonders hervorgehoben wurden im Rahmen des Vortrags zweierlei Features: Erstens eine integrierte Unittest-Engine, die Qualitätssicherung der ESP 32-Projekte erlaubt. Zweitens steht mit dem „Hint Viewer“ ein System zur Verfügung, das Informationen über Fehler und Probleme im Code liefert.

Abseits von LVGL: Slint am Start.

Obwohl der CEO in der Einleitung des gestrigen Tages nur auf LVGL einging, bedeutet dies nicht, dass man im Hause Espressif nicht beim GUI-Stack zweigleisig fahren möchte. Spezifischerweise war einer der Gründer des Unternehmens Slint vor Ort. Besonderes Verkaufsargument „für“ die Technologie war im Rahmen des Vortrags übrigens die Möglichkeit, „deklarative Programmierung“ einsetzen zu können. Vendor-Vortrag Nummero zwei wurde von WolfSSL bestritten. Jim Scraletta präsentierte - wie erwartet - einen Vortrag über die Vorteile und Möglichkeiten der hauseigenen Krypto-Bibliotheken und ging auf Methoden zur Integration in ESP_IDF ein. Auch hier gilt, dass Nutzer der jeweiligen Bibliothek gut beraten sind, den Vortrag anzusehen.

WebRTC am ESP 32.

Der letzte Vortrag des zweiten Tages beschäftigte sich dann mit der Nutzung von WebRTC - ein Verfahren, dass das Streamen von Multimediainhalten sowohl aus als auch in Richtung von Browsern zum Thema hat. Wer hier an das „Vereinfachen“ der Realisierung von Companion-Applikationen bzw. Companion-Services für IoT-Geräte dient, dürfte die Intention dieser Erweiterung von ESP _ IDF richtig erfasst haben.