Pseudo système de fichier pour une mémoire Flash embarquée

[invite33b4430c]

Bonjour à tous,
Je travaille sur un projet embarqué qui utilise une mémoire Flash externe pour sauver des données de log et maintenance.
Je programme un MPC5554 (PPC).
Pour un soucis de simplicité et taille de code, je cherche une description des systèmes de fichiers classiques pour Flash mais à chaque fois que je trouve une doc, je ne trouve que des infos sur l'architecture des donnéee en RAM après montage, et aucune information sur l'écriture des descripteurs de fichiers en Flash.
En fait ma problématique est que pour écrire en flash il faut au préalable l'effacer et ceci ne peut être fait que par block entier. Donc comment dois-je faire évoluer mon secteur de description de fichier sachant que je ne peut pas effacer le block qui contient le secteur à chaque fois sinon je tue ma Flash en 100000 utilisation. Pour ce qui est des données (fichier) en elle même cela n'est pas compliquée car il suffit de déplacer les données (fichier) à chaque modification. C'est bien l'évolution du descripteur qui me pose problème (même si j'ai quelques idées) car lui doit avoir une position (relativement) fixe pour pouvoir le retrouver).

Pour info je ne devrais avoir qu'un fichier ou deux à gérer.

Merci d'avance pour vos conseilles.
-----

[Seb.26]

Si y'a que des fichiers de log sur ta FLASH, pas besoin de FAT !
( par contre, ce n'est plus lisible sur un Pc lambda )

[invite33b4430c]

Salut,
Je ne parle pas de système FAT. Ce dont j'ai besoin c'est de gérer le décalage de mon fichier ou mes données dans la mémoire à chaque modification. C'est pour ça que je parle de pseudo système de fichier. Je connais les techniques de façon théorique mais pas en pratique.
La mémoire n'est écrite et lue que par le micro donc je peux utiliser une gestion perso.
Quelqu'un saurait m'expliquer comment gérer mon secteur de mémoire dans lequel je décris la position de mes données ? Je cherche à avoir une gestion qui se rapproche des systèmes fichier classiquement utilisés pour les flashs externe pour PC par exemple mais en simplifié.

Petit rappel de la problématique: Il ne faut pas utiliser pour des cycles effacement/écriture la même portion de flash (usure prématurée), donc il faut faire bouger les données à l'intérieur de la mémoire à chaque modification. Il en va de même pour le secteur de description mais lui vu que c'est le "point d'entré", ça me semble compliqué de le faire bouger.

Merci d'avance pour vos idées et commentaires

[invite29971eb1]

Peut-être en allant gratter du côté de YAFFS:
http://www.yaffs.net/

[A voir en vidéo sur Futura]

[Seb.26]

Si c'est un fichier de log, normalement, tu ne fais qu'ajouter des données, non ? ...

[invite33b4430c]

Ce n'est pas qu'un log.
Mon utilisation est :

1. Démarrage du micro, je lis les données actuellement en Flash et je les stocke en RAM.
2. Pendant l'exécution, je fais évoluer les données en RAM
3. Avant extinction, j'enregistre les données en Flash à un endroit différent de là où je les avais lu au démarrage pour avoir une usure minimale de la Flash.

A propos du YAFFS j'avais déjà fait un tour là bas mais je n'ai pas trouvé les détails que je cherchais mais je vais continuer dans cette direction.

J'ai aussi la possibilité de faire des écritures par bloque avec un petit flag en entête qui me renseigne sur la validité du bloque ("bloque en cours"). Mais à mon avis je perds pas mal de temps de vie de ma mémoire car mes données ne vont pas remplir un bloque entier (128 ko).

[invite29971eb1]

Je n'ai pas encore utilisé ces choses, donc je ne peux pas t'aider beaucoup plus qu'en donnant des liens.

En voici un autre, tu trouveras peut-être l'exemple qui va bien:
http://elm-chan.org/fsw/ff/00index_e.html

[Murayama]

Bonjour!

Si vous travaillez principalement en RAM, ce n'est peut-être pas la
peine de se compliquer la vie.
Vous démarrez et arrêtez le système combien de fois par jour?

Pascal

Ce n'est pas qu'un log.
Mon utilisation est :

1. Démarrage du micro, je lis les données actuellement en Flash et je les stocke en RAM.
2. Pendant l'exécution, je fais évoluer les données en RAM
3. Avant extinction, j'enregistre les données en Flash à un endroit différent de là où je les avais lu au démarrage pour avoir une usure minimale de la Flash.

A propos du YAFFS j'avais déjà fait un tour là bas mais je n'ai pas trouvé les détails que je cherchais mais je vais continuer dans cette direction.

J'ai aussi la possibilité de faire des écritures par bloque avec un petit flag en entête qui me renseigne sur la validité du bloque ("bloque en cours"). Mais à mon avis je perds pas mal de temps de vie de ma mémoire car mes données ne vont pas remplir un bloque entier (128 ko).

[invite33b4430c]

Je suis malheureusement tenu de mettre en œuvre ce genre de gestion.

En plus le nombre de cycles effacement/écriture par jour peut être assez élevé > 10 sur 20 ans ça fait 71000 sans compter les années bissextiles et c'est un minimum. Donc on est pas loin des 100000 cycles fatidiques.

[Murayama]

Bonjour! (Re!)

Si c'est une obligation, bon, ça peut se justifier, mais sinon, il y a de
nombreux processeurs avec un mode basse consommation
qui maintient la RAM. Ce qui fait qu'une écriture de temps en temps
quand on n'a rien d'autre à faire, ça peut suffire. De toute façon,
je suppose que le processeur est d'une manière ou d'une autre
en veille. Personne ne vient l'allumer et l'éteindre 10 fois par jour,
j'ai bon?
Donc il est possible de maintenir la RAM opérationnelle.

Pascal

Je suis malheureusement tenu de mettre en œuvre ce genre de gestion.

En plus le nombre de cycles effacement/écriture par jour peut être assez élevé > 10 sur 20 ans ça fait 71000 sans compter les années bissextiles et c'est un minimum. Donc on est pas loin des 100000 cycles fatidiques.

[invite33b4430c]

C'est vrai.
En réalité le nombre d'extinction sera plus de l'ordre 1/mois. Mais j'envisageais de faire des sauvegardes intermédiaires sur détection de certains événements. Ce n'est pas encore tranché. Dans ce cas les événements ont la fréquence indiquée plus haut. Je ne voudrais pas que sur bug micro on perde les données d'un mois entier (voir plus).
La zone de la RAM qui peut être maintenu par alim externe n'est pas alimentée donc sur Reset je perds tout
Je pense partir sur un solution sans zone de descripteur. Je vais placer une entête au bloque actif que je ferai passer à 0x0 quand je passe au bloque suivant. Ensuite je subdivise mon bloque en fonction du nombre de fois que je peux mettre mes données dans un bloque (la taille des données sera fixe ou bornée). La encore je mettrais un entête à mes données pour indiquer quelle zone dans mon bloque est active. Au démarrage je n'est plus qu'a trouver le couple bloque/zone actif, le copier en RAM, l'invalider. Je connais alors la zone mémoire suivante dans laquelle je ferai la prochaine sauvegarde.
Je pense que j'effacerai le bloque précédent quand je passe au bloque suivant.

Qu'en pensez-vous ?

[Kissagogo27]

bjr, en effet c'est le plus simple, copier les données a la suite dans la zone mémoire avec des octets définits comme début de fichier/fin de fichiers, réinitialisés une fois lus pour continuer dans la zone mémoire suivante indiquant la nouvelle position du nouveau fichier log... ^^