stockage des données dans le buffer

[invitec65ba29c]

Bonjour à tous,

j'utilise un Atmega32, sous le logiciel AVR studio4.
Je récupère une donnée via un capteur de température.
Cette donnée vaut par exemple 25.25 et j'aimerais le stocker dans le EEPROM du microcontroleur pour ensuite l'envoyer via la liaison RS232.

Pour le stockage des données, je suis un peu perdu......
Car on doit stocker octet par octet?
Dans ce cas, devrais je mettre 25.25 sous la forme d'un tableau comme ça :

 chaine[0] = '$' ;
 chaine[1] = '2' ;
 chaine[2] = '5' ;
 chaine[3] = '.' ;
 chaine[4] = '2' ;
 chaine[5] = '5' ;
 chaine[6] = 'C' ;

et faire

for (i=0;i<7;i++)
 {
 eeprom_write_byte (i,chaine[i]);
 }

Je me dis que, je fais un peu n'importe quoi, c'est pourquoi j'aimerais avoir votre avis.

Merci.
-----

[Jack]

Quelles fonctions d'écriture en eeprom as-tu à ta disposition?

La donnée fournie par le capteur de température est plutôt sous forme d'un entier ou d'un octet d'habitude. Pourquoi te compliquer la vie et la stocker sous la forme d'un flottant codé en ASCII?

A+

[invite29971eb1]

Et pourquoi les mettre en EEPROM?

Tu veux garder cette température même si le jus est coupé?

[invitec65ba29c]

les fonctions d'écriture EEPROM que j'ai à ma disposition sont :

void eeprom_write_byte (uint8_t *addr, uint8_t value);
void eeprom_write_word (uint16_t *addr, uint16_t value);
void eeprom_write_block (void *pointer_eeprom, const void *pointer_ram, size_t n);

les données du capteur est composé de 2 octets dont les 4 bits du poids faible représentant les chiffres après la virgule.
Je me complique la vie?Comment je pourrais le faire autrement?
Je code en ascii car je dois envoyer les données via une liaison RS232 et dans ce cas, les informations sont véhiculés octet par octet codé en ascii non?

J'ai choisi le EEPROM car je me suis dis que c'est peut être plus sure?En cas de plantage je ne risque pas de perdre les données qui ont été sauvegardé.Est ce mieux d'utiliser SRAM? Ou quelques chose dans le genre?

J'avoue que je ne m'y connais pas trop, je suis encore entrain d'apprendre le maximum sur le net, mais c'est pas trop le top...

[A voir en vidéo sur Futura]

[Jack]

Je me complique la vie?Comment je pourrais le faire autrement?
Je code en ascii car je dois envoyer les données via une liaison RS232 et dans ce cas, les informations sont véhiculés octet par octet codé en ascii non?

la taille de l'eeprom est généralement limitée. Je trouve plus naturel de stocker 2 octets représentant la valeur brute issue du capteur plutôt qu'une dizaine en ASCII. Tu peux toujours convertir la valeur en ASCII plus tard, après l'avoir relue dans l'EEPROM.

void eeprom_write_word (uint16_t *addr, uint16_t value);

la fonction précédente devrait suffire pour écrire ta valeur

A+

[invite29971eb1]

En fait, il faut bien distinguer la manière dont est stockée la donnée et la façon dont elle est présentée à l'utilisateur. Tu es libre de la stocker sous la forme que tu veux et de la transmettre sous la forme que tu veux.


Si la température est seulement destinée à être affichée sur le PC, la logique voudrait que tu la stockes sous la forme la plus compacte soit celui d'origine, 2 octets. Si tu la stockais sous forme de chaine, ça ferait 5 octets, ce qui peut être gênant si tu enregistres plusieurs températures, car tu mettrait 2,5 fois moins de mesures dans l'EEPROM.

