Création/Développement de modules EIB sur base de µC PIC

[stephane.herraiz@gmail.com]

Moi aussi j'ai eut pas mal de boulot et là je vais partir en vacances!
J'ai bien potassé les PIC24 et ils ont l'air très puissants et très
facile d'utilisation.
J'ai réalisé des petits test sous proteus 7 et MPLAB, et ça marche
très bien!
Je pense utiliser le driver TP-UART vu sur
http://homepages.fh-regensburg.de/~scg39...ibteam.htm.
Je suis en train de le potasser. Il est très complet et semble être
une bonne base (très avancée!) pour le projet.
J'ai eut un petit souci technique et j'ai perdu le schéma PCB de la
platine de test grrr tout à refaire. J'espère fournir une premier jet
en fin de semaine... sinon ce sera à mon retour de vacances mi-
octobre...
Keldo si tu as réussi à rassembler le matériel, pourrais tu faire une
liste (avec les codes commandes Farnell ou autres...) pour que je
puisse les intégrer dans mon PCB?
a++

un mot : persévérance

On 21 sep, 23:11, keldo <kelderm...@ibelgique.com> wrote:
> Bon, et alors, tout le monde dors ici ???
> Heuuu, ben non, en fait, moi aussi j'ai pas mal de travail ces
> derniers jours ...
>
> Mais bon, j'avance tout de même un petit peu, en principe j'ai tous
> les composants (classiques , pas CMS) ou leur équivalent supposé
> acceptable, pour me monter une première platine de test sur une plaque
> à pastilles.
> Je dis quoi pour le remplacement des 2 diodes exotiques pour le TP-
> UART dès que j'aurai le temps de monter le tout ... et que le résultat
> ne transforme pas en incendie miniature !
>
> Pour la partie soft, je rumine pas mal mes routines de réception et
> transmission en byte par byte, j'espère avoir un squelette qui tienne
> la route d'ici une semaine ou deux et je ne manquerai pas de mettre la
> nouvelle version sur ma mini page web. (http://eib.jesuispour.eu)
>
> A bientôt pour la suite de nos passionnantes aventures.
>
> Keldo

[keldo]

> Moi aussi j'ai eut pas mal de boulot et là je vais partir en vacances!
Bonnes vacances, j'accompagnerais volontiers ;-)

> J'ai bien potassé les PIC24 et ils ont l'air très puissants et très
> facile d'utilisation.
Oui, c'est clairement mieux foutu que la mémoire des PIC16 explosée
sur des pages et des banques.
De mon coté je regarde pas mal la doc des dsPIC30 - j'en ai quelques
exemplaires en stock chez moi - mais c'est très proche des PIC24 si on
laisse le module DSP tomber et les codes source sont compatibles si on
change 2 ou 3 paramètres.
Histoire de me faire la main , je vais prochainement m'écrire une
petite application d'interface RS-232 avec le PC pour un
dsPIC30F4013 ; juste quelques lignes de code pour que le PIC renvoie
au PC tout ce qu'il reçoit, ça fera un bon test.

> Je pense utiliser le driver TP-UART vu sur (...)
Comme je suis assez têtu, je continue toujours mon challenge de faire
tourner un mini stack EIB sur mon PIC16F877a, mais j'en suis toujours
au pseudo-code en français, donc je garde bien sur la possibilité de
tout transposer en C.
"Beeeek, maman, j'aime pas le C ..."
Mon plus gros problème avec le C étant la relecture de code existant,
je ne me lancerai pas pour l'instant dans l'étude du projet allemand
sauf si je me retrouve bloqué, mais il n'y a que les imbéciles qui ne
changent jamais d'avis, donc on verra bien pour la suite.

> J'ai eu un petit souci technique et j'ai perdu le schéma PCB de la
> platine de test grrr tout à refaire.
Backup, quand tu nous tiens ...

> Keldo si tu as réussi à rassembler le matériel, pourrais tu faire une
> liste (avec les codes commandes Farnell ou autres...) pour que je
> puisse les intégrer dans mon PCB?
Il y a le datasheet du TP-UART (fichier PDF) sur mon mini site web, le
schéma de la page 24 (attention, pas 25 !) et la liste dans le haut de
la page 26 sont ils suffisants ?


Citation du jour : "Quand plus rien ne va, sortir la tronçonneuse"

[keldo]

Désolé, peu de nouvelles par ici ces derniers temps, un méchant virus
(pas du tout informatique) me mène la vie dure depuis le début du mois
d'octobre en me pompant toute mon énergie ...

J'ai tout de même pu avancer un tout petit peu dans le pseudo-code de
la routine de réception.
La nouvelle version est disponible sur le mini-site web http://eib.jesuispour.eu/

Citation du jour : "Avec Epstein-Barr , faites péter les gamma-GT"

[stephane.herraiz@gmail.com]

Me revoilà après un petit moment d'absence.
J'ai enfin fini le schéma électronique sous Eagle Layout d'une carte à
base de PIC 24FJxxGA00x (28PDIP) pour le développement du protocole
KNX.
Cette carte comporte :
- une interface RS232 pour le PIC
- une interface ICD2 pour programmer et débugger le PIC
- un UART isolé du PIC par des optocoupleurs
- support BIM Mxxx isolé du PIC par optocoupleur
- une alimentation galvaniquement isolé pour le BIM.

J'espère que j'aurais beaucoup de remarques car je n'ai pas l'habitude
de développer de telle carte.

Le routage de la carte se fera plus tard...

Le fichier du schéma de la carte se trouve dans les fichiers du groupe
et a pour nom "EIBPICdev.sch"

Merci d'avance




On 25 oct, 18:50, keldo <kelderm...@ibelgique.com> wrote:
> Désolé, peu de nouvelles par ici ces derniers temps, un méchant virus
> (pas du tout informatique) me mène la vie dure depuis le début du mois
> d'octobre en me pompant toute mon énergie ...
>
> J'ai tout de même pu avancer un tout petit peu dans le pseudo-code de
> la routine de réception.
> La nouvelle version est disponible sur le mini-site webhttp://eib.jesuispour.eu/
>
> Citation du jour : "Avec Epstein-Barr , faites péter les gamma-GT"

[Beaufanamus]

Bonjour tout le monde.

J'ai découverts récemment ce groupe et cette discution, qui
m'intéresse au plus au point. Mes compétences en électronique et en
info indus sont modestes, alors je mets du temps à intégrer vos
réflexion actuelle.

J'en suis donc à parcourir les datasheets avant de poser des questions
trop bêtes.

Concernant les télégrammes, je n'ai pas encore trouvé une spec sur
ceux-ci. Pour l'allumage et extinction, j'ai trouvé, mais quelles sont
les données à transmettre à un variateur, comment sont transmises des
mesures physiques, comment se passe l'affectation d'adresse physique,
etc ... Est-ce que quelqu'un a cette spec?

Sur les schémas de Stéphane, avec ma compréhension actuelle, je n'ai
qu'une question/remarque surement candide. Sur les opto, les deux
phototransistors sont alimentée avec la même tension. Est-ce qu'en
utilisant les deux voies d'un même boitier pour le Rx et Tx, on ne
ruine pas l'isolation galva recherchée? Instinctivement, j'aurais
utilisé un boitier d'opto pour les 2 Tx, et l'autre pour les deux Rx.
Un coté alimenté par le 5V du TP-UART, et l'autre en 3.3V produit
éventuellement indépendamment du bus EIB, de manière à avoir
l'isolation galvanique entre les 2 parties?

[keldo]

> Concernant les télégrammes, je n'ai pas encore trouvé une spec sur
> ceux-ci. Pour l'allumage et extinction, j'ai trouvé, mais quelles sont
> les données à transmettre à un variateur, comment sont transmises des
> mesures physiques, comment se passe l'affectation d'adresse physique,
> etc ... Est-ce que quelqu'un a cette spec?

C'est évidemment un point très important.
Je pense avoir la quasi totalité de ces informations, mais elles sont
éparpillées sur des supports très différents (livre papier, feuilles
volantes, fichiers d'aide windows, fichiers PDF, etc. ).
Cela va me prendre pas mal de temps de réunir tout cela sur une seule
page html, même si cela me semble utile de le faire pour écrire et
bien documenter le soft du stack EIB.

Si tu es pressé, tu peux chercher ceci : le programme EITT Démo (EIB
Interoperability Test Tool), ou plus précisément une vielle version
démo de ce programme, est téléchargeable ici :
http://www.knx-developer.de/
Il faut prendre et installer ces deux fichiers :
http://www.knx-developer.de/online/eitt22/disk1.exe et
http://www.knx-developer.de/online/eitt22/data2.cab
Une fois le programme installé et démarré, va dans l'aide, tu y
trouveras la description bit par bit de tous les télégrammes, classés
par format de données EIS.

Il y a aussi cette page : http://www.knx-developer.de/bcu2.htm
Si tu ouvres le fichier "help" (online ou téléchargé), va dans
"Reference / Telegram decoding / EIB frame format", il y a beaucoup
d'info mais c'est très (trop) condensé.
Pour le comprendre, il faut bien savoir que certains télégrammes sont
transmis en mode "connectionless" (=j'envois l'info sur le bus, c'est
tout), c'est typiquement le cas des envois de valeur d'objets vers une
adresse de groupe ; alors que d'autres télégrammes sont transmis en
mode "connection oriented", ce qui signifie qu'il y a une procédure
d'ouverture et de fermeture de session de communication à respecter,
c'est par exemple le cas quand on reprogramme tout ou partie de la
mémoire d'un BCU.

Les modes de communication avec ou sans sessions sont "relativement"
pas trop mal expliqués dans le livre :
- EIB Installation Bus System
- Auteurs : Sauter, Dietrich, Kastner (Eds.)
- Editions : Publicis
C'est le seul livre suffisement technique sur l'EIB que j'ai trouvé en
anglais jusqu'à présent ... et pour un livre en français on peut
toujours se gratter. :-((

Pour le reste, il y a les informations officielles de l'EIB,
particulièrement le volume 3 des livres officiels de la norme EIB. Le
problème c'est que ces livres, qui étaient d'acces libres jusqu'il y a
un an ou deux, sont aujourd'hui devenus payants (depuis le passage
vers la norme KNX). Il y a bien sur plein de gens comme moi qui
possèdent encore une copie du fichier "volume3.zip" téléchargé sur le
site de EIBA "in tempore non suspecto", mais avec le changement
radical de politique de l'association KNX, il n'est pas évident de
savoir si on peut librement s'échanger ce fichier ???


> Sur les schémas de Stéphane, avec ma compréhension actuelle, je n'ai
> qu'une question/remarque surement candide. Sur les opto, les deux
> phototransistors sont alimentée avec la même tension. Est-ce qu'en
> utilisant les deux voies d'un même boitier pour le Rx et Tx, on ne
> ruine pas l'isolation galva recherchée? Instinctivement, j'aurais
> utilisé un boitier d'opto pour les 2 Tx, et l'autre pour les deux Rx.
> Un coté alimenté par le 5V du TP-UART, et l'autre en 3.3V produit
> éventuellement indépendamment du bus EIB, de manière à avoir
> l'isolation galvanique entre les 2 parties?

@Stephane
Je n'ai pas encore eu le temps de bien regarder ton schéma, mais j'ai
enfin installé Eagle sur mon PC, donc cela ne saurait tarder ...
Pour couper court à tout problème concernant les optocoupleurs
multiples dans une seul boitier, j'ai par contre ma solution miracle :
Je propose d'utiliser des optocoupleurs du type "Lite-On LTV-817", ils
se présentent sous la forme de tout petits boitiers DIL à 4 pattes,
donc il n'y a qu'un seul optocoupleur par boitier, donc zéro risque
d'erreur au niveau de l'isolation.
Et rien n'empèche de mettre plusieurs de ces petites puces "4 pattes"
côte-à-côte sur la platine - dans un grand support pour DIL - pour
gagner de la place ou pouvoir éventuellement remplacer 2 LTV-817 par
une seule puce qui contiendrait plusieurs optocoupleurs (usage des
pattes à vérifier préalablement dans ce cas là).

[jef2000]

> site de EIBA "in tempore non suspecto", mais avec le changement
> radical de politique de l'association KNX, il n'est pas évident de
> savoir si on peut librement s'échanger ce fichier ???
Moi je considère que tant qu'il est disponible sur leur site à
l'adresse:
http://www.eiba-software.com/eibacom/Volume3.zip
c'est qu'on est autorisé à le télécharger

> Et rien n'empèche de mettre plusieurs de ces petites puces "4 pattes"
> côte-à-côte sur la platine - dans un grand support pour DIL - pour
> gagner de la place ou pouvoir éventuellement remplacer 2 LTV-817 par
> une seule puce qui contiendrait plusieurs optocoupleurs (usage des
> pattes à vérifier préalablement dans ce cas là).
D'habitude, j'utilise des optocoupleurs à 6 pattes (1 opto par
boitier, 2 pattes ne sont raccordées à rien) comme le CNX62A par
exemple. Le brochage qu'ils utilisent est assez courant pour des opto
(je pense même que c'est le plus courant)

[stephane.herraiz@gmail.com]

> Sur les schémas de Stéphane, avec ma compréhension actuelle, je n'ai
> qu'une question/remarque surement candide. Sur les opto, les deux
> phototransistors sont alimentée avec la même tension. Est-ce qu'en
> utilisant les deux voies d'un même boitier pour le Rx et Tx, on ne
> ruine pas l'isolation galva recherchée? Instinctivement, j'aurais
> utilisé un boitier d'opto pour les 2 Tx, et l'autre pour les deux Rx.
> Un coté alimenté par le 5V du TP-UART, et l'autre en 3.3V produit
> éventuellement indépendamment du bus EIB, de manière à avoir
> l'isolation galvanique entre les 2 parties?

Effectivement il y a une erreur de connexion à la masse dans mon
schéma. Les masses n'étaient pas les bonnes...
J'ai mis à jour le fichier.
Je pourrais utiliser des boîtiers à un optocoupleur au lieu de deux
mais je ne comprends ce que ça change à part éviter une erreur de
conception.
Si je met les TX sur le même boîtier optocoupleur et les RX sur un
autre, je suis obligé de connecter les masses GND2 et GND3 ensemble et
en cas de problème le TUART et le BIM sautent.
je vais me renseigner sur les Lite-On LTV-817.
Jef2000 si tu as un schéma avec des CNX62A je suis preneur.
Je vous cache pas que cette partie du schéma m'a posé le plus de
problème ;-)...
Cette platine a pour but d'être utilisé par d'autres si vous avez
l'expérience d'un montage plus efficace vous pouvez modifier le schéma
et me l'envoyer.
Merci pour vos remarques et continuez la démarche.

[keldo]

> Jef2000 si tu as un schéma avec des CNX62A je suis preneur.
> Je vous cache pas que cette partie du schéma m'a posé le plus de
> problème ;-)...
> Cette platine a pour but d'être utilisé par d'autres si vous avez
> l'expérience d'un montage plus efficace vous pouvez modifier le schéma
> et me l'envoyer.
> Merci pour vos remarques et continuez la démarche.

Bonjour Stéphane.
Au cas ou tu ne l'aurais pas vu, je viens de trouver un schéma
intéressant sur :
http://www.auto.tuwien.ac.at/~mkoegler/index.php/tpuart
Cela te donnera peut-être des idées.

Keldo

[olivier95800]

Bonjour,

Dans la limite de mes compétences, je peux peut être vous aider pour:
- le schéma (je suis électronicien)
- le routage (j'en ai fait 7 ans)
- programmation (si proche 8051)
- pcb (si quantité à cause des frais d'outillage)

Olivier

[stephane.herraiz@gmail.com]

> Au cas ou tu ne l'aurais pas vu, je viens de trouver un schéma
> intéressant sur :http://www.auto.tuwien.ac.at/~mkoegler/index.php/tpuart
> Cela te donnera peut-être des idées.

Effectivement j'ai vu ce schéma et je l'ai étudié. Ce schéma me paraît
un peu compliqué : beaucoup de composants alors qu'un driver RS232
genre MAX3222 aurait suffit... Moi j'aime les trucs simples...
j'ai pas encore étudié les autres optocoupleurs.

Sinon Olivier95800 si tu peux jeter un OEil d'expert sur le schéma
(dans fichiers du groupe le fichier "EIBPICdev.sch") ça serait très
sympa!

Stéphane

[olivier95800]

Bonjour,

Je veux bien mais je n'ai rien pour lire les SCH.
Peux-tu en faire un PDF, stp ?

A+

Olivier


On 22 nov, 14:31, "stephane.herr...@gmail.com"
<stephane.herr...@gmail.com> wrote:
> > Au cas ou tu ne l'aurais pas vu, je viens de trouver un schéma
> > intéressant sur :http://www.auto.tuwien.ac.at/~mkoegler/index.php/tpuart
> > Cela te donnera peut-être des idées.
>
> Effectivement j'ai vu ce schéma et je l'ai étudié. Ce schéma me paraît
> un peu compliqué : beaucoup de composants alors qu'un driver RS232
> genre MAX3222 aurait suffit... Moi j'aime les trucs simples...
> j'ai pas encore étudié les autres optocoupleurs.
>
> Sinon Olivier95800 si tu peux jeter un OEil d'expert sur le schéma
> (dans fichiers du groupe le fichier "EIBPICdev.sch") ça serait très
> sympa!
>
> Stéphane

[stephane.herraiz@gmail.com]

Bonjour,
J'ai placé dans les fichiers du groupe le schéma en pdf
(EIBPICdev.pdf).
a+

On 23 nov, 11:08, olivier95800 <olivier95...@wanadoo.fr> wrote:
> Bonjour,
>
> Je veux bien mais je n'ai rien pour lire les SCH.
> Peux-tu en faire un PDF, stp ?
>
> A+
>
> Olivier
>
> On 22 nov, 14:31, "stephane.herr...@gmail.com"
>
> <stephane.herr...@gmail.com> wrote:
> > > Au cas ou tu ne l'aurais pas vu, je viens de trouver un schéma
> > > intéressant sur :http://www.auto.tuwien.ac.at/~mkoegler/index.php/tpuart
> > > Cela te donnera peut-être des idées.
>
> > Effectivement j'ai vu ce schéma et je l'ai étudié. Ce schéma me paraît
> > un peu compliqué : beaucoup de composants alors qu'un driver RS232
> > genre MAX3222 aurait suffit... Moi j'aime les trucs simples...
> > j'ai pas encore étudié les autres optocoupleurs.
>
> > Sinon Olivier95800 si tu peux jeter un OEil d'expert sur le schéma
> > (dans fichiers du groupe le fichier "EIBPICdev.sch") ça serait très
> > sympa!
>
> > Stéphane

[jef2000]

Quelques petites remarques.
1) Etant donné qu'on doit choisir entre l'interface EIB via BIM et
l'interface via TPUART, tu pourrais déplacer JP6 après les
optocoupleurs pour en économiser 2.
2) Tu as prévu une alim 5V pour la BIM avec un DC/DC, alors que
d'après moi elle n'a pas besoin d'alimentation. La broche +5V de bim
est une sortie servant à alimenter le module qui vient se connecter
dessus (dans les limites de puissance imposées par la spec)

[olivier95800]

Bonjour,

Pourquoi un µC en 3V3 ?
Quelle est la tension de l'alim par J3 ?
A quoi sert R12, C16n R13 et SW-PIC ?
- Vérifie le circuit de Reset du µC. La constante de temps R1xC1 me
parait faible.
- Ajoute une résistance en // sur C1 pour décharger la capa lors de la
coupure de l'alim.
- Evite de court-circuiter C1 par le switch même si c'est un condo
céramique.
- Vérifie l'étage de sortie de BIM2 (sortie TTL ou collecteur
ouvert ?)
- BIMA et BIMB ne peuvent pas être dans le même boitier car le VCC et
le GND sont commun. Prend plutôt 4 opto simple.
- N'oublie pas la condo de découplage. En général 100nF.

A+

[olivier95800]

pour Jef2000

Faut bien l'alimenter ce BIM...

A+

On 26 nov, 14:02, jef2000 <jef2...@ouaye.net> wrote:
> Quelques petites remarques.
> 1) Etant donné qu'on doit choisir entre l'interface EIB via BIM et
> l'interface via TPUART, tu pourrais déplacer JP6 après les
> optocoupleurs pour en économiser 2.
> 2) Tu as prévu une alim 5V pour la BIM avec un DC/DC, alors que
> d'après moi elle n'a pas besoin d'alimentation. La broche +5V de bim
> est une sortie servant à alimenter le module qui vient se connecter
> dessus (dans les limites de puissance imposées par la spec)

