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

[stephane.herraiz@gmail.com]

donc le PIC24 est une bonne solution, vous croyez pas?

J'ai prévu un bornier I2C pour rajouter une carte externe avec tous
les composants que l'on veut. mais je peux rajouter sur la carte une
eeprom i2C? As tu une idée de ce que tu voudrais?


On 27 nov, 23:15, keldo <kelderm...@ibelgique.com> wrote:
> > - 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-components/Download/BIM_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]

> A t'on vraiment besoin de "lire" la pin reset?
> Une simple "écriture suffit" non?
Sauf erreur, au (re-)démarage du TP-UART, la pin reset indique quand
le TP-UART est pret. Je vais tout de même relire la datasheet encore
une fois pour etre sur d'avoir bien compris.

A suivre ...

[keldo]

> J'ai prévu un bornier I2C pour rajouter une carte externe avec tous
> les composants que l'on veut. mais je peux rajouter sur la carte une
> eeprom i2C? As tu une idée de ce que tu voudrais?

A mon sens, une petite eeprom de 2 ou 4 Ko est plus que suffisante,
comme une 24AA32A de Microchip par exemple, de toute façon, que ce
soit une 8Kb, une 16Kb, ou une 32Kb, le brochage reste le même.
Le but est de pouvoir sauver la valeur des objets (normalement stockée
en RAM) lors d'une perte de la tension du bus ou d'un reset du PIC.
C'est bien sur une fonction optionelle de chaque objet, qui doit être
activée ou non par un flag positionné durant la programmation des
autres flags liés aux objets.
Je ne pense pas que cette fonctionalité (détection perte d'alim) soit
possible sur ta carte de test sans quelques composants additionnels
mais ce n'est pas bien grave, on peut simuler la détection d'une perte
de l'alim facilement et alors on pourra tester la partie du soft qui
sauve et recharge les valeurs en eeprom.
Et puis, dans l'absolu, ce n'est pas une bonne idée de trop souvent
écrire dans la flash du PIC, alors vu le prix d'une petite eeprom
32kb, pourquoi s'en priver, ça peut toujours servir.

Pour le reste, je vais encore bien regarder ton schema pour voir ce
qui reste de disponible comme pins libres sur le PIC, car j'aurais
bien voulu aussi garder disponible le port SPI et 3 pins I/O
supplémentaires (dont 1 interruption) pour une extension en SPI.

Keldo

[keldo]

Pour le cas ou l'inplémentation des optocoupleurs poseraient encore
quelques questions, ce schéma du projet "KNXcalibur" est sans doute
intéressant :
http://www.praus.at/dl.php?url=https://w...eib_gw.sch

[keldo]

AVIS A LA POPULATION :

Pour tous ceux qui ne l'ont pas encore fait, allez vite lire le post
sur "freebus", et le site internet associé aussi, bien sur.
On dirait que quelques allemands sont partit sur la même idée que nous
- malgré quelques différences - et sont bien plus avancés que nous ne
le somme !

[stephane.herraiz@gmail.com]

> Pour tous ceux qui ne l'ont pas encore fait, allez vite lire le post
> sur "freebus", et le site internet associé aussi, bien sur.
> On dirait que quelques allemands sont partit sur la même idée que nous
> - malgré quelques différences - et sont bien plus avancés que nous ne
> le somme !

Je ne comprends pas l'allemand...
C'est un projet KNX? Ils utilisent quoi comme drider de bus?

[stephane.herraiz@gmail.com]

On 2 déc, 00:08, keldo <kelderm...@ibelgique.com> wrote:
> Pour le cas ou l'inplémentation des optocoupleurs poseraient encore
> quelques questions, ce schéma du projet "KNXcalibur" est sans doute
> intéressant :http://www.praus.at/dl.php?url=https://www.auto.tuwien.ac.at/download...

Je me suis basé sur ce schéma pour réaliser le mien... ;-) (bien vu)

[keldo]

> Je ne comprends pas l'allemand...
Aïe, c'est un problème dans ce cas ...

> C'est un projet KNX? Ils utilisent quoi comme driver de bus?
Oui, en gros, ils ont réalisé un module 8 sorties relais 230V AC et un
module 8 entrées binaires 12-24V DC pour le Freebus = le bus EIB.

