next topic »

[on:]

Bonjour

Je suis tombé il y a quelques temps sur un sujet (évidement je le retrouve plus), qui parlais  de la façon d'écrire sur les cartes SD.
Il était écrit qu'il fallait éviter de faire des open/close, open/close à tout bout de champ car cela tuait très rapidement les cartes SD.

Il était conseillé de faire un open et de ne pas faire de close, mais de faire un truc qui synchronisait le ficher sur la carte SD.
Comme s’était de la fat16/32, il y avait peu de problème de perte des dernières données juste avant le retrait de la carte de son support.

Si quelqu'un sait de quoi je parle...

Merci et bon week end.

[Reply #1 on:]

Il parlait de la plate-forme Arduino ou de d'un PC.
Sur PC les écritures se font à travers un tampon géré par l'OS et donc l'écriture peut être différée, afin d'optimiser les transferts, ce qui nécessite de faire un flush si on veut être assuré que les données sont bien sur la carte avant de la retirer. C'est d'ailleurs pourquoi il y a la fonction "retirer le périphérique en toute sécurité" sur les PC.

Sur l'arduino l'écriture se fait directement donc il n'y a normalement pas de données perdues.

[Reply #2 on:]

Il parlait de la plate-forme Arduino ou de d'un PC.
Sur PC les écritures se font à travers un tampon géré par l'OS et donc l'écriture peut être différée, afin d'optimiser les transferts, ce qui nécessite de faire un flush si on veut être assuré que les données sont bien sur la carte avant de la retirer. C'est d'ailleurs pourquoi il y a la fonction "retirer le périphérique en toute sécurité" sur les PC.

Sur l'arduino l'écriture se fait directement donc il n'y a normalement pas de données perdues.

Oui ma question concerne bien arduino et le terme était aussi flush.

Donc si j'écris continuellement (toutes les minutes pour les valeur de capteur et en temps réel pour les log/debug), ça posera un problème ?

[Reply #3 on:]

Il parlait de la plate-forme Arduino ou de d'un PC.
Sur PC les écritures se font à travers un tampon géré par l'OS et donc l'écriture peut être différée, afin d'optimiser les transferts, ce qui nécessite de faire un flush si on veut être assuré que les données sont bien sur la carte avant de la retirer. C'est d'ailleurs pourquoi il y a la fonction "retirer le périphérique en toute sécurité" sur les PC.

Sur l'arduino l'écriture se fait directement donc il n'y a normalement pas de données perdues.

Oui ma question concerne bien arduino et le terme était aussi flush.

Donc si j'écris continuellement (toutes les minutes pour les valeur de capteur et en temps réel pour les log/debug), ça posera un problème ?

Je viens de trouver file.flush()
Je viens de trouver ça :
http://arduino.cc/en/Reference/FileFlush

Apparemment, les data ne sont pas sauvée automatiquement sauf par un flush ou par un close.
Donc je peux faire un flush toutes les 10mn pour ne pas griller la SD prématurement ?

[Reply #4 on:]

Bonjour

L'usure des cartes SD par des écritures 'fréquentes' est un sujet un peu controversé.
on trouve des  avis (et quelques expériences) avec les mots clefs  'SD card wear levelling'
exemple de réponses plutôt rassurantes :
http://electronics.stackexchange.com/questions/27619/is-it-true-that-a-sd-mmc-card-does-wear-levelling-with-its-own-controller
Visiblement toutes les marques n'ont pas le même niveau d'endurance.

Selon fat16lib, auteur de la librairie SD reprise dans Arduino 1 (reply #6 et #25  du fil ci dessous) l'évolution des controleurs internes des cartes SD repousse les défections dues aux écritures à répétition. (écriture différée par blocs entiers, gestion des blocs défectueux...).

Avec une écriture par minute on peut supposer que la carte succombera à une défaillance mécanique ou électrique avant de perdre un nombre significatif de blocs. Le contexte n'est pas tout à fait le même que pour d'autres types de mémoires flash. (puce flash nue, disque SSD....)
http://arduino.cc/forum/index.php?topic=87325.0
http://arduino.cc/forum/index.php/topic,87325.15.html

[Reply #5 on:]

Bonjour,
Je remonte ce sujet pour savoir si on a aujourd'hui une valeur précise du nombre d'écritures sur une carte SD? (10000? 100000?...)
Je souhaite faire du datalogging toutes les 15 secondes donc je voulais savoir si s'était possible ou si je devais changer de support.

J'ai regardé autour de l'EEPROM de l'Arduino mais elle est donnée pour 100 000 écritures donc trop peu pour moi.
Si j'ai bien fait le calcul l'EEPROM serait morte au bout de 17 jours environ.

[Reply #6 on:]

La meilleure logique est qui de toute façon n'a que très peu d'impact au niveau du confort d'utilisation, c'est de stocker dans la ram, et d'écrire d'un coup toutes les données (soit périodiquement et/ou à l'appui sur un bouton par l'utilisateur). Dans ton cas même une SD risque de vite rendre l'âme (en tout cas tu auras assez vite des secteurs défectueux).

[Reply #7 on:]

Il faut raison garder.
A chaque écriture ce n'est pas toute la carte qui s'use mais seulement le secteur qui vient d'être modifié.
Une carte 16G cela fait un certain nombre d'octets (combien ? va savoir exactement : c'est des gigabits ? des gigabytes ? )
mais cela fait beaucoup même en prenant le cas défavorable  c'est à dire en comptant en bit.

Si je prend 1 octet enregistré toutes le 15s cela fait (60/15)*24*365=35 koctets par an.
Avant de remplir entièrement la carte il va se passer des années

Je pense que le problème concerne les enregistrements de gros fichiers à partir d'un ordinateur comme des fichiers video et où la carte peut être effacée entièrement assez fréquemment.

[Reply #8 on:]

La meilleure logique est qui de toute façon n'a que très peu d'impact au niveau du confort d'utilisation, c'est de stocker dans la ram, et d'écrire d'un coup toutes les données (soit périodiquement et/ou à l'appui sur un bouton par l'utilisateur). Dans ton cas même une SD risque de vite rendre l'âme (en tout cas tu auras assez vite des secteurs défectueux).

Oui mais le problème que j'ai c'est que j'aimerais faire face à une panne d'alimentation, donc je suis obligé de stocker "en dur" les données tout le temps.
Si je stocke dans la RAM et que j'ai une panne à ce moment là, je perds les données...

Il faut raison garder.
A chaque écriture ce n'est pas toute la carte qui s'use mais seulement le secteur qui vient d'être modifié.
Une carte 16G cela fait un certain nombre d'octets (combien ? va savoir exactement : c'est des gigabits ? des gigabytes ? )
mais cela fait beaucoup même en prenant le cas défavorable  c'est à dire en comptant en bit.

Si je prend 1 octet enregistré toutes le 15s cela fait (60/15)*24*365=35 koctets par an.
Avant de remplir entièrement la carte il va se passer des années

Je pense que le problème concerne les enregistrements de gros fichiers à partir d'un ordinateur comme des fichiers video et où la carte peut être effacée entièrement assez fréquemment.

Je pense qu'il manque les heures dans ton calcul, non?:
(60/15) = 4 octets par minute
4 * 60 = 240 octets par heure
240 * 24 = 5760 octets par jour
5760 * 365 = 2102400 octets par an = 2053.125 Ko = 2Mo/an

Je comprends le calcul, en effet, je n'écrit pas beaucoup d'octets à la fois sur la carte donc je suis loin de la remplir rapidement...

Cependant on ne connait toujours pas bien le nombre d'écritures/lectures possibles du coup..

[Reply #9 on:]

"Je pense qu'il manque les heures dans ton calcul, non?:"
  elles sont restées dans la calculette

imaginons 10 octets par "cycle" d'écriture, celà fait  20Mo par an. Avec une carte 8G (c'est courant maintenant) la carte se remplie en 8000/20= 400 ans 
Je pense que je ne serais plus là 

[Reply #10 on:]

Ok, donc ce que j'ai intérêt à faire c'est uniquement de l'écriture et lecture, mais très peu d'effacement.

Il faudra donc que je gère la lecture de la dernière ligne de mon fichier pour pouvoir récupérer les dernières données sauvegardées en mémoire SD.

 

[Reply #11 on:]

Je n'ai jamais essayé mais il me semble qu'il existe une (ou +) librairie qui gère(nt) la carte Sd comme une eeprom, sans système de fichier donc.
Peut être que d'autre pourront t'en dire plus.

[Reply #12 on:]

Sur l'arduino l'écriture se fait directement donc il n'y a normalement pas de données perdues.

Pas tout à fait, il y a un buffer même dans la librairie Sdfatlib, d'où la présence de la fonction flsuh().

Il faudra donc que je gère la lecture de la dernière ligne de mon fichier pour pouvoir récupérer les dernières données sauvegardées en mémoire SD.

Faut aussi ce poser la question du format: binaire ou texte.
Si tu veut une longévité maximum le format binaire est le plus adapté.
Si tu veut pouvoir lire les données toi même sans outils le format texte est nécessaire.

Je n'ai jamais essayé mais il me semble qu'il existe une (ou +) librairie qui gère(nt) la carte Sd comme une eeprom, sans système de fichier donc.
Peut être que d'autre pourront t'en dire plus.

Sinon il existe des codes arduino de démo pour communiquer en mode SPI avec une carte SD.
Par contre ça oblige à faire des écritures par bloc il me semble (à vérifier).