[jef2000]

> Faut bien l'alimenter ce BIM...
Il est alimenté via le bus EIB, et la tension qu'il sort sur sa broche
+5V est suffisante pour allumer la led de l'opto sur TX et alimenter
la résistance tire-haut et le photo transistor de l'opto RX.

[stephane.herraiz@gmail.com]

Bonjour,
Tout d'abord merci pour toutes ces remarques,c'est très intéressant!

Effectivement vous avez raison pas besoin d'alimentation 5v.

> Pourquoi un µC en 3V3 ?
- Le choix d'un uC à 3,3v vient du fait que l'on souhaite utiliser des
Pic 16bits. Il nous reste donc deux familles : dsPic et PIC24. Je
voulais utiliser les nouveaux PIC24 (conseillé par Connexium un peu
plus tôt dans la discussion). De plus le Pic24 que j'utilise est
disponible en boîtier DIP28 plus facile à utiliser pour le
développement.
Effectivement l'utilisation d'un uC en 5v simplifiera le montage je
suis ouvert à un autre uC...

> Quelle est la tension de l'alim par J3 ?
- L'alimentation pourra être de 9v à 12V... C'est important???

> A quoi sert R12, C16n R13 et SW-PIC ?
- SW-PIC est un bête interrupteur qui servira pour simuler le bouton
qui existe sur tous les modules KNX.

