News Komponenten und Buildsystem – Espressif DevCon 2024, Tag 2


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


Angehängte Dateien:

Lesenswert?

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.


: Bearbeitet durch NewsPoster
von Vanye R. (vanye_rijan)


Lesenswert?

Ist schon interessant das unsere lieben Softwerker alles immer komplexer 
machen muessen bis es irgendwann keiner mehr versteht.

Auch wenn das nicht jedem hier gefallen wird, es geht hier nicht um 
Bastler!

Diese vom Hersteller bereitgestellten Systeme sind eigentlich dafuer da 
das Hardware/Software Entwickler so schnell wie moeglich einen positiven 
Eindruck eines Controller bezueglich eines geplanten Projektes bekommen 
damit sie den danach ein designen und idealerweise Millionen von den 
Teilen kaufen.

Vanye

von Nikolaus S. (Firma: Golden Delicious Computers) (hns)


Lesenswert?

Vanye R. schrieb:
> Ist schon interessant das unsere lieben Softwerker alles immer komplexer
> machen muessen bis es irgendwann keiner mehr versteht.
>
> Auch wenn das nicht jedem hier gefallen wird, es geht hier nicht um
> Bastler!
>
> Diese vom Hersteller bereitgestellten Systeme sind eigentlich dafuer da
> das Hardware/Software Entwickler so schnell wie moeglich einen positiven
> Eindruck eines Controller bezueglich eines geplanten Projektes bekommen
> damit sie den danach ein designen und idealerweise Millionen von den
> Teilen kaufen.

Wenn 1 Mio Teile eingebaut wird spielt jeder ct der Chips eine Rolle. 
Der Entwicklungsaufwand nicht. Daher ist es eher egal, ob das für den 
Entwickler einfach oder kompliziert ist und niemand muss sich in diesem 
Bereich besondere Mühe geben.

In Kleinserien-Projekten setzt man daher besser auf Embedded Linux. Das 
ist einfachst zu entwickeln (notfalls gcc & make auf dem Zielsystem). 
Die Chips kosten halt ein paar € mehr.

von Vanye R. (vanye_rijan)


Lesenswert?

> Wenn 1 Mio Teile eingebaut wird spielt jeder ct der Chips eine Rolle.
> Der Entwicklungsaufwand nicht. Daher ist es eher egal, ob das für den
> Entwickler einfach oder kompliziert ist und niemand muss sich in diesem
> Bereich besondere Mühe geben.

Das ist korrekt, aber da interessiert sie auch niemand mehr dafuer was 
der Hersteller fuer eine Entwicklungsumgebung mitliefert. Wir haben in 
der Firma fuer alles eigene Umgebungen/Betriebssysteme.
Aber bevor man den Aufwand reinsteckt das anzupassen, evaluiert man 
erstmal 2-3 Controller um zu pruefen ob sie das leisten werden was man 
sich da vorstellt. Dafuer braucht man die Umgebungen der Hersteller die 
einen moeglichst schnell und einfach dazu in der Lage versetzen muessen 
das auszuprobieren. Da will man keine Doktorarbeit in Systembuilding 
machen. :)
Ein Beispiel dafuer: mal zu schauen wie schnell ein bestimmter 
Algorythmus, den man in der Firma woanders nutzt, bei einer bestimmten 
Taktfrequenz laeuft damit man mittlere Leistungsaufnahme und das 
Verhaeltnis von Laufzeit zu Sleepmode abschaetzen kann. Oder ob die 
propagierten Lowpowermodis gut zur eigenen Applikation passen.

> In Kleinserien-Projekten setzt man daher besser auf Embedded Linux. Das
> ist einfachst zu entwickeln (notfalls gcc & make auf dem Zielsystem).
> Die Chips kosten halt ein paar € mehr.

Du meinst Produktionstools? Ja, da hab ich auch schon mal einen 
Raspberry aus dem Schrank genommen oder wuerde dafuer auch die Umgebung 
vom Hersteller einsetzen.
Zu Linux: Ich bin da immer hin und her gerissen. Persoenlich nutze ich 
Linux seit Jahrzehnten, privat sogar ausschliesslich. Finde es also gut. 
Aber in der Firma gibt es auch viele Leute den schlackert da die 
Unterlippe und dann gibt es hinterher zu viele Hilfe-Anrufe. :-D

Vanye

von Nikolaus S. (Firma: Golden Delicious Computers) (hns)


Lesenswert?

Vanye R. schrieb:
>> In Kleinserien-Projekten setzt man daher besser auf Embedded Linux. Das
>> ist einfachst zu entwickeln (notfalls gcc & make auf dem Zielsystem).
>> Die Chips kosten halt ein paar € mehr.
>
> Du meinst Produktionstools? Ja, da hab ich auch schon mal einen
> Raspberry aus dem Schrank genommen oder wuerde dafuer auch die Umgebung
> vom Hersteller einsetzen.
> Zu Linux: Ich bin da immer hin und her gerissen. Persoenlich nutze ich
> Linux seit Jahrzehnten, privat sogar ausschliesslich. Finde es also gut.
> Aber in der Firma gibt es auch viele Leute den schlackert da die
> Unterlippe und dann gibt es hinterher zu viele Hilfe-Anrufe. :-D

Ich meine Chips wie z.B. den X1600 oder SAMA5. Oder Module wie den RasPi 
Zero. Das sind Linux-fähige Mikroprozessoren (bzw. SoC) für ganz wenig 
Geld. Sobald man da ein Systemimage hat, kann man per Seriell oder ssh 
drauf und auf dem Zieldevice Applikationen je nach Kenntnisstand in 
verschiedensten Programmiersprachen schreiben (in C, C++, Shell-Script, 
PHP, Python, wasauchimmer). Und für viele Schnittstellen (SPI, I2C, 
GPIO, USB, LAN, ...) sind die Treiber bereits im Kernel vorhanden. Dafür 
braucht es dann nicht mal mehr ein Entwicklungssystem. Oder man 
entwickelt das auf einem Host mit irgendeinem UNIX (z.B. Linux, macOS), 
kopiert den Source per scp oder rsync auf das Device, compiliert dort 
und lässt es laufen. Klar hat das gegenüber einem BareBone 
Microcontroller Einschränkungen (v.a. in der Zeit bis das System 
gestartet ist und im perfektionierten Power-Management), aber das spielt 
nicht immer eine große Rolle. M.E. ist dieser Ansatz oft einfacher, als 
sich mit der Entwicklungsumgebung des Herstellers herumzuschlagen. Vor 
allem wenn diese eines Tages nicht mehr läuft und die neue Version nicht 
mehr mit dem Betriebssystem des Entwicklungsrechners kompatibel ist 
(oder niemals war). Dann fängt man fast von vorne an.
Wir entwickeln beispielsweise gerade ein Produkt auf Basis des X1600 
neu, das bisher einen Atmel verwendet hat. Durch das Embedded Linux 
bekommt es mit sehr geringem Aufwand neue Funktionen (z.B. 
http-Webinterface - ähnlich wie eine Fritzbox, SMB um auf eine 
angesteckte Speicherkarte zugreifen zu können, Einbinden eines 
eigentlich für Arduino gestrickten C++ Programms mit überraschend wenig 
Änderungen).
Aber wie gesagt ist das m.E. nur dann zu erwägen sinnvoll, wenn die 
Stückzahlen klein bleiben oder Powermanagement und Startup-Zeit keine 
sehr große Rolle spielt.
Man muss das letztendlich für jedes Projekt neu entscheiden und die 
eigenen Erfahrungen berücksichtigen.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.