Ils ont développé leur propre driver de bus en composants discrets et
gèrent la totalité du protocole (y compris le timing des télégrammes)
en software dans le µC.
Ils utilisent un AVR ATMega8L (=? AT89C4051 ?) ou un 89LPC922
(évolution d'un 4051).
Il y a le schéma du driver de bus ici :
http://www.freebus.org/index.php?option=...&Itemid=26
A mon sens, il manque une sérieuse protection contre les surtension,
mais pour le reste c'est d'une simplicité limpide.

Plus étonnant encore, le schéma d'un "Drossel" / "Choke" pour mettre
entre une alim 30Vdc et le bus EIB ... il n'y a pas de bobine ... :
http://www.freebus.org/index.php?option=...&Itemid=56

[olivier95800]

Bonjour,

Moi non plus, je ne comprends pas l'Allemand :-(

Mais d'après moi le montage "Drossel" sert à abaisser la tension qui
alimente le BUS EIB (28V/28.5V) et à retarder sa montée.

A+

Olivier



On 3 déc, 20:10, keldo <kelderm...@ibelgique.com> wrote:
>
> Plus étonnant encore, le schéma d'un "Drossel" / "Choke" pour mettre
> entre une alim 30Vdc et le bus EIB ... il n'y a pas de bobine ... :http://www.freebus.org/index.php?option=com_content&task=view&id=37&I...

[stephane.herraiz@gmail.com]

Tout cela est très intéressant comme quoi ce projet va dans le bon
sens!
Leur projet paraît plus complexe encore que le notre!!!Gloups ils sont
forts ces allemands!!!
Par contre je n'aime pas réinventer la roue, surtout au début!
Quelqu'un a t'il modifié mon schéma depuis peu? Keldo? Olivier?
Il me tarde de développer notre stack KNX-PIC!
Au fait, Microchip vient de sortir des uC 32bits! Ça promet!
a++

[keldo]

> Par contre je n'aime pas réinventer la roue, surtout au début!
> Quelqu'un a t'il modifié mon schéma depuis peu? Keldo? Olivier?
Pour l'instant, j'essaye d'avancer un tout petit peu sur
l'algorithme / le soft, je n'y avais pas touche depuis un certain
temps.
Promis, ce week-end je re-regarde (en detail) ton schema sur Eagle.

[olivier95800]

Bonjour,

Je n'ai pas d'autre remarque depuis celles du 26 et 27 novembre.

Olivier

On 5 déc, 18:01, "stephane.herr...@gmail.com"
<stephane.herr...@gmail.com> wrote:
> Tout cela est très intéressant comme quoi ce projet va dans le bon
> sens!
> Leur projet paraît plus complexe encore que le notre!!!Gloups ils sont
> forts ces allemands!!!
> Par contre je n'aime pas réinventer la roue, surtout au début!
> Quelqu'un a t'il modifié mon schéma depuis peu? Keldo? Olivier?
> Il me tarde de développer notre stack KNX-PIC!
> Au fait, Microchip vient de sortir des uC 32bits! Ça promet!
> a++

[keldo]

@ Stephane
> Par contre je n'aime pas réinventer la roue, surtout au début!
> Quelqu'un a t'il modifié mon schéma depuis peu? Keldo? Olivier?

Bonjour Stephane.
Alors comme promis,j'ai encore bien reflechi au schema.
En faisant une petit recapitulatif, j'arrive a :
1) Il faut supprimer le convertisseur DC-DC et l'alim 5V qui le suit,
le tout est inutile car le BIM s'alimente depuis le bus et sa pin 5V
est une sortie.
2) Les circuits autour des deux switches (SW-PIC et SW-RESPIC) doit
etre modifie : y ajouter 2 resistances (pour chaque switch) afin de
viderl e condo et de ne pas le court-circuiter.
3) On peut mettre le JP6 avant les optocoupleurs afin de reduire leur
nombre a 2 au lieu de 4, mais ce n'est pas fort important car rien
n'oblige de souder les 4 si seulement un seul mode de connection au
bus est utilise.
4) Il y a un doute sur le cablage des optocoupleurs, surtout sur ceux
des pattes "Rx" a mon avis ; je vais reflechir a la question ce soir
et je posterai un petit schema demain soir.

