stephane.herraiz@gmail.com
Unregistered
Que penses tu du PIC24FJ64GA002? Il a l'avantage d'être dispo sur
SPDIP et Il y a une carte de développement :
http://www.microchip.com/stellent/idcplg...e=en529760
Le seul problème de cette carte est son port USB au lieu d'un simple
port série...
On 27 août, 17:35, connexium <h.de...@connexium.fr> wrote:
> Pour les PIC24, le compilateur uCHIP (licence étudiante gratuite,
> seules certaines options d'optimisation sont bloquées, qu'il ne faut
> d'ailleurs pas utiliser avec le stack IP !) fonctionne très bien et a
> l'avantage d'être parfaitement intégré à l'interface. Après, il suffit
> de comparer le résultat de la compilation d'un code C vers du PIC18
> (je ne parle même pas du PIC16) et du PIC24 pour comprendre la
> différence considérable (qui se vérifie très bien en pratique) de
> performance des composants. Il me paraît donc dommage de partir sur
> une famille, certes pas vraiment obsolète, mais complètement dépassée,
> sans réel avantage financier. Le seul avantage des anciennes familles
> (il y en a un) est la disponibilité de boîtiers plus pratiques pour un
> amateur. On ne peut pas tout avoir ! Mais un amateur éclairé n'aura
> pas de réel problème avec un boîtier PQFP 64.
Eagle est effectivement un bon choix.
Pour une platine d'essai, que signifie "pas trop cher" ?
Nous utilisons actuellement des PIC24HJ256GP206 et GP210, et nous
faisons fabriquer nos cuivres à des prix très compétitifs. Le mieux
serait d'essayer de définir le schéma, puis de voir la fabrication
d'un premier prototype. Vous serez probablement surpris du coût
raisonnable s'il ya quelques exemplaires, et il n'y a alors aucune
contrainte à l'utilisation de CMS, bien au contraire (plus pratiques).
Mais essayer de réaliser un circuit (double face minimum, et suffisant
si bien conçu) au pas de 0,5 avec des moyens amateurs n'est pas
jouable. Bref, je suis disposé à apporter mon aide (schéma et circuit
imprimé, fabrication, pas le temps pour le soft) si le projet prend
une tournure favorable.
On 28 août, 17:20, "stephane.herr...@gmail.com"
<stephane.herr...@gmail.com> wrote:
> Moi j'utilise Eagle qui est gratuit est très utilisé.
>
> Pour le choix des pic c'est un casse tête.... ;-)
>
> connexium si tu sais on on pourrait trouver une platine d'essai pas
> trop cher pour les PIC24, on pourrait essayer de partir la dessus avec
> un peu d'aide de ta part...
> Une fois les développement fait, il effectivement pas trop difficile
> de graver des cartes adaptées.
> Moi j'ai jamais manipulé les cms mais je pense qu'il va falloir que je
> m'y fasse...
>
> Il faut quand même un sérieux investissement...
>
> On 27 août, 17:37, keldo <kelderm...@ibelgique.com> wrote:
>
> > On 20 août, 12:24, Krysto <kyre...@gmail.com> wrote:
>
> > > Pour les prix, c'est cool effectivement d'avoir trouvé chez Farnell.
> > > Peut être prevoir un achat groupé pour faire baisser le prix du TPUART
> > > et de la globalité de la commande.
> > > Ensuite, on repartit le tout entre nous. Vous en pensez quoi ?
>
> > Pour les TP-UART je ne connais qu'un seul fournisseur :www.opternus.de
> > et j'en ai déjà 8.
> > Pour les autre composants, je ne suis pas contre l'idée d'un achat
> > groupé mais il faut voir à quelle distance on habite l'un de l'autre
> > et/ou combien cela couterait de redispatcher les composants à chacun,
> > il n'est pas dit que l'on y gagne ...
> > En gros, moi je suis entre Bruxelles et Lille, et je vais
> > régulièrement sur Bruxelles.
> > De toute façon, autour du TP-UART il n'y a vraiment que les deux
> > diodes de protection contre les surtensions que j'ai déjà citées qui
> > soient un peu dificiles à trouver, le reste c'est résistances et
> > condos, rien de chinois.
>
> > Mon plus gros "ennui" coté composants actuellement, c'est que le TP-
> > UART n'existe que en format SOIC, donc en CMS, ce qui signifie que
> > pour mon montage sur une platine de test je vais devoir trouver un
> > module de conversion SOIC 20 pattes vers DIP 20 pins, et çà,
> > justement, chez Farnell ça coute une fortune alors que le web-shop
> > asiatique que tu proposait en propose pour une croute de pain...
> > Bref, si je ne trouve pas d'adaptateur SOIC-DIP dans un magasin à
> > Bruxelles, je vais sans doute devoir bricoler en ajoutant des bouts de
> > fils comme je devrai le faire sur les deux diodes spéciales (elles
> > sont aussi en CMS).
>
> > Ce serai sans doute plus simple avec un circuit imprimé sur mesure
> > mais on en est pas encore la, loin s'en faut ...
> > A ce propos (circuits imprimés), comme je n'avais pas d'expérience
> > dans le domaine, ni aucun logiciel de dessin donc, je me suis lancé
> > avec le freeware "KiCAD". Bien sur il manquait les composants pour
> > l'EIB, je suis en train d'en créer 3 ou 4 utiles comme le TP-UART et
> > l'embase EIB à 2 pins.
> > Cette semaine je vais regarder pour ouvrir le mini site web dont j'ai
> > déjà parlé, je pense pouvoir mettre une page web et deux ou trois
> > fichiers utiles en ligne pour le week-end prochain, dont les fichiers
> > pour KiCAD.
Bonjour.
Concernant les PIC18, je ne suis pas trop positif.
Quand on regarde bien les caractéristiques des PIC18 il semble que -
en gros - ce soit un coeur de PIC16 avec des "rustines" pour adresser
plus de mémoire. C'est pas très "propre" comme design.
Personellement, je ne vois que deux bonnes raisons de vouloir utiliser
des PIC18 :
1) Avoir besoin d'un port USB.
2) Avoir une application déjà développée pour PIC16 et vouloir la
porter sur une puce un petit peu plus "grosse" ou avec plus
d'interfaces sans trop de changements au code.
Pour le reste, je rejoins l'avis de Connexium : Si le besoin d'un
PIC18 se fait sentir, il est temps de passer sur un 24/ds30/ds33.
Dans la famille de ces PIC plus puissants, je trouve que les puces
dsPIC30F4011 et dsPIC30F4013 ont de bons atouts :
- déjà une belle taille mémoire.
- dispo en DIP 40 pins.
- fonctionnent aussi en 5V ... oui, ne pas oublier que les PIC24F/H et
les dsPIC33 sont tous en 3,3 volts.
- une zone eeprom (pour rappel, il n'y en a pas dans les 24 et 33 ...
et dans un PIC24H, la flash supporte entre 100 et 1000 cycles
d'écriture seulement).
stephane.herraiz@gmail.com
Unregistered
Si j'ai bien compris, keldo, tu veux développé sur assembleur?
Je vais chercher sur internet des bouts de code en C pour PIC24 pour
notre projet. Je ne veux pas tout réinventer si cela existe déjà.
Je suis en train d'étudier le protocole EIB et il y a beaucoup de
chose... un PIC 16 aura du mal....
connexium combien coûterait (fourchette de prix) par exemple quelques
prototypes avec un PIC24 et sa connection série?
Au fait le 3.3V ou 5V c'est la même chose...
On 29 août, 23:53, keldo <kelderm...@ibelgique.com> wrote:
> Bonjour.
>
> Concernant les PIC18, je ne suis pas trop positif.
> Quand on regarde bien les caractéristiques des PIC18 il semble que -
> en gros - ce soit un coeur de PIC16 avec des "rustines" pour adresser
> plus de mémoire. C'est pas très "propre" comme design.
> Personellement, je ne vois que deux bonnes raisons de vouloir utiliser
> des PIC18 :
> 1) Avoir besoin d'un port USB.
> 2) Avoir une application déjà développée pour PIC16 et vouloir la
> porter sur une puce un petit peu plus "grosse" ou avec plus
> d'interfaces sans trop de changements au code.
> Pour le reste, je rejoins l'avis de Connexium : Si le besoin d'un
> PIC18 se fait sentir, il est temps de passer sur un 24/ds30/ds33.
>
> Dans la famille de ces PIC plus puissants, je trouve que les puces
> dsPIC30F4011 et dsPIC30F4013 ont de bons atouts :
> - déjà une belle taille mémoire.
> - dispo en DIP 40 pins.
> - fonctionnent aussi en 5V ... oui, ne pas oublier que les PIC24F/H et
> les dsPIC33 sont tous en 3,3 volts.
> - une zone eeprom (pour rappel, il n'y en a pas dans les 24 et 33 ...
> et dans un PIC24H, la flash supporte entre 100 et 1000 cycles
> d'écriture seulement).
PIC24 ou PIC33, le choix doit se faire en fonction des
caractéristiques des périphériques, mais le coeur est le même et
excellent (quelques bugs surprenants quand même). Pour un port série,
il vaut mieux utiliser une fonction du processeur que de la refaire en
soft. Le PIC18 est un choix bâtard, on est tombés dans le piège (stock
à vendre...), les perfos réelles sont décevantes. 5V ou 3,3V,
aujourd'hui, ça ne pose pas vraiment problème, il n'y a d'ailleurs
souvent pas le choix. Pour l'eeprom, la remarque est juste, mais on
ajoute alors une eeprom externe I2C pour un coût ridicule. Pour un
cuivre fabriqué en quelques pièces, il faut compter en gros 10€
(double face, trous métallisés, sérigraphié vernis professionnel),
c'est donc abordable, et le seul moyen d'être efficace. Il faut
ensuite ajouter les composants (Farnell ou Radiospares sont la
référence haute, mais intéressante pour du proto). Enfin, le
compilateur C MPLAB C30 pour cette famille fonctionne très bien, dispo
en version gratuite, contrairement au compilateur pour PIC18. L'usure
de la flash en debug intensif n'est pas à négliger, mais on a quand
même le temps.
stephane.herraiz@gmail.com
Unregistered
Effectivement je trouve pas ça très cher! Ils faut que tu nous
fournisses les coordonnées.
Je vais éplucher la doc du IC24FJ64GA002 (il me semble suffisant pour
le moment) pour essayer de réaliser une platine d'essai sous eagle.
Peut être as tu déjà un début de plan...?
Au fait, on part sur les BIM M13x ou les TP-UART finalement ???? moi
je penche pour les BIM pour un début.
On 30 août, 21:04, "stephane.herr...@gmail.com"
<stephane.herr...@gmail.com> wrote:
> Au fait, on part sur les BIM M13x ou les TP-UART finalement ???? moi
> je penche pour les BIM pour un début.
Point de vue prix (opternus) :
- BIM avec stack ver. 2.x = environ 40 euros
- TP-UART avec composants annexes = environ 15 euros
Mais, si on se lance dans la fabrication d'une dizaine de platines
d'eesai, pourquoi ne pas prévoir les deux interfaces directement ?
Il suffit de prévoir les pistes pour le TP-UART (+ quelques composants
discrets) ET le connecteur pour la prise PEI du BCU/BIM, après, on
peut toujours décider de ne pas souder les composants pour l'un ou
l'autre, ça ne devrait quasi rien changer au prix de la platine. Il
suffirait de prévoir les pistes depuis les pins TX, RX et GND du PIC
pour les deux cas, éventuellement avec des jumpers pour choisir l'une
ou l'autre interface.
Pour le TP-UART, il faut compter une puce SOIC-20 pattes et une
quinzaine de composants classiques ou SMD (diodes, résistances, petits
condensateurs, un crystal) + les 2 pinoches pour la borne de bus EIB.
Le schema quasi complet est disponible dans la datasheet du TP-UART
(en mode "normal").
Entre le PIC et le TP-UART il faut compter minimum 4 liens (TX, RX,
GND et Reset) et maximum 7 liens (TX,RX, Reset, 5V, GND, Save,
Temperature Warning).
Pour le coté BCU/BIM, il faut TX, RX et GND vers le PIC mais il faut
aussi prévoir une résistance de haute précision (voir même plusieurs
en série si la valeur exacte n'existe pas) pour connecter les pins 5V
et PEI-Type du BCU/BIM.
Cela va compliquer un petit peu le schema mais ajouter une isolation
optique entre le PIC et le BCU/BIM ou le TP-UART peut être une bonne
idée. Dans ce cas il faut prévoir une alim externe pour le PIC.
(La ligne Reset du TP-UART étant bidirectionelle, actif = 0 Volts, il
faut sans doute deux pins du PIC et 2 optocoupleurs pour cette ligne
si elle est protégée).
Si on décide de se passer de l'isolation optique, on peut peut-être
alimenter le PIC depuis le TP-UART ou le BCU/BIM mais il faudrait
calculer la consommation du PIC et des éventuels accessoires ; au
total, pour une platine d'expérimentation, ce n'est sans doute pas une
bonne idée.
- - - - -
Admettons que l'on mette les optocoupleurs et une alim externe, je
propose alors de mettre une entrée pour une alim de 12V DC et
d'ajouter sur la platine la place pour les composants (style LM7805)
afin de prévoir une sortie 5V DC et une sortie 3,3V DC.
Une grande partie des PIC haut de gamme (je n'aime pas écrire PIC
16bits, cela porte à confusion avec les PIC "16F" - pour le "16" - et
les PIC 18F - qui codent leurs instructions sur 16 bits - alors que
les PIC "16bits" codent leurs instructions sur 24 bits ...) ont plus
d'un UART, ce serait sympa de prévoir aussi sur la platine de test une
prise RS-232 (avec MAX232 ou optocoupleurs) vers le second UART afin
de brancher notre petit montage en direct sur un PC, cela peut se
réveler très pratique pour le débugage et pour utiliser un bootloader.
Bien sur, ne pas oublier d'ajouter les pistes pour une led et un
microswitch avec le condo et la résistance d'anti-rebond (= led et
bouton de programmation de l'adresse physique sur un BCU).
Autre idée : ajouter un connecteur pour ICD2 ou prévoir des points de
connection équivalents pour les 5 signaux nécessaires serait
certainement judicieux, toujours pour la programmation et le
débuggage.
Enfin, selon la façon dont est facturé la fabrication de petites
series de platine (sans doute un forfait pour une taille maximum
donnée), il est peut être judicieux de remplir "l'espace vide" de la
platine avec :
- l'emplacement pour une petite puce I²C ou SPI (et sa piste "Chip
Select") pour ajouter l'eeprom qu'il n'y a plus dans les PIC haut de
gamme.
- l'emplacement pour un connecteur (ou plusieurs) pour cable plat,
permettant de relier les ports I/O du PIC avec d'autres cartes
contenant des périphériques (un module relais, dimmers, capteurs de
températures, etc.).
- l'emplacement pour quelques puces SOIC (14, 18, 20 ou 28 pattes) si
l'on désire ajouter l'un ou l'autre périphérique en SMD.
- des bandes latérales pré-trouées avec les signaux GND, 3.3V, 5V,
SPI, I²C, etc.
- une grille de trous métalisés.
Voila, j'ai donné mes idées en vitesse mais c'est à discuter.
Si il y a de la place pour ajouter quelques composants "perso" sur la
platine et que le prix reste dans la gamme d'une dizaine d'euros, je
suis intéressé par 5 ou 6 pièces.
De mon coté, je continue doucement à écrire mon assembleur pour le
877A mais j'écris de toute façon d'abord du pseudo code en français et
je le laisse en commentaire dans mon code source, donc :
1) c'est un bon exercice pour apprendre les PIC16 - j'ai d'autres
projets en tête pour eux de toute manière.
2) avec le pseudo code en français, j'aurai fait le plus gros du
travail d'analyse, ce sera alors facile de porter tout cela en C (ou
Pascal) quand je passerai sur PIC haut de gamme, ce qui arrivera de
toute façon bientôt car mon projet principal en EIB (gestion de
chaudière évoluée + paneaux solaires en appoint) va sans doute occuper
trop de place en mémoire et l'application serait bien plus facile avec
la gestion de la multiplication sur des réels en hardware ...
D'un autre coté, j'ai un très bon cours sur les PIC16 (et 18) mais
rien sur les PIC haut de gamme, je devrai sans doute tatoner un peu
plus au début sur un PIC24.
Pfiouu, j'avais pas remarqué mais ça fait une sacré tartine, mon
message précédent ;-)
stephane.herraiz@gmail.com
Unregistered
Je suis d'accord avec toi pour ce "grand" cahier des charges.
Cela permettra de développer confortablement.
Allez au boulot!
On 31 août, 17:36, keldo <kelderm...@ibelgique.com> wrote:
> On 30 août, 21:04, "stephane.herr...@gmail.com"
>
> <stephane.herr...@gmail.com> wrote:
> > Au fait, on part sur les BIM M13x ou les TP-UART finalement ???? moi
> > je penche pour les BIM pour un début.
>
> Point de vue prix (opternus) :
> - BIM avec stack ver. 2.x = environ 40 euros
> - TP-UART avec composants annexes = environ 15 euros
>
> Mais, si on se lance dans la fabrication d'une dizaine de platines
> d'eesai, pourquoi ne pas prévoir les deux interfaces directement ?
> Il suffit de prévoir les pistes pour le TP-UART (+ quelques composants
> discrets) ET le connecteur pour la prise PEI du BCU/BIM, après, on
> peut toujours décider de ne pas souder les composants pour l'un ou
> l'autre, ça ne devrait quasi rien changer au prix de la platine. Il
> suffirait de prévoir les pistes depuis les pins TX, RX et GND du PIC
> pour les deux cas, éventuellement avec des jumpers pour choisir l'une
> ou l'autre interface.
>
> Pour le TP-UART, il faut compter une puce SOIC-20 pattes et une
> quinzaine de composants classiques ou SMD (diodes, résistances, petits
> condensateurs, un crystal) + les 2 pinoches pour la borne de bus EIB.
> Le schema quasi complet est disponible dans la datasheet du TP-UART
> (en mode "normal").
> Entre le PIC et le TP-UART il faut compter minimum 4 liens (TX, RX,
> GND et Reset) et maximum 7 liens (TX,RX, Reset, 5V, GND, Save,
> Temperature Warning).
>
> Pour le coté BCU/BIM, il faut TX, RX et GND vers le PIC mais il faut
> aussi prévoir une résistance de haute précision (voir même plusieurs
> en série si la valeur exacte n'existe pas) pour connecter les pins 5V
> et PEI-Type du BCU/BIM.
>
> Cela va compliquer un petit peu le schema mais ajouter une isolation
> optique entre le PIC et le BCU/BIM ou le TP-UART peut être une bonne
> idée. Dans ce cas il faut prévoir une alim externe pour le PIC.
> (La ligne Reset du TP-UART étant bidirectionelle, actif = 0 Volts, il
> faut sans doute deux pins du PIC et 2 optocoupleurs pour cette ligne
> si elle est protégée).
> Si on décide de se passer de l'isolation optique, on peut peut-être
> alimenter le PIC depuis le TP-UART ou le BCU/BIM mais il faudrait
> calculer la consommation du PIC et des éventuels accessoires ; au
> total, pour une platine d'expérimentation, ce n'est sans doute pas une
> bonne idée.
>
> - - - - -
>
> Admettons que l'on mette les optocoupleurs et une alim externe, je
> propose alors de mettre une entrée pour une alim de 12V DC et
> d'ajouter sur la platine la place pour les composants (style LM7805)
> afin de prévoir une sortie 5V DC et une sortie 3,3V DC.
>
> Une grande partie des PIC haut de gamme (je n'aime pas écrire PIC
> 16bits, cela porte à confusion avec les PIC "16F" - pour le "16" - et
> les PIC 18F - qui codent leurs instructions sur 16 bits - alors que
> les PIC "16bits" codent leurs instructions sur 24 bits ...) ont plus
> d'un UART, ce serait sympa de prévoir aussi sur la platine de test une
> prise RS-232 (avec MAX232 ou optocoupleurs) vers le second UART afin
> de brancher notre petit montage en direct sur un PC, cela peut se
> réveler très pratique pour le débugage et pour utiliser un bootloader.
>
> Bien sur, ne pas oublier d'ajouter les pistes pour une led et un
> microswitch avec le condo et la résistance d'anti-rebond (= led et
> bouton de programmation de l'adresse physique sur un BCU).
>
> Autre idée : ajouter un connecteur pour ICD2 ou prévoir des points de
> connection équivalents pour les 5 signaux nécessaires serait
> certainement judicieux, toujours pour la programmation et le
> débuggage.
>
> Enfin, selon la façon dont est facturé la fabrication de petites
> series de platine (sans doute un forfait pour une taille maximum
> donnée), il est peut être judicieux de remplir "l'espace vide" de la
> platine avec :
> - l'emplacement pour une petite puce I²C ou SPI (et sa piste "Chip
> Select") pour ajouter l'eeprom qu'il n'y a plus dans les PIC haut de
> gamme.
> - l'emplacement pour un connecteur (ou plusieurs) pour cable plat,
> permettant de relier les ports I/O du PIC avec d'autres cartes
> contenant des périphériques (un module relais, dimmers, capteurs de
> températures, etc.).
> - l'emplacement pour quelques puces SOIC (14, 18, 20 ou 28 pattes) si
> l'on désire ajouter l'un ou l'autre périphérique en SMD.
> - des bandes latérales pré-trouées avec les signaux GND, 3.3V, 5V,
> SPI, I²C, etc.
> - une grille de trous métalisés.
>
> Voila, j'ai donné mes idées en vitesse mais c'est à discuter.
> Si il y a de la place pour ajouter quelques composants "perso" sur la
> platine et que le prix reste dans la gamme d'une dizaine d'euros, je
> suis intéressé par 5 ou 6 pièces.
>
> De mon coté, je continue doucement à écrire mon assembleur pour le
> 877A mais j'écris de toute façon d'abord du pseudo code en français et
> je le laisse en commentaire dans mon code source, donc :
> 1) c'est un bon exercice pour apprendre les PIC16 - j'ai d'autres
> projets en tête pour eux de toute manière.
> 2) avec le pseudo code en français, j'aurai fait le plus gros du
> travail d'analyse, ce sera alors facile de porter tout cela en C (ou
> Pascal) quand je passerai sur PIC haut de gamme, ce qui arrivera de
> toute façon bientôt car mon projet principal en EIB (gestion de
> chaudière évoluée + paneaux solaires en appoint) va sans doute occuper
> trop de place en mémoire et l'application serait bien plus facile avec
> la gestion de la multiplication sur des réels en hardware ...
>
> D'un autre coté, j'ai un très bon cours sur les PIC16 (et 18) mais
> rien sur les PIC haut de gamme, je devrai sans doute tatoner un peu
> plus au début sur un PIC24.
Merci Keldo pour toutes ces bonnes idées.
Je vous laisse cogiter sur la partie électronique.
Pour en revenir aux questions posées sur le protocole FT1.2 j'ai
quelques précisions.
FT1.2 n'est rien d'autre qu'un protocole permettant de transférer des
blocs de données simultanément et de manière fiable entre la BCU et un
autre système.
Son avantage est de ne nécessiter que les connections RXD, TXD et GND,
contrairement à son prédécesseur (PEI type 16) qui nécessite une
gestion très fine des signaux RTS/CTS
Si on se penche d'un peu plus près sur ce qui peut être transmis dans
ces "blocs de données" (voir chapitre 3/6/3 "External message
interface" de la spec), on remarque qu'une BCU permet l'accès à
plusieurs niveaux:
1) Data Link layer (bus monitor)
2) Data Link layer (normal)
3) Transport layer
4) User layer
Si je ne me trompe, le mode busmonitor n'est pas intéressant car il
permet uniquement d'écouter le bus mais pas d'envoyer
L'accès à la couche Data link en mode normal est celui qu'utilise EIBD
lorsqu'on crée un groupsocket. Il permet de recevoir les données
concernant toutes les adresses de groupes et d'envoyer des données
vers n'importe quelle adresse de groupe. Je pense que dans ce cas, la
gestion des Ack/Nack doit être faite par l'utilisateur.
Si on accède à la couche transport, j'ai cru comprendre qu'elle gère
les ack/nack/retransmission pour nous
Enfin si on accède à la couche utilisateur, il est possible de
laisser à la BCU la gestion des objets de groupe et d'aller simplement
lire la valeur (localement dans la BCU) d'un objet, la modifier et
positionner les flags pour lui indiquer ce qu'il faut faire. Le format
des messages est décrit sommairement au paragraphe "4.5 User layer
EMI" et certaines explication complémentaires peuvent être trouvées
dans le chapitre 3/4/1 "User layer" paragraphe "6 Externally
accessible user layer interface"
Comme d'habitude tout est dans la spec, c'est d'ailleurs son utilité
première. Malheureusement pour ceux à qui ça pose problème, elle est
en anglais.
En conclusion, FT1.2 est capable de faire quelque chose de plus ou
mois similaire à TPUART, mais il est également capable de beaucoup
plus, tout dépend comment on veut l'utiliser.
Merci à tous pour vos contributions, il y a quelques mois à peine, je
désespérais en croyant être le seul martien à avoir ce genre d'idées
en tête ;-)
On 3 sep, 10:23, "stephane.herr...@gmail.com"
<stephane.herr...@gmail.com> wrote:
> Je suis d'accord avec toi pour ce "grand" cahier des charges.
> Cela permettra de développer confortablement.
> Allez au boulot!
>
> On 31 août, 17:36, keldo <kelderm...@ibelgique.com> wrote:
>
> > On 30 août, 21:04, "stephane.herr...@gmail.com"
>
> > <stephane.herr...@gmail.com> wrote:
> > > Au fait, on part sur les BIM M13x ou les TP-UART finalement ???? moi
> > > je penche pour les BIM pour un début.
>
> > Point de vue prix (opternus) :
> > - BIM avec stack ver. 2.x = environ 40 euros
> > - TP-UART avec composants annexes = environ 15 euros
>
> > Mais, si on se lance dans la fabrication d'une dizaine de platines
> > d'eesai, pourquoi ne pas prévoir les deux interfaces directement ?
> > Il suffit de prévoir les pistes pour le TP-UART (+ quelques composants
> > discrets) ET le connecteur pour la prise PEI du BCU/BIM, après, on
> > peut toujours décider de ne pas souder les composants pour l'un ou
> > l'autre, ça ne devrait quasi rien changer au prix de la platine. Il
> > suffirait de prévoir les pistes depuis les pins TX, RX et GND du PIC
> > pour les deux cas, éventuellement avec des jumpers pour choisir l'une
> > ou l'autre interface.
>
> > Pour le TP-UART, il faut compter une puce SOIC-20 pattes et une
> > quinzaine de composants classiques ou SMD (diodes, résistances, petits
> > condensateurs, un crystal) + les 2 pinoches pour la borne de bus EIB.
> > Le schema quasi complet est disponible dans la datasheet du TP-UART
> > (en mode "normal").
> > Entre le PIC et le TP-UART il faut compter minimum 4 liens (TX, RX,
> > GND et Reset) et maximum 7 liens (TX,RX, Reset, 5V, GND, Save,
> > Temperature Warning).
>
> > Pour le coté BCU/BIM, il faut TX, RX et GND vers le PIC mais il faut
> > aussi prévoir une résistance de haute précision (voir même plusieurs
> > en série si la valeur exacte n'existe pas) pour connecter les pins 5V
> > et PEI-Type du BCU/BIM.
>
> > Cela va compliquer un petit peu le schema mais ajouter une isolation
> > optique entre le PIC et le BCU/BIM ou le TP-UART peut être une bonne
> > idée. Dans ce cas il faut prévoir une alim externe pour le PIC.
> > (La ligne Reset du TP-UART étant bidirectionelle, actif = 0 Volts, il
> > faut sans doute deux pins du PIC et 2 optocoupleurs pour cette ligne
> > si elle est protégée).
> > Si on décide de se passer de l'isolation optique, on peut peut-être
> > alimenter le PIC depuis le TP-UART ou le BCU/BIM mais il faudrait
> > calculer la consommation du PIC et des éventuels accessoires ; au
> > total, pour une platine d'expérimentation, ce n'est sans doute pas une
> > bonne idée.
>
> > - - - - -
>
> > Admettons que l'on mette les optocoupleurs et une alim externe, je
> > propose alors de mettre une entrée pour une alim de 12V DC et
> > d'ajouter sur la platine la place pour les composants (style LM7805)
> > afin de prévoir une sortie 5V DC et une sortie 3,3V DC.
>
> > Une grande partie des PIC haut de gamme (je n'aime pas écrire PIC
> > 16bits, cela porte à confusion avec les PIC "16F" - pour le "16" - et
> > les PIC 18F - qui codent leurs instructions sur 16 bits - alors que
> > les PIC "16bits" codent leurs instructions sur 24 bits ...) ont plus
> > d'un UART, ce serait sympa de prévoir aussi sur la platine de test une
> > prise RS-232 (avec MAX232 ou optocoupleurs) vers le second UART afin
> > de brancher notre petit montage en direct sur un PC, cela peut se
> > réveler très pratique pour le débugage et pour utiliser un bootloader.
>
> > Bien sur, ne pas oublier d'ajouter les pistes pour une led et un
> > microswitch avec le condo et la résistance d'anti-rebond (= led et
> > bouton de programmation de l'adresse physique sur un BCU).
>
> > Autre idée : ajouter un connecteur pour ICD2 ou prévoir des points de
> > connection équivalents pour les 5 signaux nécessaires serait
> > certainement judicieux, toujours pour la programmation et le
> > débuggage.
>
> > Enfin, selon la façon dont est facturé la fabrication de petites
> > series de platine (sans doute un forfait pour une taille maximum
> > donnée), il est peut être judicieux de remplir "l'espace vide" de la
> > platine avec :
> > - l'emplacement pour une petite puce I²C ou SPI (et sa piste "Chip
> > Select") pour ajouter l'eeprom qu'il n'y a plus dans les PIC haut de
> > gamme.
> > - l'emplacement pour un connecteur (ou plusieurs) pour cable plat,
> > permettant de relier les ports I/O du PIC avec d'autres cartes
> > contenant des périphériques (un module relais, dimmers, capteurs de
> > températures, etc.).
> > - l'emplacement pour quelques puces SOIC (14, 18, 20 ou 28 pattes) si
> > l'on désire ajouter l'un ou l'autre périphérique en SMD.
> > - des bandes latérales pré-trouées avec les signaux GND, 3.3V, 5V,
> > SPI, I²C, etc.
> > - une grille de trous métalisés.
>
> > Voila, j'ai donné mes idées en vitesse mais c'est à discuter.
> > Si il y a de la place pour ajouter quelques composants "perso" sur la
> > platine et que le prix reste dans la gamme d'une dizaine d'euros, je
> > suis intéressé par 5 ou 6 pièces.
>
> > De mon coté, je continue doucement à écrire mon assembleur pour le
> > 877A mais j'écris de toute façon d'abord du pseudo code en français et
> > je le laisse en commentaire dans mon code source, donc :
> > 1) c'est un bon exercice pour apprendre les PIC16 - j'ai d'autres
> > projets en tête pour eux de toute manière.
> > 2) avec le pseudo code en français, j'aurai fait le plus gros du
> > travail d'analyse, ce sera alors facile de porter tout cela en C (ou
> > Pascal) quand je passerai sur PIC haut de gamme, ce qui arrivera de
> > toute façon bientôt car mon projet principal en EIB (gestion de
> > chaudière évoluée + paneaux solaires en appoint) va sans doute occuper
> > trop de place en mémoire et l'application serait bien plus facile avec
> > la gestion de la multiplication sur des réels en hardware ...
>
> > D'un autre coté, j'ai un très bon cours sur les PIC16 (et 18) mais
> > rien sur les PIC haut de gamme, je devrai sans doute tatoner un peu
> > plus au début sur un PIC24.
Ludovic50750
Unregistered
A propos des modules perso,
peut etre est-ce hors-contexte, mais vous-êtes vous demandé quel
serait la réaction du consuel face à des elements EIB fait maison dans
un tableau electrique?
Ok, si on les rajoute apres son passage, ils n'en sauront rien :p ,
mais si on les installe avant leur passage, voire meme si le tableau
est "vide", quelle est leur reaction ?
quelqu'un s'est il deja interessé à ce point ?
On 4 sep, 16:07, Ludovic50750 <l.lemari...@gmail.com> wrote:
> vous-êtes vous demandé quel
> serait la réaction du consuel face à des elements EIB fait maison dans
> un tableau electrique?
En quoi est-ce que le Consuel est concerné ?
Il est chargé de vérifier l'installation électrique sur base de la
règlementation en vigeur.
Je n'ai que le petit bouquin Promotelec, faudrais voir avec le
règlement complet, mais çà m'étonnerais fort qu'on en parle.
Ludovic lemarinel
Unregistered
Ben peut etre que le fait qu'il n'y ait pas de logo "CE" sur les boitiers
les generais ??
je n'en sais rien, c'est juste une idée en passant !
Le 04/09/07, Marc Assin <raymond@warichet.com> a écrit :
>
>
> On 4 sep, 16:07, Ludovic50750 <l.lemari...@gmail.com> wrote:
> > vous-êtes vous demandé quel
> > serait la réaction du consuel face à des elements EIB fait maison dans
> > un tableau electrique?
>
> En quoi est-ce que le Consuel est concerné ?
> Il est chargé de vérifier l'installation électrique sur base de la
> règlementation en vigeur.
>
> Je n'ai que le petit bouquin Promotelec, faudrais voir avec le
> règlement complet, mais çà m'étonnerais fort qu'on en parle.
>
>
On 4 sep, 16:07, Ludovic50750 <l.lemari...@gmail.com> wrote:
> A propos des modules perso,
> peut etre est-ce hors-contexte, mais vous-êtes vous demandé quel
> serait la réaction du consuel face à des elements EIB fait maison dans
> un tableau electrique?
> Ok, si on les rajoute apres son passage, ils n'en sauront rien :p ,
> mais si on les installe avant leur passage, voire meme si le tableau
> est "vide", quelle est leur reaction ?
>
> quelqu'un s'est il deja interessé à ce point ?
Salut.
A mon sens, la question n'est pas dénuée d'intérêt mais on peut
l'élargir :
Imaginons que l'on ait bricolé "maison" un module EIB avec 4 sorties
triac pour commander (et pourquoi pas dimmer) 4 lampes ; et voyons
quelques cas de figures "Shit happens !" :
Cas 1) Un triac surchauffe (radiateur mal calculé et prévu trop
petit), crâme et fout le feu à la baraque ... Que va dire l'assurance
incendie ?
Cas 2) Le circuit imprimé est mal conçu, laiise tout d'un coup passer
du 230V AC sur le bus EIB et quelqu'un s'électrocute ! Pas de chance,
l'électrocuté ne vous aime pas beaucoup et vous traine en justice ...
Cas 3) Le software de notre BCU maison s'affole, envoie des
télégrammes aléatoirement, ce qui referme votre porte de garage. Pas
de chance, le vélo du fils de votre voisine est dans le chemin et se
fait écraser par la porte de garage !
Si vous imaginez d'autres cas, n'hésitez pas ...
Alors voyons :
Pour les cas 1 et 2, n'importe quel électronicien amateur prend ce
genre de risque quand il fabrique, par exemple, son propre ampli HiFi,
ou n'importe quel autre montage branché en permanence sur secteur
proposé dans un magasine d'électronique amateur.
En gros, quand on joue avec du 230V AC sur circuit imprimé, pensons à
bien séparer les pistes avec le 230V du reste et ajoutons joyeusement
des optocoupleurs, ensuite emballons le tout dans un boitier bien
fermé.
Il y a aussi sérieusement intérêt à vérifier et faire vérifier ses
montages avant de brancher le tout.
Au final, un petit détecteur de fumée placé juste au dessus du tableau
électrique, c'est pas cher payé pour dormir tranquille.
Pour le cas 3, il est assez difficile de prouver votre faute, de plus,
un tel problème peut aussi arriver si on utilise uniquement du
matériel EIB officiel mais que le système est mal programmé. Tout ceci
pour dire que le niveau de risque est à mon avis le même que quand on
programme soit même son installation EIB avec ETS, ce que font la
plupart des participants à ce forum.
Il n'empêche, rêvons un peu et imaginons que notre futur module EIB/
PIC rencontre un grand succès, un jour il sera peut-être intéressant
de se cotiser afin de le faire certifier, sachant qu'il y a un "stress
test" avec des télégrammes défectueux dans la procédure de
certification.
Reste la question de départ : Quid du "Consuel" (France ?) ou de "AIB/
Vinceotte" (Belgique).
Etant belge, je ne peux répondre pour la France, mais pour la Belgique
cela ne doit en principe pas poser de problème tant que les règles :
- de protection (calibre de câbles / disjoncteur , différentiels, mise
à la terre) et
- d'isolation (distance minimale entre BT et TBTS, prévention des
contacts avec les parties sous tension)
seront respectées, car il n'y a pas à ma connaissance de règlement
spécifique pour les "organes de commande" que sont nos actionneurs
EIB, et le problème ne se pose évidemment pas avec les capteurs.
Ludovic50750
Unregistered
Petite parenthese lexicale : on dit "Electrisé" d'un electrocuté
vivant... S'il est electrocuté, c'est que le malheureux y est resté
(paix à son ame)
S'il est vivant on dira donc electrisé 
Sinon, pour l'info, OKW vends des boitiers encastrable dans les
tableaux electriques sur RAIL DIN de différentes tailles, avec
connecteurs borniers, facade transparente ou opaque, etc...
Ils ont un beau catalogue (voir leur site internet, google est votre
ami).
stephane.herraiz@gmail.com
Unregistered
Plusieurs questions :
- Avez vous un schéma d'un régulateur de tension (5V ou autre) dont la
source de tension est le bus EIB? En fait je pensais utiliser
l'alimentation du bus et utiliser un convertisseur CC-CC avec
isolation galvanique. Du coup pas d'alimentation externe.
- J'ai du mal à trouver la consommation d'un PIC 24F. Une idée?
Bonsoir
Avec un TP-UART, le 5V peut être fourni par le TP-UART lui-même,
jusqu'à 10mA. Selon le datasheet du composant, la sortie est protégée
contre les courts-circuits.
Reste que le PIC24F s'alimente entre 2.5V typique et 3.6V max, ce qui
impose un régulateur supplémentaire. Le LM1117 peut faire l'affaire.
Pour le PIC24F, en se basant sur le datasheet du composant (http://
ww1.microchip.com/downloads/en/DeviceDoc/39747C.pdf), j'ai trouvé
quelques infos :
- 10mA max de conso en mode programmation (page 207)
- conso de la CPU variable en fonction de son activité (page 203) :
1.6mA typ, 4mA max à 1MIPS, jusqu'à 20ma type, 32 mA max à 16 MIPS
- ajouter à ça la conso des périphs en fonction de leur utilisation.
Mais là, j'ai rien trouvé dans le datasheet. Si c'est comme les micros
que j'ai déjà utilisés, le convertisseur analogique est souvent très
gourmant, surtout si on lui fait souvent changer de canal
d'acquisition.
Donc, une alim par le TP-UART semble bien juste, à moins de faire
travail la CPU au ralenti ou ne pas lui demander grand chose côté
périphériques.
Au fil des lectures, j'avais vu un schéma d'une interface EIB / RS232
pour faire un espion de bus simple. Ils alimentent l'interface par la
tension de bus, ce qui doit répondre à ce que tu cherches :
http://stielec.ac-aix-marseille.fr/cours...#interface
Toutefois, ce schéma me paraît un peu trop simple : ça doit aller pour
un montage expérimental sans trop d'abonnés sur le bus, parce que,
mine de rien, leur alim 5v est juste fabriquée avec une zener, une
résistance de 1K et une capa de filtrage de 1uF. Ce qui présente une
charge capacitive non négligeable sur le bus. Si on met plusieurs
abonnés comme ça sur le bus, je crains que le signal EIB se trouve
trop atténué.
Sur la base de ce schéma, j'aurais donc tendance à ajouter une self en
série avec la résistance, histoire de faire un bon filtre basse-bas
avec une fréquence de coupure assez loin des 9600khz du signal. Et je
remplacerais la zener par un régulateur intégré afin d'éviter les
pertes. Parce que le simple montage résistance de 1K + zener de 5V
représente déjà une conso à vide de 24mA sur le bus, et une
dissipation de presque 0.6W dans la résistance.
J'ai cherché un peu : j'ai trouvé un régulateur qui me semble pas
mal : LM2936. Existe en version 3.3V et 5V, admet une tension d'entrée
max de 60V (donc ok avec les 35V max du bus EIB) et peut délivrer un
courant max de 50mA. J'ai trouvé le composant en version TO92 chez
radiospares (un peu cher... 8 euros). Il existe aussi en so8 pour un
montage CMS. 50mA max me semble suffisant pour faire pas mal de trucs
sans alim supplémentaire.
En tout cas, merci à tous pour la démarche. J'espère pouvoir trouver
du temps pour un coup de main. Je n'ai jamais développé sur PIC, mais
développer des cartes micro et des softs de comm a été mon dada (et
mon boulot) il y a qq années. Et grâce à vos échanges, je sens le
virus revenir.
Le montage de stielec est juste un translateur de niveau pour une
interface RS232, et fonctionne très bien dans ce cas. Il ne faut pas
trop se polariser sur des aspects secondaires comme l'alim, c'est pas
très compliqué, et il est préférable de s'orienter vers du découpage
(bien fait) que vers du linéaire qui à un très mauvais rendement quand
on passe de 30 à 3,3V. Avant de choisir les composants, il est donc
préférable de mettre en évidence les contraintes (courant max, bruit
injecté...), le choix est alors affaire d'expérience. La consommation
d'un processeur est très variable selon la fréquence et les
périphériques utilisés, il est donc difficile de l'estimer à priori
sans calculs pas évidents et sans outils logiciels, mais un PIC24
consomme peu et ne devrait pas poser de problème, quand on sait qu'un
module EIB peut allumer des leds.
Bonjour.
Comme promis, j'ai mis en ligne les premiers fichiers issus de ma
réflexion.
Ce n'est vraiment pas grand chose pour l'instant mais ... petit à
petit, l'oiseau f
Bonsoir.
Comme promis, j'ai mis en ligne les premiers fichiers issus de ma
réflexion.
Ce n'est vraiment pas grand chose pour l'instant mais ... "petit à
petit, l'oiseau fait son nid".
Bref, le lien est :
http://eib.jesuispour.eu/
Bonne lecture.
On 7 sep, 00:54, alain <alain.houtek...@laposte.net> wrote:
> Bonsoir
>
> Avec un TP-UART, le 5V peut être fourni par le TP-UART lui-même,
> jusqu'à 10mA. Selon le datasheet du composant, la sortie est protégée
> contre les courts-circuits.
>
> Reste que le PIC24F s'alimente entre 2.5V typique et 3.6V max, ce qui
> impose un régulateur supplémentaire. Le LM1117 peut faire l'affaire.
Selon la doc du TP-UART il est aussi possible de lui faire sortir du
3.3V mais j'ai pas vu comment ...
> Donc, une alim par le TP-UART semble bien juste, à moins de faire
> travail la CPU au ralenti ou ne pas lui demander grand chose côté
> périphériques.
Bof, peut-être pour les petits projet ça pourrait suffire ...
Mais ce n'est pas franchement le but pour l'instant, sur une carte de
test il vaut mieux avoir de la marge pour bricoler.
> J'ai cherché un peu : j'ai trouvé un régulateur qui me semble pas
> mal : LM2936. Existe en version 3.3V et 5V, admet une tension d'entrée
> max de 60V (donc ok avec les 35V max du bus EIB) et peut délivrer un
> courant max de 50mA. J'ai trouvé le composant en version TO92 chez
> radiospares (un peu cher... 8 euros). Il existe aussi en so8 pour un
> montage CMS. 50mA max me semble suffisant pour faire pas mal de trucs
> sans alim supplémentaire.
En principe, un participant sur le bus EIB ne peut pas consommer plus
de 10mA/30V en moyenne, voir même 5mA/30V de préférence et moins c'est
encore mieux, mais rien ne lui interdit de consommer plus de temps à
autre pour une période très courte, comme par exemple pour commuter un
relais bi-stable.
Donc on peut même viser une valeur un peu plus élevée comme 100mA/5V à
condition que en moyenne le montage total ne pompe pas plus de 30mA/5V
(TP-UART, PIC et accessoires compris).
En ces temps de consommation raisonnée de l'énergie, il faut bien
réfléchir quand on fabrique un module qui va rester allumé et donc
consommer en permanence, ce qui est le cas des modules EIB.
C'est pourquoi je propose de prendre un régulateur à faible perte et
qui consomme le moins possible en stand-by.
Une petite recherche sur Farnell.com me sort des prix plus acceptables
que 8 euros :
1) LM9036MM-3.3 (NATIONAL SEMICONDUCTOR)
- le moins cher à 0.88 euro pièce ou 6.90 euro pour 10 pièces
- entrée max 55V
- sortie 3.3V à max 50mA
- LDO , cms à 8 pattes
2) LF33ABV (ST Microelectronics)
- pas cher à 1.11 euro pièce ou 7.30 euro pour 10 pièces
- entrée max 40V
- sortie 3.3V à max 500mA (bien plus qu'il n'en faut)
- LDO , TO-220 à 3 pattes
3) plusieurs LM78L05A sont vendu vers 0.34 euro pièce
- sortie 5V à maximum 100mA (voir même plus)
- entrée max 35V (tout juste mais OK si on le protège avec un zener
contre les pics de tension)
- dispo en cms (SOIC) et traversant (TO-92)
- pas un LDO, donc un peu plus de pertes ...
4) LM2936MM-5.0, comme tu proposes, mais il seulement à 2.34 euro
pièce et 17.8 pour 10 pièces
Là, ça devient payable.
> En tout cas, merci à tous pour la démarche. J'espère pouvoir trouver
> du temps pour un coup de main. Je n'ai jamais développé sur PIC, mais
> développer des cartes micro et des softs de comm a été mon dada (et
> mon boulot) il y a qq années. Et grâce à vos échanges, je sens le
> virus revenir.
Pas de quoi, moi qui pensais trouver au maximum 2 francophones (moi
compris) assez fous pour se lancer dans ce genre de projet, voila que
nous somme déjà 5 ou 6, c'est incroyable ... 8-)
En passant :
Une autre option à envisager est de repiquer du 24V sur la deuxième
paire (Blanc/Jaune) du câble EIB, comme ça on n'est plus limité par
les 10mA/30V.
Cela ne change quasi rien par rapport à l'option "tirer le jus depuis
le bus" sauf qu'il faut prévoir deux petits jumpers et un bornier en
plus sur la platine.
Heuu, il faut peut-être aussi prévoir une petite isolation
galvanique ...
Tiens, vous avez bien sur tous ajouté une alim 24V DC en plus de votre
alim EIB dans votre installation , non ??? ;-)
> C'est pourquoi je propose de prendre un régulateur à faible perte et
> qui consomme le moins possible en stand-by.
Un régulateur linéaire Low Drop n'a d'intérêt que lorsque les tensions
d'entrée et de sortie sont très proches, comme faire du 4V à partir du
5V, un régulateur normal ayant souvant plus de 1V de chute de tension
et dans ce cas inutilisable. Dans notre cas, avec un régulateur
linéaire, si on consomme 30mA sur le 3V3, on aura toujours 30mA sur le
30V, et on dissipe 800mW dans le régulateur, pour 100mW de
consommation utile, soit un rendement catastrophique de 11%,
régulateur faible perte ou non, ça ne changera rien. Avec un
convertisseur à découpage, pour 10mA sous 30V, on aura autour de 90mA
sous 3V3, ce qui est confortable, et le rendement sera supérieur à 90%.
On 8 sep, 12:11, connexium <h.de...@connexium.fr> wrote:
> Dans notre cas, avec un régulateur
> linéaire, si on consomme 30mA sur le 3V3, on aura toujours 30mA sur le
> 30V, et on dissipe 800mW dans le régulateur, pour 100mW de
> consommation utile, soit un rendement catastrophique de 11%,
Evidement, vu comme ça, un LDO c'est pas une bonne idée ...
Que proposes-tu comme convertisseur à découpage ?
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
|
