Arduino: Comment déconnecter l'alimentation sans que la boucle "loop()" recommence du début ?

[invitef7125f97]

Bonjour,

Je poste ce message après de nombreuses et infructueuses recherches pour comprendre comment fonctionne exactement le système Arduino lorsqu'on le met hors-tension.

Tout d'abord, j'utilise une carte Arduino Uno.
J'ai besoin que mon programme se stoppe et redémarre exactement là où je l'ai arrêté, c'est-à-dire qu'il ne redémarre pas au début de la boucle loop(). J'ai compris que cela était possible grâce à un interrupteur mais le problème qui se pose alors est qu'au bout d'un moment la batterie qui alimente Arduino va finir par se décharger, et la carte sera alors hors tension... Et le programme devrait alors redémarrer la prochaine fois au début de la boucle, ce que je veux éviter.
Il doit bien y avoir un moyen d'éviter cela. Pouvez-vous m'aider ?

Ma question reste théorique car je n'ai pour l'instant pas tous les composants nécessaires pour réaliser mon projet donc j'anticipe.

Merci
-----

[invitee05a3fcc]

Il doit bien y avoir un moyen d'éviter cela. Pouvez-vous m'aider ?

A la coupure du jus, tu stockes la valeur du PC en EEPROM.
Par contre, au redémarrage, il y aura la ré-initialisation du contexte du µC ( sortie, entrée, UART, Timer etc etc)
Bref ..... le mieux, c'est de prévoir une bonne batterie .... ou de changer la philosophie de ton programme .

[invitef7125f97]

A la coupure du jus, tu stockes la valeur du PC en EEPROM.

C'est-à-dire ?

Par contre, au redémarrage, il y aura la ré-initialisation du contexte du µC ( sortie, entrée, UART, Timer etc etc)

C'est-à-dire que le void setup() se relance ? Qu'est-ce que le contexte ?

Bref ..... le mieux, c'est de prévoir une bonne batterie .... ou de changer la philosophie de ton programme .

Combien de temps une simple pile 9v energizer peut durer à votre avis ?

[invitee05a3fcc]

Vu les questions que tu poses .... tu n'as pas les compétences pour mener à bien ce projet . Met une batterie 12V 45Ah !

[A voir en vidéo sur Futura]

[invitef7125f97]

D'accord, merci de votre franchise. Je vais faire ça alors.

[invitee05a3fcc]