J'amerais y ajouter les points siuvants :
5) Si j'etais toi, je supprimerais le JP-EIB, le SW-BIM, R30 et
LED5 ... ainsi que le BIM2 !
Un BCU2 a placer dans un boitier mural, ce n'est rien d'autre qu'un
BIM113 sous boitier plastique avec moins de pins accessibles. Pour
ceux qui desirent utiliser le mode FT1.2 plutot qu'un TP-UART, ce
serait stupide de s'amuser a commander specifiquement un BIM113 chez
Opternus et payer des frais de transport alors que nous avons surement
tous a la maison un BCU2 disponible pour nos tests ... et si non il
est sans doute plus facile d'en acheter un que de commander chez
Opternus. De plus, une fois les tests finis, ce BCU2 pourra servir
aautre chose dans la maison. Bref, pour moi, toute la partie "BIM" du
circuit sera avantageusement remplacee par un petit connecteur male
2x5 pins pour connecter la plaque de dvlpmt sur un BCU2
"classique" (et peu importe la marque de ce dernier). Le brochage de
ce 2 x 5 pins est disponible sur le net (mais je n'ai pas le lien sous
la main a l'instant) et un petit cable plat 10 fils + 2 connecteurs (1
male cote BCU2, un femelle cote plaque dvlpmt). Seul 5 pins seront a
cabler : GND, 5V (pour alimenter les optos), Tx, Rx et PEItype, le
reste est inutile.
Sur la platine de dvlpmt, il faut garder R29 pour le coder le type
PEI, connectee directement au connecteur 2 x 5, mais je pense que elle
doit etre branchee au 5V et non a GND ...
6) J'ai comme un doute avec le brochage de certaines lignes du TP-
UART, je te dis quoi demain soir.
7) Les lignes RTS et CTS sont elles bien utiles sur l'UART vers le
PC ? Il ne reste plus grand chose de disponible comme pins sur le
PIC ...
8) Le bus I2C et son petit connecteur pour une extension sont tres
bien, n'y touchons pas. Par contre, j'aimerais beaucoup utiliser le
port SPI1 sur les pins 4 (SDI1), 5 (SDO1) et 14 (SCK1OUT) pour relier
le PIC a une petite EEPROM externe, elle aussi sur la platine de
dvlpmt. Je propose une petite 25LC160A comme exemple mais cela a peu
d'importance puisque le brochage 8 pins est le meme pour quasi toutes
les tailles. Comme l'eeprom sera le seul peripherique SPI relie au
PIC, on peut se contenter de 3 lignes (SDO, SDI et SCK) et fixer la
valeur des 5 autres pattes de l'eeprom une fois pour toute. Comme les
pins 4 et 5 du PIC sont aussi utilisees pour la programmation, on peut
eventuellement prevoir un petit bloc de jumpers pour choisir entre
eeprom et port ICD2.
9) A quoi va servir le second crystal de 32,768 kHz ? Est-ce bien
utile ?
10) Sur la page 1, a droite du JP-LINK, les labels "Rx" et "Tx"
seraient utilement remplace par (respectivement) "Tx-PIC" et "Rx-PIC".


Pour le reste, le projet Freebus et la lecture attentive des
possibilites du TP-UART m'ont donne une idee assez interessante.
J'ecrirai a ce sujet d'ici tres peu de temps.

[stephane.herraiz@gmail.com]

Wouaa super, merci de faire avancer la chose!
Je vais de ce pas bosser sur le schéma!
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...
Au fait le second crystal crystal de 32,768 kHz sert pour la RTC (real
time clock) du pic, utile si on veut gérer le temps.
A+

