Arduino Uno relié à un Arduino Mega - Alimentation

Bonjour !

Voila mon montage :
J'ai un récepteur infrarouge relié a une carte arduino uno.
J'ai une carte arduino mega alimentée par la uno via un transistor.
En gros, lorsque le récepteur infrarouge du uno reçoit le bon code, il active le transistor qui laisse passer le jus entre le uno et le mega. Ensuite le code du mega se met en route automatiquement.

Le problème c'est que l'alimentation du mega est insuffisante, les diodes sur la carte s'allument mais faiblement. Effectivement il y a 4 capteurs ultrasons et un buzzer reliés sur la carte donc ça ne m'étonne pas trop que le 5V du uno ne suffise pas. J'ai donc branché par la prise jack du uno une alimentation de 12V qui peut débiter jusqu'à 1A. Je me dis c'est largement suffisant mais surprise les diodes du mega sont toujours aussi faiblardes !

Voila dites moi si j'ai fait une connerie ou autre et je vous remercie d'avance pour vos réponses

Je pense que ton choix est doublement une mauvaise idée.

  1. Le 5V de la UNO est prévu pour alimenter la UNO. Ca peut paraître bête de dire ça mais il n'est pas prévu pour délivrer de la puissance.

  2. Commander un micro-contrôleur en lui coupant ou établissant son alim n'est pas terrible. Outre les problèmes de fiabilité (un composant souffre plus à l'allumage ou extinction qu'en service permanent) il existe d'autres méthodes comme l'attente d'un changement de niveau sur un pin dotée d'une fonction d'interruption ou même des mises en sommeil. La mise en sommeil économise le courant consommé mais est moins évidente à mettre en œuvre que la gestion d'une interruption.

Voici mon montage (en réalité c'est un uno et un mega)

Le transistor est un NPN de référence 2N2222A voici sa doc :
http://pdfs.datasheetdirect.com/view/1538089/2N2219A%202N2222A.png

Je n'ai mis aucunes résistances dans mon montage tu penses que c'est ça le problème ?

Merci.

J'ai opté pour cette méthode car au départ, j'avais tout mes composants reliés au méga mais il y avait un problème du fait qu'il y avait 2 librairies qui rentraient en conflit (IRRemote pour gérer l'infrarouge et NewPing pour gérer les capteurs ultrasons). C'est pour cela que j'ai voulu dissocier les deux en mettant une carte qui gère l'infrarouge (le uno) et l'autre les capteurs à ultrasons (le mega)

Ouh là, laisser l'alim branchée en permanence et couper la masse quelle source de conneries en tout genre !!!!!!.
La masse doit TOUJOURS être raccordée.
La masse c'est la REFERENCE pour les tensions comme le niveau de la mer l'est pour les hauteurs. Sans référence on ne maîtrise plus rien.
Je persiste : mettre le Mega en attente d'une interruption générée par la broche D2 ou D3 de la UNO fonctionnera plus proprement.
Même si ta solution "tombe en marche par le plus grand des hasards" qu'est-ce qui te permet d'être certain que tu n'aura pas un retour de masse non prévu provoqué par un composant par exemple ?

Les remarques de pepe sur les transistors sont juducieuses, je pense qu'il faudrait que tu documentes plus sur le sujet.
En particulier pas de résistance dans la base = dégradation de la sortie du micro.
ET une sortie de micro n'est PAS faite pour délivrer en permanence plus de 20 mA, les 40 mA du site sont une grossière erreur de lecture de la datasheet de la part de l'équipe Arduino.

Une référence de tension commune est nécessaire si l'on réalise des échanges de signaux, mais cette référence n'est pas nécessairement la masse

Permets moi de nuancer ces propos.
Dans leur très grande majorité les fournisseurs "sérieux", et Atmel en fait partie, respectent une convention pour définir les alimentations.
Il existe deux catégories de produit :

  1. Ceux dont les broches d'alim sont spécifiées Vee et Vcc ou Vdd et Vss.
    Un bon exemple est la catégorie des amplificateurs opérationnels.
    Ces circuits intégrés sont conçus dès le départ pour avoir la référence des tensions soit au plus soit au moins.

  2. Ceux dont les broches d'alim sont spécifiées Gnd et Vcc, ou Gnd et Vee, ou Gnd et Vdd ou Gnd et Vss.
    Les circuits sont conçus pour avoir la référence des tensions sur une polarité bien précise. Et c'est le cas du micro-contrôleur.
    Comme toujours rien n'est binaire et on peut toujours trouver des configurations où le montage fonctionne en prenant une référence sur la polarité opposée .
    Mais quand on prend ce genre de liberté il ne faut pas s'attendre à ce que les spécifications techniques du produit soient respectées dans leur intégralité.

