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

[electroremy]

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

Exact, mais au moment de l'execution du programme, flash et ROM ne peuvent être que lues, c'est presque pareil.

D'ailleurs à l'époque où CPU, ROM et RAM étaient dans des composants séparés, pour stocker le programme :
- on utilisait une flash ou une RAM avec une batterie pour la mise au point
- puis une ROM ou une EPROM sur la version finale
Le CPU n'y voyait que du feu.

Question intéressante : est-il possible d'écrire un programme qui par mégarde écrit la flash ? (comme ce que fait le bootloader)
Dans le même esprit, est-ce possible d’exécuter des instructions en RAM ?

Ca ne serait pas très utile sauf pour hacking ou des choses très expérimentales.

Imaginons un programme qui plante car le pointeur de programme reçoit une mauvaise valeur ce qui amène l'Arduino à exécuter des données stockées en flash (valeurs de constantes, textes, valeurs en PROGMEM)
Si des instructions assembleur permettant d'écrire la flash sont possible, alors il est possible, lors de ce plantage, que le programme dans l'Arduino se "suicide" en modifiant son propre code en flash.
Dans le cas de ce plantage, l'Arduino peut d'autodétruire si les instructions exécutées par erreur agissent sur les entrées sorties.

A bientôt

[jpbbricole]

Bonsoir electroremy

Exact, mais au moment de l'exécution du programme, flash et ROM ne peuvent être que lues, c'est presque pareil.

Mouai!!


Cordialement
jpbbricole

[Beginner.]

Si des instructions assembleur permettant d'écrire la flash sont possible, alors il est possible, lors de ce plantage, que le programme dans l'Arduino se "suicide" en modifiant son propre code en flash.
Dans le cas de ce plantage, l'Arduino peut d'autodétruire si les instructions exécutées par erreur agissent sur les entrées sorties.

Mais pour écrire dans la mémoire flash n'y y a-t-il pas des conditions au niveau hardware à respecter ? Je pose la question je n'ai pas vérifié...

Cela dit si c'est faisable uniquement par programme alors on pourrait se servir d'une partie de la mémoire flash comme RAM, non ?

[Delias]

Bonsoir à tous

La bonne méthode dans ce cas c'est de mettre des collecteurs ouverts au serveur et les entrées des clients en pull-up. (collecteur ouvert, c'est le même schéma que pour la commande du relais, une résistance et un transistor NPN, sans la diode de roue-libre)
Mais vu que le serveur ne peut pas être éteint alors que des clients sont allumés, on peut simplifier et utiliser les I/O en pseudo collecteur ouvert. L'écriture sur les sorties se fait sur le mode et non la valeur. En Input, la sortie est collecteur ouvert et laisse le 5V du pull-up, et en output valeur = 0, la sortie tire vers la masse le signal du client. En codage AVR on se contente d'écrire dans DDRX,n et PortX,n reste à 0.
Petit bonus, on peut lire si le client est en fonction en lisant l'I/O lorsqu'elle est à 1 (càd mode input).

On peut écrire dans toute la flash par le code. C'est un peu casse pied pour écrire sur soit-même mais c'est faisable.
Condition: que cela soit autorisé par les fusibles (fuses) et faire la bonne série d'opérations. Il faut écrire dans plusieurs registres à la suite pour lancer une écriture de la Flash. C'est une sorte de protection statistique, il est quasi impossible d'avoir par erreur la série d'instruction correcte qui lance une programmation de la Flash, alors que avec une seule instruction cela pourrait effectivement arriver.

Par contre il est impossible d’exécuter un code depuis la RAM, d'où l'impossibilité de faire tourner un langage interprété.

Bonne suite

Delias

[Beginner.]

Merci Delias.

Je ne suis pas sûr de savoir ce que sont les fusibles dont tu parles, il faudrait que je vois ça...

[Delias]

Bonsoir Beginner

Les fusibles sont des cases mémoires définissant quelques paramètres fondamentaux du fonctionnement du micro. Historiquement c'était vraiment des "fusibles" sous la forme de petites pistes ou de diodes que l'on pouvait faire griller à la programmation (donc non réversible). Maintenant c'est juste une mini mémoire EEPROM ou Flash. Par contre on ne peut les programmer qu'en programmation ISP ou Parallèle.

Pour la programmation, toutes les explications sont aux chapitres 25 à 27 du datasheet de l'ATMega328P.

Bonne lecture

Delias

[electroremy]

La bonne méthode dans ce cas c'est de mettre des collecteurs ouverts au serveur et les entrées des clients en pull-up. (collecteur ouvert, c'est le même schéma que pour la commande du relais, une résistance et un transistor NPN, sans la diode de roue-libre)

Oui, mais évidemment, il faut un transistor pour chaque client.

Concrètement le serveur alimente le fil "ping", via la résistance de 330 qu'on peut laisser pour protéger la sortie du server contre les courts circuits éventuels.

Dans chaque client, le fil "ping" alimente une résistance de 10K relié à la base d'un transistor NPN dont l'émetteur est à la masse, et le collecteur relié à l'entrée "ping" du client.

Une variante est d'utiliser un optocoupleur à collecteur ouvert, là on respecte bien mieux les principes des catégories 1 à 4, mais le serveur devra être capable d'alimenter autant d'optocoupleurs qu'il y a de clients.

Mais vu que le serveur ne peut pas être éteint alors que des clients sont allumés, on peut simplifier et utiliser les I/O en pseudo collecteur ouvert. L'écriture sur les sorties se fait sur le mode et non la valeur. En Input, la sortie est collecteur ouvert et laisse le 5V du pull-up, et en output valeur = 0, la sortie tire vers la masse le signal du client. En codage AVR on se contente d'écrire dans DDRX,n et PortX,n reste à 0.
Petit bonus, on peut lire si le client est en fonction en lisant l'I/O lorsqu'elle est à 1 (càd mode input).

En effet cela permet d'éviter d'utiliser des transistors.
La lecture pour savoir si le client est en fonction c'est une bonne idée, car le problème des relais bistables c'est que leur état peut être inconnu au démarrage, car même si on sauvegarde l'état des relais en EEPROM avant extinction "propre" du système, en cas de reset sauvage ou de plantage on aura une incertitude sur l'états des relais, sauf à imaginer qu'au démarrage on a une séquence d'initialisation des relais.
Cela impose d'avoir une sortie "ping" du server pour chaque client.
Vu que mon câblage sera "en étoile" avec le serveur au centre de l'étoile, je peux opter pour cette solution, si j'ai assez de sorties disponibles sur le server.
En plus, cela permet de "pinguer" les clients individuellement et pas tous ensemble.
Il faudra juste que le serveur dispose de 2 sorties par client (une pour l'éteindre, et une pour le "ping").
Vu que ce ne sera pas du "haut débit", on peut recourir à un circuit de démultiplexage pour ces sorties.

On peut écrire dans toute la flash par le code. C'est un peu casse pied pour écrire sur soit-même mais c'est faisable.
Condition: que cela soit autorisé par les fusibles (fuses) et faire la bonne série d'opérations. Il faut écrire dans plusieurs registres à la suite pour lancer une écriture de la Flash. C'est une sorte de protection statistique, il est quasi impossible d'avoir par erreur la série d'instruction correcte qui lance une programmation de la Flash, alors que avec une seule instruction cela pourrait effectivement arriver.

C'est rassurant...
D'ailleurs cela me fait penser à autre chose : désactiver le bootloader pour avoir un temps de démarrage plus rapide et quelques octets en plus pour la flash.
Je le ferais certainement sur le projet final.

A bientôt

[Beginner.]

Merci Delias pour la réponse.