Discussion :

[electroremy]

Bonjour,

Dans quel état les broches I/O d'un Arduino sont lorsqu'il n'est pas alimenté ?

La question se pose lorsque plusieurs appareils (Arduino et autres) sont connectés entre eux, sans être alimentés tous forcément ensemble.

De façon plus vicieuse, dans un système composé de plusieurs éléments, les alimentations ne sont pas toutes prêtes au même moment, sans compter le temps de démarrage des différentes cartes.

Dans mon application, j'ai plusieurs Arduino "clients" dont une broche configurée en entrée est reliée à la broche d'un autre Arduino "server" configurée en sortie.

J'ai placé des résistances de protection :
- la broche de sortie de l'Arduino server est reliée à une résistance de 330 Ohms dont l'autre extrémité va au "noeud" de connection
- chaque Arduino client a sa broche d'entrée reliée à une résistance de 10 KOhms dont l'autre extrémité va au "noeud" de connection

Cette broche sert à faire un "ping", le server peut ainsi obliger les clients à le contacter en faisant une requête.
Le ping se fait sur changement d'état (passage de 0V à 5V ou passage de 5V à 0V) ce qui facilite la programmation, car un client peut être occupé et "rater" une impulsion

Ca fonctionne très bien ainsi, mais j'aimerais savoir si mes résistances sont suffisantes et bien dimensionnées.

A bientôt

[Delias]

Bonsoir Rémy

Réponse pour les Arduino à base d'AVR (Uno, Mego, Nano, etc.) puisque cela dépend du microcontrôleur, mais c'est très probablement identique pour les autres.

Chaque I/O est en haute impédance tant que le programme n'a pas demandé autre chose, mais chaque I/O ne peut pas être en dessous de Gnd - 0.5V (la patte GND de la puce) et au dessus de Vcc + 0.5V. Donc à l'état sans alimentation une I/O ne peut pas être alimentée au delà de quelques dixièmes de volt.
Constructivement il y a des diodes entres chaque I/O et les rails d'alimentation qui empêche la tension d'aller au delà. Si on alimente une I/O avec une tension supérieur à l'alimentation, on alimente le micro et tout ce qui est sur la même alimentation par l’intermédiaire de ces diodes.
Sauf que ces diodes sont des protections ESD qui n'ont pas une capacité de courant ni une capacité thermique élevée. Alimenter un micro par ces diodes c'est généralement signer leur destruction assez rapidement, puis celle de l'I/O ou du micro en entier.

C'est notamment de là que vient le fait d'avoir des pull-up et un tirage à la masse sur les circuits externes. Dans un système à multi-alimentation les transitions doivent être étudiées, soit en utilisant des sorties collecteurs ouverts, soit avec des circuits de bus qui n'ont pas ces limitations, soit en insérant des résistances dans les lignes de données (plutôt du bricolage pour cette dernière variante). De toute manière une alimentation différente signifie généralement une certaine distance et donc la nécessité de l'utilisation d'un bus (RSxxx, Modbus, CAN, etc.)

Bonne semaine

Delias

[Beginner.]

Salut,

Question intéressante à laquelle peu doivent penser...

[electroremy]

Bonjour,

Grâce ou à causes des diodes de protection des I/O, les entrées ne sont donc pas à "haute impédance" lorsqu'un Arduino est éteint.
Pour une sortie ce n'est pas gênant, mais ça l'est pour une entrée.
C'est important et à prendre en compte.

Les résistances ont l'inconvénient de diminuer la bande passante.
C'est à prendre en compte aussi.

Il y a un autre problème épineux : l'état des I/O lors du démarrage.
On sait déjà que certaines broches (TX/RX) doivent être évitées si on utilise le bootloader et/ou le port série en débug.

Mais j'ai un truc bizarre sur mon Arduino UNO, équipé du Shield Ethernet 2 : si je resete la carte, alors la broche A2 passe furtivement à l'état haut.

C'est emmerdant car je m'en sert en sortie pour piloter la bobine d'un relais bistable.
Donc à chaque reset, le relais se... reset aussi évidemment ce comportement n'est pas voulu
Là aussi ce comportement est ennuyeux pour une sortie, et encore plus pour une entrée - les broches Ai sont quand même conçues à la base pour être des entrées analogiques.

J'utilise aussi A0 et A1 de la même façon et je n'ai pas ce problème.

Savez vous pourquoi ?

Arduino a voulu rendre facile l'usage des microcontrôleurs mais n'a pas pensé à ces aspects... Vu le prix des cartes, une circuiterie type ouput enabled aurait été la bienvenue...

A bientôt

[Vincent PETIT]

Bonjour,
En effet quand le circuit est éteint on ne parle plus de haute impédance, il est juste éteint

Ces diodes de protections internes peuvent mettre de l'électronique simple en route malgré qu'elle soit éteinte. Certains circuit CMOS peuvent démarrer si on envoie des signaux sur les entrées malgré l’absence d'alimentation (il s'auto-alimente.) Imaginons ce circuit intégré non alimenté, si on envoie 5V sur son entrée, la diode D1 se met à conduire (la tension sur son anode est de 5V et la tension sur la cathode est de 0V), on perd 0.6V au passage et il peut rester 4.4V sur V_S.



