- In der Embedded-Systementwicklung bietet Lua mehr Stabilität und Skalierbarkeit als MicroPython
- Lua lässt sich leicht mit C integrieren, ist leichtgewichtig und deterministisch aufgebaut und bietet größere Vorteile bei Wartbarkeit des Codes und langfristiger Kostensenkung
- MicroPython eignet sich für schnelles Prototyping, stößt aber bei großen Projekten oder in Produktionsumgebungen an Grenzen
- Lua lässt sich als kleine und effiziente ausführbare Datei bauen und ohne unnötige Funktionen betreiben; von Prototyping bis zur Produktisierung bietet es hohe Skalierbarkeit und Wartbarkeit
- Das Xedge Framework optimiert Lua für Embedded-Systeme und bietet leistungsstarke IoT- und Web-Funktionen
Lua vs. MicroPython in professionellen Embedded-Umgebungen
- In professionellen Embedded-Projekten wie Industrieautomatisierung, Medizintechnik und kommerziellem IoT werden hochrangige, aber dennoch leichtgewichtige Umgebungen zunehmend bevorzugt
- MicroPython hat Stärken bei schnellem Prototyping und Deployment vor Ort, verfügt aber vor allem über ein auf Hobby- und Bildungsboards ausgerichtetes Ökosystem
- Große Bibliotheken, die eine Stärke von Python sind, wie NumPy und pandas, fehlen in MicroPython; auch die Standardbibliothek ist stark reduziert
- Auch die Integration mit C-Erweiterungen ist bei MicroPython vergleichsweise komplex
- Lua verfolgt die Integration mit C-Anwendungen als grundlegende Designphilosophie
- Es bietet eine stabile und minimale C-API sowie eine Bytecode-VM
- C/C++-Funktionen und Datenstrukturen lassen sich leicht für Lua bereitstellen
- Die Lua-ANSI-C-Bibliothek ist für Embedded-Systeme konzipiert und in ihrer Struktur einfach, leichtgewichtig und deterministisch
- MicroPython ist eine Reimplementierung von Python 3, in der Annahmen einer Desktop-orientierten Sprache erhalten geblieben sind; daher werden Grenzen in ressourcenbeschränkten Umgebungen schnell sichtbar
Nahtlose C-Anbindung ist der Kern von Lua
- Der größte Vorteil von Lua ist die reibungslose Integration mit C
- Die API ist stabil und minimal gehalten, und eigene C/C++-Funktionen und Datenstrukturen lassen sich leicht in Lua verfügbar machen
- MicroPython unterstützt ebenfalls C-Erweiterungen, erfordert aber Custom-Firmware-Builds, und der Workflow ist komplexer
- Bei Lua ist die C-Anbindung selbst Teil der Designphilosophie
- Die Lua-C-API kann manuell genutzt werden, oder mit automatischen Binding-Tools wie SWIG, sodass C-Funktionen/-Strukturen aus Lua heraus aufgerufen werden können
- Leistungsrelevante Logik kann in C verbleiben, während hochrangige Business-Logik in Lua umgesetzt wird, was Wartbarkeit und Skalierbarkeit verbessert
Minimaler Footprint und Skalierbarkeit
- Lua hat einen sehr kleinen Core-Interpreter, und nicht benötigte Funktionen lassen sich leicht entfernen
- Auch MicroPython ist für Embedded-Systeme optimiert, jedoch ist das Basis-Image größer, und beim Aktivieren notwendiger Module wächst der Umfang weiter
- Beide eignen sich für schnelles Prototyping, aber Lua skaliert hervorragend bis in die Produktion
- Mit Lua lässt sich eine Architektur mit Trennung zwischen High-Level und Low-Level leicht entwerfen, sodass ein schneller Prototyp später zu einer wartbaren Hybridstruktur weiterentwickelt werden kann
- Lua kann von Anfang an mit C-Code kombiniert werden, wodurch Scale-up natürlich verläuft und der Entwicklungsfluss nicht unterbrochen wird
- Bei MicroPython kann es nach dem Prototyp nötig werden, Kernlogik neu zu schreiben, oder das System stößt an Grenzen
Ökosystem und Bibliothekszugang - Qualität vor Quantität
- MicroPython verfügt über ein lebendiges, auf Hobby- und Bildungshardware wie Wi-Fi-Boards ausgerichtetes Ökosystem, aber wichtige Bibliotheken des großen Python-Ökosystems fehlen
- Lua hat weniger Bibliotheken, lässt sich aber leicht mit C erweitern und stößt dadurch seltener an die Grenzen seines Ökosystems
Vorteile bei Wartung und Kosten
- Lua bietet eine kleine Codebasis, und Tests, Debugging und Übergabe sind einfacher
- Bei wachsendem Projekt lässt sich die Schichtentrennung zwischen Lua-Skripten und C-Core beibehalten, was Übergabe und Zusammenarbeit erleichtert
- MicroPython ist ebenfalls gut lesbar, doch mit zunehmender Projektgröße neigen Systemcode und Scripting-Layer dazu, sich zu vermischen, was die Wartungskosten erhöhen kann
Fazit: Wähle, was skaliert
- Für Lern- und Prototyping-Zwecke ist MicroPython ebenfalls eine hervorragende Wahl
- Für Embedded-Produkte, bei denen Sicherheit, Zuverlässigkeit und Wartbarkeit wichtig sind, ist Lua praktischer und bietet Skalierbarkeit, Flexibilität und Stabilität zugleich
- Lua ist nicht nur eine einfache Skriptsprache, sondern eine Embedded-Entwicklungsstrategie
So integriert man Lua-C-Bibliotheken in Embedded-Geräte
- Die Lua-C-Bibliothek ist leichtgewichtig, ANSI-C-kompatibel und hat außer der Standard-C-Bibliothek kaum Abhängigkeiten
- Sie eignet sich für Bare-Metal- und RTOS-basierte Systeme; beim Portieren ist bei einigen Elementen der Standard-C-Bibliothek wie stdin/stdout Vorsicht nötig
-
Xedge Framework von Real Time Logic
- Das Xedge Framework bietet eine für Embedded-Umgebungen optimierte Lua-Runtime und ein API-Set
- Integriert sind IoT-/Web-Funktionen wie sichere Kommunikation über TLS, MQTT5, WebSocket, RESTful Webservices, Echtzeit-Datenverarbeitung sowie Protokolle wie Modbus/OPC UA
- Es bewahrt die Flexibilität und Leichtgewichtigkeit von Lua und bietet zugleich ein vollwertiges Embedded-Framework für den Praxiseinsatz
- Wenn Lua in ein Embedded-Produkt eingebettet werden soll, ist Xedge die praktischste Option: Es vereinfacht die Integration, erhöht die Entwicklungsgeschwindigkeit und ermöglicht es, sich auf differenzierende Logik zu konzentrieren
2 Kommentare
Von vornherein unterstützen Komponentenhersteller, die Geräte produzieren, weder Lua noch Python besonders gut. Eher noch C?
Hacker-News-Kommentare
Als ich mich entschied, eine Game-Engine zu bauen und das gesamte Spiel in einer Skriptsprache zu schreiben, habe ich zwischen JavaScript (QuickJS), Python (Boost.Python) und Lua (Sol2) abgewogen.
Lua einzubetten ist wirklich einfach, und auch zusammen mit einem C++-Wrapper ist es sehr bequem zu nutzen.
In kurzer Zeit hatte ich eine Engine, bei der ich dachte: „Die kann man direkt einsetzen.“
Dazu ist die Lua-VM sehr leichtgewichtig.
Details gibt es im carimbo-Projekt
Mir gefällt, dass man Fennel verwenden kann, wenn eine Engine oder Anwendung Lua als Skriptsprache unterstützt.
Fennel ist eine Sprache, die nach Lua transpiliert.
Offizieller Fennel-Link
Persönlich halte ich Boost.Python als Skripting-Werkzeug für nicht besonders gut.
Das könnte die Entscheidung ebenfalls beeinflusst haben.
Ich frage mich, ob Sol2 eine Lua-VM ist oder nur ein Wrapper für die Standard-Lua-VM.
Die Formulierung „Lua ist nicht nur eine einfache Hochsprache, sondern eine Embedded-Entwicklungsstrategie“ finde ich schwer nachvollziehbar.
Artikel mit solchen Formulierungen kann ich nur schwer ernst nehmen.
Insgesamt wirkt der Text wie „Ich habe Lua lange genug benutzt und kann jetzt ein Urteil fällen“.
Mit MicroPython scheint der Autor in der Praxis aber nicht viel Erfahrung zu haben, und es gibt einige übertriebene Kritikpunkte.
Zum Beispiel ist die Aussage „Im MicroPython-Projekt sind Systemcode und Skript-Layer so vermischt, dass die Wartung schwierig ist“ nur schwach belegt.
Das könnte auch an Sprache, Projektmanagement oder der Struktur des Designs liegen; ich denke, die Ursachen müssten genauer bewertet werden.
Dieser Text wirkt eher wie Werbung für das Xedge-Lua-Framework als wie ein echter Artikel.
Das ist einfach Werbung.
Insgesamt klingt der Text nach ChatGPT-Stil.
Bei Werbetexten scheint es letztlich egal zu sein, ob sie von Menschen oder einem LLM geschrieben wurden.
Wie auch in den Kommentaren erwähnt, wirkte es nach ChatGPT, und deshalb machte mir das Lesen keinen großen Spaß.
In der Liste PLDB Top 1000 steht Lua höher als MicroPython.
In diesem Vergleichsartikel meint der Github-Nutzer SkipKaczinksi, dass Lua im Allgemeinen schneller sei.
Michael Polia erwähnt in einem Hackaday-Artikel, dass Lua klein und schnell ist.
Die Sprache Toit behauptet, 30-mal schneller als MicroPython zu sein.
Der Gründer von Toit war in der Frühphase für die Entwicklung von V8 verantwortlich.
Man sollte zwischen „embedded“ und „embeddable“ unterscheiden.
MicroPython wird zwar auf Embedded-Plattformen eingesetzt, ist aber keine „embeddable Runtime“, die sich wie Lua in bestehende Anwendungen integrieren lässt.
Das Ziel von MicroPython ist vielmehr, die traditionelle C-Runtime zu ersetzen, sodass man sie mit einem minimalen C-Wrapper initialisiert und den restlichen Business-Logic-Code in MicroPython-Skripten schreibt.
Es gibt keine Struktur wie
lua_State, in der mehrere Interpreter gleichzeitig laufen können, und auch kein Sandboxing.Mit anderen Worten: MicroPython ist eher dafür optimiert, auf einem IoT-Board Sensordaten mit Python auszulesen, als für schnelle iterative Entwicklung per Skripting innerhalb einer Game-Engine.
Es funktioniert nicht komplett out of the box, und etwas Glue-Code ist nötig.
Als Referenz kann man sich das Beispiel für den Embed-Port ansehen.
Ich halte Lua auch für eine hervorragende Sprache für Embedded-Zwecke.
Ich mag auch Produkte auf Lua-Basis, aber dieser Text erklärt nicht überzeugend, „warum Lua gegen MicroPython gewinnt“.
MicroPython mit C zu erweitern ist leichter als man denkt; externe Module entwickelt man im Grunde genauso wie offizielle Module.
Deshalb kann man sie bei einem angepassten Firmware-Build ohne große Schwierigkeiten hinzufügen.
Und obwohl kritisiert wurde, dass Python-nahe Bibliotheken wie numpy nicht funktionieren, gibt es mit
ulabtatsächlich auch eine Bibliothek, die Teile von numpy und scipy nachimplementiert.Für mich klingt das, was ich gehört habe, nach Marketing.
Wenn ein Mikrocontroller genügend Ressourcen hat, verwende ich MicroPython.
Wenn Stromverbrauch, Speicher und CPU-Kontrolle wirklich entscheidend sind, lande ich am Ende bei C/C++.
Netzwerkentwicklung war in C/C++ schwierig, und es gab nur wenige Optionen, die schnell und sicher waren, auch wenn die integrierte TLS-Unterstützung inzwischen vermutlich besser geworden ist.
Lua wirkt auf mich wie eine sanfte Verpackung um C herum.
Ein reichhaltiges Bibliotheksangebot wäre schön, aber man trägt die Last, selbst die Lua-Toolchain, die Mikrocontroller-Toolchain und alle benötigten Bibliotheken zu portieren.
Deshalb denke ich, dass ein solcher Marketingtext im Grunde sagt: Nutzt einfach das Produkt Xedge und lagert es aus.
Ich frage mich, ob es wirklich Leute gibt, die MicroPython oder Lua „ernsthaft“ für Embedded-Entwicklung einsetzen.
Ich habe fast 20 Jahre lang als Freelancer Embedded-Produkte mit Schwerpunkt Lua entwickelt.
Ich habe Lua in ganz unterschiedlichen Bereichen eingesetzt, darunter VOIP-Geräte, Hausautomation, industrielle Router und digitale Videorekorder.
Typischerweise bestanden die Systeme aus einem Linux-Kernel, libc, dem Lua-Interpreter und einigen externen Bibliotheken.
Der Lua-Anwendungscode hatte zwischen 30.000 und 100.000 Zeilen; nach heutigen Maßstäben waren darunter auch „kleine“ Produkte mit 8 MB Flash und 64 MB RAM.
Lua funktioniert in solchen Umgebungen sehr gut.
All das sind aktive Produkte, und sie verdienen auch Geld für die Kunden.
Die Anbindung zwischen Lua und C ist sehr einfach, und selbst für asynchrones Arbeiten löst Lua Dinge schon seit Langem, an denen moderne Sprachen noch immer herumdenken.
Die Sprache ist einfach und zugleich mächtig, und mit Coroutines, Closures und Metatables kann man verschiedene Paradigmen nutzen.
Bei Projekten in dieser Größenordnung würde ich mich weiterhin für die Kombination Lua + C/C++ entscheiden.
Ich habe auch andere Ökosysteme wie Elixir, Rust und Nim verwendet, aber keine Sprache gefunden, die so mächtig und flexibel ist wie Lua.
Wir entwickeln sogar Medizinprodukte der Klasse B mit MicroPython.
Die Embedded-Welt ist sehr breit gefächert.
Wenn Sicherheit kritisch ist, darf man es regulatorisch nicht einsetzen, aber bei Testgeräten etwa spielt Regulierung keine Rolle, also nimmt man einfach, was praktisch ist.
Auch im IoT-Bereich nutzt letztlich jeder das, was für ihn am bequemsten ist.
MicroPython wird tatsächlich auch in Satellitenmissionen wie CubeSats eingesetzt.
Dazu gibt es Beispiele aus Konferenzen und Podcasts.
Tausende Produkte verwenden intern Lua oder zumindest in Teilbereichen.
Ich habe mir kürzlich auch LuaJIT angesehen und finde, dass es unterschätzt wird.
Ich denke, die meisten „ernsthaften Embedded-Entwickler“ verwenden kompilierte Sprachen.
Als Hobby nutze ich einfach Arduino (Platformio).
Auf Mikrocontrollern geht das Kompilieren und Flashen so schnell, dass man nicht unbedingt einen Interpreter braucht.
Irgendwann würde ich gern auch mal eine andere kompilierte Sprache ausprobieren, die C++ ersetzen könnte.
Ich frage mich, ob es eine empfehlenswerte Sprache gibt, die auf dem Raspberry Pi Pico gut läuft.
Ich bin zwar kein Experte, aber Rust wirkt auf mich wie eine der beliebtesten Alternativen.
Es ist modern, behebt viele Probleme von C++ und hat auch ein ordentliches Tooling.
Zig sieht ebenfalls interessant aus, und ich würde es gern ausprobieren.
Raspberry Pi ist leistungsfähig genug, dass auch Nicht-Systemsprachen darauf laufen können.
Ich mag auch Kotlin; grundsätzlich braucht es eine JVM, aber Native-Builds sind möglich.
Allerdings müsste man zur GPIO-Steuerung auf dem Pico möglicherweise direkt mit dem Dateisystem arbeiten. Außerdem bin ich mir bei Kotlin-Unterstützung auf dem Pico nicht sicher.
Nim scheint ebenfalls eine ziemlich gute Option zu sein.
Siehe dazu die Nim-Unterstützung in picostdlib.
Lua ist im Kern eine deutlich einfachere Sprache.
Python vertritt den Glauben, es gebe „nur einen Weg“, wirkt in der Praxis aber eher wie ein Multitool, in das von allem etwas eingebaut wurde.
Das macht den Einstieg leichter und beschleunigt die Entwicklung dank vieler Bibliotheken,
passt aber nicht gut zu ressourcenarmen, kleinen Umgebungen.
Einen schicken Stuhl kann man eben nur begrenzt in einen Eames-Stuhl aus Sperrholz verwandeln.
Python ist leicht, Lua ist einfach.
Das Problem bei „leicht“ ist, dass die innere Komplexität verborgen wird; „einfach“ bedeutet dagegen, dass vom Nutzer mehr Aufwand verlangt wird.
Python hat eine schwache Versionskompatibilität, sodass beim Übergang von 3.x zu 3.x+1 häufig Probleme auftreten.
Lua ist auch nicht perfekt, aber es hat immerhin den Vorteil, dass viele Fälle mehrere Lua-Versionen unterstützen und man daher seltener zu abrupten Versions-Upgrades gezwungen wird.