20/05/2009, 07:55:17
Je suis d'accord pour les modules tout fait...BCU, BCU2, etc....
Cette solution permet aux industriels de développer rapidement un
produit KNX.
Mais pour des raisons de cout, cette solution trop onéreuse pour des
grosses quantités d'industrialisation va impliquer directement sur le
prix des produits KNX. c'est pourquoi les modules KNX sont aussi cher.
La solution TP_UART permet de réduire les couts. En effet, pour des
grandes séries, il est plus intéressant de développer soit même la
stack KNX (ce que je fais, et même si ca prends un certain temps, ce
n'est pas ce qu'il y a de plus compliqué vu que le protocole est très
bien spécifié).
Mais en effet, l'utilisation du TP_UART n'est que transitoire. ce qui
permet de sortir la nouvelle gamme produit plus rapidement et être
certifié plus facilement également. Dans un second step, vu que nous
produirons en grande série, nous nous passerons du TP_UART, en
incluant un transceiver "fait maison", et en rajoutant la couche
logiciel pour les couches 1 et 2. il y aura en effet un léger gain sur
le prix (plus en matière première de fabrication que sur le prix final
client).
Pour ton projet, le TP_UART n'est pas aussi sorcié que ca à souder,
c'est un gros CMS tout de même. Mais en effet, tu gagneras du temps à
acheter une platine de test tout fait.
Pour la programmation par ETS....il faut avoir en effet les outils de
développement de base de donnée ETS...et ca, c'est un développement
complément à part et très mal documenté. donc en effet pour un produit
de démonstration universitaire, vaut mieux oublier. je trouve plus
facile à développer la stack EIB que la base de donné+plugin pour ETS.
La solution, Keldo te la donné, crée un projet ETS avec des produits
commercialisés (simple module d'entrées sorties par exemple), créé des
liens entre ces produits. Branche ton produit sur le bus, et fait toi
passer pour ces produits en interceptant et envoyant les trames avec
les adresses des groupes que tu as créé via ETS.
Choisir cette solution, te permet d'avoir un produit pas complètement
finalisé mais fonctionnel pour une démonstration. pas la peine de
gérer toute la stack KNX...donc très rapide a mettre en place si tu es
a l'aise avec les microcontroleurs.
Voila j'espère que toutes ces informations te serviront. Et lorsque tu
seras en train de monter ta stack EIB, n'hésite pas
On 20 mai, 02:15, keldo <kelderm...@ibelgique.com> wrote:
> > De nombreuse entreprise utilisent les BCU toute faite,
> > Ces modules utilisent un microcontroleur de type motorola ainsi que le
> > fameux FZE -> c'est module utilise un mapping mémoire (RAM et EEPROM)
> > figé (mask version) connu d'ETS...(e.g. ETS sait ou aller écrire les
> > tables d'adresse, d'association, etc...)
>
> Ceci est vrai uniquement pour les BCU1, c'est à dire la très ancienne
> première génération qui est de moins en moins utilisée.
>
> A partir du BCU2, une autre technique de programmation, dite des "EIB
> objects", doit être utilisée car une bonne partie des modules
> estampillés "BCU2" aujourd'hui sur le marché n'utilisent plus un CPU
> Motorola mais bien un NEC 78F053x, cet autre CPU a une architecture
> mémoire complètement différente et utilise une flash à la place d'une
> eeprom.
> De plus, à partir du stack "BCU2", un système d'autorisation de
> lecture et/ou d'écriture des "EIB objects" et des zones mémoires est
> mis en place à l'aide de mots de passe ("keys" & "access levels").
> Par contre, au niveau logiciel, le stack EIB d'un BCU2 sur motorola
> propose le même API que celui sur NEC, ce qui peut porter à
> confusion ...
>
> Pour une comparaison de technologie, un petit tour sur le site
> d'Opternus (zone "Composants", "Siemens", " KNX Bus Interface Module")
> est instructif.
>
> La génération "BCU1" est basée sur des modules du type BIM M111 et
> M115, avec un CPU Motorola 68HC05.
>
> La génération "BCU2 Motorola" est basée sur des modules du type BIM
> M113, avec un CPU Motorola 68HC05 plus rapide et plus généreux en
> mémoire.
>
> Les anciens participants EIB "haut de gamme" présentant beaucoup
> d'objets de communication sur le bus, comme les écrans LCD monochrome
> de type MT701 chez Merten et Jung, utilisent généralement un module
> BIM M112 avec un stack proche de la version "BCU2" appelé "version
> 70.x" et un processeur Motorola 68HC11 plus puissant que les 68HC05.
>
> Les participant de la nouvelle génération "Nec" utilisent toujours un
> stack qui se comporte comme un "BCU2" mais sont basé sur les nouveaux
> (environ 2 ans ?) modules de la série BIM M130 --> M135 et le code de
> leur stack est certainement issu d'un nouveau développement
>
> Pour compliquer le tout, il existe aujourd'hui plusieurs stacks EIB de
> type "BCU2" disponibles - moyennant finances - pour d'autres CPU comme
> le Texas Instruments MSP43x, par exemple celui de chez Tapko
> (http://www.tapko.de).
>
> Au niveau programmation, à l'exception du BCU-SDK de l'université de
> Vienne, le code applicatif à charger dans les modules basés sur un CPU
> Motorola est normalement écrit directement en assembleur, vu les
> ressources TRES limitées en mémoire des CPU Motorola 6805.
> Une particularité de ces CPU Motorola est de pouvoir exécuter du code
> depuis la mémoire EEPROM.
> Sur ces CPU, le stack EIB est en PROM (donc non effaçable), le
> programme uploadé via ETS ainsi que toute la config se retrouve dans
> l'EEPROM, c'est pourquoi il ne peut être très long ...
>
> Le kit de programmation "officiel" des modules BIM M13x basés sur CPU
> NEC est lui proposé pour le langage C.
>
> Le gros avantage du TP-UART pour les industriels, c'est qu'il est déjà
> certifié EIB-KNX pour les couches 1 et 2, ce qui simplifie et rend
> moins couteux les processus de développement et de certification des
> nouveaux produits.
> C'est un choix logique tant que les modules EIB ne seront pas produit
> en très grande série.
> Le jour ou il y aura une centaine de modules EIB dans chaque maison
> d'Europe, l'économie d'échelle aura joué et les industriels auront
> préféré payer un peu plus durant la phase de développement d'un
> nouveau module EIB de manière à pouvoir remplacer un TP-UART devenu
> trop couteux par rapport à un software plus élaboré et une poignée de
> composants discrets simples et quasiment gratuits quand achetés par
> millions.
>
> Si jamais tu penses passer commande de quelques TP-UART chez Opternus,
> je te conseille de réfléchir sérieusement à commander plutôt la
> platine de test toute faite de Siemens, aussi en vente sur le site ;
> c'est trois fois plus cher que le TP-UART seul, mais tu ne dois pas te
> taper la soudure des fines pattes du CMS (le TP-UART n'existe pas en
> format DIP ...) ni chercher une équivalence à la double Zenner
> "Transil/Transorb/..." anti-surtension ; finalement, avec le quartz,
> les condos, les diodes non-classiques et le reste, je pense pas que la
> platine de test revienne beaucoup plus cher ... et c'est beaucoup plus
> simple, sans parler du risque de griller la puce durant la soudure.
>
> Concernant l'écriture d'un petit soft qui "parle" sur le bus via un TP-
> UART, c'est effectivement possible d'écrire quelque chose de
> fonctionnel en quelques heures, mais écrire tout un stack pour imiter
> le comportement d'un BCU est beaucoup moins simple ...
> Dans la zone téléchargement de ce forum, tu trouveras un fichier
> archive qui s'appelle "Stack EIB pour PIC24 ..." ou un truc du style,
> c'est totalement incomplet et je n'ai pas pris le temps d'y travailler
> depuis longtemps mais tu pourras sans doute déjà réutiliser les
> structures de données (l'entête du télégramme notamment) qui s'y
> trouvent.
>
> Concernant le support "officiel" de Konnex via web, sachant que le
> siège de l'association est à Bruxelles, il vaut sans doute mieux
> passer par le site officiel principal plutôt que par le site Suisse.
> J'ai déjà contacté, par e-mail, le siège pour un problème technique
> (je cherchais un fichier de base de donné ".vd1" devenu introuvable
> sur le web, BOSCH ayant arrête la vente - et le support !!! - de ses
> modules EIB depuis longtemps) et j'ai été très satisfait de leur
> réponse, même s'il a fallut quelques jours pour l'obtenir : ils ont
> finalement reconstruit le fichier pour moi à partir de leurs
> archives ...
> Il y a aussi un développeur de chez Konnex appelé Steven (je
> crois ...) qui passait sur ce forum et répondait de temps en temps
> mais je n'ai plus vu de message de sa part depuis un an ... peut-être
> pourrais-tu le retrouver parmi les anciennes discussions et lui
> envoyer un message perso ? De mémoire, il est intervenu - entre autre
> - dans une discussion à propos de la possibilité de changer l'ID
> "fabricant/constructeur" d'un BCU.
>
> Il te reste aussi les forums allemands, avec des gens plus calés que
> les francophones, encore faut-il pouvoir lire et écrire en allemand ou
> en anglais.
>
> Le site de l'université de Vienne (http://www.auto.tuwien.ac.at) propose
> aussi pas mal d'infos.
>
> Du point de vue livres techniques, le seul qui ne soit pas en allemand
> est "EIB - Installation bus système" (par Sauter, Dietrich, Kastner)
> aux éditions "Publicis" : il est en anglais, propose pas mal
> d'informations intéressantes mais il n'est pas un modèle de clarté ...
> les informations ne sont pas toujours bien organisées.
Cette solution permet aux industriels de développer rapidement un
produit KNX.
Mais pour des raisons de cout, cette solution trop onéreuse pour des
grosses quantités d'industrialisation va impliquer directement sur le
prix des produits KNX. c'est pourquoi les modules KNX sont aussi cher.
La solution TP_UART permet de réduire les couts. En effet, pour des
grandes séries, il est plus intéressant de développer soit même la
stack KNX (ce que je fais, et même si ca prends un certain temps, ce
n'est pas ce qu'il y a de plus compliqué vu que le protocole est très
bien spécifié).
Mais en effet, l'utilisation du TP_UART n'est que transitoire. ce qui
permet de sortir la nouvelle gamme produit plus rapidement et être
certifié plus facilement également. Dans un second step, vu que nous
produirons en grande série, nous nous passerons du TP_UART, en
incluant un transceiver "fait maison", et en rajoutant la couche
logiciel pour les couches 1 et 2. il y aura en effet un léger gain sur
le prix (plus en matière première de fabrication que sur le prix final
client).
Pour ton projet, le TP_UART n'est pas aussi sorcié que ca à souder,
c'est un gros CMS tout de même. Mais en effet, tu gagneras du temps à
acheter une platine de test tout fait.
Pour la programmation par ETS....il faut avoir en effet les outils de
développement de base de donnée ETS...et ca, c'est un développement
complément à part et très mal documenté. donc en effet pour un produit
de démonstration universitaire, vaut mieux oublier. je trouve plus
facile à développer la stack EIB que la base de donné+plugin pour ETS.
La solution, Keldo te la donné, crée un projet ETS avec des produits
commercialisés (simple module d'entrées sorties par exemple), créé des
liens entre ces produits. Branche ton produit sur le bus, et fait toi
passer pour ces produits en interceptant et envoyant les trames avec
les adresses des groupes que tu as créé via ETS.
Choisir cette solution, te permet d'avoir un produit pas complètement
finalisé mais fonctionnel pour une démonstration. pas la peine de
gérer toute la stack KNX...donc très rapide a mettre en place si tu es
a l'aise avec les microcontroleurs.
Voila j'espère que toutes ces informations te serviront. Et lorsque tu
seras en train de monter ta stack EIB, n'hésite pas
On 20 mai, 02:15, keldo <kelderm...@ibelgique.com> wrote:
> > De nombreuse entreprise utilisent les BCU toute faite,
> > Ces modules utilisent un microcontroleur de type motorola ainsi que le
> > fameux FZE -> c'est module utilise un mapping mémoire (RAM et EEPROM)
> > figé (mask version) connu d'ETS...(e.g. ETS sait ou aller écrire les
> > tables d'adresse, d'association, etc...)
>
> Ceci est vrai uniquement pour les BCU1, c'est à dire la très ancienne
> première génération qui est de moins en moins utilisée.
>
> A partir du BCU2, une autre technique de programmation, dite des "EIB
> objects", doit être utilisée car une bonne partie des modules
> estampillés "BCU2" aujourd'hui sur le marché n'utilisent plus un CPU
> Motorola mais bien un NEC 78F053x, cet autre CPU a une architecture
> mémoire complètement différente et utilise une flash à la place d'une
> eeprom.
> De plus, à partir du stack "BCU2", un système d'autorisation de
> lecture et/ou d'écriture des "EIB objects" et des zones mémoires est
> mis en place à l'aide de mots de passe ("keys" & "access levels").
> Par contre, au niveau logiciel, le stack EIB d'un BCU2 sur motorola
> propose le même API que celui sur NEC, ce qui peut porter à
> confusion ...
>
> Pour une comparaison de technologie, un petit tour sur le site
> d'Opternus (zone "Composants", "Siemens", " KNX Bus Interface Module")
> est instructif.
>
> La génération "BCU1" est basée sur des modules du type BIM M111 et
> M115, avec un CPU Motorola 68HC05.
>
> La génération "BCU2 Motorola" est basée sur des modules du type BIM
> M113, avec un CPU Motorola 68HC05 plus rapide et plus généreux en
> mémoire.
>
> Les anciens participants EIB "haut de gamme" présentant beaucoup
> d'objets de communication sur le bus, comme les écrans LCD monochrome
> de type MT701 chez Merten et Jung, utilisent généralement un module
> BIM M112 avec un stack proche de la version "BCU2" appelé "version
> 70.x" et un processeur Motorola 68HC11 plus puissant que les 68HC05.
>
> Les participant de la nouvelle génération "Nec" utilisent toujours un
> stack qui se comporte comme un "BCU2" mais sont basé sur les nouveaux
> (environ 2 ans ?) modules de la série BIM M130 --> M135 et le code de
> leur stack est certainement issu d'un nouveau développement
>
> Pour compliquer le tout, il existe aujourd'hui plusieurs stacks EIB de
> type "BCU2" disponibles - moyennant finances - pour d'autres CPU comme
> le Texas Instruments MSP43x, par exemple celui de chez Tapko
> (http://www.tapko.de).
>
> Au niveau programmation, à l'exception du BCU-SDK de l'université de
> Vienne, le code applicatif à charger dans les modules basés sur un CPU
> Motorola est normalement écrit directement en assembleur, vu les
> ressources TRES limitées en mémoire des CPU Motorola 6805.
> Une particularité de ces CPU Motorola est de pouvoir exécuter du code
> depuis la mémoire EEPROM.
> Sur ces CPU, le stack EIB est en PROM (donc non effaçable), le
> programme uploadé via ETS ainsi que toute la config se retrouve dans
> l'EEPROM, c'est pourquoi il ne peut être très long ...
>
> Le kit de programmation "officiel" des modules BIM M13x basés sur CPU
> NEC est lui proposé pour le langage C.
>
> Le gros avantage du TP-UART pour les industriels, c'est qu'il est déjà
> certifié EIB-KNX pour les couches 1 et 2, ce qui simplifie et rend
> moins couteux les processus de développement et de certification des
> nouveaux produits.
> C'est un choix logique tant que les modules EIB ne seront pas produit
> en très grande série.
> Le jour ou il y aura une centaine de modules EIB dans chaque maison
> d'Europe, l'économie d'échelle aura joué et les industriels auront
> préféré payer un peu plus durant la phase de développement d'un
> nouveau module EIB de manière à pouvoir remplacer un TP-UART devenu
> trop couteux par rapport à un software plus élaboré et une poignée de
> composants discrets simples et quasiment gratuits quand achetés par
> millions.
>
> Si jamais tu penses passer commande de quelques TP-UART chez Opternus,
> je te conseille de réfléchir sérieusement à commander plutôt la
> platine de test toute faite de Siemens, aussi en vente sur le site ;
> c'est trois fois plus cher que le TP-UART seul, mais tu ne dois pas te
> taper la soudure des fines pattes du CMS (le TP-UART n'existe pas en
> format DIP ...) ni chercher une équivalence à la double Zenner
> "Transil/Transorb/..." anti-surtension ; finalement, avec le quartz,
> les condos, les diodes non-classiques et le reste, je pense pas que la
> platine de test revienne beaucoup plus cher ... et c'est beaucoup plus
> simple, sans parler du risque de griller la puce durant la soudure.
>
> Concernant l'écriture d'un petit soft qui "parle" sur le bus via un TP-
> UART, c'est effectivement possible d'écrire quelque chose de
> fonctionnel en quelques heures, mais écrire tout un stack pour imiter
> le comportement d'un BCU est beaucoup moins simple ...
> Dans la zone téléchargement de ce forum, tu trouveras un fichier
> archive qui s'appelle "Stack EIB pour PIC24 ..." ou un truc du style,
> c'est totalement incomplet et je n'ai pas pris le temps d'y travailler
> depuis longtemps mais tu pourras sans doute déjà réutiliser les
> structures de données (l'entête du télégramme notamment) qui s'y
> trouvent.
>
> Concernant le support "officiel" de Konnex via web, sachant que le
> siège de l'association est à Bruxelles, il vaut sans doute mieux
> passer par le site officiel principal plutôt que par le site Suisse.
> J'ai déjà contacté, par e-mail, le siège pour un problème technique
> (je cherchais un fichier de base de donné ".vd1" devenu introuvable
> sur le web, BOSCH ayant arrête la vente - et le support !!! - de ses
> modules EIB depuis longtemps) et j'ai été très satisfait de leur
> réponse, même s'il a fallut quelques jours pour l'obtenir : ils ont
> finalement reconstruit le fichier pour moi à partir de leurs
> archives ...
> Il y a aussi un développeur de chez Konnex appelé Steven (je
> crois ...) qui passait sur ce forum et répondait de temps en temps
> mais je n'ai plus vu de message de sa part depuis un an ... peut-être
> pourrais-tu le retrouver parmi les anciennes discussions et lui
> envoyer un message perso ? De mémoire, il est intervenu - entre autre
> - dans une discussion à propos de la possibilité de changer l'ID
> "fabricant/constructeur" d'un BCU.
>
> Il te reste aussi les forums allemands, avec des gens plus calés que
> les francophones, encore faut-il pouvoir lire et écrire en allemand ou
> en anglais.
>
> Le site de l'université de Vienne (http://www.auto.tuwien.ac.at) propose
> aussi pas mal d'infos.
>
> Du point de vue livres techniques, le seul qui ne soit pas en allemand
> est "EIB - Installation bus système" (par Sauter, Dietrich, Kastner)
> aux éditions "Publicis" : il est en anglais, propose pas mal
> d'informations intéressantes mais il n'est pas un modèle de clarté ...
> les informations ne sont pas toujours bien organisées.