Dans cette autre configuration on voit qu'en ayant mis une résistance devant on limite le courant passant dans la diode (pour ne pas qu'elle casse déjà) mais surtout, s'il reste quand même 4.4V sur V_S, la résistance d'entrée fait que le courant est tellement limité que le composant aura du mal à s'auto-alimenter (pas assez de pêche sur le 4.4V)




ps : dans le premier schéma la résistance de 400Ω sert juste à limiter le courant qui passe dans la diode afin de la protéger.

Les résistances ont l'inconvénient de diminuer la bande passante.

C'est à dire ? Par rapport à la capacité parasite de l'entrée du composant, qui formerait avec la résistance un jolie filtre passe bas RC ?

Il y a un autre problème épineux : l'état des I/O lors du démarrage.

Oui c'est un des détails les plus important dans un montage électronique car il est source de glitch.

Mais j'ai un truc bizarre sur mon Arduino UNO, équipé du Shield Ethernet 2 : si je resete la carte, alors la broche A2 passe furtivement à l'état haut.

C'est emmerdant car je m'en sert en sortie pour piloter la bobine d'un relais bistable.
Donc à chaque reset, le relais se... reset aussi évidemment ce comportement n'est pas voulu
Là aussi ce comportement est ennuyeux pour une sortie, et encore plus pour une entrée - les broches Ai sont quand même conçues à la base pour être des entrées analogiques.

J'utilise aussi A0 et A1 de la même façon et je n'ai pas ce problème.

Savez vous pourquoi ?

Tu as les schémas ?

Arduino a voulu rendre facile l'usage des microcontrôleurs mais n'a pas pensé à ces aspects

En effet, je pense qu'ils ont été confronté à un compromis entre complexité et prix. Ils auraient pu faire du Arduino un char d'assaut en compatibilité électromagnétique et en protection lors des essais destructifs (moi j'étais obligé de le faire dans mes design pour anticiper des mauvaises connexions, inversion de l'alimentation, surtension sur les sorties, etc) mais le prix n'aurait pas été le même

[Delias]

Bonjour Rémy

