TP-UART vs FZE 1066

[JT]

Salut !

J'étudie les différentes solutions de couplage au bus KNX en paire
torsadée TP1.
Est-ce que quelqu'un pourrait m'indiquer ce qu'apporte de plus le
transceiver TP-UART par rapport au transceiver de bit FZE 1066 ?
En effet, il est dit que le TP-UART permet une interface en protocole
série UART. Mais les télégrammes présents sur le bus sont déjà
composés de caractères UART (1 start bit + 8 bits de données + 1 bit
de parité + 1 stop bit). Donc un simple transceiver de bits comme le
FZE 1066 devrait suffir à pouvoir relier les données transmises sur le
bus à une entrée UART d'un microcontroleur.

Merci d'avance pour vos réponses !

[Kylia]

Les données transmises sur le bus sont sur du 29 volts pincée, donc
pas de rapport avec le 0-5 volts de l'UART d'un micro.

Il faut donc absolument un tranceiver -> remise en forme des signaux
(soit la couche 1 du modèle OSI). C'est le rôle de FZE1066.
Si tu couple un FZE1006 directement avec ton micro, tu peux te taper
toute la couche 2 du modèle OSI...-> prise de ligne, gestion des
accusé de réception, traitement de trame valide, etc...et crois moi ça
peut vite devenir un beau bordel....

L'intérêt du TP-UART (qui fait également office de tranceiver
analogique en plus de son intelligence numérique), c'est qu'il ne te
balance pas les bits du bus directement. Il reçoit la trame, regarde
si elle est valide. Et si c'est le cas, te l'envoie à ton micro.
premier point donc, tu ne reçois que des trames valides....
Tu veux envoyer une trame? très simple, tu l'envoie au TP_UART, celui
ci regarde si elle est valide ou non (si elle n'est pas valide, il te
renvoie un code d'erreur)...et ensuite c'est le TP UART qui gère toute
la comm avec le bus, c'est lui qui va faire la prise de ligne pour
envoyer la trame au bon moment. Et si il ne reçois pas d'ack de la
part du destinataire, va renvoyer jusqu'à 3 fois la trame...etc...

Je ne vais pas te faire toute la description du protocole, mais en
clair, le TP_UART gère toute la couche 1 et 2 du protocole EIB/KNX
alors que le FZE1066 ne gère que la couche 1 (pour un euro de plus, ça
vaut le coup)

Utilisation du FZE :
- prend bcp de ressource sur ton micro pour gèrer la couche 2 qui est
assez lourde
- tu dois recoder ce qui existe deja sur le TP_UART avec les bug en
plus
- un poil moins cher

Utilisation du TP_UART :
- drivers codé en un après midi -> rapide à mettre en place
- couche 1 et 2 déjà certifié

Je n'ai peut être pas été très clair, mais si tu veux monter une
petite appli rapidement, choisi le TP_UART les yeux fermés. en plus la
datasheet est vraiment trés bien expliqué....

N'hésites pas si tu veux plus de détails.


On 13 mai, 14:18, JT <jeremy.ta...@groupe-arcom.com> wrote:
> Salut !
>
> J'étudie les différentes solutions de couplage au bus KNX en paire
> torsadée TP1.
> Est-ce que quelqu'un pourrait m'indiquer ce qu'apporte de plus le
> transceiver TP-UART par rapport au transceiver de bit FZE 1066 ?
> En effet, il est dit que le TP-UART permet une interface en protocole
> série UART. Mais les télégrammes présents sur le bus sont déjà
> composés de caractères UART (1 start bit + 8 bits de données + 1 bit
> de parité + 1 stop bit). Donc un simple transceiver de bits comme le
> FZE 1066 devrait suffir à pouvoir relier les données transmises sur le
> bus à une entrée UART d'un microcontroleur.
>
> Merci d'avance pour vos réponses !

[JT]

D'abord, merci pour cette réponse rapide et la clarté de tes
explications.
Toutefois il y a quelques points sur lesquels j'ai encore quelques
interrogations :

- Tu dis que le TP-UART contrôle toutes les données provenant du bus
et ne transmet au microcontroleur que les trames valides. Mais d'après
le paragraphe 3.2.1 de la datasheet, dans certains cas le TP-UART
n'indique pas au controleur les erreurs et le controleur doit se
débrouiller tout seul pour les reconnaitre (voir la phrase que j'ai
mis en majuscule) :
"The signals can be transmit without a break and the Idle-level is 1.
The parity bit of every signal is checked while down loading and
faults, which can appear,
are transmitted to the host controller. The check mechanism runs also
while receiving of
telegrams from the EIB, but here isn’t any possibility to transmit a
fault to the host controller.
In those cases THE HOST CONTROLLER HAS TO RECOGNIZE THE PARITY FAULTS
IN THE TRANSMITTED TELEGRAM BY ITS OWN."
Quels sont ces cas où le controleur doit assumer seul la détection des
erreurs ?

- Ensuite, je me pose des questions sur les modes de fonctionnement du
TP-UART : le mode normal et le mode analogique. Quelles sont les
différences entre ces 2 modes, au-delà du fait qu'en mode normal
l'état de repos est "1" et "0" en mode analogique ? Etant donné qu'en
mode analogique la partie numérique du TP-UART n'est pas utilisée, est-
ce que ça veut dire que dans ce mode le TP-UART fonctionne comme un
simple transceiver de bit (c'est à dire comme le FZE 1066 par
exemple) ?

- Sinon, dernière question qui n'a rien à voir avec la technique : est-
ce que quelqu'un connait un fournisseur de TP-UART autre qu'Opternus,
pour acheter juste 1 ou 2 composants ?

Merci à toi Kylia et aux éventuelles personnes que ces questions
intéressent.

[keldo]

J'ai déjà lu la doc du TP-UART plusieurs fois, mais ma petite platine
de test ne fonctionne pas encore correctement, donc je n'ai pas encore
de certitudes.
Néanmoins, selon ma compréhension encore limitée de la chose,
l'intérêt du TP-UART au niveau de la gestion des erreurs, c'est :

1) en émission d'un télégramme :
Si le bus renvoit un NACK, le TP-UART va répéter ton télégramme
jusqu'à 3 fois (configurable) sans que ton microcontroleur ne doive
intervenir.