On 11 déc, 18:49, keldo <kelderm...@ibelgique.com> wrote:
> @ Stephane
>
> > Par contre je n'aime pas réinventer la roue, surtout au début!
> > Quelqu'un a t'il modifié mon schéma depuis peu? Keldo? Olivier?
>
> Bonjour Stephane.
> Alors comme promis,j'ai encore bien reflechi au schema.
> En faisant une petit recapitulatif, j'arrive a :
> 1) Il faut supprimer le convertisseur DC-DC et l'alim 5V qui le suit,
> le tout est inutile car le BIM s'alimente depuis le bus et sa pin 5V
> est une sortie.
> 2) Les circuits autour des deux switches (SW-PIC et SW-RESPIC) doit
> etre modifie : y ajouter 2 resistances (pour chaque switch) afin de
> viderl e condo et de ne pas le court-circuiter.
> 3) On peut mettre le JP6 avant les optocoupleurs afin de reduire leur
> nombre a 2 au lieu de 4, mais ce n'est pas fort important car rien
> n'oblige de souder les 4 si seulement un seul mode de connection au
> bus est utilise.
> 4) Il y a un doute sur le cablage des optocoupleurs, surtout sur ceux
> des pattes "Rx" a mon avis ; je vais reflechir a la question ce soir
> et je posterai un petit schema demain soir.
>
> J'amerais y ajouter les points siuvants :
> 5) Si j'etais toi, je supprimerais le JP-EIB, le SW-BIM, R30 et
> LED5 ... ainsi que le BIM2 !
> Un BCU2 a placer dans un boitier mural, ce n'est rien d'autre qu'un
> BIM113 sous boitier plastique avec moins de pins accessibles. Pour
> ceux qui desirent utiliser le mode FT1.2 plutot qu'un TP-UART, ce
> serait stupide de s'amuser a commander specifiquement un BIM113 chez
> Opternus et payer des frais de transport alors que nous avons surement
> tous a la maison un BCU2 disponible pour nos tests ... et si non il
> est sans doute plus facile d'en acheter un que de commander chez
> Opternus. De plus, une fois les tests finis, ce BCU2 pourra servir
> aautre chose dans la maison. Bref, pour moi, toute la partie "BIM" du
> circuit sera avantageusement remplacee par un petit connecteur male
> 2x5 pins pour connecter la plaque de dvlpmt sur un BCU2
> "classique" (et peu importe la marque de ce dernier). Le brochage de
> ce 2 x 5 pins est disponible sur le net (mais je n'ai pas le lien sous
> la main a l'instant) et un petit cable plat 10 fils + 2 connecteurs (1
> male cote BCU2, un femelle cote plaque dvlpmt). Seul 5 pins seront a
> cabler : GND, 5V (pour alimenter les optos), Tx, Rx et PEItype, le
> reste est inutile.
> Sur la platine de dvlpmt, il faut garder R29 pour le coder le type
> PEI, connectee directement au connecteur 2 x 5, mais je pense que elle
> doit etre branchee au 5V et non a GND ...
> 6) J'ai comme un doute avec le brochage de certaines lignes du TP-
> UART, je te dis quoi demain soir.
> 7) Les lignes RTS et CTS sont elles bien utiles sur l'UART vers le
> PC ? Il ne reste plus grand chose de disponible comme pins sur le
> PIC ...
> 8) Le bus I2C et son petit connecteur pour une extension sont tres
> bien, n'y touchons pas. Par contre, j'aimerais beaucoup utiliser le
> port SPI1 sur les pins 4 (SDI1), 5 (SDO1) et 14 (SCK1OUT) pour relier
> le PIC a une petite EEPROM externe, elle aussi sur la platine de
> dvlpmt. Je propose une petite 25LC160A comme exemple mais cela a peu
> d'importance puisque le brochage 8 pins est le meme pour quasi toutes
> les tailles. Comme l'eeprom sera le seul peripherique SPI relie au
> PIC, on peut se contenter de 3 lignes (SDO, SDI et SCK) et fixer la
> valeur des 5 autres pattes de l'eeprom une fois pour toute. Comme les
> pins 4 et 5 du PIC sont aussi utilisees pour la programmation, on peut
> eventuellement prevoir un petit bloc de jumpers pour choisir entre
> eeprom et port ICD2.
> 9) A quoi va servir le second crystal de 32,768 kHz ? Est-ce bien
> utile ?
> 10) Sur la page 1, a droite du JP-LINK, les labels "Rx" et "Tx"
> seraient utilement remplace par (respectivement) "Tx-PIC" et "Rx-PIC".
>
> Pour le reste, le projet Freebus et la lecture attentive des
> possibilites du TP-UART m'ont donne une idee assez interessante.
> J'ecrirai a ce sujet d'ici tres peu de temps.

[jef2000]

> Sur la platine de dvlpmt, il faut garder R29 pour le coder le type
> PEI, connectee directement au connecteur 2 x 5, mais je pense que elle
> doit etre branchee au 5V et non a GND ...
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.

[keldo]

@Stephane
> Je pensais avoir déjà supprimer le convertisseur 5V sur mon schéma...
> J'ai fait des modifications sur mon schéma mais je ne l'ai pas sur moi
> (je suis en déplacement), notamment sur les opto (erreurs sur les
> masses) et l'alimentation...

Ben, moi j'ai imprimé la version pdf qui se trouve parmis les fichier
sur ce forum, mais la date du fichier .sch n'est pas plus récente ...
n'aurais-tu pas oublié d'uploader la version modifiée ?