> - Vérifie le circuit de Reset du µC. La constante de temps R1xC1 me
> parait faible.
- Si je me suis pas trompé ça fait une constante de temps de 1ms.
D'après la doc (page 50) le délai nominal (Trst) est de 20µs.

> - Ajoute une résistance en // sur C1 pour décharger la capa lors de la
> coupure de l'alim.
> - Evite de court-circuiter C1 par le switch même si c'est un condo
> céramique.
- Je me suis basé sur un schéma de Microchip mais si tu as mieux je
suis preneur.

> - Vérifie l'étage de sortie de BIM2 (sortie TTL ou collecteur
> ouvert ?)
- D'après ce que j'ai compris c'est une interface normalisée PEI. Je
vais donc chercher dans la doc de KNX...

> - BIMA et BIMB ne peuvent pas être dans le même boitier car le VCC et
> le GND sont commun. Prend plutôt 4 opto simple.
- On m'a déjà fait la remarque je modifie mon schéma.

> - N'oublie pas la condo de découplage. En général 100nF.
- C'est vrai il faut que j'en rajoute sur les alimentations.

Je modifie tout ça et je vous tiens au courant.

Merci encore
a+

[olivier95800]

Bonjour,

- Ok pour un µC 3.3V, pourquoi pas... Mais toutes tes I/O devront être
en 3V3.
- Oui la tension d'alim est importante. Il faut être dans la plage de
la tension d'entrée du régulateur et du convertisseur. Il ne faut pas
dépasser, non plus, la puissance max du régulateur (plus la tension
d'entrée sera grande, plus grande sera la dissipation).
- Ok pour SW-PIC. Mais à quoi sert la "tripaille" autour, R12, C16 et
R13 ? A mon avis R12 doit suffire.
- 20µs effectivement dans la doc... c'est assez curieux ! Cela veut
dire que l'alimentation doit être stabiliée en moins de 20µs...
- Si tu coupe l'alim, C1 ne peut pas se décharger que par sa propre
résistance interne. Il faudrait mieux mettre en résistance en //. La
valeur doit être au moins 10x supérieure à cette de R1 (pont
diviseur).
- Ajoute une résistance en série avec SW-RESPIC pour décharger C1. La
valeur doit être au moins 10x inférieur à R1 (pont diviseur).
- Je ne sais pas à quoi ressemble l'étage de sortie du BIM mais si
c'est un colecteur ouvert, la liaison avec l'opto ne va pas.
- Un condo de découplage au plus près des CI sur l'alim.
- Pour l'alim par le bus, c'est bien possible... j'avoue ne pas trop
connaitre ce que contient un BIM.

A+

Olivier

[jef2000]

> > - Vérifie l'étage de sortie de BIM2 (sortie TTL ou collecteur
> > ouvert ?)
>
> - D'après ce que j'ai compris c'est une interface normalisée PEI. Je
> vais donc chercher dans la doc de KNX...
J'ai cherché un peu partout et je n'ai rien trouvé. Quand j'ai
construit mon interface avec la BIM, j'ai un peu expérimenté et j'en
suis arrivé à mettre un transistor avant l'opto. Malheureusement je ne
me souviens plus si c'était indispensable ou bien si je l'ai juste
fait par analogie avec l'autre direction pour laquelle l'UART en avait
besoin. En tout cas le schéma suivant fonctionne sans problèmes chez
moi:
http://ouaye.net/linknx/bcu-interface/bc...erface.png

