ESP8266 - ESP-01

[spourre]

@mirlant: tu peux lire mais j'espère que cela ne va pas trop d'embrouiller

@Bud
@Destroyedlolo

Vous conseillez, tous les deux, d'utiliser LUA que je ne connais pas (plus exactement que je ne pratique pas).
Néanmoins, sauf erreur de ma part, ce langage de script est interprété.
Quand on voit, sur une machine disposant de plus de ressources (un pi 3 par exemple), les limitations temporelles apportées par des pythonneries interprétées, on peut se poser la question de la réactivité sur un dispositif encore plus limité et destiné principalement à de l'embarqué.

Sylvain

[Bud Spencer]

Oui, tout à fait, c’est un langage interprété. On le trouve encore assez souvent dans l’industrie ou il est utilisé pour scripter des ‘plugins’ pour des programmes écrit en langage compilé. C’est très léger et l’approche est plutôt facile avec une syntaxe plutôt commune. Pour moi, lua est d’ailleurs bien plus adapté à l’apprentissage de la programmation que le Python. Après en termes de performance, c’est sûr que ce n’est pas du c++, mais c’est avant tout destiné à de petit programme et pour linker quelques sondes avec un esp, ça fait très largement le boulot avec très peu de code.

[miralant]

Pour vous donner mon "socle technique", si ça peut aider dans le choix. Je fais actuellement du vb.net (client lourd), SQL server, webservice, BI, c'est assez large. J'ai une formation électronique/Telecom, j'ai derivé professionnellement avec les années

Le lua est peut être une bonne alternative car il est largement utilisé dans Domoticz pour éviter de passer par blocky. En passant, Blocky est vraiment pas terrible même pour faire des scénarios simples.
Je pense que le lua sera peut être un excellent point d'entrée car j'ai des scénarios que je n'arrive pas à faire en Blocky. Ça sera l'occasion d'appréhender un nouveau language que je pourrai utiliser dans les 2 projets.
En tout cas merci, vous êtes ultra pointus et de très bons conseils.

[spourre]

...
En tout cas merci, vous êtes ultra pointus et de très bons conseils.

Tant mieux si on a pu apporter une contribution utile.
Vu la précision apportée par Bud, sauf à vouloir réaliser un projet avec de fortes contraintes temporelles (sans aller jusqu'au temps réel), LUA semble donc être un bon compromis.
Destroyedlolo te le recommande aussi et comme il a une "certaine " expertise en domotique, je pense que cela doit te conforter dans ton choix.
Moi, je suis un dinosaure et je n'aurais jamais envisagé de faire de l'interprété dans un microcontrôleur .

Sylvain

[destroyedlolo]

Lua utilise une vm et du bytecode comme beaucoup de langages actuels. C'est évident qu'il n'aura pas les perfs d'un C ou d'un C++... Mais est-ce vraiment indispensable ?
Perso, il me sert de language de scripts embarqué pour mes démons C et est la base de toute ma Domotique... On peut même faire y faire de l'objet.
Malgré le côté VM, il reste très léger (très très loin d'un Java ou python) et est utilisé dans pas mal de jeu, et dans pas mal de soft Unix (je l'ai découvert avec l'excellentissime Conky).
Comme je le disais, la seule chose vraiment galère, c'est des qu'on veut faire du multithreading depuis une appli C (surtout à cause du manque de docs)

Faut-il y aller ?
- oui si on ne connaît pas le C
- oui pour découvrir

Mais si on connaît déjà le monde arduino, ça n' à pas beaucoup d'intérêt (sauf à apprendre qq chose de nouveau)

Pour Domotiquez, il ne faut pas oublier que blocky a été créé pour faire de l'apprentissage... Pas pour faire des scénario complexes. Sinon, pour le fun, le blocky est converti en interne en Lua pour exécution

De mon côté, je suis en train de prendre le chemin inverse : comme je le disais, une bonne partie de ma domotique est en Lua... Mais je suis en train d'y ajouter la possibilité d'y mettre du blocky pour les scénario simples (genre "heure creuses->pompe piscine") pour rendre le truc accessible à tous... Tout en gardant Lua pour les trucs péchus.

C + Lua + blocky me semble un bon trio... Verdict dans quelques mois

Envoyé de mon WAS-LX1A en utilisant Tapatalk

[spourre]

Lua utilise une vm et du bytecode comme beaucoup de langages actuels.
...

Je crois l'avoir déjà signalé dans une autre discussion mais ça ne peut nuire de le redire.
Les jeunes croient souvent avoir tout inventé mais moi, qui suis un dinosaure, je constate le recyclage de pas mal de concepts des années 70/80 (autant dire une éternité en informatique).

La VM et un byte code remontent à 1969, la même année que la création du Pascal. C'est d'ailleurs une VM pascal qui interprète, à la volée, du P-code (jit comme dirait un djeune):
http://www.threedee.com/jcm/psystem/
Linux qui est un système POSIX est donc l'héritier direct (au niveau des concepts, pas du code) d'UNIX qui date aussi de 1969. Au passage, notez l'admirable clairvoyance des auteurs qui ont su concevoir des systèmes d'adressage et des systèmes de fichiers capable de gérer des volumes inimaginable à l'époque.
Le client léger me fait furieusement penser au terminal X des années 90.

La seule "évolution" notable semble est la programmation objet mais je ne suis pas certain que ce soit un progrès vu la lourdeur du code généré par un niveau d'abstraction trop élevé de la machine.

Sylvain

[destroyedlolo]

La VM et un byte code remontent à 1969, la même année que la création du Pascal. C'est d'ailleurs une VM pascal qui interprète, à la volée, du P-code (jit comme dirait un djeune):

Sans vouloir te contredire, le JIT n'est pas ca, le JIT c'est convertir "à la volé" du ByteCode en binaire natifs. Comme il n'est plus interprété, il devient presque aussi rapide d'un programme en C ... enfin, c'est ce que veulent nous faire croire les tenants du Java.
Mais bon, quand certains essaient de nous vendre des OS ou tout est en bytecode ... j'ai un peu peur pour les perfs quand meme

[miralant]

Bonjour,

J'ai reçu mon FTDI, programmation ulta-simple avec ESPeasy. Y'a plus qu'a s'amuser avec les modules !

Merci pour votre aide et expertise.