Pour le connecteur du BCU2, le lien est :
http://www.dehof.de/eib/pdfs/BIM_Schaltplan.pdf
Il y a tout ce qu'il nous faut sur la page 3.


Pour information, je suis actuellment en train de me documenter
serieusement sur l'usage du C30 sur le PIC24. J'ai commandé le livre
"Learning to fly the PIC24" ( http://www.flyingpic24.com ) et j'espère
avancer à grand pas dans son étude dès le semaine prochaine.
Bref, j'ai bien compris que le meilleur moyen de venir à bout du code
pour un stack EIb est de passer par du C, quitte à optimiser quelques
routines en les ré-écrivant en ASM ensuite.


@Jef2000
> Il serait peut-être intéressant de prévoir la place pour une
> seconde résitance en parallèle, comme ça si on n'a pas la
> valeur exacte (c'est une valeur un peu exotique), on peut la
> "fabriquer" en connectant 2 résistances de valeurs
> courantes en parallèle.
Très bonne remarque, 45.3 kOhms en 1 %, ça ne court pas les rues.

En passant, as-tu vu que le webmaster de Freebus.org parle de LinKNX
sur son site ?
Va voir en bas de la page http://www.freebus.org/index.php?option=...&Itemid=67


- - - - - - -


Maintenant, à propos de ma nouvelle idée ...
Cela fait un petit moment que je lis et relis le datasheet du TP-UART,
et franchement je trouve le produit un peu entre deux chaises ... soit
il en fait trop, soit pas assez, mais en tout cas il ne fait pas ce
que j'aimerais, c'est à dire supprimer totalement la contrainte de
réponse par le PIC dans un temps déterminé et assez court.
Pour 10 euros, j'aurais voulu mieux ...
Finalement, c'est le schéma de base du projet Freebus qui provoqué le
déclic :
L'idéal serait de disposer d'un super TP-UART aux fonctions étendues,
ci-après dénomé "TP-I2C-PIC".
Attention, ce qui suit plus bas constitue toujours un "périphérique de
communication", il faudra donc encore y connecter un composant maitre
"intelligent" quelconque dont la puissance est TRES variable (un
16F877 pourrait suffire pour une application simple mais on peut aussi
imaginer de connecter un PC surpuissant pour réaliser une méga-
supervision avec gestion de 60.000 objets EIB ...) ; en tout état de
cause, le PIC24H cité plus bas NE contiendra PAS d'application
spécifique au projet de chacun, mais bien un programme écrit une fois
pour toute.

A) Le hardware.
En gros, on prend le schéma du projet freebus ici :
http://www.freebus.org/index.php?option=...&Itemid=26
et on y ajoute :
- le deux pinoches pour recevoir un connecteur EIB.
- un PIC 24HJ12GP201 (18pins c'est juste ce qu'il faut, et il existe
aussi en DIP pour les essais).
- un SMBJ40CA pour tout protèger contre les surtensions (ça manque sur
le schema de Freebus).
- un connecteur 2 x 5 pins.
- un "gros" condensateur (de l'ordre de 100µF) pour garder un peu de
jus durant une courte coupure du bus EIB (ça manque aussi sur le
schema de Freebus).
- deux résistances de haute précision (30k et 2k, 1/4W, 0.1%) ainsi
qu'un condo de 0.1µF (ou plus gros ?), pour pouvoir mesurer la tension
réelle du bus via le port ADC du PIC.
- OPTIONNEL : une puce mémoire EEPROM ou, mieux, Flash, commandée en
SPI par le PIC et d'une taille généreuse, jusqu'à maximum 2Mbits.
Inutile dans la quasi totalité des cas (= jusqu'à 2048 adresses de
groupes).
Personellement, je remplacerais aussi la 1N4148 du schema Freebus par
une 1N4936, mais si ça marche bien comme ça ...
En gros, pour tout ceci, on reste dans une fourchette de 10 euros
(hors mémoire SPI optionelle), soit pas plus cher qu'une puce TP-UART.

B) Fonctionalités.
Le circuit repris du schéma Freebus fourni du 3,3V à partir du bus et
se charge de l'interface physique avec le bus.
Le PIC24H va gèrer tout le protocol bas niveau avec le bus EIB -
timing des bits, priorité, CSMA-CA, etc. (on peut s'inspirer du code
de Freebus, avec leur accord bien sur ...) et donc faire tout ce que
fait un TP-UART.

Les 2 résistances de haute précision constituent un diviseur de
tension pour permettre au PIC24H de mesurer la tension du bus
régulièrement. Le condo 0.1 µF compense la haute impédance de ce
diviseur pour le module ADC du PIC24H.

Au dela des fonctions du TP-UART, le PIC24H aura dans sa mémoire
l'adresse physique du participant ainsi que la totalité de la table
des adresses de groupe (si nécessaire dans la puce mémoire externe en
SPI, avec un maximum de 2Mbits, ce qui couvre les 65535 adresses de
groupe possibles). Ces deux informations ne devront plus être stockée
dans le "maitre" qui contiendra l'application proprement dite.
Comme le PIC24H dispose de ces info, il peut prendre entièrement en
charge :
En réception,
- le filtrage des télégrammes "utiles" pour le "maitre".
- le controle de la parité et du byte de checksum.
- la gestion de la réponse ACK, NACK, BUSY.
- la gestion des télégrammes répétés suite à un NACK ou un BUSY.
- la mise en buffer des télégrammes "utiles" non encore traités par le
"maitre".
En émission,
- la génération de la parité et du byte de checksum.
- la gestion des réponses ACK, NACK, BUSY.
- la répétition des télégrammes suite à un NACK ou un BUSY.
- la mise en buffer des télégrammes non encore envoyés ("maitre" trop
rapide ou bus encombré).


C) L'interface avec le maitre.
Physiquement, l'interface avec le maitre se limite à quelques lignes,
2 minimum.
Le circuit TP-I2C-PIC peut discuter avec son maitre via une liaison
I2C (si le TP-I2C-PIC est esclave I2C, il faut prévoir une 3ième ligne
afin de pouvoir générer une interruption sur le maitre/maitre I2C).
Il est aussi possible de faire une liaison asynchrone vers le maitre
avec l'UART, il suffit alors de modifier un tout petit bout du
software dans le PIC24H.
Il est possible que le circuit TP-I2C-PIC fournisse du 3,3V à sont
maitre, mais il faut bien calculer les consommations pour ne pas trop
charger le bus EIB.
Si une isolation galvanique est nécessaire, on peut la réaliser
facilement avec des optocoupleurs en mode UART, mais c'est nettement
moins simple en I2C (voir la page 15 du document
http://www.nxp.com/acrobat_download/othe..._82b96.pdf ).
D'un point de vue protocole, le maitre n'a pas besoin de garder la
table des adresses de groupe, donc le PIC24H va enlever cette info des
télégrammes reçu pour la remplacer par l'index dans la table des
liaisons aux objets avant de les mettre en buffer pour le maitre ; le
traitement inverse est vrai aussi en transmission de télégramme vers
le bus.
Vu que le PIC24H peut mesurer la tension du bus EIB, il est possible
de lui faire envoyer un signal du type "EIB bus power failure" vers le
maitre si nécessaire.

Il est peut-être aussi possible de déléguer au PIC24H du circuit TP-
I2C-PIC la gestion des sessions dans le cadre des communications
"connection-oriented" (re-progrmmation des tables EIB ou de
l'application, etc. ) mais je n'ai pas encore une assez bonne maitrise
de cette partie du stack EIB pour me faire une idée.



Le design du hardware est quasi fini, vu le circuit Freebus existant
et ne conporterait que des pièces "classiques".
Le software serait un mix du code Freebus et de celui pour notre
platine de développement.
Un fois ce module développé (hard + soft), écrire la partie haute du
stack EIB et des applications (= le soft du "maitre") deviendrait un
jeu d'enfant en C.

Voila l'idée. Qu'en pensez-vous ?

[stephane.herraiz@gmail.com]

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 ?

[jef2000]

@keldo
> 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é).
En gros, tu veux fabriquer un BCU pour 10 euros... Le prix de
fabrication des vrais BCU est probablement du même ordre, sauf que
pour le vrai, le prix de vente inclut également le développement
software (et accessoirement les bénéfices des sociétés qui ont investi
dedans). Mais si tu es prêt à nous faire le développement software
pour pas un rond, je ne peux que saluer l'initiative. Si j'avais
suffisamment de temps libre, je me lancerait volontiers aussi dans
l'aventure. En attendant que cette solution aie fait ses preuves, je
pense que je vais rester sur mon idée d'utiliser des BCU2 (ou BIM M113
si je trouve d'autres personnes intéressées pour commander en
quantités raisonnables).