De part les tolérances en tension et les capacités en courant des composants, je classe les connexions entre puces en 4 catégories (ce n'est rien d'officiel)
1: Les connexions au sein de la même carte électronique. Un Arduino avec Shield peut rentrer dans cette catégorie, dû à la fiabilité des contacts et l'absence de longueur de fils.
2: Les connexions inter-cartes (et capteurs déportés) au sein d'un même appareil (taille maxi un PC de bureau). L'exemple type c'est les bus fond de panier.
3: Les connexions entre appareil partageant une masse commune (les différents périphériques d'un PC)
4: Les connexions entre appareil qui bien que branché à la même terre, ne peuvent pas partager une masse commune (exemple plusieurs PC d'un même bâtiment)
Hors catégorie: Les connexions entre appareil n'ayant pas la même terre -> Il faut de l'isolation galvanique c'est fibre optique ou plus anciennement des transfos comme pour les téléphones analogiques.

Les microcontrôleurs sont de base limité à la catégorie 1. Les AVR furent parmi les premiers à s'autoriser la catégorie 2 avec limitation. C'est maintenant le cas de la plupart des micro en 5V, alors que ceux en 3V3 restent limité à la 1.
Petite aparté, le SPI est un bus de la catégorie 1 de part sa vitesse, l'I2C peut aller dans le 2. Certain capteurs à faible vitesse peuvent très bien se mettre en catégorie 1.

Ta demande rentre dans la cat 3, où l'on retrouve des adaptations de la cat 2 (le port parallèle pour les imprimante, le PS2 pour clavier et souris) et des bus adaptés (RS232, USB)

Les liaisons de la catégorie 4 c'est l'Ethernet, le CAN, le RS485, etc. La différence avec le 3 c'est qu'il y a beaucoup de bruit entre les masses des deux appareils, et il faut une bonne réjection du mode commun.

Question alimentation, c'est alimentation unique (éventuellement avec plusieurs tensions) pour les catégories 1 et 2, ce n'est qu'a partir de la 3 que l'on retrouve des alimentations multiples. Dans les catégorie 1 et 2, si on a plusieurs alimentation, il faut ajouter des circuits qui permettent de gérer cela (une des solutions simple mais un peu battarde, c'est de maintenir le reset tant que toutes les alimentations ne sont pas à valeur nominale).

Il ne faut pas oublier que Arduino c'est la découverte des microcontrôleurs sans devoir s’inquiéter de la conception électronique ni de la configuration de base du micro. C'est à double tranchant, d'un côté cela aide à rentrer dans le domaine, de l'autre, le step pour sortir et aller plus loin est grand et décourageant. Il faut également une bonne dose d’apprentissage pour passer ce step.

Pour ton problème sur A2, ce n'est pas de base du micro. Soit tu as une pull-up externe, soit le circuit externe va à 1 quand il est en l'air (ce qui est peu probable pour une commande de relai), soit l'I/O est configurée en Pull-up ou en sortie à 1 avant l'écriture de l'état 0. (Par le bootloader ou par ton programme)

Edit: J'ai failli ne pas voir la réponse de Vincent

En effet quand le circuit est éteint on ne parle plus de haute impédance, il est juste éteint

Ou pas, certains circuits acceptent d'avoir leur entrées alimentées sans s'auto-alimenter dessus, mais c'est généralement les circuits dédiés aux catégories 3 et 4 de mon message.
Mais sur les micros, c'est toujours en "haute impédances dans la limite des deux rails d'alimentation", comme quand c'est en marche (mais avec une plage plus faible). Essayez de mettre -1V ou 6V sur une I/O d'un AVR en marche et il se passera le même problème (ça fume).

Bonne suite

Delias

[electroremy]

Bonjour,

Merci pour ces réponses bien argumentées...

Mon système est composé de plusieurs boitiers éloignés (des clients et un serveur) connectés entre eux
Un "boitier" c'est un Arduino avec un shield Ethernet, un écran (sauf pour le serveur) et quelques petits composants discrets

Je pense avoir (presque) bien fait les choses :

Les boitiers sont reliés entre eux :
- par Ethernet
- par quatre fils :
* une alimentation 9V commune
* une masse commune
* mon fameux fil de "ping" commun
* un fil "de mise en route client" mais il n'est pas relié aux Arduino

Pour l'alimentation et le fil de "ping", deux des quatre paires Ethernet seront utilisées (car en 100 Mbits on utilise que 2 des 4 paires)
C'est du bon câble Ethernet CAT6 avec écran et blindage.
D'ailleurs j'envisage même de tirer deux câbles : un Ethernet pour la communication et un Ethernet pour l'alimentation et le fil de ping.
Ce n'est pas très cher et utile pour les évolutions ultérieures.

Tous les boitiers clients ne sont pas alimentés en permanence.
D'où ma question initiale.
Le fil de "ping", quand il est au niveau +5V, va donc "pousser" du courant dans les broches des Arduino clients qui sont éteints.
Ma résistance de protection fait 10kOhms, le courant "poussé" est donc faible : 0,5mA.
Mais je mesure quand même 0,9V aux bornes de l'entrée. Si on enlève la chute de tension dans la diode, j'alimente mon Arduino avec 0,3V.
Est-ce dangereux ? Si oui, les Arduinos auraient du "frirent"* depuis le temps.
Rien ne m'empêche d'augmenter la valeur de cette résistance.

* les américains disent frirent au lieu de cramer, parce que le gras c'est la vie

Dans chaque boitier client, un bouton poussoir de mise en route relie à la masse le fil de mise en route.
Dans le boitier serveur, chaque fil de mise en route de chaque client arrive sur la bobine "SET" d'un relai bistable, bobine dont l'autre connexion est relié à l'alimentation.
Bien sûr il y a une diode de roue libre.
Il suffit donc d'appuyer sur le bouton pour mettre le relai en position "ON"
Je pense que vous avez deviné, les contacts de ce relais connectent le fil d'alimentation du client à l'alimentation 9V centrale située au niveau du serveur.

C'est le serveur qui éteint les clients.
C'est tout bête : au bout de X minutes d'inactivité du client, le server envoie une impulsion sur la bobine "RESET" du relais bistable du client pour l'éteindre.
Bien sûr, je n'ai pas relié directement la bobine à une sortie du server Arduino.
La sortie est connectée à une résistance de 10K Ohms qui va à la base d'un transistor NPN.
L'émetteur du transistor est à la masse, le collecteur relié à la bobine "RESET" dont l'autre extrémité est reliée à l'alimentation.
Bien sûr il y a une diode de roue libre.

Bref, c'est le schéma très classique de commande d'un relais bistable.

Pour mon histoire avec la broche A2 je ne comprend pas...
Je viens de faire les tests tout de suite... et tout fonctionne, le problème n'est plus là
J'ai essayé plusieurs fois, j'ai recommencé avec l'USB branché au PC pour programmer le server, pareil...

Avant de recommencer le test pour vous répondre, j'avais remis au propre une fonction, sachant que je ne vois pas comment cette fonction a pu causer le problème , et dommage je n'ai plus l'ancienne version ...

J'ai du corriger un bug sans le vouloir

Moralité on gagne toujours à reprendre son code pour le rendre plus propre.
Surtout sur Arduino quand on a du code qui utilise des Buffers[], des pointeurs en RAM, des pointeurs en ROM (progmem) ça donne des bugs avec des résultats toujours surprenants

A bientôt

[jpbbricole]

Bonsoir electroremy

Surtout sur Arduino quand on a du code qui utilise des Buffers[], des pointeurs en RAM, des pointeurs en ROM (progmem) ça donne des bugs avec des résultats toujours surprenants

Progmem, c'est de la mémoire flash, la mémoire ROM ne peut être que lue ? (Read Only Memory)

Cordialement
jpbbricole