¿Por qué no rodar el tuyo?
El diario no es terriblemente difícil de implementar. Todo lo que necesita es un poco de espacio en la EEPROM para poder almacenar una cola circular de acciones y si están completas o no.
Si su EEPROM es pequeña, es posible que solo pueda almacenar los metadatos. Esto evitará la corrupción del sistema de archivos, pero no ayudará con la corrupción de datos de archivos. Si tiene suficiente espacio para almacenar los datos para las escrituras en progreso, puede evitar la corrupción del sistema de archivos y de los datos.
- ¿El laboratorio de codificación dexter es bueno para C / C ++?
- ¿Qué es un buen libro sobre estructuras de datos y algoritmos en javascript?
- ¿Qué algoritmo se puede usar para la predicción de pasajes aéreos?
- ¿Dónde se puede encontrar una foto y detalles biográficos de Burton Howard Bloom, inventor del filtro Bloom?
- Cómo dividir una matriz en 2 nuevas variables de matriz y encontrar el promedio de ellas
Una búsqueda rápida en Google descubre lo siguiente, que puede ser apropiado: peteratebs / tinyfatfs
Pero no ha dado una idea de sus limitaciones, por lo que no sé si se trata de un controlador de 8 bits con 16 GB de memoria direccionable. Supongo que no. Así que supongo que necesitas algo pequeño y fácil de integrar.
He escrito cuatro sistemas de archivos flash. Quizás en el más simple de estos, implementé un esquema como este:
- Los archivos solo pueden ser tan grandes como un solo sector flash (64 KB). [Entonces ~ 128 archivos en una parte de 8MB].
- Directorio raíz único, sin subdirectorios.
- Nivelación de desgaste y registro primitivo integrado en 16 bytes de metadatos almacenados con cada archivo (por lo que la capacidad real de almacenamiento de archivos fue de 64 KB-16B).
Los 16 bytes de metadatos fueron los siguientes:
- Hash de 32 bits del nombre de archivo *.
- Contador descendente de generación de 32 bits a partir de 0xFFFFFFFF.
- Longitud de contenido de 32 bits.
- CRC de 32 bits de metadatos.
* El sistema de archivos contenía una lista bien conocida de archivos, que se guardaba por separado en otra EEPROM, por lo que no era necesario mantener nombres largos en la EEPROM.
Cada vez que se escribe un archivo, primero se encuentra una ranura válida. Una ranura válida es un sector vacío / no válido (identificado por un CRC de metadatos fallido) o una generación válida pero desactualizada de un archivo existente. Esta desconexión entre el contenido del archivo y la ubicación ayuda a nivelar el desgaste.
Una vez que se encuentra un espacio válido, se escriben los datos del archivo.
Una vez que se escriben los datos del archivo, los metadatos se actualizan.
Las escrituras sucesivas del mismo archivo disminuirán la generación del archivo en los metadatos.
El CRC de 32 bits se escribe en último lugar. De esta manera, una interrupción de una escritura en cualquier etapa dejará esta generación * actual * del archivo en un estado no válido. Los metadatos y los datos del archivo de cualquier generación anterior del archivo se conservan y están disponibles cuando se recupera el sistema.
También se implementó la prevención de bloqueo de archivos estáticos. Un archivo escrito con frecuencia tendería a rebotar en sectores ‘libres’ sin esto. De vez en cuando, cuando se escribe un archivo, el sistema de archivos ‘topará’ [reescribirá] otro archivo inalterable para utilizar su espacio sectorial. Si se interrumpe esta reescritura ‘de relieve’, no se pierden datos en el archivo ‘golpeado’, mientras que los datos [pero no el historial, si existen versiones anteriores] se perderían en el archivo escrito con frecuencia.
Al encender el sistema de archivos, simplemente debe pasar por cada uno de los sectores, CRC los metadatos, realizar un seguimiento de la última generación de cualquier archivo válido encontrado y actualizar una tabla de RAM de estos punteros para cuando el archivo se va a leer. El CRC o la protección de los datos del archivo depende de la aplicación.
