12/12/2007, 09:15:36
je suis d'accord avec toi le TP-UART pourrait en faire un peu plus!
Le problème c'est que je vois plus trop l'intérêt de développer un
autre BIM. On l'a déjà sur étagère et il marche très bien!
On va réinventé quelque chose qui existe déjà...
Pourquoi l'on pourrait pas ajouter du code perso sur le PIC 24?
Le projet freebus est intéressant mais mon idée à long terme est de
pouvoir certifié KNX du matériel open-source, donc je voudrais me
baser pour l'instant sur du matériel certifié. Cela implique le TP-
UART.
Je trouve cependant l'idée super intéressante, en effet cela permettra
de réaliser un système complètement open-source, sans dépendre d'aucun
constructeur KNX.
Mais comment va réagir l'association KNX et les fabriquants?
Qu'en penses tu?
On 12 déc, 00:47, keldo <kelderm...@ibelgique.com> wrote:
> @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 pagehttp://www.freebus.org/index.php?option=com_content&task=view&id=50&I...
>
> - - - - - - -
>
> 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=com_content&task=view&id=13&I...
> 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 documenthttp://www.nxp.com/acrobat_download/other/mcu/notes_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 ?
Le problème c'est que je vois plus trop l'intérêt de développer un
autre BIM. On l'a déjà sur étagère et il marche très bien!
On va réinventé quelque chose qui existe déjà...
Pourquoi l'on pourrait pas ajouter du code perso sur le PIC 24?
Le projet freebus est intéressant mais mon idée à long terme est de
pouvoir certifié KNX du matériel open-source, donc je voudrais me
baser pour l'instant sur du matériel certifié. Cela implique le TP-
UART.
Je trouve cependant l'idée super intéressante, en effet cela permettra
de réaliser un système complètement open-source, sans dépendre d'aucun
constructeur KNX.
Mais comment va réagir l'association KNX et les fabriquants?
Qu'en penses tu?
On 12 déc, 00:47, keldo <kelderm...@ibelgique.com> wrote:
> @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 pagehttp://www.freebus.org/index.php?option=com_content&task=view&id=50&I...
>
> - - - - - - -
>
> 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=com_content&task=view&id=13&I...
> 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 documenthttp://www.nxp.com/acrobat_download/other/mcu/notes_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 ?