Reprise du message précédent :
RS et Farnell. Ils ont des entrepôts en europe/france.

J'étais justement entrain de regarder RS .
Par contre Farnell de mémoire c'est juste pour les entreprises et étudiants.

ça ne l'est plus
 
et sinon il y a le premier post

 
Si tu cherches un truc simple avec de l'ethernet (mais pas dit que ca puisse se connecter avec du wifi) : http://tuxgraphics.org/electronics [...] 6061.shtml

Oui je connais
 
C'est le PHY Ethernet Microchip utilisé par le Stack TCP/Ip Microchip.
Pour rajouter le Wifi le plus simple d'après ce que j'ai lu c'est d'utiliser un adaptateur Ethernet->Wifi. Mais bon, pas terrible.
Ou sinon utilisé les modules Wifi de Mircochip qui sont supportés nativement.
 
 
Sinon petite question.
Les vias vers les pad thermique c'est très efficace???
 
J'hésite à mettre :
- le pad thermique des LED, côté LED (et pistes en-dessous)  
- mettre les pistes au-dessus, et pad thermique en dessous et avec l'avantage qu'il sera plus grand. Mais je sais pas avec quelle efficacité les vias transfert la chaleur.
 
edit:
Ah ben je viens de trouver cet article:
http://www.digikey.com/us/en/techz [...] mance.html
 
 
Sinon il y a moyen de retourne la face du PCB sur Eagle???
Parce que bon relié les pins avec des puces en face arrière, donc en miroir, c'est chiant  

Mais tu as pas de plan thermique pour les LED. Si tu parles du contrôleurs, il vaut mieux que les pistes soient face Pistes et le plan de masse/thermique faces Composants (composants trad et pas CMS).
 
Et les vias thermiques c'est efficace et ca évite de faire du gruyère.

En plus j'ai une autre difficulté.
 
Les LED RGB ont les caractéristiques suivantes:
 
Forward voltage (MAX):
R:  2.3V
G:  3.7V
B:  3.5V
 
Cherchez l’intrus
 
Si je les branche à du 4V, ca voudra dire que les driver LED (branchés à la cathode [-] de la LED) devra dissiper (4V-2.3V) * 10mA = 17mA rien que pour la LED rouge. Alors que pour la verte et bleu ca sera forcément moins, 3mW et 5mW respectivement. C'est quand même pas négligeable comme différence.
 
