Mémoriser un temps de fonctionnement

[SGRmetrage]

Bonjour;
Je me présente étudiant en Terminale STI2D et notre projet et de réaliser un stylo 3D (Pour plus d'informations faites une recherche c'est vraiment un projet passionnant) ce n'est pas la première fois que je viens sur ce forum pour ce projet j'ai de nouveau besoin de votre aide.

Voici ce que je dois réaliser : Explorer des solutions pour mémoriser le temps de fonctionnement à l'arrêt de la tête et cumuler ce temps lors d'un redémarrage.
Je m'explique, à l'aide du RTC (DS1302 ou DS1307) nous allons estimer le temps de fonctionnement du stylo pour prévoir la maintenance du stylo en changeant la tète. Nous voulons donc mémoriser ce temps de fonctionnement lorsque l'on arrête le stylo et le cumuler ce temps lorsqu'on le rallume.
Pour cela j'ai deux solutions :
- La première, qui était l'idée de mon prof stocker sur la RTC
- La seconde, stocker sur l'eeprom interne de ma carte arduino

Après de nombreuses recherche je n'arrive toujours pas à me décider, certain me dise qu'il faut prendre la première solution, d'autre non... J'aurais besoin donc d'avis. Sachant que je ne suis vraiment pas très doué en électronique... alors si vous pourriez m'aider, m'expliquer le fonctionnement, comment réaliser cela..

merci d'avance .
-----

[SGRmetrage]

Pour avoir plus d'informations sur notre projet voici le cahier des charges :
le cahier des charges du groupe entier : http://www.partage-facile.com/J1CNVS...drage.pdf.html
Et plus précisément le mien : http://www.partage-facile.com/TFU2LR..._n__4.pdf.html

[SGRmetrage]

Après une discussion avec mon prof il n'est pas contre pour utiliser leprome mais le soucis c'est qu'il n'y a pas une grosse mémoire... en même temps nous n'en avons pas besoin de beaucoup .

[PA5CAL]

Bonjour

L'idée du prof n'est pas mauvaise. Puisqu'on utilise une RTC pour compter le temps, autant profiter de la mémoire sauvegardée qu'elle contient, et qui suffit à l'application.


En comparaison, l'écriture de l'EEPROM interne du µC de l'Arduino nécessite une somme de précautions, dont certaines peuvent être gênantes pour l'exécution de l'application (arrêt momentané des interruptions), et d'autres difficilement contrôlables (garantie d'une tension d'alimentation minimal).

Si la limite du nombre de cycles d'écriture (100000) peut être géré (il ne faut pas venir écrire chaque seconde à la même adresse), en revanche les risques de ne pas pouvoir écrire ces données au moment voulu ou de les avoir corrompues restent non négligeables.

[A voir en vidéo sur Futura]

[SGRmetrage]

D'accord donc si je comprend bien il est tout de même préférable d'utiliser la mémoire de la RTC ?

[SGRmetrage]

Pourtant on me dit aussi je cite "Une RTC est inutile, il suffit de générer un intérruption toute les secondes pour compter le temps et ne pas oublier de sauver ce compteur en cas de perte d'alimentation.
Pour un Arduino c'est encore plus simple, tu utilise l'instruction millis()."

[PA5CAL]

Le choix d'utiliser ou non la RTC t'appartient. Que tu le fasses ou que tu ne le fasses pas, il faut que tu aies une bonne raison.

On va rester dans les généralités, puisque tu sembles nous distribuer au compte-goutte les informations et conseils extérieurs concernant ton projet.


Comme je l'ai indiqué, pour écrire dans l'EEPROM, il est nécessaire de disposer d'une tension d'alimentation minimale, supérieure à la tension requise pour faire tourner le µC. En cas de perte d'alimentation, "ne pas oublier de sauver le compteur" pourrait tout bonnement se solder par une opération d'écriture incorrecte et l'altération de l'information qu'on se propose de sauvegarder.

