Un Arduino est-il capable de fonctionner 24/7?

46

Je crée un serveur Web Arduino simple et je veux le garder allumé tout le temps. Donc, il faut supporter de continuer à travailler en permanence.

J'utilise un Arduino Uno avec un Ethernet Shield. Il est alimenté par une simple prise de courant 5V @ 1A.

Mes questions:

  • Aurais-je des problèmes à quitter l'Arduino tout le temps?
  • Existe-t-il une autre carte Arduino mieux recommandée pour cela?
  • Y a-t-il des précautions dont je dois tenir compte à ce sujet?
Butzke
la source
Première question!
TheDoctor
Note du modérateur: il semble que nous obtenions beaucoup de réponses indiquant que cela fonctionnait dans leur situation. Si vous avez quelque chose de technique à ajouter à la question, n'hésitez pas à y répondre. Cependant, les réponses techniques semblent indiquer que cela fonctionne. Si vous devez absolument déclarer que votre situation a fonctionné, il serait préférable d'ajouter un commentaire.
Anonyme Penguin

Réponses:

58

Vous ne devriez pas avoir de problèmes à le garder tout le temps, cependant, il faut prendre en compte tous les compteurs que vous pourriez avoir, comme l’utilisation de millis().

De la documentation Arduino sur millis :

Ce nombre débordera (reviendra à zéro) après environ 50 jours.

Ainsi, pour les projets qui durent longtemps, il se peut que vous ne voyiez pas un problème immédiatement, mais quelque chose comme cela pourrait apparaître et causer des erreurs plus tard.

Sachleen
la source
19
Pour être précis, millis est une uint32_tvariable, donc il débordera ("reviendra à zéro") en 4294967296 millisecondes, ce qui correspond à environ 49,7 jours, ~ 1193 heures ou ~ 71582 minutes.
Connor Wolf
5
Ensuite, tout ce que vous avez à faire est d’utiliser un autre uint32_t qui s’incrémente au premier retournement. Ensuite, vous pouvez profiter d’environ 5,846 × 10 ^ 8 années entre deux roulements.
80HD le
4
si vous faites millis () - startTime (avec l'heure de début comme un unsigned long, alias uint32_t), vous obtiendrez toujours un résultat valide à moins que plusieurs débordements ne se produisent
Lesto
1
Pour être plus précis, le débordement survient après 49 jours, 17 heures, 2 minutes, 47 secondes et 295 millisecondes.
Memet Olsen
4
Le dépassement de millis () ne doit jamais être un problème. Voir millis () débordement ... une mauvaise chose? pour plus de détails. En gros, si vous calculez des intervalles de temps par soustraction en utilisant les types de données appropriés, vous ne rencontrerez jamais de problème.
Nick Gammon
33

Quelques points à garder à l'esprit (en dehors de la mention de @ Sachleen millis()):

  • Comme toute électronique, la chaleur peut être perturbatrice. Le microcontrôleur lui-même ne posera probablement pas un problème énorme du point de vue de la chaleur, mais d’autres composants tels que l’alimentation pourraient poser problème.

  • Si votre code utilise EEPROM.write(), sachez que la mémoire EEPROM de l'ATmega328P de votre Uno n'est conçue que pour 100 000 écritures.

Matthew G.
la source
12

N'oubliez pas que la durée de vie des mémoires flash et EEPROM est limitée (environ 10 000 et 100 000 cycles d'écriture, respectivement). Par conséquent, si vous écrivez beaucoup, elles risquent d'être corrompues. Dans un test que j'ai fait, une EEPROM externe a pris environ 3 jours pour commencer à devenir corrompue.

Le docteur
la source
1
Bien que la documentation puisse répertorier 10 000 cycles, de nombreux tests ont montré que les problèmes commencent à se situer aux alentours de 100 000.
Ron
La durée de vie de l'EEPROM est d'au moins 100 000 cycles d'écriture, conformément à la fiche technique. Je pense me souvenir d’avoir lu un test où la corruption avait commencé à près d’un million de personnes.
user2973
10

Faire fonctionner l'Arduino 24/7 ne devrait pas être un problème.

Mais assurez-vous que vous avez un boîtier qui permet la ventilation et le conservez dans un endroit bien ventilé. Tout comme les ordinateurs, si vous ne les gardez pas dans un environnement qui les garde au frais, ils ne le resteront pas.

La charge du serveur devrait également être une chose à prendre en compte, plus il y a de charge sur le serveur, plus le traitement à effectuer est important, et plus il génère de chaleur.