2) en réception :
Si le télégramme reçu comporte une erreur, le TP-UART le transmet au
micro-controleur qui doit détecter l'erreur et décider"jetter" le
télégramme, mais le TP-UART se charge tout seul d'envoyer un NACK sur
le bus.

[keldo]

Je pense que l'extrait en anglais parle du cas ou une erreur apparait
sur la liaison série entre le TP-UART et le microcontroleur, chose que
le TP-UART ne peut évidemment pas controler ou corriger.

[keldo]

On 14 mai, 16:21, jeremy.ta...@gmail.com wrote:
> Sinon, pour reprendre une question que j'avais posée plus haut :
> quelqu'un a-t-il des infos sur les différences entre le mode normal et
> le mode analogique ?
> [ ... ] je pense qu'en mode
> analogique le TP-UART fonctionne comme un transceiver de bit (c'est à
> dire comme un FZE 1066)
> Pour faire bref, je pense que dans le mode analogique, le TP-UART ne couvre que la couche 1.

C'est exactement comme cela que je le comprends aussi.

Jusqu'ici, je n'ai pas trouvé d'autre source qu'Opternus, mais je n'ai
pas eu de problème avec eux pour en commander une petite dizaine et me
faire livrer en Belgique.

Avec un petit peu de recul (cela fait bientôt 2 ans que je chipote sur
l'écriture d'un stack EIB pour microcontroleur PIC24-30-33), je trouve
que le TP-UART ne fait pas grand chose pour son prix et son
"encombrement", vu qu'il lui faut pas mal de composants annexes ... ,
pour chaque télégramme qui se balade sur le bus, ton CPU doit de toute
manière passer en revue sa table d'adresses de groupe et répondre au
TP-UART dans un temps assez limité pour dire si le message l'intéresse
oui ou non.
Vu que je les ai déjà achetés, je vais terminer l'écriture de mon
stack pour une interface TP-UART, mais ensuite je compte bien
l'adapter pour fonctionner avec une interface du type de celle mise au
point par les petits gars du projet Freebus "www.freebus.org" : ils
travaillent avec leur microcontroleur quasi en direct sur le bus et,
finalement, du point de vue logiciel, il "suffit" d'ajouter la
gestion de l'arbitrage de l'accès au bus + la gestion des erreurs +
réserver un timer pour calculer la durée des bits afin de se passer de
TP-UART ; pour un microcontroleur rapide et doté d'un système
d'interruptions évolué, ce n'est franchement pas la mer à boire.