[stephane.herraiz@gmail.com]

N'aurais tu pas mis un transistor avant l'opto pour inverser le signal
(le transistor de l'opto inverse le signal d'entrée) ??

[keldo]

> - Ok pour un µC 3.3V, pourquoi pas... Mais toutes tes I/O devront être
> en 3V3.
Pas si sur car, sauf erreur, les PIC24 acceptent 5V en entrée.
...
Pour rester avec un boitier "facile" comme un DIL-28 mais en 5V, on
pourrait remplacer le PIC24FJ64GA002 par un dsPIC30F2010/2012/2020
mais le brochage n'est malheureusement pas le même, donc il faudrait
une autre platine ; de plus le PIC24 possède 2 UARTs, ce qui peut être
pratique pour du débogguage.
Pour trouver 2 UARTs en 16bits/5V, il faut un dsPIC30 à 40 pins, ce
qui complique encore la platine de test.
Tous les PICs modernes sortent en 3.3V alors il faudra de tout manière
y passer un jour ou l'autre et la pluspart des puces périphériques se
trouvent sans problème en 3.3V aujourd'hui (une EEPROM en SPI serait
bien utile par exemple ...)

> - Je ne sais pas à quoi ressemble l'étage de sortie du BIM mais si
> c'est un colecteur ouvert, la liaison avec l'opto ne va pas.
Un peu de logique va nous aider ici !
Un BCU2, c'est un BIM M113 dans un petit boitier plastique qui
n'expose que un sous ensemble des pins d'interface (=les 10 pins de
l'interface PEI du BCU).
Un BIM M113, c'est un µC 68HC705BE12 avec un transiever pour se
connecter sur le bus EIB.
Les pins Tx et Rx du PEI sont donc des pins du µC 68HC05, il suffit de
voir les caractéristiques de ce dernier pour savoir comment brancher
les optos..
Vous trouverez une confirmation dans ce document ci, dans le tableau
page 2 :
http://www.opternus.de/opternus-componen...M113_a.pdf
Le tableau "PEI-DC Characteristics" de la page 6 est sans doute utile
aussi.
Par contre, je n'ai pas le lien vers la doc du µC 68HC705BE12.

> - Pour l'alim par le bus, c'est bien possible...
Je confirme, ni le BCU/BIM, ni le TP-UART n'ont besoin d'une alim
externe, ils tirent leur propre puissance depuis le bus EIB et sont
capables de fournir quelques mA en 5V (et aussi en 20V pour un BIM) à
un module externe comme un e plaque de boutons-poussoirs, par exemple,
ou, dans notre cas, à des optos coupleurs.

> j'avoue ne pas trop connaitre ce que contient un BIM.
Voila qui est déjà un petit peu moins vrai maintenant ... ;-)