JVarhol
la source
3
L’ATmega n’a pas les modes traditionnels à faible consommation d’énergie, contrairement aux ordinateurs classiques; la charge n’est donc pas pertinente. Si vous ne faites pas de calcul actif, il vous suffit d'attendre le spin. En réalité, la consommation d’énergie lors de l’exécution est plutôt statique (à l’exception de choses telles que l’écriture sur la mémoire EEPROM / flash), du moins pour l’ATmega MCU. La consommation électrique de l’interface Ethernet peut varier en fonction de la charge de trafic, mais rien n’est susceptible de générer suffisamment de chaleur pour poser problème, à moins que ce soit dans un vide parfait, sur un radiateur ou quelque chose du genre.
Connor Wolf
1
Atmega328p possède un mode veille à faible consommation d’énergie, qui tire ~ 0,1 µA.
JRobert
2
Ce qui ne serait pertinent que si le code met le processeur en veille.
Chris Stratton
8

Nous utilisons notre système d’accès RFID basé sur Arduino chez Bloominglabs Hackerspace à Bloomington IN depuis la fin de l’année 2011 et, mis à part quelques pannes de courant et mises à jour logicielles, il fonctionne 24 heures sur 24, sans problème. Plus récemment, nous avons ajouté un thermostat en réseau, même solution: il fonctionne 24 heures sur 24.

sdcharle
la source
Moi aussi, j'ai un système d'accès RFID fonctionnant 24h / 24 et 7j / 7. La seule fois où il "échoue" est si le courant est coupé, car il fonctionne à partir du secteur. Cela fonctionne depuis 2011 sans aucun problème.
Nick Gammon
Haha, hé Steve!
Deltaray
@ NickGammon Oui, votre système est cool, mais pourquoi l'authentification n'est-elle pas basée sur les données de la carte, mais uniquement sur le jeton UID? S'il vous plaît nous montrer une solution intelligente.
user2497
à quoi veux-tu en venir? cela n'a rien à voir avec la question de l'affiche.
sdcharle
6

Arduinos peut fonctionner sans problème pendant très longtemps, mais en fonction des conditions locales et de l'intensité du calcul, il peut être nécessaire de fixer des dissipateurs de chaleur.

De plus, gardez-le bien ventilé.

Cela dépend également du programme utilisé. Si votre serveur sert une page de temps en temps, cela ne devrait pas être un problème, mais si vous vous attendez à un trafic constant, l'Arduino risque de chauffer rapidement.

Vous voudrez également assurer la stabilité de l'alimentation électrique. Lorsque vous effectuez des expériences sur ordinateur avec un Arduino, ce n'est pas un gros problème, mais cela peut devenir un problème si le courant passe du secteur à une installation permanente.

Manishearth
la source
2
Il n'y a aucune raison d'attendre que la charge de calcul cause la surchauffe d'un Arduino. Comme cela a été souligné dans les réponses plus factuelles, le cas normal est de fonctionner à pleine charge. S'il existe un composant susceptible de surchauffer, il s'agira du régulateur de tension, mais cela dépend principalement de la tension d'entrée, car il fonctionne déjà presque au courant le plus élevé attendu sans rien faire.
Chris Stratton
@ChrisStratton un blindage Ethernet peut varier en puissance en fonction de l'utilisation. En outre, l'Arduino pourrait être dans un état d'alimentation faible (par exemple, dormir entre 12h et 5h).
Pingouin anonyme
4

Je n'ai jamais couru un Arduino aussi longtemps, mais il ne devrait pas y avoir de problème. Une chose à surveiller est la tension d'entrée.

Tandis qu’un Arduino est capable de gérer 7-20 v en entrée, tout ce qui dépasse 12 v peut surchauffer après de longues périodes et endommager la carte. Comme une recommandation rapide pour éviter toute surchauffe de l'Arduino, je maintiendrais la tension aussi proche que possible de 7v.

Steven10172
la source
4

J'aimerais mentionner un problème qui ne se pose pas très souvent, mais qui peut causer des problèmes à long terme. Fuites de mémoire et fragmentation de tas. Presque personne ne mallocs dans les éléments incorporés, mais si vous le faites, faites-le correctement.

ÉternitéForêt
la source
Vous m'avez battu, +1.
hoosierEE
Je crois que la classe String utilise malloc et que c'est assez courant.
user2973
D'accord. Surtout avec un serveur Web, assurez-vous de ne rien faire qui puisse fragmenter la mémoire, comme utiliser la classe String. Cependant, il est facile d'éviter cela. J'ai un Arduino fonctionnant comme serveur Web pour me laisser savoir si ma porte de garage est fermée. Cela dure depuis des années.
Nick Gammon
4

J'ai construit un moniteur de puissance simple avec mon premier Arduino. Il est alimenté via USB à partir d'un serveur Web, lui-même alimenté par une batterie de secours assez importante (sans possibilité de notification).