Si tu ne sais pas ce que c'est qu'une EEPROM, un compteur CP, un contexte d'un µC ....... tu n'as pas la compétence (ce n'est pas un reproche, mais une constatation) pour faire ça .

Alors, maintenant, ce qui serait intéressant, c'est : Pourquoi tu veux faire ça ?

Quelle est l'application et la finalité de cette demande ?

Tropique disait : Dis moi ce dont tu as besoin, je te montrerais comment t'en passer !

[invite1d577638]

A la coupure du jus, tu stockes la valeur du PC en EEPROM.

C'est effectivement ce à quoi je pense, mais j'ai peur que le bootloader qui s'exécute avant l'exécution normale du programme ne pose problème ?

Mais sinon +1 pour le contexte à préciser.

[invitee05a3fcc]

C'est effectivement ce à quoi je pense, mais j'ai peur que le bootloader qui s'exécute avant l'exécution normale du programme ne pose problème ?

Pas forcément .
Le BootMachin, après exécution donne la main au programme utilisateur .
On vient tester le contenu de l'EEPROM qui mémorise le CP d'avant. On trouve FFFFFF, c'est la première mise sous tension . Terminé.
C'est différent ? On ré-initialise le contexte et GOTO à la valeur PC .

Ce que j'explique, c'est dans le monde des Bisounours car c'est plus complexe. A la coupure du jus, le CP était dans un sous-programme ? une INT ? donc il fallait sauvegarder le stack .....

Bref faut bien réfléchir avant de se lancer dans ce genre de manip !

[invite1d577638]

Certes !

Tout ça pour dire que s'il est possible de l'éviter, c'est encore mieux...!

[invitee05a3fcc]

Voir la réponse du grand philosophe :

Tropique disait : Dis moi ce dont tu as besoin, je te montrerais comment t'en passer !

[invitef7125f97]

Le programme que je veux réaliser est très simple:
J'ai un moteur pas à pas qui tourne à une vitesse constante dans son système d'origine. Mon but est de modifier sa vitesse de rotation: lui donner une vitesse variant périodiquement car les engrenages du système de transmission entraînent des erreurs. Mon programme consiste donc à dire au moteur d'aller à une certaine vitesse pendant un certain temps, puis une autre vitesse, puis encore une autre (petites variations de vitesse) sur une période de l'ordre de 10 minutes.

En résumé, à la place d'un signal constant, j'envoie au moteur un signal périodique que j'ai programmé une fois pour toute d'après les erreurs périodiques que j'ai relevé expérimentalement: l'axe du moteur étant fixé au reste du système de transmission, il faut donc que la rotation du moteur reprenne exactement là où elle s'est arrêtée (d'où l'objet de la discussion).

[invite1d577638]

Donc, tu enregistres uniquement la vitesse, et éventuellement la tempo restante du cycle en cours...?

[azad]

Salut
Toute cette discussion me laisse rêveur.
Si le matériel se résume à une carte Arduino, alors (sauf erreur) il est impossible de reprendre un programme interrompu par une coupure d'alimentation au point où il était avant la coupure.
Les conseils de Daudet ne sont applicables que dans le cas d'un µprocesseur classique. Et encore, à condition de prendre des précautions drastiques du genre déceler la coupure de courant et lancer la procédure (interruption prioritaire) de sauvegarde qui consistera à comme le dit Daudet à sauver le PC (program counter), l'état de la pile, le registre d'état, sans oublier la valeur des différentes variables du programme. Et où sauver tout cela ? Jadis la méthode classique consistait à utiliser une mémoire de maintient à très faible consommation (quelques µA) alimentée par une petite batterie de 3,6V. Et il fallait que la routine de l'interruption s'exécute avant que la disparition du 5V soit effective. On ne dispose que de quelques milli-secondes.
Mais cela n'est vrai que pour un micro-processeur classique. Avec un ATmegaXXX il en va tout autrement, car il faudrait aussi sauvegarder tous les états des périphériques internes à l' AVR (PIA, compteurs, timers, USART, j'en passe sans doute, et des meilleurs).
Avec un programme entièrement écrit en assembleur, cela est peut-être possible, que quelqu'un me corrige si je me trompe.
Et encore une précision : rien ne peut fonctionner en cas de déconnexion de l'alimentation. Ne pas confondre déconnexion et coupure. Avec une coupure et de bons condensateurs, on peut espérer avoir le temps de sauver quelque chose, avec une déconnexion, rien.
Donc, je rejoins Daudet : jamais de coupure, vivent les grosses batteries.

[invitef7125f97]

Donc, tu enregistres uniquement la vitesse, et éventuellement la tempo restante du cycle en cours...?

Oui, si je pouvais faire ça ce serait suffisant. Mais d'après ce qui suit...

Si le matériel se résume à une carte Arduino, alors (sauf erreur) il est impossible de reprendre un programme interrompu par une coupure d'alimentation au point où il était avant la coupure.

Dans ce cas, il est clair que ce que je souhaite faire n'est pas possible. Donc grosse batterie ! Marché conclu.


Merci beaucoup pour votre aide !

[Gérard]

...
lui donner une vitesse variant périodiquement car les engrenages du système de transmission entraînent des erreurs.
...

Comment les engrenages peuvent entrainer des erreurs ?

[invitef7125f97]

Les dents des pignons sont parfois mal fabriquées, ce qui provoque des petits retards puis des petites "avances" lors du cycle d'un pignon. Bien que sur un cycle complet, ces erreurs s'équilibrent.

[antek]

Comment les engrenages peuvent entrainer des erreurs ?

Et comment une variation de vitesse peut supprimer ces erreurs.

[Gérard]

Les dents des pignons sont parfois mal fabriquées, ce qui provoque des petits retards puis des petites "avances" lors du cycle d'un pignon. Bien que sur un cycle complet, ces erreurs s'équilibrent.

Alors achète de bons pignons, ça règle simplement les problèmes invoqués.

[invitef7125f97]

Antek, si je ralentis le moteur quand les pignons accélèrent le mouvement je compense le problème

Gérard, je pourrais effectivement faire ça mais le but était de régler le problème sans toucher à la monture. Mais tu as raison, c'est le plus simple.

[invited9257714]

Bonjour,
Au bout d'un moment il ne risque pas d'y avoir des déviations? Si par exemple l'arduino à un retard de 1% et que le moteur a fait 50 tours ça va amplifier les erreurs.
Pourquoi ne pas mettre un retour vers l'arduino comme un potentiomètre sans butée? Avec ça pas besoin de rester dans le loop. Tu fait une petite fonction pour convertir la position en vitesse.

[invited9257714]

Bonjour,
Au bout d'un moment il ne risque pas d'y avoir des déviations? Si par exemple l'arduino à un retard de 1% et que le moteur a fait 50 tours ça va amplifier les erreurs.
Pourquoi ne pas mettre un retour vers l'arduino comme un potentiomètre sans butée? Avec ça pas besoin de rester dans le loop. Tu fait une petite fonction pour convertir la position en vitesse.

[invitef7125f97]

Oui tu as raison. C'est plus difficile mécaniquement mais plus simple informatiquement, et plus précis..

[invitef7125f97]

Difficile mécaniquement car je n'ai pas accès à l'axe de rotation de sortie sous forme d'un arbre où je pourrais facilement installer un potentiomètre.

[jiherve]

Bonjour,
Serait ce pour un entrainement de monture équatoriale ?
Si c'est le cas alors il suffit de définir un zéro sur l'axe horaire et de le rejoindre en cas de redémarrage, la séquence de compensation restera la même.
Les sauvegardes de contexte sont des procédure délicates à mettre en œuvre(j'en ai 40 ans d’expérience derrière moi) et si l'on peut les éviter il ne faut pas hésiter, ce d'autant plus que les Flash ou les EEPROM ont une limite en ce qui concerne les cycles d’écriture/effacement, il faut donc une gestion par blocs tournants pour éviter leur destruction prématurée.
JR

[invitef7125f97]

C'est exactement ça Jiherve, et effectivement cela règle le problème ! Merci

As-tu toi-même réalisé une compensation de la sorte ?

[jiherve]

Re
Il y a de çà tres longtemps dans une tres lointaine galaxie j'ai effectivement bidouillé un entrainement pour monture équatoriale mais comme à cette époque les plus petits ordinateurs faisaient la taille d'une machine à laver soit on vivait avec les erreurs soit la solution devait être mécanique.
Mais si j'avais à le refaire c'est comme indiqué plus haut que je procéderais, de toutes façon à moins de disposer d'un capteur précis sur l'arbre c'est ce qu'il te faudra faire pour faire un GOTO qui est je présume dans tes projets?
JR

[invitef7125f97]

D'accord je vois oui

Non mon projet se limite simplement à optimiser le suivi de ma monture dans le cadre d'un projet d'étude en fait Or si je remplace les pignons le sujet perd de son intérêt, voilà pourquoi je suis réticent sur ce point

[invitee05a3fcc]

Notre ami Cyril33127 l'a rêvé ? Texas Instruments l'a fait !
http://www.electroniques.biz/compone...nes-de-courant

[jiherve]

Bonsoir
Pas mal l'engin , la fonctionnalité d'une NOVRAM incluse dans le µC c'est astucieux.
Sont toujours bons chez TI!
JR

[invitee05a3fcc]

Sont toujours bons chez TI!

Ouais ... faut modérer le jugement . Depuis que je les ai quitté en 1982, visiblement, y a moins de matière grise ......