A+
Jean-François

[keldo]

Bonsoir.

Un petit mot en vitesse pour vous signale que j'ai definitivement
change mon fusil d'epaule : je suis passe au C pour le code source en
cours.
J'ai recu il y a quelques jours les bouquins que j'avais commande et
je suis en train de lire :
- Learning to fly the PIC24 - Programming 16-bits microcontrollers in
C.
ainsi que
- Embedded Multitasking, with small microcontrollers.
Jusqu'ici je ne regrette pas mes achats, les livres sont tres
interessants et donnent des idees, de plus mes cours de C d'il y a 10
ans me reviennent judicieusement en memoire.
Bref, cela carbure et j'ai debute aujourd'hui la reecriture du code
pour le stack EIB en C sur PIC24.

Avec tout cela, j'en ai oublie le probleme des optocoupleurs et de la
pin reset du TP-UART pour la platine ... mais ca vient bientot, c'est
dans le pipeline comme on dit ...

Keldo.

[stephane.herraiz@gmail.com]

Bonsoir,
Tout d'abord bonne année!
Ton bouquin a l'air pas mal...
Moi je me suis équipé du kit de développement de PIC24 l'exploreur 16
de Microchip.
Ça donne une bonne idée des possibilités des PIC24!! De plus il y a
des connecteurs où il serait facile d'ajouter un TPUART...
J'ai mis en ligne le schéma mis à jour. Je pense avoir réglé le
problème des optocoupleurs.
Pour ce qui est du soft je suis en train d'écrire une doc (à base de
schémas fonctionnelles) du driver de TPUART pour uc Intel (http://
homepages.fh-regensburg.de/~scg39398/eibteam/eibteam.htm). Cela me
semble une bonne base et le code et complet!
Keldo si j'ai bien compris tu te bases sur le projet freebus?


