La stack est à peu près celle-là:
* buildroot pour la base
* beam, la vm erlang
* elixir, le langage qui compile sur la vm erlang, mais avec une syntaxe plus proche de ruby
* Nerves: un ensemble de librairies pour un faire quasi un OS: gestion des périphériques, du réseau, etc
En gros, les problématiques que tu évoques sont toutes couvertes, soit par le langage lui-même, soit par les librairies fournies:
* communication par message dans le langage
* threads légers gérés par la vm
* gestion des périphériques dynamiques sous forme d'évènements
* les pannes/fautes sont gérés par des superviseurs de threads, de manière très simple: tu déclares les threads à superviser, leur état initial et le système s'occupe du redémarrage, des notifications si les fautes sont trop fréquentes, etc
* serveur web ultra-léger et performant disponible sous forme de librairie (cowboy ou la stack complète phoenix)
* pour la partie gui, il existe un framework dédié: https://hexdocs.pm/scenic/welcome.html
Bref, je l'ai déjà utilisé pour un client. Le projet consistait en un raspberry qui contrôlait une MCU par RS232, avec une interface web (REST + SPA angular), du SNMP, un LCD + des boutons de contrôle. L'appli permettait également de multiplexer un port USB en façade. Tout cela tourne parfaitement sur un raspberry 2 et tient sur une image de 30Mo.
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
# Moi j'utiliserais...
Posté par Jean Parpaillon . En réponse au journal RaspberryPi, capteurs USB, dbus et systemd, utiliser des briques Linux "desktop" pour une architect. Évalué à 1.
Bravo pour le boulot et merci de le partager.
Sinon, par curiosité, as-tu déjà regardé ce projet: https://nerves-project.org/ ?
La stack est à peu près celle-là:
* buildroot pour la base
* beam, la vm erlang
* elixir, le langage qui compile sur la vm erlang, mais avec une syntaxe plus proche de ruby
* Nerves: un ensemble de librairies pour un faire quasi un OS: gestion des périphériques, du réseau, etc
En gros, les problématiques que tu évoques sont toutes couvertes, soit par le langage lui-même, soit par les librairies fournies:
* communication par message dans le langage
* threads légers gérés par la vm
* gestion des périphériques dynamiques sous forme d'évènements
* les pannes/fautes sont gérés par des superviseurs de threads, de manière très simple: tu déclares les threads à superviser, leur état initial et le système s'occupe du redémarrage, des notifications si les fautes sont trop fréquentes, etc
* serveur web ultra-léger et performant disponible sous forme de librairie (cowboy ou la stack complète phoenix)
* pour la partie gui, il existe un framework dédié: https://hexdocs.pm/scenic/welcome.html
Bref, je l'ai déjà utilisé pour un client. Le projet consistait en un raspberry qui contrôlait une MCU par RS232, avec une interface web (REST + SPA angular), du SNMP, un LCD + des boutons de contrôle. L'appli permettait également de multiplexer un port USB en façade. Tout cela tourne parfaitement sur un raspberry 2 et tient sur une image de 30Mo.
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier