20/11/2007, 08:31:18
On 19 nov, 22:49, alain <alain.houtek...@laposte.net> wrote:
> Bien vu pour la vitesse et la parité !
Et deux lanternes, deux ! ;-)
> Me reste plus qu'à comprendre comment envoyer une commande vers un
> groupe, et, surtout, de recevoir tout le trafic du bus (donc activer
> la fonction bus monitor).
Selon mes maigres connaissances FT1.2, et si j'ai bien compris, il y a
trois modes de fonctionnement distincts des BCU2 en FT1.2.
1) Le bus monitor : on reçoit tout mais il est impossible d'envoyer.
2) Le mode "normal", dans lequel il faut configurer une ou plusieures
adresses de groupe pour chaque objet disponible du BCU2 et le
protocole FT1.2 communique alors sur le port série les mises à jours
des objets. Dans ce mode, le BCU2 fonctionne comme pour n'importe
quelle application classique (un bouton poussoir par ex.), donc il
possède et gère en mémoire une table d'objets, une table
d'associations objets/adresses, une table d'adresse de groupe, une
adresse physique, etc. ; la seule différence est qu'aucune application
spécifique ne tourne sur le BCU2, il faut la faire tourner sur un CPU
externe relié par la liaison série. Dans ce mode il est possible de
demander au BCU2 d'envoyer vers le bus la valeur d'un objet mais pas
de choisir via soft vers quelle adresse de groupe est dirigé le
télégramme (c'est fixé par la table d'association du BCU2).
3) Le mode "transciever". Dans ce mode, le BCU2 ne garde en mémoire
aucune information, c'est donc le CPU externe relié par la liaison
série qui doit tout faire : connaitre son adresse physique, faire le
tri de tous les télégrammes reçus depuis le bus, calculer le checksum
et, le cas échéant, répondre par ACK, NACK ou BUSY, ce CPU devra aussi
gèrer toutes les tables d'adresse de groupe, associations, flags des
objets, etc. Dans ce mode, le CPU reçoit et envoit des télégrammes
encapsulé dans une trame FT1.2 ; c'est évidemment le mode le plus
intéressant pour faire une visu sur PC mais il y a pas mal de boulot à
prévoir pour l'écriture du soft de gestion du protocole.
> Bien vu pour la vitesse et la parité !
Et deux lanternes, deux ! ;-)
> Me reste plus qu'à comprendre comment envoyer une commande vers un
> groupe, et, surtout, de recevoir tout le trafic du bus (donc activer
> la fonction bus monitor).
Selon mes maigres connaissances FT1.2, et si j'ai bien compris, il y a
trois modes de fonctionnement distincts des BCU2 en FT1.2.
1) Le bus monitor : on reçoit tout mais il est impossible d'envoyer.
2) Le mode "normal", dans lequel il faut configurer une ou plusieures
adresses de groupe pour chaque objet disponible du BCU2 et le
protocole FT1.2 communique alors sur le port série les mises à jours
des objets. Dans ce mode, le BCU2 fonctionne comme pour n'importe
quelle application classique (un bouton poussoir par ex.), donc il
possède et gère en mémoire une table d'objets, une table
d'associations objets/adresses, une table d'adresse de groupe, une
adresse physique, etc. ; la seule différence est qu'aucune application
spécifique ne tourne sur le BCU2, il faut la faire tourner sur un CPU
externe relié par la liaison série. Dans ce mode il est possible de
demander au BCU2 d'envoyer vers le bus la valeur d'un objet mais pas
de choisir via soft vers quelle adresse de groupe est dirigé le
télégramme (c'est fixé par la table d'association du BCU2).
3) Le mode "transciever". Dans ce mode, le BCU2 ne garde en mémoire
aucune information, c'est donc le CPU externe relié par la liaison
série qui doit tout faire : connaitre son adresse physique, faire le
tri de tous les télégrammes reçus depuis le bus, calculer le checksum
et, le cas échéant, répondre par ACK, NACK ou BUSY, ce CPU devra aussi
gèrer toutes les tables d'adresse de groupe, associations, flags des
objets, etc. Dans ce mode, le CPU reçoit et envoit des télégrammes
encapsulé dans une trame FT1.2 ; c'est évidemment le mode le plus
intéressant pour faire une visu sur PC mais il y a pas mal de boulot à
prévoir pour l'écriture du soft de gestion du protocole.