Go Down

Topic: Chargement partiel d'un code compilé (Read 865 times) previous topic - next topic

Bonjour,

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.

Merci d'avance

Gromain
"pour résoudre un gros problème, il est souvent plus facile de le diviser en petits problèmes élémentaires..."

projet domotique xPLDuino
IRC: freenode #xplduino

fdufnews

#1
Nov 04, 2012, 12:05 pm Last Edit: Nov 04, 2012, 12:07 pm by fdufnews Reason: 1
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.

fdufnews,

Quote
Il n'y a rien de prévu pour faire ça simplement.

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 ?
"pour résoudre un gros problème, il est souvent plus facile de le diviser en petits problèmes élémentaires..."

projet domotique xPLDuino
IRC: freenode #xplduino

fdufnews

Ils consistent en quoi ces scénarios?

barbudor

Salut

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.
Barbuduino: Arduino sur Breadboard & VinciDuino: Clone Leonardo // WR703: Mini-routeur hacké // LauchPad MSP430 et Stellaris // Panda II Arduino-like .NetMF sous VisualC#
RTFC: Read That F.....g Code / RTFD: Read That F.....g Doc / RTFDS: Read That F.....g DataSheet / RTFS: Read That F.....g Schematic / Wot da ya wanna D.I.Y. today ?

fdufnews

#5
Nov 04, 2012, 01:50 pm Last Edit: Nov 04, 2012, 01:52 pm by fdufnews Reason: 1
Quote
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

merci pour les réponses.

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...

Gromain
"pour résoudre un gros problème, il est souvent plus facile de le diviser en petits problèmes élémentaires..."

projet domotique xPLDuino
IRC: freenode #xplduino

skywodd

Bonjour,

L'idée de l'interpréteur est bien plus simple et est faisable sans trop de problème (stockage en EEPROM, ...).

J'ai utilisé ce principe pour mon générateur de chiptune, ça peut servir de base de réflexion :
https://github.com/skywodd/generic_chiptune_generator/blob/master/tracker.c
Des news, des tutos et plein de bonnes choses sur http://skyduino.wordpress.com !

#8
Nov 14, 2012, 03:04 pm Last Edit: Nov 14, 2012, 03:05 pm by Gromain59 Reason: 1
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:

Code: [Select]
*             _____        _____        ______
* [ 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

"pour résoudre un gros problème, il est souvent plus facile de le diviser en petits problèmes élémentaires..."

projet domotique xPLDuino
IRC: freenode #xplduino

bricofoy

ç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.

http://www.linuxcnc.org/docs/HAL_User_Manual_fr.pdf
-tu savais que si tu passe le CD de windows à l'envers, tu entends une chanson satanique ?
-non, mais il y a pire : à l'endroit, ça l'installe !

Go Up