03/12/2007, 12:21:47
@ Marc Assin
> > je ne pense pas que ce module
> > réutilise le programme d'application du module Jung.
> Si, si, regarde bien la page où le module est décrit
> C'est marqué explicitement.
> ûûûh ?!? d'où ma remarque cfr plus haut
Et bien j'ai bien relu les 5 lignes sur la page du module "8 sorties
binaires" et ce que je comprends c'est que le software simule un
acteur Jung.
Ce que je comprends par la, c'est que pour le programmer via ETS, il
faut faire "comme si" c'était l'acteur Jung, donc utiliser ce
programme d'application dans ETS, mettre les adresses de groupe et le
flags et ensuite lancer la procédure de programmation :
- adresse physique
- programme d'applic
- paramètres
- table d'adresses de groupe
- flags
On peut supposer que ETS ne donnera pas de message d'erreur lors de la
programmation, donc le module Freebus va se comporter comme le module
Jung pour l'ETS, mais RIEN n'oblige le module Freebus à sauver la
totalité des données envoyées par l'ETS dans sa mémoire flash.
A mon avis, lors de la phase de programmation de l'application, le
module Freebus accepte les données (le code hexa de l'application)
envoyées par l'ETS mais il n'en fait rien et les jette à la poubelle (/
dev/null).
C'est probablement pour cela que les gens de Freebus disent que les
"paramètres" ne sont pas encore gérés par leur module ; en effet, ETS
applique les paramètres en modifiant certaines parties du code hexa de
l'application, donc pour décoder la valeur de ces paramètres, il y a
plusieurs étapes :
1) A l'aide d'un "sniffeur" de bus, enregistrer ce que l'ETS envoit
comme programme d'application dans chaque cas de figure, donc pour
chaque modification de l'un ou l'autre paramètre. Plus le nombre de
paramètres et de valeurs possible par paramètre augmente, plusce
travail est énorme.
2) Comparer toutes ces captures de "code du programme d'application"
en hexa, trouver les différences et en déduire quelle modification
correspond à quelle valeur de quel paramètre.
3) Modifier le software du module Freebus pour qu'il reconnaisse et
interpète ces modifications lors de la phase "programmation de
l'application" et les applique comme paramètres dans sont propre code.
Bref, ce n'est pas un boulot simple, et c'est très certainement
pourquoi les paramètres ne "marchent" pas encore sur le module Freebus.
> > je ne pense pas que ce module
> > réutilise le programme d'application du module Jung.
> Si, si, regarde bien la page où le module est décrit
> C'est marqué explicitement.
> ûûûh ?!? d'où ma remarque cfr plus haut
Et bien j'ai bien relu les 5 lignes sur la page du module "8 sorties
binaires" et ce que je comprends c'est que le software simule un
acteur Jung.
Ce que je comprends par la, c'est que pour le programmer via ETS, il
faut faire "comme si" c'était l'acteur Jung, donc utiliser ce
programme d'application dans ETS, mettre les adresses de groupe et le
flags et ensuite lancer la procédure de programmation :
- adresse physique
- programme d'applic
- paramètres
- table d'adresses de groupe
- flags
On peut supposer que ETS ne donnera pas de message d'erreur lors de la
programmation, donc le module Freebus va se comporter comme le module
Jung pour l'ETS, mais RIEN n'oblige le module Freebus à sauver la
totalité des données envoyées par l'ETS dans sa mémoire flash.
A mon avis, lors de la phase de programmation de l'application, le
module Freebus accepte les données (le code hexa de l'application)
envoyées par l'ETS mais il n'en fait rien et les jette à la poubelle (/
dev/null).
C'est probablement pour cela que les gens de Freebus disent que les
"paramètres" ne sont pas encore gérés par leur module ; en effet, ETS
applique les paramètres en modifiant certaines parties du code hexa de
l'application, donc pour décoder la valeur de ces paramètres, il y a
plusieurs étapes :
1) A l'aide d'un "sniffeur" de bus, enregistrer ce que l'ETS envoit
comme programme d'application dans chaque cas de figure, donc pour
chaque modification de l'un ou l'autre paramètre. Plus le nombre de
paramètres et de valeurs possible par paramètre augmente, plusce
travail est énorme.
2) Comparer toutes ces captures de "code du programme d'application"
en hexa, trouver les différences et en déduire quelle modification
correspond à quelle valeur de quel paramètre.
3) Modifier le software du module Freebus pour qu'il reconnaisse et
interpète ces modifications lors de la phase "programmation de
l'application" et les applique comme paramètres dans sont propre code.
Bref, ce n'est pas un boulot simple, et c'est très certainement
pourquoi les paramètres ne "marchent" pas encore sur le module Freebus.