Il est également connecté à un chargeur de téléphone portable branché sur une prise d'alimentation sans UPS.

Donc, si l’alimentation meurt, l’Arduino envoie un message à un petit programme exécuté sur le serveur. Le programme serveur m'envoie à son tour une notification par courrier électronique.

Il a été installé fin septembre 2013, le 23 mars 2014 - j'ai reçu mon premier email!

Donc, je n'ai pas vu de problème (il n'utilise pas millis ()) mais il échantillonne la puissance toutes les 5 secondes.

TimboTinkerer
la source
1

Un Arduino est-il capable de fonctionner 24/7?

C'est une question de fiabilité. En termes de fiabilité, il y a beaucoup de choses à considérer.

  1. Les logiciels. Il existe des logiciels plus robustes. Il existe des logiciels moins robustes. Par exemple, pour les applications critiques, l’allocation dynamique de mémoire est déconseillée car elle pourrait entraîner une fragmentation de la mémoire. Malheureusement, Arduino dépend fortement de l’allocation dynamique de la mémoire. Ce problème est exacerbé car la plupart des cartes Arduino ont une mémoire RAM très limitée.
  2. Les bibliothèques Beaucoup de bibliothèques Arduino ont des bogues (même ceux intégrés dans le paquet Arduino, aussi simple que WString!). En fonctionnement normal, ces bugs peuvent ne pas apparaître du tout. Cependant, vous ne pouvez pas espérer que "tout ira bien" et que "l'utilisateur" (ou le sous-système) agira comme prévu. Les bibliothèques peuvent aussi avoir leurs limites (c’est-à-dire ne pas être correctement bogues). Par exemple, de nombreux utilisateurs ont déjà cité la fonction millis (), qui réinitialise après 50 jours. Ceci, s'il n'est pas géré correctement, peut conduire à de graves bugs.
  3. La fiabilité du matériel (ne parle même pas de clones Arduino bon marché ...). Ici s'ouvre une nouvelle classe de sous-questions. Je ne citerai qu'un sous-ensemble très limité.
    • Les cartes Arduino sont-elles conçues pour la fiabilité? (par exemple, quelle est la
      fiabilité des condensateurs utilisés? et des autres composants?)
    • Robustesse contre les EMI? Je ne m'appuierais pas là-dessus: la plupart des cartes Arduino ne comportent que deux couches et ne disposent pas d'un plan de masse / masse approprié.
    • EEPROM (logiciel et matériel). Votre logiciel utilise-t-il l'EEPROM? Est-ce que la mise en œuvre d'un algorithme pour empêcher le cyclage (écriture / effacement répété sur les mêmes cellules)?
    • Temps de rétention de la mémoire flash. Le temps de rétention diminue avec la température et aussi avec le nombre de cycles de programmation.
    • Rayonnement ionisant. Oui, même si la probabilité est TRÈS faible, du moins au niveau de la mer, la probabilité de perturbation d'un événement isolé par rayonnement n'est pas nulle et il convient de prendre des contre-mesures adéquates (en particulier si la RAM ne détecte aucune erreur matérielle ) dans des applications critiques.
    • La qualité de l'alimentation.
    • L'environnement d'exploitation. Un environnement contrôlé à 25 ° C ou dans une boîte noire sur le toit (70 ° C sous le soleil en été)? Plus la température est élevée, plus tous les mécanismes de dégradation sont rapides.
    • ...

Néanmoins, vous ne devriez pas être surpris si votre arduino fonctionnera parfaitement pendant de nombreuses années. Mais cela ne garantit pas que chaque arduino le fera.

Certaines contre-mesures augmenteront la fiabilité:

  • Utilisez le chien de garde: il est préférable de réinitialiser un système non réactif que d’avoir un système bloqué / mal conduit.
  • Évitez d'utiliser une bibliothèque utilisant l'allocation de mémoire.
  • Implémentez (si vous utilisez l'EEPROM) un algorithme pour le préserver!
  • Bonne alimentation
  • Évitez les environnements difficiles (température élevée, humidité élevée, cycles thermiques importants et continus, etc.).
prochain hack
la source
0

Il peut certainement fonctionner 24/7. J'utilise soit 5V sur la broche 5V, soit un 7808 sur la broche Vin pour décharger le vreg. Idéalement, il serait de 6,5 V, mais je n'ai pas de telles fournitures. Cependant, vous voudrez peut-être un capuchon découpleur sur 5V pour absorber les pointes mineures lors de la mise sous tension.

Tout matériel connecté fonctionnant à 5V, je me nourris avec un 7805. Vous pouvez utiliser des LM317 ou des LM350 à la place des 78XX, mais vous aurez besoin de quelques résistances pour ceux-ci, peut-être des trimpots.

utilisateur2497
la source