L'autre avantage de la solution "freebus", c'est qu'elle n'utilise que
des composants discrets et à petit budget, il est donc possible de les
trouver chez divers fournisseurs "classiques" (Farnell, Digikey,
Radiosp... ???) et non pas uniquement chez Opternus.

Pour le reste, ton intérêt pour les TP-UART me titille ... pourrais-tu
me dire à quel type de projet ou d'usage tu le destines ?

[Mathieu Gallissot]

Tu peut surement contacter l'association KNX France pour avoir quelques
infos, les constructeurs étant en général assez collaboratif vis à vis des
universitaires.

2009/5/18 <jeremy.tadla@gmail.com>

>
> Salut keldo !
>
> Je vais jeter un coup d'oeil au projet Freebus.
> Seulement, mon projet d'étude (je suis à l'université Lyon 1) était de
> synthétiser les différentes architectures d'un participant KNX. Je
> dois donc surtout m'intéresser aux solutions les plus souvent adoptées
> par les fabricants. Or je pense que la solution "Freebus" (sans
> transceiver) est très minoritaire. Mais merci quand même pour l'info,
> ca peut être intéressant !
> Ce qui m'intéresserait ce serait de pouvoir faire une démo avec ets
> starter peut-être, même si c'est juste pour faire clignoter 2 leds...
> Mais j'ai pu constaté qu'il n'y a pas de stack libre et que l'écriture
> semble laborieuse. D'un point de vue général il n'y a pas beaucoup
> d'info sur KNX sur le net. De toute façon je n'ai pas encore définis
> tous les éléments de mon participant, notamment le microcontrôleur.
>
> En tout cas merci pour les infos sur le TP-UART !
>

[Kylia]

Pour maquetter un projet d'université....je reste sur la solution
TP_UART.
Pour la stack EIB sur TP_UART, elle est vraiment très simple à mettre
en place pour un projet de ce genre
Je te conseille donc de prendre le TP_UART.

Ce que les entreprises utilisent? et bien pour être au coeur de la
question je peux te donner des éléments de réponse :
De nombreuse entreprise utilisent les BCU toute faite, c'est un module
qui coutent très cher (environ 40€)-> d'ou le prix élevé des produits
KNX, compatible et déjà certifié KNX.
Dans ce module il y a un espace mémoire pour que le manufacturer
développe sa couche d'application ainsi qu'un connecteur (PEI) avec un
certain nombre d'entrées/sorties pour brancher une électronique
annexe.
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...)

Pour certains produits complexe, il est impossible d'utiliser ces
modules, il existe alors plusieurs solution:

