12/12/2007, 00:47:51
@Stephane
> Je pensais avoir déjà supprimer le convertisseur 5V sur mon schéma...
> J'ai fait des modifications sur mon schéma mais je ne l'ai pas sur moi
> (je suis en déplacement), notamment sur les opto (erreurs sur les
> masses) et l'alimentation...
Ben, moi j'ai imprimé la version pdf qui se trouve parmis les fichier
sur ce forum, mais la date du fichier .sch n'est pas plus récente ...
n'aurais-tu pas oublié d'uploader la version modifiée ?
Pour le connecteur du BCU2, le lien est :
http://www.dehof.de/eib/pdfs/BIM_Schaltplan.pdf
Il y a tout ce qu'il nous faut sur la page 3.
Pour information, je suis actuellment en train de me documenter
serieusement sur l'usage du C30 sur le PIC24. J'ai commandé le livre
"Learning to fly the PIC24" ( http://www.flyingpic24.com ) et j'espère
avancer à grand pas dans son étude dès le semaine prochaine.
Bref, j'ai bien compris que le meilleur moyen de venir à bout du code
pour un stack EIb est de passer par du C, quitte à optimiser quelques
routines en les ré-écrivant en ASM ensuite.
@Jef2000
> Il serait peut-être intéressant de prévoir la place pour une
> seconde résitance en parallèle, comme ça si on n'a pas la
> valeur exacte (c'est une valeur un peu exotique), on peut la
> "fabriquer" en connectant 2 résistances de valeurs
> courantes en parallèle.
Très bonne remarque, 45.3 kOhms en 1 %, ça ne court pas les rues.
En passant, as-tu vu que le webmaster de Freebus.org parle de LinKNX
sur son site ?
Va voir en bas de la page http://www.freebus.org/index.php?option=...&Itemid=67
- - - - - - -
Maintenant, à propos de ma nouvelle idée ...
Cela fait un petit moment que je lis et relis le datasheet du TP-UART,
et franchement je trouve le produit un peu entre deux chaises ... soit
il en fait trop, soit pas assez, mais en tout cas il ne fait pas ce
que j'aimerais, c'est à dire supprimer totalement la contrainte de
réponse par le PIC dans un temps déterminé et assez court.
Pour 10 euros, j'aurais voulu mieux ...
Finalement, c'est le schéma de base du projet Freebus qui provoqué le
déclic :
L'idéal serait de disposer d'un super TP-UART aux fonctions étendues,
ci-après dénomé "TP-I2C-PIC".
Attention, ce qui suit plus bas constitue toujours un "périphérique de
communication", il faudra donc encore y connecter un composant maitre
"intelligent" quelconque dont la puissance est TRES variable (un
16F877 pourrait suffire pour une application simple mais on peut aussi
imaginer de connecter un PC surpuissant pour réaliser une méga-
supervision avec gestion de 60.000 objets EIB ...) ; en tout état de
cause, le PIC24H cité plus bas NE contiendra PAS d'application
spécifique au projet de chacun, mais bien un programme écrit une fois
pour toute.
A) Le hardware.
En gros, on prend le schéma du projet freebus ici :
http://www.freebus.org/index.php?option=...&Itemid=26
et on y ajoute :
- le deux pinoches pour recevoir un connecteur EIB.
- un PIC 24HJ12GP201 (18pins c'est juste ce qu'il faut, et il existe
aussi en DIP pour les essais).
- un SMBJ40CA pour tout protèger contre les surtensions (ça manque sur
le schema de Freebus).
- un connecteur 2 x 5 pins.
- un "gros" condensateur (de l'ordre de 100µF) pour garder un peu de
jus durant une courte coupure du bus EIB (ça manque aussi sur le
schema de Freebus).
- deux résistances de haute précision (30k et 2k, 1/4W, 0.1%) ainsi
qu'un condo de 0.1µF (ou plus gros ?), pour pouvoir mesurer la tension
réelle du bus via le port ADC du PIC.
- OPTIONNEL : une puce mémoire EEPROM ou, mieux, Flash, commandée en
SPI par le PIC et d'une taille généreuse, jusqu'à maximum 2Mbits.
Inutile dans la quasi totalité des cas (= jusqu'à 2048 adresses de
groupes).
Personellement, je remplacerais aussi la 1N4148 du schema Freebus par
une 1N4936, mais si ça marche bien comme ça ...
En gros, pour tout ceci, on reste dans une fourchette de 10 euros
(hors mémoire SPI optionelle), soit pas plus cher qu'une puce TP-UART.
B) Fonctionalités.
Le circuit repris du schéma Freebus fourni du 3,3V à partir du bus et
se charge de l'interface physique avec le bus.
Le PIC24H va gèrer tout le protocol bas niveau avec le bus EIB -
timing des bits, priorité, CSMA-CA, etc. (on peut s'inspirer du code
de Freebus, avec leur accord bien sur ...) et donc faire tout ce que
fait un TP-UART.
Les 2 résistances de haute précision constituent un diviseur de
tension pour permettre au PIC24H de mesurer la tension du bus
régulièrement. Le condo 0.1 µF compense la haute impédance de ce
diviseur pour le module ADC du PIC24H.
Au dela des fonctions du TP-UART, le PIC24H aura dans sa mémoire
l'adresse physique du participant ainsi que la totalité de la table
des adresses de groupe (si nécessaire dans la puce mémoire externe en
SPI, avec un maximum de 2Mbits, ce qui couvre les 65535 adresses de
groupe possibles). Ces deux informations ne devront plus être stockée
dans le "maitre" qui contiendra l'application proprement dite.
Comme le PIC24H dispose de ces info, il peut prendre entièrement en
charge :
En réception,
- le filtrage des télégrammes "utiles" pour le "maitre".
- le controle de la parité et du byte de checksum.
- la gestion de la réponse ACK, NACK, BUSY.
- la gestion des télégrammes répétés suite à un NACK ou un BUSY.
- la mise en buffer des télégrammes "utiles" non encore traités par le
"maitre".
En émission,
- la génération de la parité et du byte de checksum.
- la gestion des réponses ACK, NACK, BUSY.
- la répétition des télégrammes suite à un NACK ou un BUSY.
- la mise en buffer des télégrammes non encore envoyés ("maitre" trop
rapide ou bus encombré).
C) L'interface avec le maitre.
Physiquement, l'interface avec le maitre se limite à quelques lignes,
2 minimum.
Le circuit TP-I2C-PIC peut discuter avec son maitre via une liaison
I2C (si le TP-I2C-PIC est esclave I2C, il faut prévoir une 3ième ligne
afin de pouvoir générer une interruption sur le maitre/maitre I2C).
Il est aussi possible de faire une liaison asynchrone vers le maitre
avec l'UART, il suffit alors de modifier un tout petit bout du
software dans le PIC24H.
Il est possible que le circuit TP-I2C-PIC fournisse du 3,3V à sont
maitre, mais il faut bien calculer les consommations pour ne pas trop
charger le bus EIB.
Si une isolation galvanique est nécessaire, on peut la réaliser
facilement avec des optocoupleurs en mode UART, mais c'est nettement
moins simple en I2C (voir la page 15 du document
http://www.nxp.com/acrobat_download/othe..._82b96.pdf ).
D'un point de vue protocole, le maitre n'a pas besoin de garder la
table des adresses de groupe, donc le PIC24H va enlever cette info des
télégrammes reçu pour la remplacer par l'index dans la table des
liaisons aux objets avant de les mettre en buffer pour le maitre ; le
traitement inverse est vrai aussi en transmission de télégramme vers
le bus.
Vu que le PIC24H peut mesurer la tension du bus EIB, il est possible
de lui faire envoyer un signal du type "EIB bus power failure" vers le
maitre si nécessaire.
Il est peut-être aussi possible de déléguer au PIC24H du circuit TP-
I2C-PIC la gestion des sessions dans le cadre des communications
"connection-oriented" (re-progrmmation des tables EIB ou de
l'application, etc. ) mais je n'ai pas encore une assez bonne maitrise
de cette partie du stack EIB pour me faire une idée.
Le design du hardware est quasi fini, vu le circuit Freebus existant
et ne conporterait que des pièces "classiques".
Le software serait un mix du code Freebus et de celui pour notre
platine de développement.
Un fois ce module développé (hard + soft), écrire la partie haute du
stack EIB et des applications (= le soft du "maitre") deviendrait un
jeu d'enfant en C.
Voila l'idée. Qu'en pensez-vous ?
> Je pensais avoir déjà supprimer le convertisseur 5V sur mon schéma...
> J'ai fait des modifications sur mon schéma mais je ne l'ai pas sur moi
> (je suis en déplacement), notamment sur les opto (erreurs sur les
> masses) et l'alimentation...
Ben, moi j'ai imprimé la version pdf qui se trouve parmis les fichier
sur ce forum, mais la date du fichier .sch n'est pas plus récente ...
n'aurais-tu pas oublié d'uploader la version modifiée ?
Pour le connecteur du BCU2, le lien est :
http://www.dehof.de/eib/pdfs/BIM_Schaltplan.pdf
Il y a tout ce qu'il nous faut sur la page 3.
Pour information, je suis actuellment en train de me documenter
serieusement sur l'usage du C30 sur le PIC24. J'ai commandé le livre
"Learning to fly the PIC24" ( http://www.flyingpic24.com ) et j'espère
avancer à grand pas dans son étude dès le semaine prochaine.
Bref, j'ai bien compris que le meilleur moyen de venir à bout du code
pour un stack EIb est de passer par du C, quitte à optimiser quelques
routines en les ré-écrivant en ASM ensuite.
@Jef2000
> Il serait peut-être intéressant de prévoir la place pour une
> seconde résitance en parallèle, comme ça si on n'a pas la
> valeur exacte (c'est une valeur un peu exotique), on peut la
> "fabriquer" en connectant 2 résistances de valeurs
> courantes en parallèle.
Très bonne remarque, 45.3 kOhms en 1 %, ça ne court pas les rues.
En passant, as-tu vu que le webmaster de Freebus.org parle de LinKNX
sur son site ?
Va voir en bas de la page http://www.freebus.org/index.php?option=...&Itemid=67
- - - - - - -
Maintenant, à propos de ma nouvelle idée ...
Cela fait un petit moment que je lis et relis le datasheet du TP-UART,
et franchement je trouve le produit un peu entre deux chaises ... soit
il en fait trop, soit pas assez, mais en tout cas il ne fait pas ce
que j'aimerais, c'est à dire supprimer totalement la contrainte de
réponse par le PIC dans un temps déterminé et assez court.
Pour 10 euros, j'aurais voulu mieux ...
Finalement, c'est le schéma de base du projet Freebus qui provoqué le
déclic :
L'idéal serait de disposer d'un super TP-UART aux fonctions étendues,
ci-après dénomé "TP-I2C-PIC".
Attention, ce qui suit plus bas constitue toujours un "périphérique de
communication", il faudra donc encore y connecter un composant maitre
"intelligent" quelconque dont la puissance est TRES variable (un
16F877 pourrait suffire pour une application simple mais on peut aussi
imaginer de connecter un PC surpuissant pour réaliser une méga-
supervision avec gestion de 60.000 objets EIB ...) ; en tout état de
cause, le PIC24H cité plus bas NE contiendra PAS d'application
spécifique au projet de chacun, mais bien un programme écrit une fois
pour toute.
A) Le hardware.
En gros, on prend le schéma du projet freebus ici :
http://www.freebus.org/index.php?option=...&Itemid=26
et on y ajoute :
- le deux pinoches pour recevoir un connecteur EIB.
- un PIC 24HJ12GP201 (18pins c'est juste ce qu'il faut, et il existe
aussi en DIP pour les essais).
- un SMBJ40CA pour tout protèger contre les surtensions (ça manque sur
le schema de Freebus).
- un connecteur 2 x 5 pins.
- un "gros" condensateur (de l'ordre de 100µF) pour garder un peu de
jus durant une courte coupure du bus EIB (ça manque aussi sur le
schema de Freebus).
- deux résistances de haute précision (30k et 2k, 1/4W, 0.1%) ainsi
qu'un condo de 0.1µF (ou plus gros ?), pour pouvoir mesurer la tension
réelle du bus via le port ADC du PIC.
- OPTIONNEL : une puce mémoire EEPROM ou, mieux, Flash, commandée en
SPI par le PIC et d'une taille généreuse, jusqu'à maximum 2Mbits.
Inutile dans la quasi totalité des cas (= jusqu'à 2048 adresses de
groupes).
Personellement, je remplacerais aussi la 1N4148 du schema Freebus par
une 1N4936, mais si ça marche bien comme ça ...
En gros, pour tout ceci, on reste dans une fourchette de 10 euros
(hors mémoire SPI optionelle), soit pas plus cher qu'une puce TP-UART.
B) Fonctionalités.
Le circuit repris du schéma Freebus fourni du 3,3V à partir du bus et
se charge de l'interface physique avec le bus.
Le PIC24H va gèrer tout le protocol bas niveau avec le bus EIB -
timing des bits, priorité, CSMA-CA, etc. (on peut s'inspirer du code
de Freebus, avec leur accord bien sur ...) et donc faire tout ce que
fait un TP-UART.
Les 2 résistances de haute précision constituent un diviseur de
tension pour permettre au PIC24H de mesurer la tension du bus
régulièrement. Le condo 0.1 µF compense la haute impédance de ce
diviseur pour le module ADC du PIC24H.
Au dela des fonctions du TP-UART, le PIC24H aura dans sa mémoire
l'adresse physique du participant ainsi que la totalité de la table
des adresses de groupe (si nécessaire dans la puce mémoire externe en
SPI, avec un maximum de 2Mbits, ce qui couvre les 65535 adresses de
groupe possibles). Ces deux informations ne devront plus être stockée
dans le "maitre" qui contiendra l'application proprement dite.
Comme le PIC24H dispose de ces info, il peut prendre entièrement en
charge :
En réception,
- le filtrage des télégrammes "utiles" pour le "maitre".
- le controle de la parité et du byte de checksum.
- la gestion de la réponse ACK, NACK, BUSY.
- la gestion des télégrammes répétés suite à un NACK ou un BUSY.
- la mise en buffer des télégrammes "utiles" non encore traités par le
"maitre".
En émission,
- la génération de la parité et du byte de checksum.
- la gestion des réponses ACK, NACK, BUSY.
- la répétition des télégrammes suite à un NACK ou un BUSY.
- la mise en buffer des télégrammes non encore envoyés ("maitre" trop
rapide ou bus encombré).
C) L'interface avec le maitre.
Physiquement, l'interface avec le maitre se limite à quelques lignes,
2 minimum.
Le circuit TP-I2C-PIC peut discuter avec son maitre via une liaison
I2C (si le TP-I2C-PIC est esclave I2C, il faut prévoir une 3ième ligne
afin de pouvoir générer une interruption sur le maitre/maitre I2C).
Il est aussi possible de faire une liaison asynchrone vers le maitre
avec l'UART, il suffit alors de modifier un tout petit bout du
software dans le PIC24H.
Il est possible que le circuit TP-I2C-PIC fournisse du 3,3V à sont
maitre, mais il faut bien calculer les consommations pour ne pas trop
charger le bus EIB.
Si une isolation galvanique est nécessaire, on peut la réaliser
facilement avec des optocoupleurs en mode UART, mais c'est nettement
moins simple en I2C (voir la page 15 du document
http://www.nxp.com/acrobat_download/othe..._82b96.pdf ).
D'un point de vue protocole, le maitre n'a pas besoin de garder la
table des adresses de groupe, donc le PIC24H va enlever cette info des
télégrammes reçu pour la remplacer par l'index dans la table des
liaisons aux objets avant de les mettre en buffer pour le maitre ; le
traitement inverse est vrai aussi en transmission de télégramme vers
le bus.
Vu que le PIC24H peut mesurer la tension du bus EIB, il est possible
de lui faire envoyer un signal du type "EIB bus power failure" vers le
maitre si nécessaire.
Il est peut-être aussi possible de déléguer au PIC24H du circuit TP-
I2C-PIC la gestion des sessions dans le cadre des communications
"connection-oriented" (re-progrmmation des tables EIB ou de
l'application, etc. ) mais je n'ai pas encore une assez bonne maitrise
de cette partie du stack EIB pour me faire une idée.
Le design du hardware est quasi fini, vu le circuit Freebus existant
et ne conporterait que des pièces "classiques".
Le software serait un mix du code Freebus et de celui pour notre
platine de développement.
Un fois ce module développé (hard + soft), écrire la partie haute du
stack EIB et des applications (= le soft du "maitre") deviendrait un
jeu d'enfant en C.
Voila l'idée. Qu'en pensez-vous ?