On 26 déc 2007, 01:18, keldo <kelderm...@ibelgique.com> wrote:
> Bonsoir.
>
> Un petit mot en vitesse pour vous signale que j'ai definitivement
> change mon fusil d'epaule : je suis passe au C pour le code source en
> cours.
> J'ai recu il y a quelques jours les bouquins que j'avais commande et
> je suis en train de lire :
> - Learning to fly the PIC24 - Programming 16-bits microcontrollers in
> C.
> ainsi que
> - Embedded Multitasking, with small microcontrollers.
> Jusqu'ici je ne regrette pas mes achats, les livres sont tres
> interessants et donnent des idees, de plus mes cours de C d'il y a 10
> ans me reviennent judicieusement en memoire.
> Bref, cela carbure et j'ai debute aujourd'hui la reecriture du code
> pour le stack EIB en C sur PIC24.
>
> Avec tout cela, j'en ai oublie le probleme des optocoupleurs et de la
> pin reset du TP-UART pour la platine ... mais ca vient bientot, c'est
> dans le pipeline comme on dit ...
>
> Keldo.

[olivier95800]

Bonjour,

1. Si R1=R2=10k, C1 va se charger à 3V3 / 2. J'avais signalé
précédemment que R2 > 10 x R1.
2. idem pour R3/R12. Même si je ne vois toujours pas l'intérêt de
toute cette tripaille pour simuler "le bouton qui existe sur tous les
modules KNX"
3. et les résistances en série avec les SW, pour éviter de court-
circuiter les capas ?
4. ne pas oublier la capa de 0.1µF au plus près de la broche VCC du
MAX3222.
5. Le TPUART fournit 5mA sur sa broche TXD alors que l'opto 6N136
nécessite 25mA (!)
6. Il y a peut être le même pb avec la broche TXD du BIM

dans quelle famille comptes tu prendre le 7404 ? il faut s'assurer que
la sortie puisse fournir 25mA.

Olivier

[keldo]

> Pour ce qui est du soft je suis en train d'écrire une doc (à base de
> schémas fonctionnelles) du driver de TPUART pour uc Intel (http://
> homepages.fh-regensburg.de/~scg39398/eibteam/eibteam.htm). Cela me
> semble une bonne base et le code et complet!
Merci pour le lien, je vais jetter un coup d'oeil.