Pour réduire ce risque, on peut s'interdire d'écrire dans l'EEPROM lorsque la tension d'alimentation chute, et effectuer des sauvegardes fréquentes du comptage afin de réduire l'erreur commise en cas de perte d'alimentation. Malheureusement, on fait alors face au problème de la limitation du nombre d'écritures dans l'EEPROM.

D'autre part, cette solution requiert l'utilisation d'un timer du µC pour le seul comptage du temps, timer qui ne sera donc plus disponible pour d'autres usages dans ton application.

Il est tout de même probable qu'on puisse trouver une compromis pour mettre en œuvre cette solution. Mais tu ne nous as pour l'instant donné aucune information qui nous permettrait d'y réfléchir.


Comparativement, la solution à RTC, dont la mémoire RAM sauvegardée par pile ne connaît pas de limite en terme de nombre d'écritures, ne pose pas ces problèmes.

[SGRmetrage]

Bonsoir;
Tout d'abord veillez m'excuser de vous distribuer au compte-goutte les informations et conseils extérieurs je découvre les solutions envisageable en fouillant sur les forums...
Nous ne savons pas du coup quoi prendre, quoi utiliser. Certain disent qu'ils vaut mieux prendre l'eeprom d'autre plus la rtc... en fin de compte nous sommes perdu, nous n'avons aucune notions la dessus...
Je pense plutôt me pencher vers la RTC qui pose moins de problème.

[PA5CAL]

La RTC ne pose pas le genre de problème que j'ai évoqué, mais cela ne veut pas dire que ce soit la meilleure solution.

Avant de faire des choix, il est important de connaître les critères qui permettent de les faire.

D'une manière plus générale, quand on mène un projet, on commence avant tout par exprimer les besoins auxquels on souhaite répondre, le plus précisément possible, et établir les contraintes sur le produit final (environnement, sécurité, éléments imposés, ...) et sur le projet lui-même (budget et temps impartis, moyens techniques disponibles, ...). Ces informations permettent d'établir un cahier des charges fonctionnel, à partir duquel on pourra concevoir une solution adaptée décrite dans un cahier des charges technique, résultant de choix qu'on saura être adaptées aux contraintes et besoins répertoriés. Le développement du produit proprement dit ne peut commencer qu'ensuite.

Bref, tu ne peux choisir ou rejeter une solution (en l'occurrence la RTC ou l'EEPROM) qu'en sachant quels sont les avantages et les inconvénients elle représente du point de vue des objectifs et des contraintes de ton projet. Il faudrait donc commencer par les établir.

[SGRmetrage]

A vrai dire nous n'avons pas vraiment de contraintes imposé.
le cahier des charges du groupe entier : http://www.partage-facile.com/J1CNVS...drage.pdf.html
Et plus précisément le mien : http://www.partage-facile.com/TFU2LR..._n__4.pdf.html