Keldo.

[keldo]

@stephane

Pour la partie TP-UART, j'ai une requète un petit peu spéciale :
La pin "Reset" du TP-UART est bidirectionelle, quand le TP-UART
effectue un reset, il force cette pin à 0V, mais quand le TP-UART
fonctionne normalement le PIC peut aussi forcer cette même pin à 0V
pour provoquer un reset du TP-UART.
Comme on isole le PIC du TP-UART avec des optocoupleurs, il faudra 2
optocoupleurs en tête-bèche pour pouvoir controler cette ligne
bidirectionelle ; et à mon avis il faudra utiliser 2 pins du PIC
(l'une In, l'autre Out) pour que cela fonctonne sans créer de "dead-
lock" entre les 2 optos.
Si les plus spécialistes que moi en électronique (ça ce n'est pas
compliqué) sont d'accord avec mon analyse, serait-il possible
d'ajouter une ligne connectée à la pin "reset" du TP-UART avec une
"entrée" d'opto et une "sortie" d'un autre opto (et ce qu'il faut
d'autres composants pour que la ligne reste à 5V en état passif) ; en
connectant l'autre coté de chaque opto sur une pin séparée du PIC.
Cela simplifirait pas mal le software pour sychroniser le PIC et le TP-
UART si cette ligne "Reset" était controlable.

Keldo.

[stephane.herraiz@gmail.com]

Pour le régulateur LF33CV, la tension d'entrée maximale est de 40V
donc on a de la marge...

> - 20µs effectivement dans la doc... c'est assez curieux ! Cela veut
> dire que l'alimentation doit être stabilisée en moins de 20µs...
Je pense que c'est le contraire... Dans ma logique la durée d'un reset
(mise à la masse de l'entrée) doit être supérieur à 20us pour que l'uC
détecte l'action reset. Le couple RC a pour but de supprimer l'effet
de rebond qui risque de pertuber la détection du reset par l'uC.

> - Ok pour SW-PIC. Mais à quoi sert la "tripaille" autour, R12, C16 et
> R13 ? A mon avis R12 doit suffire.
Même chose la "tripaille" sert à éliminer l'effet de rebond du bouton
poussoir

> - Ajoute une résistance en série avec SW-RESPIC pour décharger C1. La
> valeur doit être au moins 10x inférieur à R1 (pont diviseur).
Ok c'est rajouté

Si tu vois autres choses

[stephane.herraiz@gmail.com]

A t'on vraiment besoin de "lire" la pin reset?
Une simple "écriture suffit" non?

On 27 nov, 23:42, keldo <kelderm...@ibelgique.com> wrote:
> @stephane
>
> Pour la partie TP-UART, j'ai une requète un petit peu spéciale :
> La pin "Reset" du TP-UART est bidirectionelle, quand le TP-UART
> effectue un reset, il force cette pin à 0V, mais quand le TP-UART
> fonctionne normalement le PIC peut aussi forcer cette même pin à 0V
> pour provoquer un reset du TP-UART.
> Comme on isole le PIC du TP-UART avec des optocoupleurs, il faudra 2
> optocoupleurs en tête-bèche pour pouvoir controler cette ligne
> bidirectionelle ; et à mon avis il faudra utiliser 2 pins du PIC
> (l'une In, l'autre Out) pour que cela fonctonne sans créer de "dead-
> lock" entre les 2 optos.
> Si les plus spécialistes que moi en électronique (ça ce n'est pas
> compliqué) sont d'accord avec mon analyse, serait-il possible
> d'ajouter une ligne connectée à la pin "reset" du TP-UART avec une
> "entrée" d'opto et une "sortie" d'un autre opto (et ce qu'il faut
> d'autres composants pour que la ligne reste à 5V en état passif) ; en
> connectant l'autre coté de chaque opto sur une pin séparée du PIC.
> Cela simplifirait pas mal le software pour sychroniser le PIC et le TP-
> UART si cette ligne "Reset" était controlable.
>
> Keldo.