- En développement de systèmes embarqués, Lua offre une stabilité et une évolutivité supérieures à MicroPython
- Lua se distingue par une intégration facile avec C, une structure légère et déterministe, avec des avantages plus marqués en maintenabilité du code et en réduction des coûts à long terme
- MicroPython convient bien au prototypage rapide, mais atteint ses limites dans les projets de grande ampleur ou les environnements de production
- Lua peut être compilé en binaire petit et efficace, utilisable sans fonctionnalités inutiles, avec une bonne évolutivité et une forte maintenabilité du prototype jusqu’au produit final
- Le framework Xedge optimise Lua pour les systèmes embarqués et fournit de puissantes fonctions IoT et web
Lua vs. MicroPython dans les environnements embarqués professionnels
- Dans les projets embarqués professionnels comme l’automatisation industrielle, les dispositifs médicaux ou l’IoT commercial, les environnements haut niveau mais légers sont de plus en plus privilégiés
- MicroPython excelle dans le prototypage rapide et le déploiement sur le terrain, mais son écosystème est principalement centré sur des cartes orientées hobby/éducation
- Les grandes bibliothèques qui font la force de Python, comme NumPy et pandas, sont absentes de MicroPython, et sa bibliothèque standard est aussi fortement réduite
- L’intégration avec des extensions C est également relativement plus complexe dans MicroPython
- Lua adopte comme philosophie fondamentale l’intégration avec les applications C
- fournit une API C stable et minimaliste ainsi qu’une machine virtuelle à bytecode
- permet d’exposer facilement à Lua des fonctions et structures de données C/C++
- la bibliothèque Lua en ANSI C est conçue pour l’embarqué, avec une structure simple, légère et déterministe
- MicroPython est une réimplémentation de Python 3, et conserve des hypothèses issues d’un langage orienté desktop, ce qui fait que ses limites apparaissent rapidement dans des environnements aux ressources contraintes
L’intégration transparente avec C est au cœur de Lua
- Le principal atout de Lua est son intégration fluide avec C
- Son API est stable et minimale, et permet d’exposer facilement à Lua ses propres fonctions C/C++ et structures de données
- MicroPython prend aussi en charge les extensions C, mais cela nécessite une compilation de firmware personnalisée et un workflow plus complexe
- Dans Lua, l’interopérabilité C fait partie de la philosophie de conception
- il est possible d’utiliser manuellement l’API C de Lua, ou d’employer des outils de binding automatique comme SWIG pour appeler des fonctions/structures C depuis Lua
- on peut séparer la logique critique pour les performances en C et la logique métier de haut niveau en Lua, ce qui améliore la maintenabilité et l’évolutivité
Empreinte minimale et évolutivité
- Lua a un interpréteur cœur très compact, et les fonctions inutiles peuvent être retirées facilement
- MicroPython est lui aussi optimisé pour l’embarqué, mais son image de base est plus volumineuse, et sa taille augmente lorsque les modules nécessaires sont activés
- Les deux conviennent au prototypage rapide, mais Lua passe mieux à l’échelle jusqu’à la production
- Lua facilite la conception d’une architecture séparant haut niveau et bas niveau, ce qui permet de développer rapidement un prototype puis de le faire évoluer vers une structure hybride maintenable
- Lua peut être combiné dès le départ avec du code C, rendant la montée en charge naturelle sans rupture dans le flux de développement
- Avec MicroPython, il peut être nécessaire de réécrire la logique cœur après le prototype, ou de se heurter à certaines limites
Écosystème et accessibilité des bibliothèques - Quality Over Quantity
- MicroPython bénéficie d’un écosystème actif centré sur du matériel hobby/éducation comme les cartes Wi-Fi, mais il lui manque les bibliothèques majeures du vaste écosystème Python
- Lua dispose de moins de bibliothèques, mais il est facilement extensible en C, ce qui permet de moins subir les limites de l’écosystème
Avantages en maintenance et en coûts
- Lua offre une base de code plus réduite, et facilite les tests, le débogage et la transmission du projet
- Quand le projet grandit, il est plus facile de conserver une séparation des couches entre scripts Lua et cœur C, ce qui favorise la passation et la collaboration
- MicroPython reste très lisible, mais à mesure que le projet grossit, le code système et la couche de scripting ont tendance à se mélanger, ce qui peut faire augmenter les coûts de maintenance
Conclusion : Choose What Scales
- Pour des objectifs éducatifs ou de prototypage, MicroPython reste un excellent choix
- Pour des produits embarqués où la sécurité, la fiabilité et la maintenabilité sont cruciales, Lua est plus pratique et offre évolutivité, flexibilité et stabilité à la fois
- Lua n’est pas seulement un langage de script, c’est une stratégie de développement embarqué
Comment intégrer la bibliothèque C de Lua sur un appareil embarqué
- La bibliothèque C de Lua est légère, compatible ANSI C et dépend très peu d’autre chose que de la bibliothèque C standard
- Elle convient bien aux systèmes bare-metal et basés sur RTOS, même si certains éléments de la bibliothèque C standard comme
stdin/stdout demandent de l’attention lors du portage
-
Xedge Framework de Real Time Logic
- Le framework Xedge fournit un runtime Lua et un ensemble d’API optimisés pour les environnements embarqués
- Il intègre des fonctions IoT/web comme les communications sécurisées TLS, MQTT5, WebSocket, les services web RESTful, le traitement de données en temps réel, ainsi que des protocoles comme Modbus/OPC UA
- Tout en conservant la souplesse et la légèreté de Lua, il fournit un framework embarqué complet prêt pour un usage réel
- Pour embarquer Lua dans un produit embarqué, Xedge apparaît comme l’option la plus pratique : il simplifie l’intégration, accélère le développement et permet de se concentrer sur la logique différenciante
2 commentaires
À la base, les fabricants de composants qui produisent l’équipement prennent rarement bien en charge Lua ou Python. Du C, à la rigueur ?
Avis Hacker News
Quand j’ai décidé de créer un moteur de jeu et d’écrire tout le jeu dans un langage de script, j’ai hésité entre JavaScript (QuickJS), Python (Boost.Python) et Lua (Sol2)
Intégrer Lua est vraiment facile, et c’est très simple même avec un wrapper C++
En peu de temps, j’avais un moteur que je me suis dit pouvoir utiliser immédiatement
En plus, la VM Lua est extrêmement légère
Plus de détails dans le projet carimbo
Quand je vois qu’un moteur ou une application prend en charge Lua comme langage de script, j’aime le fait qu’on puisse utiliser Fennel
Fennel est un langage transpillé vers Lua
Lien officiel de Fennel
Personnellement, je trouve que Boost.Python n’est pas terrible comme outil de scripting
Ça peut aussi influencer le jugement
Je me demande si Sol2 est une VM Lua, ou simplement un wrapper autour de la VM Lua standard
La formule « Lua n’est pas un simple langage de haut niveau, c’est une stratégie de développement embarqué » me paraît difficile à accepter
J’ai du mal à prendre au sérieux un texte qui emploie ce genre de formulation
Globalement, c’est un article qui donne l’impression de dire : « j’utilise Lua depuis longtemps, donc je peux maintenant conclure »
En revanche, il ne semble pas avoir beaucoup d’expérience concrète avec MicroPython, et il y a plusieurs critiques exagérées
Par exemple, l’affirmation selon laquelle « le projet MicroPython mélange code système et couche de script, ce qui rend la maintenance difficile » manque de fondement
Cela peut venir du langage, ou de la gestion du projet / de la conception de l’architecture, mais la cause devrait être évaluée rigoureusement
Ce texte ressemble davantage à une publicité pour le framework Xedge qu’à un véritable article
C’est juste une pub
Dans l’ensemble, le texte a un style très chatgpt
Dans le cas d’un article promotionnel, peu importe qu’il ait été écrit par un humain ou par un LLM
Comme les commentaires l’ont aussi souligné, ça faisait très chatgpt et je n’ai pas vraiment pris plaisir à le lire
Dans la liste PLDB Top 1000, Lua est classé plus haut que MicroPython
Dans cet article comparatif, l’utilisateur GitHub SkipKaczinksi estime que Lua est généralement plus rapide
Michael Polia, dans un article de Hackaday, mentionne lui aussi que Lua est petit et rapide
Le langage Toit affirme être 30 fois plus rapide que MicroPython
Le fondateur de Toit a dirigé les débuts du développement de V8
Il faut distinguer les notions d’« embedded » et d’« embeddable »
MicroPython s’utilise sur des plateformes embarquées, mais ce n’est pas un « runtime embarquable » qu’on intègre dans une application existante comme Lua
L’objectif de MicroPython est de remplacer un runtime C traditionnel : on fait juste l’initialisation avec un wrapper C minimal, puis on écrit le reste de la logique métier en scripts MicroPython
Il n’a pas d’architecture comparable au
lua_Statede Lua, avec plusieurs interpréteurs utilisables simultanément ou du sandboxingAutrement dit, MicroPython est davantage optimisé pour « lire les données d’un capteur en Python sur une carte IoT » que pour « itérer rapidement via des scripts dans un moteur de jeu »
Ce n’est pas quelque chose qui fonctionne entièrement prêt à l’emploi, et un peu de glue code est nécessaire
On peut voir comme référence cet exemple de port embed
Je pense que Lua est un excellent langage aussi pour l’embarqué
Je pense aussi que les produits basés sur Lua sont intéressants, mais cet article convainc mal sur le « pourquoi Lua bat MicroPython »
Étendre MicroPython en C est plus facile qu’on ne le croit, et il suffit de développer des modules externes de la même manière que les modules officiels
On peut donc les ajouter sans grande difficulté lors d’un build firmware personnalisé
Et il y avait aussi la critique selon laquelle les bibliothèques de l’écosystème Python (numpy, etc.) ne fonctionnent pas, alors qu’en réalité il existe aussi la bibliothèque ulab, qui réimplémente une partie de numpy et scipy
Personnellement, tout ça me donne l’impression d’un discours marketing
Sur microcontrôleur, s’il y a assez de ressources, j’utilise micropython
Si la maîtrise de l’alimentation, de la mémoire et du CPU est vraiment cruciale, au final j’utilise du C/C++
Le développement réseau a toujours été difficile en C/C++, et il y avait peu d’options pour le faire rapidement et en toute sécurité (même si le support TLS intégré s’est probablement amélioré récemment)
Lua donne l’impression d’un habillage plus fluide du C
Avoir beaucoup de bibliothèques, c’est bien, mais devoir porter soi-même tout l’outillage Lua, l’outillage microcontrôleur et les bibliothèques nécessaires représente une lourde charge
Donc si ce texte est du marketing, j’y vois le message « utilisez le produit Xedge et sous-traitez le reste »
Je me demande s’il y a vraiment des gens qui utilisent micropython ou lua pour du développement embarqué « sérieux »
Je fabrique depuis près de 20 ans, en freelance, des produits embarqués centrés sur Lua
J’ai utilisé Lua dans des appareils VOIP, la domotique, des routeurs industriels, des enregistreurs vidéo numériques et d’autres domaines
En général, le système se compose du noyau Linux, de libc, de l’interpréteur Lua et de quelques bibliothèques externes
Le code source des applications Lua représente entre 30 000 et 100 000 lignes, et il existe même selon les standards actuels des produits « petits » (flash 8 Mo, RAM 64 Mo, etc.)
Lua fonctionne bien dans ce type d’environnement
Tous ces produits sont encore en production et rapportent de l’argent aux clients
L’interfaçage entre Lua et C est très simple, et pour le travail asynchrone aussi, Lua résolvait déjà depuis longtemps des problèmes sur lesquels les langages modernes continuent de réfléchir
Le langage est simple mais puissant, et permet différents paradigmes grâce aux coroutines, aux closures, aux métatables, etc.
Pour des projets de cette taille, je choisirais encore aujourd’hui la combinaison Lua + C/C++
J’ai aussi essayé d’autres écosystèmes (Elixir, Rust, Nim), mais je n’ai pas trouvé de langage aussi puissant et flexible que Lua
Nous développons même des dispositifs médicaux de classe B avec MicroPython
Le monde de l’embarqué couvre un spectre très large
Si la sécurité est sensible, la réglementation peut l’interdire, mais pour du matériel de test, par exemple, la contrainte réglementaire n’existe pas, donc chacun utilise ce qui lui convient
Dans l’IoT aussi, on peut considérer que chacun utilise ce qui lui est le plus pratique
MicroPython est réellement utilisé jusque dans des missions spatiales, comme les CubeSats
Il existe des exemples liés à des conférences et des podcasts sur le sujet
Des milliers de produits utilisent Lua en interne, ou au moins pour une partie
J’ai récemment regardé LuaJIT aussi, et je pense qu’il est sous-estimé
Je pense que la plupart des développeurs embarqués « sérieux » utilisent des langages compilés
Pour le hobby, j’utilise simplement Arduino (Platformio)
Sur microcontrôleur, compiler et flasher prend peu de temps, donc je n’ai pas vraiment besoin d’un interpréteur
J’aimerais essayer un jour un autre langage compilé qui pourrait remplacer le C++
Je me demande s’il existe des langages recommandés qui fonctionnent bien sur Raspberry Pi Pico
Je ne suis pas un expert, mais j’ai l’impression que Rust est l’une des alternatives les plus populaires
C’est tendance, ça corrige beaucoup de problèmes du C++, et l’outillage est plutôt bon
Zig a aussi l’air intéressant, et j’aimerais l’essayer
Raspberry Pi a des spécifications suffisamment confortables pour pouvoir faire tourner autre chose qu’un langage système
J’aime bien Kotlin aussi, et même s’il faut en principe la JVM, on peut faire des builds natifs
En revanche, sur Pico, il faudra peut-être contrôler les GPIO en touchant directement au système de fichiers (et au passage, je ne suis pas sûr du support de Kotlin sur Pico)
Nim semble être une option tout à fait correcte
Voir à ce sujet la prise en charge de Nim dans picostdlib
Lua est par essence un langage beaucoup plus simple
Python prétend qu’« il n’y a qu’une seule bonne manière de faire », mais en pratique on a plutôt l’impression d’un « couteau suisse » où tout a été ajouté
Cela le rend plus facile à prendre en main, et l’abondance de bibliothèques facilite aussi le développement
Mais ce n’est pas très adapté aux environnements à faibles ressources
On ne peut pas indéfiniment transformer une chaise sophistiquée en chaise Eames faite de planches
Python est facile, Lua est simple
Le problème du « facile », c’est qu’il masque une complexité interne ; la « simplicité », elle, demande davantage d’effort à l’utilisateur
Python a une compatibilité de version fragile, et il y a souvent des problèmes quand on passe de 3.x à 3.x+1
Lua n’est pas parfait non plus, mais il a l’avantage d’avoir beaucoup de cas où plusieurs versions de Lua sont prises en charge, sans imposer brutalement de grosses montées de version à court terme