Du coup je me demandais s'il ne valait pas mieux faire 2 alim distinctes pour les LED, une pour les LED rouge, l'autre pour les bleues et vertes. Du coup ca faudrait aussi 2 pad thermiques distincts (oui le pad thermique je ne peux les mettre que sur l'anode).  

C'est quoi déjà la ref du driver ?

TLC59116
 
Pour la dissipation thermique du driver aucun problème, mais ca fera consommer le tout inutilement.
 
 
Là, les 2 possibilités pour la dissipation thermique des LED.
A gauche les pad thermiques [2] en haut et les pistes (d'une des 2 LED seulement) vers le driver en bas.
 
Et à droite les pad thermiques en bas (surface plus grande, manque les vias, mais ca sera au niveau des pin des LED) et les pistes en haut (ne sont pas dessinées encore)

 
J'ai pas la réponse mais je suis sûr à 99% que tu t'embêtes pour rien  

Probable.
 
En plus je suis bête, des TOPLED de ce type j'en ai encore quelques unes en stock, j'ai qu'à tester si ca chauffe ou pas.
Alors c'est pas des RGB, que des vertes et rouges, mais bon à 20mA ca équivaut à une RGB à 10mA par couleur (sachant que je vais utiliser que max 2 couleurs simultanément, bleu combiné aux autres ca donne des couleurs bizarres   )

Encore moi
 
Dites j'ai un petit doute qui me taraude
 
Une puce qui supporte l'I2C en mode "Fast Mode" max 400Hz, et en "High Speed Mode" du 3.4Hz, est-ce qu'elle supporte le mode "Fast Mode +" qui est une extension plus récente du mode "Fast Mode" mais à 1MHz???
 
(Sachant que le protocole de comme entre le FM et FM+ est identique, ce qui n'est pas le cas du mode HS)

 
Je dis peut être une connerie, mais m'est avis qu'il vaut mieux se focaliser sur la dissipation du contrôleur que des LED.
Il faut tester anéfé ou étudier la datasheet, mais si tu dois choisir entre un bon plan thermique/masse pour le contrôleur ou un bon plan thermique pour les LED, je choisirais de privilégier le contrôleur.
 
Pour ce qui est de la double alim, faut voir ce que le contrôleur peut dissiper. Mais pas dit que ca soit très utile d'en faire deux.
 
 
 
Faut essayer, mais c'est pas dit que ca marche. Faut voire si les timings sont respectés...

Non pas de prob de ce côté là, le contrôleur supporte 1.5W, j'en suis très loin. C'est juste pour des raisons d'optimisation pour réduire la conso, car mine de rien avec le Vf de 2.3V et une alim de 4V, ca fait 17mW que le driver devra dissiper pour chaque LED rouges allumées. Donc ca va facilement dépasser le Watt en tout. Un peu dommage tout ca, je préfère une deuxième alim que pour la LED rouge.

Dites il y a quoi d'autre comme connecteur compact, pour des bus data (SPI, I2C, USB, 5V, GND)???
 
Ca c'est trop gros à mon goût. :-/

Vous avez une bonne adresse pour du matos pas cher pour souder du cms? Je pense à du fil fin, une troisième main avec éclairage, tresse, et peut ête que j'oublie qq chose

www.molex.com
www.samtec.com
www.fischer.com
www.harting.com

et tout le catalogue RS/Farnell/Future/Rutronik...

ebay ?

Petit question PIC/I2C
 
Alors je vais placer des petits PIC sur les 3 PCB. Chaque PIC ayant 2 I2C Master, mais je veux me laisser la possibilité de brancher l'I2C directement au PC (adaptateur USB-I2C) ou une puce ARM (.Net ou pas).
Donc pour ne pas devoir passer par un multiplexer I2C, il faut que je réduise au max le nombre de lignes i2c (Les STM32 n'en ont que 3).
 
Donc comme chaque PCB a 2 bus I2C reliés au PIC, il faudrait que je les chaine pour n'en former qu'un seul. Pas de problème suffit d'un jumper ou switch.
Mais du coup j'aurais le même bus I2C relié 2 fois au PIC. Est-ce que ca pose problème?
 
 
AVANT
 
PIC en tant que master
 
     /------- I2C#1 ---- Puce I2C----...---- Puce I2C----...---- PIN d'extension
PIC
     \------- I2C#2 ---- Puce I2C----...---- Puce I2C----...---- PIN d'extension
 
 
 
APRES
 
Pic en tant que slave ou en état permanent de RESET.
 
     /------- I2C#1 ---- Puce I2C----...---- Puce I2C----...---- PIN d'extension-> cable vers ARM/Adaptateur I2C USB
PIC     |
     \------- I2C#2 ---- Puce I2C----...---- Puce I2C----...---- PIN d'extension

Je dois dire que j'ai pas compris ton truc là...

Aussi pense à regarder combien de contrôleurs tu peux connecter à un même bus. Ca dépends du nombre de pin de configuration d'adresse.

Je réexplique alors.
 
1 PIC a 2 I2C master. Autant les utiliser tous les deux. Donc je vais utiliser 2 tracés I2C distincts sur le PCB.
 
Néanmoins comme je veux garder la possibilité de piloter les puces I2C non pas par le PIC mais via software PC ou ARM, je veux pouvoir me brancher à ces 2 tracés I2C de "l'extérieur".
Etant limité dans ce cas en nombre de master i2c dispo, les 2 tracés I2C sur le PCB ne vont en faire qu'un, en gros je les chaîne via un jumper.
 
Mais du coup le PIC a le même I2C (vu qu'il n'y en a plus qu'un) branché 2 fois en même temps sur ses pin .
 
Bon j'imagine que ca ne doit pas trop poser de problème, mais je préfère demander.

Je vois pas le souci. Si tu désactives les contrôleurs I²C dans le PIC ca ira.
Par contre tu perds l'intérêt d'avoir deux liens I²C distincts donc un souci d'adressage...

Perso je pense que l'archi de ta carte est mal pensée...

J'ai pas de soucis d'adressage
Si j'ai 2 bus I2C sur un PCB c'est pour être sûr qu'ils ne soient pas saturés et parce que le PIC disposent de 2 master i2c.
 
 
Je veux que les 3 PCB soient indépendants car si je veux les agencer différemment plus tard, ou n'en garder que deux, ben je n'aurai rien à changer niveau logiciel ni hardware.

Tu sais que le nombres de périphériques I²C qu'on peut connecter à un bus est limité ?
Ca dépend même du périphérique (nombre de broches de configuration de l'adresse)...

Euh je suis déjà plus avancé que ca au niveau de la conception du bazar .
Ca passe sans soucis que ce soit au niveau de l'adressage ou que ce soit pour la limite indépendance de 400pF.
(Le drivers LED a 4 pins programmables et 2 adresses réservées, ce qui me permet en théorie d'en mettre 14 sur un PCB, j'en ai moins que ca)
 
Par contre chaque PCB doit avoir son ou ses I2C, relier les 3 PCB au même I2C ca passe pas sauf avec un multiplexer/switch.
Mais bon comme je veux 3 PCB indépendants, le problème est résolu donc.
 
Mon seul problème actuellement c'est le fait qu'il me manque de la place pour le PIC et les connecteurs USB/SPI et ICSP, les régulateurs de tension et pad thermiques me prenant plus de place que prévue.
 
 
Alors ca a l'air inutilement complexe et trop modulable. Mais mon but c'est aussi de m'amuser à programmer tout ca (USB , SPI, I2C,...) que ce soit PIC ou ARM.... c'est pas tant le truc final qui m'importe, mais là j'ai au moins quelque chose de concret avec lequel faire joujou.

Dites une Led rayon X ,(tres faible intensité ,en dessous du mw ) , c'est un bingo ou un bof ?

Bon attaché vos ceinture j'ai un gros pavé
 
Attendez-vous à tout une série de questions de noob, numérotées pour faciliter les réponses .
Je remercie d'avance ceux qui prendront la peine de lire ce gros pavé.
 
 
Bon ayant découvert il y a quelques temps qu'il ne fallait absolument pas appliquer de tension sur les pin I/O des puces si elle ne sont alimentées, j'ai dû faire quelques modifications sur un circuit.
 
Je vous explique brièvement ce que c'est et s'en suivront quelques questions.
Ne vous occupez pas de la référence des composants je les ai pris au pif.
 
(click droit -> afficher l'image pour la voir en gros si votre navigateur la rend illisible)

 
 
Description:
 
- On a un PIC (IC1)
 
- Un tas de puces reliées en I2C, p.ex IC2 qui est une sonde de température avec une sortie "Alert" de type drain ouvert, pour signaler le dépassement d'une limite de température (relié à la masse quand alerte il y a donc).
 
- 2 régulateurs de tension (VR1 & VR2). Celui de gauche (VR2) sert à alimenter les puces I2C et PIC. Et Celui de droite (VR1) tout une série de LED (piloter via un driver LED I2C non présent sur le schéma)  
 
------------------------------------------------------------------------------------------------------------------------------------------------------
 
Le petit problème est que le PIC peut dans certains cas de figure être relié soit en SPI et/ou via USB à un autre circuit externe respectivement un PC.
Inévitablement si ces 2 bus sont branchés il faut que le PIC soit alimenté pour ne pas le bousiller. Donc le SPI et USB doivent alimenter le PIC si le régulateur de tension (VR1) sur le PCB est éteint ou parce que non alimenté en courant tout simplement.
 
Et là tout se corse pour moi .
Donc j'ai réalisé la partie en bleu qui a comme but de faire en sorte que:
 
- si VR1 est allumé/alimenté, c'est celui-ci qui alimente le PIC et autres puces.
- si VR1 est allumé/alimenté, alors c'est le connecteur SPI qui alimente le PIC (et que le PIC!).
- si VR1 n'est pas allumé/alimenté ni le connecteur SPI alors c'est l'USB qui se charge d'alimenter le PIC (et que le pic!).
 
Question:
1. Est-ce que le circuit à cet effet est ok???
 
2. Mosfet P, résistance 33k de pull-down relié à la grille, c'est ok???
 
3. Manques des diodes au niveau des P-Mosfet???
 
4. La diode D4 et D5 est ok pour protéger l'alim USB????  
 
5. Si c'est le SPI ou USB qui alimentent que le PIC (donc puce I2C éteinte), le bus I2C issu du PIC aura son alim de pull-up éteinte aussi. Donc j'imagine que si les puces I2C ne sont pas alimentées en courant, ca ne pose pas de problème sur leur I/O (Sans pull-up, le signal I2C est au pire branché à la masse). Pas de problème donc?
 
6. Sinon la grosse question de noob. Les masses????
La masse du SPI sera la même que la masse du VR1, VR2 et des puces et PIC, bref de tout le PCB, donc pas de problème.
Mais la masse de l'USB??? Je peux pas la mettre en commun avec la masse sur le PCB. Sachant que VR2 et VR1 doivent générer un courant de plusieurs ampères, comment éviter que ce courant ne passe (du moins en partie) par la masse de l'USB, ce qui est bien évidemment beaucoup trop pour l'USB. Donc je ne peux pas mettre la masse du PCB en commun avec la masse de l'USB.
 
Si????
 
Dois-je utiliser un mosfet additionnel qui branchera la masse du pic à la masse de l'USB si c'est que l'USB qui l'alimente (donc masse de VR1/VR2 non connecté)?
 
------------------------------------------------------------------------------------------------------------------------------------------------------  
 
 
Passons à la partie de de droit maintenant, en en orange  
 
Là, même problème avec les IO qui ne doivent pas être alimentés si la puce elle-même n'est pas sous tension. Donc imaginez que le VR1 a bien son alim 12V branchée, je ne peux pas appliquer la tension de pull-up au IC2 par exemple (Pin: Alerte, open-drain), ni au PIC s'ils sont éteints.
Du coup je suis obligé de mettre un transistor N (Q1)en série avec un transistor P (Q2), pour "isoler" ces deux circuits.
Si j'ai mis un transistor N (Q1), c'est pour éviter que le VR1 ne soit désactivé si la puce IC1 n'est pas alimentée (en gros pour faire la distinction entre, l'alerte activée et la puce sonde de température éteinte)
 
 
Question:
7. Est-ce que le circuit à cet effet est ok???
 
8. Mosfet P, Résistance 33k de pull-down relié à la grille est ok???
 
9. Manques des diodes au niveau des P-Mosfet???
 
10. Est-ce que je peux changer les mosfet par des transistors bipolaires sans rien rajouter/enlever?
 
11. J'ai lu ca dans une doc sur les IO des PIC:

 
Comment ca masse commune? C'est valable que pour les bipolaire n'est-ce pas, pas les mosfet?
Parce que du coup je me retrouve avec le même problème avec la masse de l'USB branché au PIC.
 
 
 
Merci beaucoup!

Bleu: J'ai pas bien compris les "combinaisons" d'alimentation ni quelle était la tension fournie par VR1... Sinon je vois direct un soucis avec Q7 car ta source est relié à 5V et ta grille soit à 3,3 ou 0V, dans les deux cas ton Mos sera passant.
 
Orange: je pige rien au schéma.  
 

Si c'est valable aussi pour les mosfets mais toi c'est des canals P que tu utilises donc c'est l'alim positive qui doit être commune.

Ben en fait j'ai eu la flemme de rajouter un régulateur de tension linéaire 5V -> 3.3V sur le schéma vu que c'était pas la question.
Donc pas de soucis de ce côté alors finalement.
 

VR1, pin EN c'est l'enable (On/Off du VR quoi). Il y a une résistance R3 de pull-up branché au 12V d'alimentation (c'est aussi celle qui alimente le VR).
La puce IC2 c'est une sonde de température qui active (branche à la masse) son pin "Alert" dès que ca chauffe trop.
Le but étant de couper le VR avant que la maison ne crame .
En gros, si le pin alert (ou jumper, non présent sur le schéma) est low, EN est high. Si le pin alert est high, EN est à la masse, VR éteint donc.
 
 
 
Le problème est que le pin Alert a une tolérance max de:  -0.5V to VCC + 0.5V
Or si la puce n'est pas alimenté, VCC = 0, donc pas possible de lui appliquer une tension de 12V (celle du pull-up 12V/R3) sur ce pin si la puce est éteint, d'où le P-Mosfet (Q2).
 
Le N-Mosfet (Q1), lui permet de bloquer la mise à la masse de EN si la sonde de température est éteint. En gros ca permet de faire la distinction entre le fait que l’alerte est actif et la sonde éteinte.
 
 
Mais bon je sens qu'il me manque un sacrée bagage technique  

 
T'as pas besoin de tout ce merdier. Il te suffit d'un canal N commandé par Alert avec une pull-down sur la grille, pull-up 12V/entrée EN sur le drain. T'as pas trop à te soucier des tensions sur les circuits éteints tant qu'il s'agit de pull-up donc de sources de tension avec très forte résistance interne.

P, sinon il éteint le VR si la temperature est ok.
 
Mais sur le fond c'est exactement ce que j'ai fait   , c'est juste que j'ai rajouté un deuxième mos, un N cette fois pour différencier entre entre le détecteur de température éteint et un alerte à la masse (actif).

T'as une source pour cette info?
Je préfère en être sûr.

 
Si EN doit être à 0 quand ALERT est à 1 c'est un canal N qu'il te faut voir montage inverseur http://kudelsko.free.fr/articles/mosfet2.htm (Montage à gauche)
 
 
 
Jamais eu de problème de ce genre au pire met une diode pour protéger la sortie ALERT.

Le pin alert est de type drain ouvert. Donc faut un pull-up inévitablement.
Donc un transitor P.
 
 
edit:
Tiens je me rends compte que j'ai mis les P-Mos à droite dans le mauvais sens.

 
Bah si c'est une sortie à drain-ouvert une pull-up suffit même pas besoin de transistor    

Je sais c'est prévu pour.
 
Sauf quand la sonde n'est pas alimentée ca peut bousiller la sortie "alert" d'où l'ajout des transistors pour l'isoler sinon je ne me serais pas fait chier avec ca

Si tu veux vraiment mettre des transistors je crois qu'il te faudra en utiliser deux, un canal N et un canal P.

Ca tombe bien j'ai ce que j'ai dans le schéma    
(Bon le P-Mos est à l'envers, mais bon le principe est là)
 
 
Par contre j'aimerai bien résoudre ce problème d'I/O et de tension
C'est quand même bizarre. Il y a des périphériques USB qui ne crame pas alors que le cable USB est branché mais pas l'alim de l'appareil.
Il doit bien avoir une astuce.
 
Transistor pour mettre le bus USB à la masse (+ grosse résistance pour limiter le courant au max) tant que le PIC n'est pas allumé et ne coupe la mise à la masse du bus USB???

Bon je viens d'avoir confirmation.
 
T'avais bien raison BenFromLA. La tension sur le pin n'est pas déterminant à elle seule. Tant que le courant total qui rentre par ces pin n'excède pas les 10-20mA, la diode interne de protection ne cramera pas.
Donc une grosse résistance en série + diodes de clamping et hop ca roule.
 
Donc j'ai fait tout ca pour rien    
 
 
 
Par contre j’aurais apprécié avoir la réponse sur la masse commune USB et PCB.
 
Si la masse de l'USB est commune à la masse sur le PCB, comment être sur qu'il n'y a pas 2A de courant qui vont essayer de se barrer par le câble de masse de l'USB. Si le courant ne passe que par la masse du transfo ok pas de problème, mais si la masse est commune à celle de l'USB je me demander comme le courant va se comporter.  

Salut tout le monde,
 
J'ai un TP à rendre et je dois simuler un capteur (ultrason/infrarouge...), qui, lorsqu'il détecte un obstacle active une DEL. Je dois bosser ça sous Multisim, vous avez des idées de montages possibles? J'ai d'abord penser à mettre un relais qui une fois commuté activerait la DEL mais je trouve ça trop lourd.
 
Merci beaucoup

Bon déjà je te préviens je suis nulle en électronique mais je te donne mon opinion quand même .
 
Déjà faut déjà savoir quelle type de capteur. Si c'est un capteur analogique il va te sortir évidemment une tension proportionnelle à la distance de l’obstacle.

 
A partir de la ben c'est assez simple je dirais.
Un transistor, avec les bonnes résistance comme diviseur de tension au niveau de la base pour qu'il ne conduise que dès que la tension du capteur dépasse la tension voulue et hop la LED qui brille.
 
 
Mais ca c'est que mon avis perso

Ah oui désolé j'avais oublié de préciser, non c'est du niveau logique (0=pas d'obstacle, 1= obstacle).
 
J'ai donc pensé au transistor, mais du coup j'ai juste à mettre une source de tension branchée sur un transistor lui même relié à ma DEL/moteur (les deux sont proposés) et le tour est joué?

Et voici la question gold du noob : suite á la lecture de http://skyduino.wordpress.com/2013 [...] -pour-moi/, je me suis dit "ça a l'air cool un oscilloscope".
 
Mais, pour quoi faire ?
 
J'ai fait pendant mon DUT 2 ans d'électroniques (applique aux traitement des signaux analog ou num) á raison de 6h par semaines. On en a utiliser... Mais á par pour visualiser les signaux sur les circuits et dire "ho bah merde, le prof ne dit pas de conneries dans son cours", j'avoue que son utilité pour moi en pratique me parait plus que flou.
 
Donc suivant ma philosophie, si je ne vois pas á quoi ça peut me servire, c'est que je n'en ai pas besoin. Mais aux dires de certains, c'est super pratique pour debugger un circuit qui ne fonctionne pas comme voulu.
 
Je fais principalement des montages (simples) á base d'arduino (leds, controle de moteur pas á pas, etc). Mais je compte pas me limiter á si peu (je me lancerai bien dans la realisation de pedales d'effet de grattes ou autres, un petit robot autonome, etc)
 
Est ce utile un tel objet dans mon cas present (futur plutôt) ?