En conséquence je déconseille totalement le schéma de "MrLeblanc".

Bonjour,
De plus, pourquoi vouloir "couper" le Gnd au lieu du + Vcc ?
'
Je pense avoir compris qu'il voulait éviter d'avoir une chute de tension sur le + ?
Quelle que soit la position de la coupure, la carte 2 subira la chute de tension du transistor !
'
Un transistor MOSFET créerait une plus faible chute de tension qu'un 2N2222 ?

En conséquence je déconseille totalement le schéma de "MrLeblanc".

Géryko

Un transistor MOSFET créerait une plus faible chute de tension qu’un 2N2222 ?

Peut-être oui peut être non.
Tout dépend du courant qui traverse le transistor, du type et du modèle de transistor.
Ne pas oublier qu’on parle souvent des Rdson miracles des Mosfets de puissance mais ils sont donnés au courant max.
Or au démarrage le rapport delta(V)/delta(I) est très défavorable.
A 500 mA un transistor MOSFET 20A avec un Rdson <=1milliohm @20A n’est pas obligatoirement meilleur qu’un simple transistor MOSFET 1A et Rdson <= 1ohms, qui lui même n’est pas forcément meilleur qu’un transistor bipolaire avec Vcesat <= 300mV.

Tout est dans la nuance, il n’y a pas de recette miracle. Quand on est obligé d’optimiser la solution est dans le choix du bon composant au bon endroit.

La théorie c’est beau.
J’ai eu la chance de participer à la conception de 5 circuits intégrés “maison”. Je n’étais pas aux manettes j’étais “le client interne”. Mais je suis intervenu dans l’implantation et particulièrement dans la possibilité de réaliser des “vrais découplages d’alim” car j’avais la vision de la carte que j’aurais à réaliser avec.
Voila sur quoi je base mes propos.

Bonsoir,

L’auteur du sujet a peut-être peur d’affronter le problème par logiciel pour l’instant ?
Sous réserve des justes remarques de 68tjs, de pepe, et d’autres inconnues concernant l’installation
son schéma pourrait ressembler à cela : (principe)

C’est une expérience, Je n’ai pas encore compris comment insérer une image dans le texte.
Mais c’est très bien ainsi.

La coupure de l'alimentation pourrait être évitée en mettant le processeur en veille. Il y a des modes dans lesquels la consommation du processeur tombe à quelques µA.

@fdufnews :
C'est ce que j'ai suggéré tout au début mais dans sa réponse l'auteur MrLeblanc ne mettait pas en avant une volonté de réduction de la consommation mais une incompatibilité de bibliothèques :

J'ai opté pour cette méthode car au départ, j'avais tout mes composants reliés au méga mais il y avait un problème du fait qu'il y avait 2 librairies qui rentraient en conflit (IRRemote pour gérer l'infrarouge et NewPing pour gérer les capteurs ultrasons). C'est pour cela que j'ai voulu dissocier les deux en mettant une carte qui gère l'infrarouge (le uno) et l'autre les capteurs à ultrasons (le mega)

En fonction de cette réponse j'ai toujours déconseillé de couper l'alimentation et suggéré d'utiliser les interruptions, bien que la vraie solution aurait été d'identifier "les incompatibilités" et de les résoudre avec l'aide du forum.
Maintenant chacun fait comme il veut.

Bonjour à tous et merci pour vos réponses très précises

pepe j'ai branché le transistor dans le bon sens, relié le 5V du uno au 5v du mega et mis une résistance de 290 ohm entre la sortie 7 et la base du transistor mais lorsque le mega s'allume, le code ne s'active pas. Si je connecte directement sans transistor les gnd et les 5v là ça fonctionne donc je pense qu'il me manque encore quelque chose dans mon montage non ?

68tjs c'est vrai que couper-réenclencher l'alimentation est une méthode un peu "bourrin" mais pour ma défense j'avoue ne pas comprendre grand chose aux interruptions et au mode sleep dont tu parles et qui sont surement de meilleures solutions c'est pourquoi j'essaye de faire simple.