Le choix du mode d'envoi va dépendre de ce que tu vas utiliser comme programme côté PC. Si c'est le simple terminal de Windows, tu as tout intérêt à la transmettre sous forme de chaine pour qu'elle s'affiche correctement.

Si maintenant tu écris un petit programme de visualisation, tu peux très bien remettre en forme la température à partir des 2 octets de base.

Pour le choix SRAM/EEPROM, encore une fois, ça dépend de tes besoins.
Effectivement, si tu veux garder tes données même alimentation coupée, tu as tout intérêt à choisir l'EEPROM mais il faut savoir que son accès est bien plus lent que la SRAM. Sur un log de température, ça ne semble pas critique, mas sur une acquisition de signaux rapides, ça peut l'être.

Egalement, il faut savoir que l'EEPROM a une durée de vie limitée qui s'exprime en nombre de lectures/écriture. Au-delà de 100 000 écritures, le constructeur ne garantit pas que la donnée soit enregistrée correctement.

Mais à nouveau, dans ton cas, je ne pense pas que tu sois concerné. En enregistrant la température toutes les heures, et en la stockant toujours au même endroit dans l'EEPROM, tu es déjà tranquille pour 11 ans. La batterie sera morte avant ça

[invitec65ba29c]

Bonjour et merci pour vos réponses avec tant de précision.

Alors, j'ai oublié de préciser que j'ai d'autres capteurs derrière comme par exemple le capteur de pression, d'humidité et je dois mettre tous ces données en une seul trame et le stocker dans le buffer par exemple de la forme $T,25.25,C,P,1.02,B,H,76.
J'écris cette trame dans le buffer octet par octet (charactère par characère) mais d'un autre coté, dès qu'un octet est écrit dans le buffer il y a une autre fonction qui se charge de le véhiculer vers un autre microcontroleur via la liaison RS232.

Si non quand je fais :

void eeprom_write_word (uint16_t *addr, uint16_t value);

un word c'est composé de 2 octets? Donc ça veut dire qu'il faut prévoir par exemple l'adresse 1 + l'adresse 2 pour une seul word?
Par exemple si je fais :

eeprom_write_word (1,temp);
eeprom_write_word (2,press);

ça ne marche pas car on écrase la première valeur?

[Jack]

oui, un octet par adresse, donc pour stocker un word, il faudra utiliser des adresses de 2 en 2.

A+

[invitec65ba29c]

Merci,

Tout compte fait, je ne peux pas stocker la valeur brute issue du capteur car je dois stocker sous une certaine forme, par exemple : $T,25.25,C,P,1.02,B,H,76.
Dans ce cas, j'ai essayé d'utiliser un sprintf comme ça :

char buff[10];
sprintf(buff,"%f",25.25);
int taille = strlen(buffer);

for (i=0;i<taille;i++)
 {
 eeprom_write_byte (i,buff[i]);
 }

Mais ça n'a pas l'air si simple.
Le sprintf ne marche pas.
Est ce que quelqu'un a déjà eu à utiliser un sprintf avec un float sous AVR studio4?

[Jack]

Les compilateurs pour petits µcontrôleurs sont un peu spéciaux car la taille de l'exécutable est un élément essentiel. Or un sprintf est très gourmant. Du coup, il y a peut-être des options de compilation gérant ceci dans AVR studio. Il faudrait jeter un oeil sur la doc.

Autre piste, as-tu autorisé la gestion des flottants, ceux-ci pouvant être interdits à cause de la taille de la bibliothèque les gérant?

A+

[invitec65ba29c]

Merci pour ta réponse,

Finalement, ça a l'air d'aller, reste à savoir si c'est vraiment une bonne méthode de faire comme ça.
Effectivement, il fallait un peu modifier le makefile pour faire marcher le sprintf.
Apparemment, il vaut mieux éviter les float tant que possible.

Au cas où ça pourra aider quelqu'un plus tard :
http://winavr.scienceprog.com/avr-gc...n-avr-gcc.html

Merci à vous deux!

++