-il y a les industrielles qui soit refond complètement l'électronique
avec des composants passifs. ces derniers sont très rares puisqu'il y
a la certification derrière...
-il y a les industrielles qui recrée une BCU : micro + FZE : j'ai un
exemple de produit en tête, mais je tairai le nom (puisqu'il s'agit
d'une entreprise concurrente à la mienne)
- Et pour finir, micro + TP_UART ( c'est sur cette architecture que je
conçois notre futur gamme de produit)

Pour être honnete la solution micro+FZE et micro+tp_uart s'équivalent
au final. La deuxième solution va couter moins chère puisque le FZE
coute 1€ de moins, mais il y a plus de certification derrière et cela
demande plus de temps de développement. La solution avec TP_UART même
si un poil plus cher permet d'être plus rapide dans le développement
tout en garantissant la certification des premières couches....

C'est un vaste sujet sur lequel on peut beaucoup discuter...chaque
solution a des avantages et des inconvénient....personne n'a tord,
personne n'a raison...

La stack pour faire fonctionner le TP_UART est très rapide en mettre
en place (quelques heures seulement). Etant donnée qu'il ne s'agit que
d'une maquette de démo, ca peut être très vite bouclé (pas besoin de
faire certifier le produit, donc pas nécessaire d'implémenter toutes
les fonctions). maintenant, si tu veux créer une réelle application
programmable via ETS, il te faudra les outils (manufacturer tool) pour
développer ta base de produit ETS (vd3)...et pour pouvoir télécharger
l'ensemble de l'application depuis ETS, il te faudra développer toute
la stack "connection oriented".
Tout ca pour dire que ton projet peut prendre énormément de temps à
mettre en place comme très peu de temps, tout dépends exactement de ce
que tu veux faire exactement.

Sinon peut etre encore un détail entre TP_UART et FZE. l'avantage du
TP_UART, c'est qu'il gère la prise de ligne, les timers etc pour gérer
la communication avec le bus....il libère donc pas mal de ressources
au microcontroleur qui peut avoir besoin de ces mêmes ressources pour
gérer une application complexe.

Voila...

On 13 mai, 14:18, JT <jeremy.ta...@groupe-arcom.com> wrote:
> Salut !
>
> J'étudie les différentes solutions de couplage au bus KNX en paire
> torsadée TP1.
> Est-ce que quelqu'un pourrait m'indiquer ce qu'apporte de plus le
> transceiver TP-UART par rapport au transceiver de bit FZE 1066 ?
> En effet, il est dit que le TP-UART permet une interface en protocole
> série UART. Mais les télégrammes présents sur le bus sont déjà
> composés de caractères UART (1 start bit + 8 bits de données + 1 bit
> de parité + 1 stop bit). Donc un simple transceiver de bits comme le
> FZE 1066 devrait suffir à pouvoir relier les données transmises sur le
> bus à une entrée UART d'un microcontroleur.
>
> Merci d'avance pour vos réponses !

[keldo]

> 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.

[keldo]

> Seulement, mon projet d'étude (je suis à l'université Lyon 1) était de
> synthétiser les différentes architectures d'un participant KNX.
Infos en passant :
Pour la connexion au bus TP1, outre le TP-UART et le FZE-1066, il
existe aussi un FZE-1065 : l'un des deux utilise un transformateur
d'isolement, l'autre pas.
Il existe aussi un type de bus TP0 (uniquement KNX, pas en EIB).
Il existe aussi des modules EIB radio, en 433 et en 868 MHz notamment.
Il existe des modules utilisant le courant porteur en 230vac, en deux
variantes.
Il existe - du moins en théorie - des modules directement sur Ethernet
et IP.
Il existe aussi certains modules qui transmettent en infrarouge (des
boutons poussoirs Siemens notamment).

> Ce qui m'intéresserait ce serait de pouvoir faire une démo avec ets starter
> même si c'est juste pour faire clignoter 2 leds...

Utiliser ETS pour programmer un module que tu as construit ?
Il vaut mieux oublier, car les outils de développement des "bases de
données produit" pour ETS ne sont disponibles que pour les membres -
payants - de KONNEX.
Et sans base de donnée produit spécifique à ton module, ETS ne peut
pas le programmer.
Le seul moyen est de fabriquer un module qui simule un module
commercial pour lequel on dispose de la "base de donnée produit",
c'est la technique utilisée pour les modules Freebus.

[Kylia]

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.