09/08/2007, 14:42:23
On 9 août, 10:05, "stephane.herr...@gmail.com"
<stephane.herr...@gmail.com> wrote:
> Je pense que cette idée est très intéressante parce qu'elle permettra
> de développer un accès au bus "amateur"!
Oui, c'est une première étape importante pour réellement ouvrir le
système EIB aux hobbyistes que nous sommes.
La deuxième étape sera de décoder le format des
fichiers .vd2/.vd3/.vd4 afin de pouvoir les utiliser dans un futur
clone d'ETS open-source, ou bien de créer nos propres fichiers .vd*
pour nos interfaces faites maisons et pouvoir les configurer dans ETS.
Cette étape sera sans doute plus difficile si l'EIBA ne nous aide pas
mais on verra bien, je suis déjà curieux de voir leur réaction face à
l'apparition de petites interface faite maison.
> Pour l'instant, je connais assez bien le PIC 16F876. Je le programme
> en C avec le compileur CCS mais celui-ci n'est pas gratuit...
> Sur quel outil tu te bases pour développer sur les pics?
Entre un 876 et un 877, la transition est plus que facile, pour ma
part, j'ai préfèré prendre le modèle avec un petit peu plus de mémoire
car comme je n'ai pas beaucoup d'expérience je vais sans doute
gaspiller de la mémoire dans mes premières réalisations.
Je ne suis pas un grand copain du C que je trouve assez peu lisible,
alors, à tout prendre, je me suis lancé directement en assembleur.
J'utilise "bêtement" MPLAB IDE et l'assembleur inclus, le tout étant
gratuit - merci Microchip.
Je ne suis encore qu'un grand débutant avec les microcontroleurs, mais
avec les cours de Bigonoff (gratuits sur le web) cela me semble
vraiment facile à utiliser.
> J'utilise aussi un bootloader.
Oui, pourquoi pas, c'est sans doute très pratique, mais pour l'instant
je suis très content de la facilité de (re-)programmation des PIC in-
situ permise par l'ICD2 : on retire le montage du bus, on enlève 5
petits jumpers, on branche les 5 fils de l'ICD2 sur les pinoches des
jumpers et hop l'affaire est faite.
A terme, j'aimerais aussi pouvoir implémenter la programmation des
tables et de l'application via le bus EIB, à ce moment là le
bootloader ne sera plus très utile, mais dans un premier temps ce sera
sans doute une bonne idée d'utiliser un bootloader pour tous ceux qui
utilisent un programmateur avec socket ZIF, ce qui oblige de retirer
le PIC du montage à chaque fois.
> Si j'ai bien compris ton projet est de développer une interface au bus
> EIB en utilisant le protocole EIB et pas le protocole FT1.2? Je pense
> que c'est une bonne chose malgré les remarques comme quoi c'est un
> projet trop difficile...
Oui et non, cela dépend comment on relie le PIC au bus EIB.
Si on utilise un transceiver du type FZE 1065/1066 comme sur les bon
vieux BCU et BIM 11x, ou si l'on construit soit-même son transceiver
en composants discrets, le PIC doit alors tenir compte de nombreuses
contraintes temporelles afin de respecter toutes les règles de
priorité d'acces au bus et la résolution des conficts. Au total, cela
donne une gestion des interruptions et des timers très complexe et je
ne suis pas sur que la famille des PIC16F soit bien équipée pour cette
tâche (il y trop peu de timers disponibles et un seul niveau de
priorité dans les interruptions), pour ce genre de projet je prendrais
plutôt un PIC24 ou un dsPIC, mais c'est de tout façon trop complexe
pour moi actuellement.
Par contre, moi je pense utiliser un TP-UART comme interface avec le
bus, ce qui simplifie beaucoup les choses et reduit grandement les
contraintes temporelles. Je ne connais pas bien le protocol FT1.2 mais
à mon avis interfacer un PIC avec un TP-UART ou avec un BCU en mode
FT1.2 représente quasiment le même travail.
Je pense que du point de vue prix, l'option BCU est plus cher mais ce
n'est pas certain vu les quelques composants qu'il faut ajouter autour
de la puce TP-UART.
J'ai acheté 8 TP-UART chez Opternus mais je ne suis pas encore assez
loin dans mon projet pour commencer à souder quoi que ce soit pour
l'instant.
Dans un premier temps, je vais tester les réponses de mon PIC en
simulant le TP-UART (et donc le BUS EIB) avec le port série de mon PC,
ensuite je penserai au hardware.
<stephane.herr...@gmail.com> wrote:
> Je pense que cette idée est très intéressante parce qu'elle permettra
> de développer un accès au bus "amateur"!
Oui, c'est une première étape importante pour réellement ouvrir le
système EIB aux hobbyistes que nous sommes.
La deuxième étape sera de décoder le format des
fichiers .vd2/.vd3/.vd4 afin de pouvoir les utiliser dans un futur
clone d'ETS open-source, ou bien de créer nos propres fichiers .vd*
pour nos interfaces faites maisons et pouvoir les configurer dans ETS.
Cette étape sera sans doute plus difficile si l'EIBA ne nous aide pas
mais on verra bien, je suis déjà curieux de voir leur réaction face à
l'apparition de petites interface faite maison.
> Pour l'instant, je connais assez bien le PIC 16F876. Je le programme
> en C avec le compileur CCS mais celui-ci n'est pas gratuit...
> Sur quel outil tu te bases pour développer sur les pics?
Entre un 876 et un 877, la transition est plus que facile, pour ma
part, j'ai préfèré prendre le modèle avec un petit peu plus de mémoire
car comme je n'ai pas beaucoup d'expérience je vais sans doute
gaspiller de la mémoire dans mes premières réalisations.
Je ne suis pas un grand copain du C que je trouve assez peu lisible,
alors, à tout prendre, je me suis lancé directement en assembleur.
J'utilise "bêtement" MPLAB IDE et l'assembleur inclus, le tout étant
gratuit - merci Microchip.
Je ne suis encore qu'un grand débutant avec les microcontroleurs, mais
avec les cours de Bigonoff (gratuits sur le web) cela me semble
vraiment facile à utiliser.
> J'utilise aussi un bootloader.
Oui, pourquoi pas, c'est sans doute très pratique, mais pour l'instant
je suis très content de la facilité de (re-)programmation des PIC in-
situ permise par l'ICD2 : on retire le montage du bus, on enlève 5
petits jumpers, on branche les 5 fils de l'ICD2 sur les pinoches des
jumpers et hop l'affaire est faite.
A terme, j'aimerais aussi pouvoir implémenter la programmation des
tables et de l'application via le bus EIB, à ce moment là le
bootloader ne sera plus très utile, mais dans un premier temps ce sera
sans doute une bonne idée d'utiliser un bootloader pour tous ceux qui
utilisent un programmateur avec socket ZIF, ce qui oblige de retirer
le PIC du montage à chaque fois.
> Si j'ai bien compris ton projet est de développer une interface au bus
> EIB en utilisant le protocole EIB et pas le protocole FT1.2? Je pense
> que c'est une bonne chose malgré les remarques comme quoi c'est un
> projet trop difficile...
Oui et non, cela dépend comment on relie le PIC au bus EIB.
Si on utilise un transceiver du type FZE 1065/1066 comme sur les bon
vieux BCU et BIM 11x, ou si l'on construit soit-même son transceiver
en composants discrets, le PIC doit alors tenir compte de nombreuses
contraintes temporelles afin de respecter toutes les règles de
priorité d'acces au bus et la résolution des conficts. Au total, cela
donne une gestion des interruptions et des timers très complexe et je
ne suis pas sur que la famille des PIC16F soit bien équipée pour cette
tâche (il y trop peu de timers disponibles et un seul niveau de
priorité dans les interruptions), pour ce genre de projet je prendrais
plutôt un PIC24 ou un dsPIC, mais c'est de tout façon trop complexe
pour moi actuellement.
Par contre, moi je pense utiliser un TP-UART comme interface avec le
bus, ce qui simplifie beaucoup les choses et reduit grandement les
contraintes temporelles. Je ne connais pas bien le protocol FT1.2 mais
à mon avis interfacer un PIC avec un TP-UART ou avec un BCU en mode
FT1.2 représente quasiment le même travail.
Je pense que du point de vue prix, l'option BCU est plus cher mais ce
n'est pas certain vu les quelques composants qu'il faut ajouter autour
de la puce TP-UART.
J'ai acheté 8 TP-UART chez Opternus mais je ne suis pas encore assez
loin dans mon projet pour commencer à souder quoi que ce soit pour
l'instant.
Dans un premier temps, je vais tester les réponses de mon PIC en
simulant le TP-UART (et donc le BUS EIB) avec le port série de mon PC,
ensuite je penserai au hardware.