Dans le cadre de mon contrôleur domotique xplduino..
est-ce que parmi les pointures du forum, quelqu'un pourrait me dire s'il est possible d'avoir une sorte de partitionnement de la mémoire flash ?
c'est à dire avoir la tache principal A qui tourne et fait appel à une tache B située dans une autre zone de la mémoire. Le code compilé de cette tache B serait mis à jour indépendamment du code de la tache A, par la tache A...
Je pense que ça doit être possible mais pas facile.
L'idée est d'avoir la tache A qui gère les E/S, la communication ethernet etc, et la tache B qui exécuterait les scénarios.
Il n'y a rien de prévu pour faire ça simplement.
Par contre rien ne t'empêche de coder les fonctions dans le code principal et d'envoyer les scénarios sous forme de texte. Le texte sera interprété à la réception par ton logiciel qui le traduira pour construire des tableaux décrivant l’enchaînement de tâches c-à-d contenant entre autres choses des pointeurs de fonctions.
j'aurais dû préciser que ma question dépassait largement le cadre d'arduino.
Je suis prêt à aller bien au delà de ce que permettent les outils traditionnels
Pour ta proposition, c'est l'idée sur laquelle je travaille, mais je trouve dommage de ne pas profiter d'un code compilé.
J'ai un peu de mal à concevoir un tel interpreteur sans qu'il soit surconsommateur de mémoire :-/
tu aurais des exemples ?
Dans le principe de base, rien ne devrait l'empecher. De plus, l'ATmega ne possède pas de mémoire cache ce qui complique le code autogénéré/modifié sur d'autres micros....
Le code généré par défaut semble relogeable donc un soucis de moins.
Par contre il ne sera pas possible que le code chargé accède de manière transparente à des variables du programme principal (c'est à dire a des variables globales). De même interdire toute variables globales dans les code chargé dynamiquement.
Le plus simple est de mettre les variables partagées dans une grosse structure et passer un pointeur sur cette structure au code chargé.
De même si le code chargé à besoin de mémoire, il faudrait lui réserver de l'espace avant.
J'ai déjà fait du code chargé dynamiquement dans le temps. Il faut vraiment que le jeu en vaille la chandelle.
Sinon coté interpreté, j'ai vue passer sur HackADay recemment un article a propos d'une machine java pour micro 8 bit.
Sinon coté interpreté, j'ai vue passer sur HackADay recemment un article a propos d'une machine java pour micro 8 bit
Oui enfin si les scénarios c'est du genre exécuter telle fonction et puis et puis telle autre, attendre tant de temps, faire changer telle sortie, on reste dans des trucs assez simple. Pour autant que la taille des dits scénarios ne soit pas trop importante. Et encore s'il sont volumineux on peut toujours imaginer de les stocker dans une EEPROM ou une carte SD
Un interpréteur serait sans doute la plus simple des solutions.
Quand je parles de scénarios, c'est pour accéder à l'état des différentes instances de mes classes, et faire du combinatoire avec.
Ex: si j'ai l'état "on" du bouton 1, géré par l'instance 1 de ma classe "switch", ET que j'ai l'état "off" du bouton 2 (instance 2 de la classe "switch"), alors j'appelle la méthode "toggle" de l'instance 3 de la classe "lighting" qui gère la lampe 3.
Toutes ces instances de classes sont créées dynamiquement en fonction de paramètres en eeprom (ou carte SD)
Bon, le vocabulaire utilisé est sans doute pas le bon, veuillez m'en excuser...
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:
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.
ça me fait penser au principe de la couche HAL du système de commande numérique linuxCNC,. Peut-être pourrais tu t'inspirer de celui-ci ? En plus pour linuxCNC, il existe un plugin eagle pour générer les fichier HAL de manière graphique.