D'après moi il serait plus simple de mettre une RTC qui a bien sur ses inconvénients c'est sur mais pour nous la RTC serait plus simple. Après d'un autre coté pour mes autres fonctions qui sont :
- "Afficher une informations temps de fonctionnement atteint par une led"
Je m'explique, à l'aide d'une RTC (DS1302 ou DS1307) nous allons estimer le temps de fonctionnement du stylo pour prévoir la maintenance du stylo en changeant la tète. Nous voulons donc mémoriser ce temps de fonctionnement lorsque l'on arrête le stylo et le cumuler ce temps lorsqu'on le rallume. Imaginons qu'on a fixé un seuil à 100h d'utilisation, le but serait de faire allumer une led qui indiquerais que les 100h sont dépassé.
- "Afficher des informations de température (Led température de fusion atteinte et led température de sécurité dépassé) "
Mème principe mais cette fois avec une led de température de fusion atteinte et une led température de sécurité dépassé
Une bref schéma : On a un capteur de température (qui sort une tension variable, pour cela on va utiliser une Thermistance Pt100, La PT100 en entrée de deux comparateurs, mais avec un seuil différent (Seuil de température atteinte, seuil de sécurité) que l'on règles grâce à un potentiomètre.)-->Arduino(qui transforme la tension en valeur numérique et en déduit la température) --> La température est comparé au seuil et si elle le dépasse la led s'allume (allumée par l'arduino) C'est à peut prèt cela que je veux réaliser.

J'aurais besoin d'une RTC pour compter le temps ou d'un Timer dans ce cas je devrais alors prendre un EEPROM.

[SGRmetrage]

Nous avons après envisager d'autres solutions.
Si je comprends bien : dans la carte arduino on a un microcontrôleur type ATMEGA328, et un timer y es intégré. C'est bien cela ou est-ce un module à part ?
Ce timer va donc nous permettre de mesurer une durée. Mais pour la stocker ? On peut faire donc faire cela dans l'eeprom interne d'arduino non ?
Tout cela n'est-il pas trop compliqué ? étant donné mon faible niveau en language arduino..

Je tenais à vous remercier pour toutes l'aides que vous m'apportez, ainsi que le temps que vous prenez pour m'aider.
Merci.

[PA5CAL]

L'Arduino est un système de développement complet, incluant des librairies logicielles qui facilitent grandement la programmation sans avoir à se soucier du fonctionnement sous-jacent du microcontrôleur de la carte. C'est ce qui le rend accessible à des débutants.


Le microcontrôleur ATmega328P de la carte Arduino Uno intègre en fait un timer de 16 bits et deux timers de 8 bits (en interne, et pas dans un module externe). Toutefois certaines librairies logicielles, lorsqu'on les utilise, en réservent l'usage pour leur fonctionnement propre. Un timer ne pouvant pas être utilisé simultanément pour deux usages incompatibles, les possibilités d'un développement "simple" s'en trouvent limitées.

Si l'application envisagée imposait d'utiliser plus que les trois timers disponibles, il serait probablement possible de contourner le problème, mais au prix d'une bien plus grande complexité de la programmation (manipulation directe des registres, recours au langage assembleur, ...).


Pour écrire dans l'EEPROM interne du microcontrôleur, il existe une librairie spécifique qu'il suffit d'invoquer. Pour ce faire, au début du programme on inclut la déclaration :

#include <EEPROM.h>

Ensuite, pour écrire un octet de valeur val à l'adresse addr dans l'EEPROM, on appelle la fonction :

EEPROM.write(addr, val);

et pour relire cette valeur, on appelle la fonction :

val = EEPROM.read(addr);

Ce n'est pas compliqué.

Mais comme je le disais précédemment, les problèmes auxquels on s'expose sont :
- le nombre limité d'écritures dans l'EEPROM (si l'on devait écrire une valeur à la même adresse chaque seconde, la durée de vie indiquée par le constructeur serait atteinte au bout de seulement 28 heures de fonctionnement !)
- le risque de perdre l'information enregistrée dans l'EEPROM si l'opération d'écriture intervient à un moment où la tension d'alimentation est trop basse.

[SGRmetrage]

Comment vous remercier ? Je suis tout de suite plus éclairé...

Dans mon cas je n'aurais besoin que d'un seul timer donc ce sera largement suffisant.
Je vous remercie pour les indications sur le programmes, ça me permet bien de me situer.

Pour ce qui est du problème d'écriture, voila ce que l'on m'avait conseiller :

Il n'est pas obligatoire d'enregistrer les données toujours à la même adresse

Exemple d'enregistrement de valeurs comprises entre 0 et 254 (0xFE) :

1- Initialisation de l'EEPROM => mettre la valeur 0xFF à toutes les adresses

2- A chaque enregistrement d'une nouvelle valeur, l'enregistrer à l'adresse suivante (la valeur 0xFF étant interdites car elle représente la valeur de zone non utilisée)

=> donc pour détecter la dernière valeur, c'est la valeur qu'il y a juste avant la première valeur 0xFF

=> il faut diviser la mémoire au moins en deux zones pour gérer le cas où l'on arrive en fin de zone : quand la zone 2 est rempli, il faut effacer la zone 1

Avec cette methode (pour une EEPROM de 1024 octets), tu pourras donc sauvegarder 1024x100 000/2 = 51.2 millions de fois un octet en aillant au moins les 1024/2=512 dernières valeurs encore en mémoire

Donc en sauvegardant toutes les minutes, tu tiendras 97 ans

[SGRmetrage]

De plus je tiens à préciser que le choix d'une d'une RTC n'etait pas sans intérêt par rapport à un timer. Lorsque je fais un timer pour allumer une LED, une erreur de quelques milli secondes ne pose absolument aucun problème. Par contre, comme ton but est de calculer un temps total d'utilisation (donc plusieurs centaines d'heures ? Milliers d'heures ?) on devras accumuler plusieurs milliers ou millions de fois ton timer. Une erreur systématique sur le temps va donc s'accumuler et les erreurs de mesure aléatoires s'accumulent.

Donc, se pose la question de savoir si cette erreur de mesure est importante et intéressante à mesurer. En toute honnêteté, je n'en sais rien

[PA5CAL]

Pour ce qui est du problème d'écriture, voila ce que l'on m'avait conseiller :

Il n'est pas obligatoire d'enregistrer les données toujours à la même adresse

Exemple d'enregistrement de valeurs comprises entre 0 et 254 (0xFE) :

1- Initialisation de l'EEPROM => mettre la valeur 0xFF à toutes les adresses

2- A chaque enregistrement d'une nouvelle valeur, l'enregistrer à l'adresse suivante (la valeur 0xFF étant interdites car elle représente la valeur de zone non utilisée)

=> donc pour détecter la dernière valeur, c'est la valeur qu'il y a juste avant la première valeur 0xFF

=> il faut diviser la mémoire au moins en deux zones pour gérer le cas où l'on arrive en fin de zone : quand la zone 2 est rempli, il faut effacer la zone 1

Avec cette methode (pour une EEPROM de 1024 octets), tu pourras donc sauvegarder 1024x100 000/2 = 51.2 millions de fois un octet en aillant au moins les 1024/2=512 dernières valeurs encore en mémoire

Donc en sauvegardant toutes les minutes, tu tiendras 97 ans

C'est une solution possible pour retarder suffisamment le problème de la limite du nombre d'écritures (il en existe d'autres).

Toutefois, elle ne règle pas le problème de la corruption éventuelle de l'EEPROM en cas de tension d'alimentation trop basse.

[PA5CAL]

Par contre, comme ton but est de calculer un temps total d'utilisation (donc plusieurs centaines d'heures ? Milliers d'heures ?) on devras accumuler plusieurs milliers ou millions de fois ton timer. Une erreur systématique sur le temps va donc s'accumuler et les erreurs de mesure aléatoires s'accumulent.

La fonction millis() qui a été suggérée plus haut n'est pas une temporisation, mais un comptage du temps écoulé depuis la mise en route de l'Arduino à l'aide du timer matériel. Ce comptage s'effectuant sur 32 bits, il est normalement mené de manière continue jusqu'à son dépassement de capacité, qui intervient après 2³² millisecondes (soit approximativement après 49 jours, 17 heures et 3 minutes), au moment duquel il repart à zéro.

Si l'on s'y prend bien dans la programmation et si le nombre de remises en marche de l'Arduino n'est pas exagéré, il n'y a pas de raison de voir s'accumuler une erreur significative pour cette raison.


Par ailleurs, la base de temps étant un quartz à 16 MHz, la précision de la mesure de temps n'atteint peut-être pas celle d'un oscillateur à quartz horloger bien réglé, mais elle reste assez convenable pour l'application visée. Le quartz étant spécifié pour 30ppm, sans compensation logicielle, l'erreur ne devrait pas dépasser 2,6s par jour (sauf défaut de fabrication de l'Arduino ou utilisation à des températures hors norme).


NB: ce message me laisse dubitatif... dois-je comprendre que vous êtes plusieurs à squatter le même compte utilisateur sur le forum ?

[SGRmetrage]

C'est ce que je pensais et puis même si l'erreur était de quelques minutes ce serait infime.
Non j'ai simplement fais des recherches.

Merci pour votre confirmation.