Création/Développement de modules EIB sur base de µC PIC - Version imprimable +- Forum KNX francophone / English KNX forum (https://www.knx-fr.com) +-- Forum : Français (https://www.knx-fr.com/forumdisplay.php?fid=3) +--- Forum : Archives eib-domotique (https://www.knx-fr.com/forumdisplay.php?fid=8) +--- Sujet : Création/Développement de modules EIB sur base de µC PIC (/showthread.php?tid=52) |
Création/Développement de modules EIB sur base de µC PIC - stephane.herraiz@gmail.com - 24/09/2007 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/~scg39398/eibteam/eibteam.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 Création/Développement de modules EIB sur base de µC PIC - keldo - 24/09/2007 > 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" Création/Développement de modules EIB sur base de µC PIC - keldo - 25/10/2007 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" Création/Développement de modules EIB sur base de µC PIC - stephane.herraiz@gmail.com - 13/11/2007 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" Création/Développement de modules EIB sur base de µC PIC - Beaufanamus - 17/11/2007 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? Création/Développement de modules EIB sur base de µC PIC - keldo - 18/11/2007 > 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à). Création/Développement de modules EIB sur base de µC PIC - jef2000 - 18/11/2007 > 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) Création/Développement de modules EIB sur base de µC PIC - stephane.herraiz@gmail.com - 20/11/2007 > 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. Création/Développement de modules EIB sur base de µC PIC - keldo - 21/11/2007 > 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 Création/Développement de modules EIB sur base de µC PIC - olivier95800 - 22/11/2007 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 Création/Développement de modules EIB sur base de µC PIC - stephane.herraiz@gmail.com - 22/11/2007 > 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 Création/Développement de modules EIB sur base de µC PIC - olivier95800 - 23/11/2007 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 Création/Développement de modules EIB sur base de µC PIC - stephane.herraiz@gmail.com - 26/11/2007 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 Création/Développement de modules EIB sur base de µC PIC - jef2000 - 26/11/2007 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) Création/Développement de modules EIB sur base de µC PIC - olivier95800 - 26/11/2007 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+ Création/Développement de modules EIB sur base de µC PIC - olivier95800 - 26/11/2007 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) Création/Développement de modules EIB sur base de µC PIC - jef2000 - 26/11/2007 > 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. Création/Développement de modules EIB sur base de µC PIC - stephane.herraiz@gmail.com - 26/11/2007 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+ Création/Développement de modules EIB sur base de µC PIC - olivier95800 - 27/11/2007 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 Création/Développement de modules EIB sur base de µC PIC - jef2000 - 27/11/2007 > > - 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/bcu-uart-interface.png Création/Développement de modules EIB sur base de µC PIC - stephane.herraiz@gmail.com - 27/11/2007 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) ?? Création/Développement de modules EIB sur base de µC PIC - keldo - 27/11/2007 > - 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. Création/Développement de modules EIB sur base de µC PIC - keldo - 27/11/2007 @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. Création/Développement de modules EIB sur base de µC PIC - stephane.herraiz@gmail.com - 28/11/2007 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 Création/Développement de modules EIB sur base de µC PIC - stephane.herraiz@gmail.com - 28/11/2007 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. |