Bonjour pepe,

  • j'ai modifié un peu mon schéma original suivant tes recommandations
  • Il s'agissait d'un schéma de principe, pouvant inspirer d'autres lecteurs
    (mais pas pour alimenter un Arduino2 à partir d'un Arduino1, ce qui est absurde)
  • Mea-culpa, je n'avais pas regardé les datasheets.
    Effectivement le BS250 ne convient pas du tout.
    Généralement les MOSFET font moins de 1 Ohm
  • Concernant la R de commande sur G, je mets toujours le maxi lorsque je n'ai pas besoin de fronts raides.
  • merci pour la mise en page d'une image.
    Géryko

@MrLeblanc
Et si tu en disais un peu plus sur les "incompatibilités de librairies" ?

L'incompatibilité que l'on rencontre le plus souvent sur ce forum est quand 2 bibliothèques utilisent les mêmes pin du micro.
Est-ce le cas ?

Pour le savoir il faut lire les fichiers des bibliothèques. Ne penses-tu pas que ce serait une bonne idée de donner les liens qui permettront d'avoir accès au code ?

MrLeblanc:
68tjs c'est vrai que couper-réenclencher l'alimentation est une méthode un peu "bourrin" mais pour ma défense j'avoue ne pas comprendre grand chose aux interruptions et au mode sleep dont tu parles et qui sont surement de meilleures solutions c'est pourquoi j'essaye de faire simple.

Pour en savoir plus sur les interruptions :

Un site en français :
http://www.mon-club-elec.fr --> l'adresse est dans les "Guides" en tête de forum
plus particulièrement sur les bibliothèques arduino :
Référence Arduino français Main/Reference

Un "exemple" qui compile mais que je n'ai pas vérifié :

/* déclaration variables globales */

int verrou;

/* fonctions de bases de l'IDE */
void setup()
{
  verrou = 0 ; 
  attachInterrupt(0,travail_interruption , FALLING);
}

void loop()
{
  if(verrou)
  {
    fait_ton_boulot();
  }
}

/*        Fonctions utilitaires  */

void fait_ton_boulot()
{
  /*   le travail à faire
     zzzzzzzzzzzzzzzzzz ;
     zzzzzzzzzzzzzzzzzz ;
  */
  verrou = 0;   // met le verrou à 0 pour bloquer le processus
 // en attente d'une nouvelle interruption
}

void travail_interruption()
{
  verrou = 1;
}

Le principe :
Le "travail" réalisé dans une interruption doit être le plus bref possible. L'interruption se contente de donner la valeur 1 à une variable appelée "verrou"

Dans la boucle loop() la ligne
if (verrou) {fait_ton_boulot();}
attends que verrou soit à 1 pour lancer la fonction fait_ton_boulot().
NB le résultat de ce qui est entre parenthèse après le if est un booléen. Écrire "if (verrou)" est équivalent à écrire "if (verrou ==1)"

En fin de fonction "fait_ton_boulot()" la variable verrou est remise à 0 pour bloquer l'exécution de "fait_ton_boulot()" jusqu'à la prochaine interruption.

Le mode sleep est plus complexe et ne serait utile que si tu tenais à faire des économies de courant consommé.

Mais, mais, la meilleure solution reste de savoir pourquoi il y a "une incompatibilté" entre deux bibliothèques.

Bonjour

J'ai du nouveau !

En cherchant le pourquoi de l'incompatibilité des bibliothèques, j'ai enfin trouvé une solution.
Les bibliothèques IRremote et NewPing (lorsqu'elles sont appelées dans le même code) provoquent en effet une erreur à la compilation. Après un petit bidouillage du fichier IRremoteInt.h (il suffit de choisir un autre timer en décommentant une ligne) mon code fonctionne parfaitement et je peux donc me reservir que d'un seul Arduino.

IRremoteInt.h

#if defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
  //#define IR_USE_TIMER1   // tx = pin 11
 // #define IR_USE_TIMER2     // tx = pin 9
  #define IR_USE_TIMER3   // tx = pin 5
  //#define IR_USE_TIMER4   // tx = pin 6
  //#define IR_USE_TIMER5   // tx = pin 46

J'utilise ici le timer 3 et il n'y a plus de conflit avec la librairie NewPing.

J’espère en tout cas que ce topic servira à d'autres et merci encore à vous 68tjs et pepe !

Et bien voilà, c'est quand même mieux comme cela.