Bonjour.
Cette discussion est dédiée au développement personnel de modules EIB/
KNX sur base d'un microcontroleur de la famille PIC de Microchip, elle
permettra aux quelques martiens partiquant ce sport méconnu d'échanger
impressions, idées et résultats.
Ludovic lemarinel
Unregistered
A propos du Stack EIB : ne consiste-t-il juste pas à ecouter le BUS, et dès
qu'une trame est pour soi, la traiter puis envoyer l'accué de reception
(pour un actionneur par exemple) ?
Je vais regarder ca de plus prés.
Quelqu'un a-t-il deja commencé quelques chose?
Si oui, sur quel modele de PIC ? 16F, 18F ?
On 14 août, 08:33, "Ludovic lemarinel" <l.lemari...@gmail.com> wrote:
> A propos du Stack EIB : ne consiste-t-il juste pas à ecouter le BUS, et dès
> qu'une trame est pour soi, la traiter puis envoyer l'accué de reception
> (pour un actionneur par exemple) ?
Bonjour.
En gros et pour les fonctions de base, oui, tu viens de décrire la
fonction de réception, mais il faut bien entendu aussi implémenter :
- Les fonctions d'émission + réémission en cas de accusé de réception
négatif.
- La gestion en mémoire des valeurs d'objets de communication avec
leurs flags (read, write, transmit, update, read-on-init).
- La programmation de l'adresse physique par le bus (avec gestion du
bouton de programmation).
Avec ceci, les besoins de base sont couverts.
Maintenant, pour écrire un stack EIB complet tel que celui dans un
BCU2, il manque encore beaucoup de fonctionnalités, dont, en vrac :
- Sauvegarde éventuelle de la valeur des objets dans une EEPROM en cas
de chute de tension sur le bus.
- Programmation de l'application via le bus.
- Programmation de la table de groupes via le bus.
- Programmation de la table des flags des objets via le bus.
- Programmation des paramètres de l'application via le bus.
- Gestion de la communication avec session et des "clefs de sécurité".
- Lecture/écriture en mémoire du PIC, acces variable selon le niveau
de sécurité.
- Réponse aux requètes d'information (mask version, vendor ID, serial
number, type PEI connecté, application ID, tension du bus, etc.).
Mon projet actuel est de développer la première partie sur un PIC
16F877A en utilisant une puce TP-UART comme interface avec le bus.
ca me plait tout ca.
je crois que je vais regarder ca samedi et sortir mes 877A.
Par contre, je vais regarder pour le TP-UART, pas sur d'en avoir sinon
je passerais commande.
Je vais relire les specs de l'EIB2 (KNX).
Pour ce qui est de l'integration dans ETS3 :
Quelqu'un sait il comment creer le fichier database .VDx associé?
Pour le moment, on va faire simple:
sur http://www.konnex.org , j'ai retrouvé le Toolkit pour developper
la database utilisable sur ETS3, et tester l'integration de son
produit.
Le kit coute plus de 3000€ (prix indiqué).
Bref, ca fait mal.
On 15 août, 13:45, Krysto <kyre...@gmail.com> wrote:
> Pour le moment, on va faire simple:
>
> surhttp://www.konnex.org, j'ai retrouvé le Toolkit pour developper
> la database utilisable sur ETS3, et tester l'integration de son
> produit.
>
> Le kit coute plus de 3000€ (prix indiqué).
>
> Bref, ca fait mal.
Oui, en effet, c'est un peu cher pour moi aussi. ;-)
Il y a une alternative open-source possible mais je n'ai pas encore eu
le temps de bien regarder :
http://www.auto.tuwien.ac.at/~oalt/basys/
Basys2003 remplace l'ETS et les fichiers .vd* sont remplacés par des
fichiers en XML.
Mais je ne suis pas trop sur qu'il soit possible d'importer des
fichiers .vd* de matériel "officiel" dans Basys2003, ce qui est tout
de même un tres gros problème potentiel.
Concernant les TP-UART, j'en ai acheté quelques uns chez Opternus.de
mais finalement je ne pense pas les utiliser dans un premier temps car
le datasheet du TP-UART recommande l'usage de quelques composants
périphériques un peu exotiques (dont une double diode de protection
contre les surtensions). Chez Digikey.com, il est possible de les
trouver pour pas cher ... mais par 1000 pièces ! Je pense avoir
trouvé des composants équivallents ET vendu à la pièce chez
Farnell.com mais le prix n'est pas génial ...
Au final, pour les premiers essais du software, je pense qu'utiliser
un BCU2 en mode FT1.2 doit être plus simple et le protocol de
communication semble être assez proche de celui du TP-UART (mais c'est
encore à confirmer) ; c'est d'ailleurs aussi le projet Stephane
Herraiz qui, je l'espère, nous rejoindra bientôt dans ce groupe de
discussion.
De mon coté, j'en suis à la description des tables en mémoire et des
"state machines" pour l'envoi et la réception.
Je vais très prochainement mettre une ou deux page web en ligne avec
le fruit de mes cogitations histoire de partager l'info.
P.S.
1) Je pensais écrire le tout en assembleur.
2) Je ne suis encore qu'un débutant en PIC (et en électronique en
général).
Keldo
Ok ok.
Pour Basys2003, je regarderais ca.
sinon pour le matos electronique, je commande chez http://www.futurlec.com,
beaucoup, beaucoup moins cher que les sites européens. Ils sont en
tha¨lande.
tout est bien packagé, jamais eu de problemes.
Tu vas tout ecrire en ASM ?
Moi je pense que je vais ressortir mon version de PICC Compiler.
Et ecrire une lib en C si mes routines fonctionnent bien.
J'ai aussi trouvé ce lien :
http://homepages.fh-regensburg.de/~scg39...ibteam.htm
C'est une team allemande.
Peut être moyen d'avoir des infos.
Apparement, ils ont leurs fichiers sources en telechargement.
stephane.herraiz@gmail.com
Unregistered
Bonjour à tous,
Bien trouvé Krysto cette team allemande semble super avancé dans un
projet similaire!! Je vais étudier leur code!
Pour l'instant je cherche un bon compiler C avec plein de source déjà
écrite (notamment une liaison série avec gestion de parité)...
Je potasse un livre sur l'EIB pour connaître à fond le protocole!
On Aug 16, 2:08 pm, Krysto <kyre...@gmail.com> wrote:
> J'ai aussi trouvé ce lien :http://homepages.fh-regensburg.de/~scg39398/eibteam/eibteam.htm
> C'est une team allemande.
> Peut être moyen d'avoir des infos.
> Apparement, ils ont leurs fichiers sources en telechargement.
On 16 août, 21:19, "stephane.herr...@gmail.com"
<stephane.herr...@gmail.com> wrote:
> Je potasse un livre sur l'EIB pour connaître à fond le protocole!
Bonjour Stéphane.
Tu as donc reçu ton livre ...
Pour la description précise du contenu des télégrammes, Steven (de
l'asso. KNX) nous donne le truc suivant dans une autre discussion. Le
fichier d'aide installé par le programme EITT vaut le détour, c'est
une mine d'information.
==>
>On 10 août, 14:45, Steven <steven.debru...@konnex.org> wrote:
>> Reverse engineering ne doit pas être nécessaire. Si je me trompe pas,
>> le lien http://www.knx-developer.de/online/eitt22/disk1.exe (et allez
>> chercher aussi disk2) permet de télécharger l'outil EITT 'demo), qui
>> sait analyser chaque telegrame. Mais ETS 3 donne déjà le même detail.
>> Qule information est-ce qu'il vous manque?
Ma réponse.
>Oui, j'ai installé le EITT en version demo. Je ne sais pas encore
> si le programme nous sera utile mais le fichier d'aide
> contient beaucoup d'informations intéressantes, dont le descriptif
> du télégramme pour chaque type d'objet EIS, c'est
> justement ce que je cherchais avec précision, merci beaucoup.
On 16 août, 10:51, Krysto <kyre...@gmail.com> wrote:
> sinon pour le matos electronique, je commande chezwww.futurlec.com,
> beaucoup, beaucoup moins cher que les sites européens. Ils sont en
> tha¨lande.
> tout est bien packagé, jamais eu de problemes.
Merci pour l'adresse, leur choix n'est pas super énorme mais c'est
vrai que coté prix c'est bien plus sympa que les deux gros sites que
j'avais cités.
Malheureusement, il ne semble pas y avoir les deux diodes "exotiques"
du TP-UART dans leur catalogue.
Pour info, je mets ici les ref. de ces deux pièces :
1) Suppressor Diode, SMAJ43CA (Manufacturer: General Semiconductor).
2) Rectifier Diode, BYG21M, Fast rectifier (Manufaturer: Vishay,
Temic).
Après vérification, je les ai trouvées chez http://www.farnell.com à un prix
plus abordable que je ne pensais (je n'avais pas vu un équivallent
pour la première diode et donc je devais compter 25€ de supplément
pour en faire venir des USA ...).
1) SMBJ43CA-TR (Manufacturer ST.Microelectronics) : 0,48€ pour 1 pièce
(qui est la quantité minimale pour une commande).
Ce n'est pas la pièce exacte mais je pense qu'elle est équivallente,
seule la taille change.
2) BYG21M-E3/TR (Manufacturer : Vishay General Semiconductor) : 0,139€
pour 1 pièce (qui est la quantité minimale pour une commande).
La, ça devient tout à fait payable et tout de même moins cher qu'un
BCU2 pour le mode FT1.2, même si il faut encore ajouter 10€ pour le TP-
UART.
Les autres composants à ajouter au TP-UART sont classiques.
Bref, je vais sans doute sortir mon fer à souder (le tout petit, il y
a des SMD, grrrrr.) d'ici quelques semaines.
stephane.herraiz@gmail.com
Unregistered
Bonjour,
Je pense que j'ai trouvé le bon compilateur C pour développer un stack
EIB pour PIC c'est CCS.
Il a déjà des bouts de codes comme la gestion de la parité (pour une
communication en FT1.2)!
Je pense que nous devrions réfléchir sur les fonctions qui nous
intéresseraient comme lire/écrire un bit, répondre à une question sur
le statut d'un port etc...
En gros il nous faudrait rédiger un cahier des charges...
Peut ëtre créer un groupe exprès pour ce développement...
J'attends vos idées!!!
Vite, en passant, une info et deux petites questions :
L'info, c'est un lien vers la page perso d'un autre fabricant de
modules EIB amateur, il a des chouettes réalisations à analyser :
http://www.dehof.de/eib/EN/index.html
La première question c'est : Avez vous un lien vers une bonne
explication du protocol FT1.2 ? J'aimerai faire une comparaison avec
le protocol du TP-UART afin de voir si il y a beaucoup de changements
pour passer de l'un à l'autre.
La seconde question est plus spécifique pour Stéphane : Si tu utilises
un BCU2 en mode FT1.2 pour communiquer entre le PIC et le bus, lequel
des microcontroleurs va gèrer les adresses de groupe et répondre ACK/
NACK/BUSY dans les temps quand c'est nécessaire, le PIC ou le 68HC05
du BCU2 ?
Bref, tu utilises le BCU2 juste comme un tranceiver ammélioré et le
PIC gère tout ou bien tu confies au BCU2 le travail de gèrer le stack
EIB et alors le PIC ne doit gèrer que l'application proprement dite ?
stephane.herraiz@gmail.com
Unregistered
Pour moi le BCU est transparent... Le PIC reçoit une trame EIB
encapsulée dans une trame FT1.2 qu'il doit interpréter.
Je me suis pas encore penché sur les ACK/NACK/BUSY, mais je pense que
c'est au pic de gérer ces réponses. Cela me semble logique car c'est
lui qui connaît son adresse individuelle et de groupe.
Je connais pas bien le TP-UART mais pour moi l'avantage du BCU c'est
que l'on a pas à s'embêter avec la communication bas niveau...
Très intéressant de faire une comparaison entre un BCU et un TP-
UART!!!
On 18 août, 23:43, keldo <kelderm...@ibelgique.com> wrote:
> Vite, en passant, une info et deux petites questions :
>
> L'info, c'est un lien vers la page perso d'un autre fabricant de
> modules EIB amateur, il a des chouettes réalisations à analyser :http://www.dehof.de/eib/EN/index.html
>
> La première question c'est : Avez vous un lien vers une bonne
> explication du protocol FT1.2 ? J'aimerai faire une comparaison avec
> le protocol du TP-UART afin de voir si il y a beaucoup de changements
> pour passer de l'un à l'autre.
>
> La seconde question est plus spécifique pour Stéphane : Si tu utilises
> un BCU2 en mode FT1.2 pour communiquer entre le PIC et le bus, lequel
> des microcontroleurs va gèrer les adresses de groupe et répondre ACK/
> NACK/BUSY dans les temps quand c'est nécessaire, le PIC ou le 68HC05
> du BCU2 ?
> Bref, tu utilises le BCU2 juste comme un tranceiver ammélioré et le
> PIC gère tout ou bien tu confies au BCU2 le travail de gèrer le stack
> EIB et alors le PIC ne doit gèrer que l'application proprement dite ?
Bonjour
Si ça peut vous aider, je vous signale que dans la technologie
LONWORKS, il y a une seule puce qui fait tout, mais en réalité il y a
trois processeurs dans la puce
Un qui gère le réseau de terrain, élaboration des messages,
surveillance de la ligne, envoi des messages etc...
Un qui gère le process et les entrées sorties sur le monde physique
(l'application particulière que vous développez en NEURON C langage C
dédié à cette puce)
Et un troisième qui gère le transfert entre la première et la deuxième
puce.
Donc l'idée de répartir le travail entre plusieurs processeurs semble
être universelle.
Certes on doit pouvoir tout traiter sur un seul processeur (avec un
processeur puissant par exemple) mais certainement en faisant des
compromis.
Salutations
yves Accard
On 19 août, 14:20, "stephane.herr...@gmail.com"
<stephane.herr...@gmail.com> wrote:
> Pour moi le BCU est transparent... Le PIC reçoit une trame EIB
> encapsulée dans une trame FT1.2 qu'il doit interpréter.
> Je me suis pas encore penché sur les ACK/NACK/BUSY, mais je pense que
> c'est au pic de gérer ces réponses. Cela me semble logique car c'est
> lui qui connaît son adresse individuelle et de groupe.
> Je connais pas bien le TP-UART mais pour moi l'avantage du BCU c'est
> que l'on a pas à s'embêter avec la communication bas niveau...
> Très intéressant de faire une comparaison entre un BCU et un TP-
> UART!!!
>
> On 18 août, 23:43, keldo <kelderm...@ibelgique.com> wrote:
>
> > Vite, en passant, une info et deux petites questions :
>
> > L'info, c'est un lien vers la page perso d'un autre fabricant de
> > modules EIB amateur, il a des chouettes réalisations à analyser :http://www.dehof.de/eib/EN/index.html
>
> > La première question c'est : Avez vous un lien vers une bonne
> > explication du protocol FT1.2 ? J'aimerai faire une comparaison avec
> > le protocol du TP-UART afin de voir si il y a beaucoup de changements
> > pour passer de l'un à l'autre.
>
> > La seconde question est plus spécifique pour Stéphane : Si tu utilises
> > un BCU2 en mode FT1.2 pour communiquer entre le PIC et le bus, lequel
> > des microcontroleurs va gèrer les adresses de groupe et répondre ACK/
> > NACK/BUSY dans les temps quand c'est nécessaire, le PIC ou le 68HC05
> > du BCU2 ?
> > Bref, tu utilises le BCU2 juste comme un tranceiver ammélioré et le
> > PIC gère tout ou bien tu confies au BCU2 le travail de gèrer le stack
> > EIB et alors le PIC ne doit gèrer que l'application proprement dite ?
Ca sent bon tout ca.
Faut que je regarde ce que fait un BCU.
Pour moi, je suis OK pour que le TP-UART soit transparent.
Vu la vitesse du bus KNX, il est assez simple de cadencer un 16F877A à
20MHz pour avori le temps de faire plein d'uatres gestions.
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 ?
Un petit conseil de choix de processeur, pour avoir fait du
développement sur PIC : prendre la série PIC24, bien plus agréable que
les autres pour ses performances (16 bits) et surtout sa gestion de la
mémoire. Un stack IP tourne sans problème sur un 24, en plus de
l'application principale, alors que sur un 18F, les perfo s'écroulent
à cause de la gestion des pages. Un PIC24 coûte environ 5€, les
compilateurs C sont beaucoup plus efficaces, et l'assembleur devient
lisible (imbuvable sur du 16 ou 18).
On 20 août, 12:24, Krysto <kyre...@gmail.com> wrote:
> Ca sent bon tout ca.
>
> Faut que je regarde ce que fait un BCU.
>
> Pour moi, je suis OK pour que le TP-UART soit transparent.
> Vu la vitesse du bus KNX, il est assez simple de cadencer un 16F877A Ã
> 20MHz pour avori le temps de faire plein d'uatres gestions.
> 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 ?
On 21 août, 10:20, connexium <h.de...@connexium.fr> wrote:
> Un petit conseil de choix de processeur, pour avoir fait du
> développement sur PIC : prendre la série PIC24, bien plus agréable que
> les autres pour ses performances (16 bits) et surtout sa gestion de la
> mémoire. Un stack IP tourne sans problème sur un 24, en plus de
> l'application principale, alors que sur un 18F, les perfo s'écroulent
> à cause de la gestion des pages. Un PIC24 coûte environ 5€, les
> compilateurs C sont beaucoup plus efficaces, et l'assembleur devient
> lisible (imbuvable sur du 16 ou 18).
Oui, pour un utilisation avec un compilateur, y a pas photo, les PIC24
et les dsPIC ont l'air bcp mieux, mais bon, pour ce premier projet,
c'est avant tout un essai et comme le 16F877(a) est bien connu de bcp
de monde ça me semble être un choix pas trop mauvais pour recréer un
équivallent de BCU1.
Après, si on a un algorithme correct et du code (bien documenté !) qui
tourne, rien n'empèche de migrer vers un PIC 24/ds.
Par contre, pour ce qui est des 16F, je trouve que l'assembleur est
pas si mal, il convient bien pour rester économe en RAM et la
lisibilité est surtout une question de documentation et d'organisation
du code.
Tiens, pour ceux qui pensent programmer en C, avez-vous déjà essayé
les "MikroC", "MikroBasic" et "MikroPascal" ?
--> http://www.mikroelektronika.co.yu/en/compilers/
Le prix à encore l'air "correct", il semble y avoir une belle
bibliothèque de routines déjà prêtes et, surtout, on peut télécharger
toutes les versions gratuitement pour les essayer le temps que l'on
désire, la seule limite étant la taille du fichier .hex généré : 2k
words pour les pic 12/16/18F , 8k words pour les pic 24/ds30/ds33.
Bref, de quoi se faire une bonne petite idée avant d'acheter.
J'ai installé le MikroPascal (je suis plus Pascal que C) et ... plutôt
bof au total.
Mon "bof" viens surtout des librairies, il y en a beaucoup mais elles
semblent assez limitées, par exemple pour notre petit projet EIB, une
bonne librairie UART est importante et dans MikroPascal le seul
paramètre modifiable de la librairie USART est la vitesse de
transmission, pour le reste on n'a pas le choix, c'est 8 bits et pas
de parité. Bref, inutilisable dans notre cas.
L'IDE du produit à l'air sympa mais il a aussi quelques limites
génantes : je n'ai pas trouvé le moyen d'utiliser l'ICD2 (de
Microchip) comme programmeur car le menu ne parle que de 2 appareils
de la même marque que le compilateur, ni le moyen d'intégrer
MikroPascal dans le MPLAB IDE.
Je n'ai pas pu tester la qualité du code généré par le compilateur.
Le trois produits C, Pascal et Basic partagent un grand nombre de
points comme leur IDE, les librairies, etc.
Au total, je ne peut pas dire si c'est un bon ou un mauvais produit
mais je ne pense pas qu'il convienne pour le projet "PIC on EIB".
On 19 août, 14:20, "stephane.herr...@gmail.com"
<stephane.herr...@gmail.com> wrote:
> Pour moi le BCU est transparent... Le PIC reçoit une trame EIB
> encapsulée dans une trame FT1.2 qu'il doit interpréter.
OK, donc tu vas l'utiliser comme un tranciever, c'est bien ce que je
pensais.
> Je me suis pas encore penché sur les ACK/NACK/BUSY, mais je pense que
> c'est au pic de gérer ces réponses. Cela me semble logique car c'est
> lui qui connaît son adresse individuelle et de groupe.
Oui, dans ce cas-ci ce sera bien le travail du PIC.
Tout ceci signifie que le travail du PIC dans le cas du TP-UART ou du
FT1.2 sera très proche, la seule chose qui changera sera "l'habillage"
des télégrammes, on peut donc envisager de partager une très grande
partie du code pour le PIC et de ne changer que quelques lignes pour
passer d'une interface à l'autre.
> Très intéressant de faire une comparaison entre un BCU et un TP-
> UART!!!
Je cherche toujours une explication claire du protocol FT1.2, de ton
coté, sur quoi te bases-tu ?
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.
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 :
http://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.
Ludovic lemarinel
Unregistered
Avez vous regardé du coté des Pics 18FXXXX, ils sont assez interessant pour
la plupart, et le compilateur C gratuit MCC18 de microchip propose pas mal
d'options et de librairies...
Le 27/08/07, keldo <keldermans@ibelgique.com> a écrit :
>
>
>
>
> 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 :
> http://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.
>
>
stephane.herraiz@gmail.com
Unregistered
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.
|
