Ma situation spécifique, lorsque j'utilise un langage de script interprété dans une application majeure:
Il existe un périphérique externe qui remplit plusieurs fonctions. Mesures, contrôle, lectures. C'est assez "stupide" lui-même et nécessite un contrôle précis, étape par étape, incluant de nombreux états d'attente et une prise de décision ad-hoc du côté du mécanisme de contrôle.
Diverses fonctionnalités de l'appareil sont requises à différents moments de l'application principale, à différents moments, souvent à la demande. L'application principale ne permet pas les états d'attente en tant que tels, tout doit être fait avec des machines à états finis.
Maintenant, quiconque a écrit une machine à états finis sait que la mise en œuvre d'un état d'attente correspond effectivement à au moins deux, souvent trois ou quatre états internes de la machine. Mettre en œuvre vingt états d’attente pour diverses fonctions (et attendre leurs réponses et réagir en conséquence) du périphérique externe serait une expérience extrêmement frustrante.
Ainsi, à la place, il existe des états "exécuter une fonction non attendue", "exécuter une fonction de blocage", "exécuter un branchement / conditionnel / saut" dans la machine à états finis, peut-être six états au total. Et il existe des scripts de contrôle dont l'exécution est planifiée, puis exécutée par l'interpréteur contrôlant le périphérique externe, et leurs résultats placés là où ils sont requis.
En résumé, l’application: dans un RTOS, l’utilisation d’un langage de script interprété interne peut considérablement réduire la complexité d’exécution de tâches abondantes dans des états d’attente (fonctions de blocage).