14/08/2007, 16:40:57
On 14 août, 08:33, "Ludovic lemarinel" <l.lemari...@gmail.com> wrote:
> A propos du Stack EIB : ne consiste-t-il juste pas à ecouter le BUS, et dès
> qu'une trame est pour soi, la traiter puis envoyer l'accué de reception
> (pour un actionneur par exemple) ?
Bonjour.
En gros et pour les fonctions de base, oui, tu viens de décrire la
fonction de réception, mais il faut bien entendu aussi implémenter :
- Les fonctions d'émission + réémission en cas de accusé de réception
négatif.
- La gestion en mémoire des valeurs d'objets de communication avec
leurs flags (read, write, transmit, update, read-on-init).
- La programmation de l'adresse physique par le bus (avec gestion du
bouton de programmation).
Avec ceci, les besoins de base sont couverts.
Maintenant, pour écrire un stack EIB complet tel que celui dans un
BCU2, il manque encore beaucoup de fonctionnalités, dont, en vrac :
- Sauvegarde éventuelle de la valeur des objets dans une EEPROM en cas
de chute de tension sur le bus.
- Programmation de l'application via le bus.
- Programmation de la table de groupes via le bus.
- Programmation de la table des flags des objets via le bus.
- Programmation des paramètres de l'application via le bus.
- Gestion de la communication avec session et des "clefs de sécurité".
- Lecture/écriture en mémoire du PIC, acces variable selon le niveau
de sécurité.
- Réponse aux requètes d'information (mask version, vendor ID, serial
number, type PEI connecté, application ID, tension du bus, etc.).
Mon projet actuel est de développer la première partie sur un PIC
16F877A en utilisant une puce TP-UART comme interface avec le bus.
> A propos du Stack EIB : ne consiste-t-il juste pas à ecouter le BUS, et dès
> qu'une trame est pour soi, la traiter puis envoyer l'accué de reception
> (pour un actionneur par exemple) ?
Bonjour.
En gros et pour les fonctions de base, oui, tu viens de décrire la
fonction de réception, mais il faut bien entendu aussi implémenter :
- Les fonctions d'émission + réémission en cas de accusé de réception
négatif.
- La gestion en mémoire des valeurs d'objets de communication avec
leurs flags (read, write, transmit, update, read-on-init).
- La programmation de l'adresse physique par le bus (avec gestion du
bouton de programmation).
Avec ceci, les besoins de base sont couverts.
Maintenant, pour écrire un stack EIB complet tel que celui dans un
BCU2, il manque encore beaucoup de fonctionnalités, dont, en vrac :
- Sauvegarde éventuelle de la valeur des objets dans une EEPROM en cas
de chute de tension sur le bus.
- Programmation de l'application via le bus.
- Programmation de la table de groupes via le bus.
- Programmation de la table des flags des objets via le bus.
- Programmation des paramètres de l'application via le bus.
- Gestion de la communication avec session et des "clefs de sécurité".
- Lecture/écriture en mémoire du PIC, acces variable selon le niveau
de sécurité.
- Réponse aux requètes d'information (mask version, vendor ID, serial
number, type PEI connecté, application ID, tension du bus, etc.).
Mon projet actuel est de développer la première partie sur un PIC
16F877A en utilisant une puce TP-UART comme interface avec le bus.