Salut,
j'ai abandonné l'idée du chargement partiel d'un code, même si c'est techniquement possible, je suis donc parti sur la voie de l'interpréteur.
J'ai donc codé un moteur de scenario basé sur des classes.
Chaque "boite" est une instance d'une classe, créé dynamiquement au démarrage du soft, par lecture des paramètres stockés en eeprom, et l'utilisation de malloc() et des pointeurs (merci osaka pour son tuto sur les pointeurs)
Ca me permet d'obtenir facilement ce genre d'équation:
* _____ _____ ______
* [ pin 2 ]-O| AND |------| |------| S |-----[ pin 13 ]
* [ pin 3 ]--|_____| | OR | | |
* _____ | | | SR |
* [ pin 4 ]--| XOR |------|_____| | |
* [ pin 5 ]--|_____| | |
* [ pin 6 ]----------------------------| R |
* |______|
Le fonctionnement est simple, chaque boite est évaluée dans un ordre précis (dans l'exemple ce sera: AND, XOR, puis OR, et enfin SR)
Lors de l'évaluation d'une boite, on lit l'état des entrées car elle connait la source à interroger(codé dans les attributs de la classe lors de l'initialisation de l'instance).
Ainsi, la boite AND "sait" qu'elle doit interroger l'état de la pin 2, et la boite OR l'état des boites AND et XOR.
Une fois les entrées de la boite lues, l'état de la boite est calculé et mémorisé pour la rendre disponible à la (aux) boite(s) où elle est connectée.
Bien sur, les classes peuvent être de tout type, pourvu qu'elle fournisse une information (cas des entrées), et/ou supporte des commandes (cas des sorties)
Le GROS point maintenant, pour que tout ceci est un sens, est le développement d'une interface graphique qui permette la génération d'une table de paramètre reprenant les paramètres de chaque boite, et l'ordre d'évaluation.
Un exemple est disponible sur le dépôt software du projet.
Gromain