> Keldo si j'ai bien compris tu te bases sur le projet freebus?
Non, pas pour l'instant, j'ai plusieurs idées mais un projet à la fois
c'est suffisant, donc je reste toujours sur :
- un PIC24 (je teste sur un dsPIC30 mais en gros c'est pareil...).
- un TP-UART ou un BCU2/BIM113 comme interface avec le bus.

L'idée générale derrière mon soft en développement, c'est de faire
"tourner" le stack EIB entièrement durant les interruptions, avec la
partie application qui serait la boucle principale.
C'est clair que la gestion des interruptions sur les PIC 16bits est
nettement plus agréable pour implémenter mon idée (6 niveaux + nesting
= le pied).

Pour ce qui est de l'idée sur base de Freebus, on verra quand le
projet en cours tournera.

Il y a quelques jours, j'ai monté un TP-UART sur une platine d'essai
et j'ai un problème bizarre : sur la sortie du TP-UART, je reçois les
deux premiers octets des télégrammes (EIB ctrl field + 1ière moitié de
l'adresse de l'exp.) et puis ... plus rien !?!
Et ce n'est pas un problème avec le PIC vu qu'il n'y en a encore aucun
dans le circuit ...
Si jamais quelqu'un a une idée, je suis preneur.

[jef2000]

Bonjour,

> 1. Si R1=R2=10k, C1 va se charger à 3V3 / 2. J'avais signalé
> précédemment que R2 > 10 x R1.
Effectivement, là il y a un problème. A mon avis, on peut simplement
supprimer R2, de toute façon si le 3v3 tombe à 0 la capa va se
décharger via R1
> 3. et les résistances en série avec les SW, pour éviter de court-
> circuiter les capas ?
En théorie, il faut effectivement mettre une résistance en série pour
éviter un pic de courant dans le switch qui va générer une étincelle
et à la longue abimer le switch. Comme c'est un bouton qui ne sera pas
utilisé intensivement, je pense que ça fonctionnerait très bien sans,
mais c'est plus propre avec.
> 6. Il y a peut être le même pb avec la broche TXD du BIM
En ce qui concerne le TP-UART, je laisse la réponse aux spécialistes.
Pour le BIM, l'alimentation 5V peut fournir max 10mA, pour mon
interface BIM, j'ai utilisée des optos CNX62A qui sont moins rapides
(c'est vraiment nécessaire d'zvoir des optos si rapides??) mais
consomment moins de 10mA. J'ai également ajouter un transistor PNP
avant l'opto car au repos, le BIM sort du +5V sur TX, donc sans
transistor l'opto serait allumé en permanence.
Détails: voir schéma: http://ouaye.net/linknx/bcu-interface/bc...erface.png

> dans quelle famille comptes tu prendre le 7404 ? il faut s'assurer que
> la sortie puisse fournir 25mA.
Pas vu de 7404 :-(

Jean-François

[keldo]

> En ce qui concerne le TP-UART, je laisse la réponse aux spécialistes.
> Pour le BIM, l'alimentation 5V peut fournir max 10mA, pour mon
> interface BIM, j'ai utilisée des optos CNX62A qui sont moins rapides
> (c'est vraiment nécessaire d'zvoir des optos si rapides??) mais
> consomment moins de 10mA. J'ai également ajouter un transistor PNP
> avant l'opto car au repos, le BIM sort du +5V sur TX, donc sans
> transistor l'opto serait allumé en permanence.
> Détails: voir schéma:http://ouaye.net/linknx/bcu-interface/bcu-uart-interface.png

Pour le TP-UART, même combat que le BIM : on peut sortir 10mA maximum.

Comme on va travailler en 19200 bps, on peut estimer la vitesse
minimale des optos :
Un bit = environ 1/20000 s = environ 0.05 ms = environ 50µs.
Donc, à la grosse louche, il faut des optos qui prennent moins de 2 ou
3 µs pour une transition, voir 5 µs grand max.

[keldo]

Dans le cas de notre montage (ligne série sans ligne d'horloge ni de
synchro), la vitesse de l'opto n'est pas trop critique, la chose
importante c'est que la vitesse de montée de l'opto soit proche de sa
vitesse de descente - de l'ordre de 2 à 3 µs - afin de garder la durée
des bits 0 et 1 équivallente.

Pour info, "mes" petits optos 4 pattes LTV-817 possèdent les
caractéristiques suivantes :
- montée et descente typique : environ 4µs.
- un courant de 5 mA en entrée sur la diode donne un courant de 5mA
en sortie sur le transistor, peu importe la tension emetteur-
collecteur.

Ce devrait convenir, non ?