Implementar el protocolo FAT32 en un microcontrolador (PIC,AVR,ARM,Z80, etc)

Si el microcontrolador es necesario que tenga 8Kb de RAM mínimo para que pueda correr el protocolo FAT. Igual en una de esas se pueda optimizar el código para que corra en micros con menos prestaciones.
 
Muy buena informaciónramción. Espero que con esto sigas con tu proyecto del USB y elmanual crezca.

Un PIC18F como máximo veo que alcanza 3,968 bytes de RAM. DE 8KBytes nada de nada.

Hay memorias RAM externas que también ha creado Microchip Technology Inc. - a Leading Provider of Microcontroller and Analog Semiconductors de unos 32KB, no se si hay más valores altos que estos, son rápidas, caras y no las he visto en la calle todavía. Se comunican en paralelo y es bueno tener PIC18F de 40 patas como mínimo, ya que usan más de 8 de datos, otras pin para control de no se que, etc...

Hace tiempo leí esta noticia en algún lugar de ELEKTOR.es ? Plataforma para electrónica y microcontroladores
 
Ellos dan esta información sobre el uso de memoria del codigo que utilizan. Ten en cuenta el uso adicional del SPI y del RS232 o USB dependiendo de tu selección.

Memory Usage (R0.07c)


These are the memory usage on some target systems with following condition. The memory sizes are in unit of byte, D means number of volumes and F means number of open files. All samples are optimezed in code size.


moz-screenshot-2.jpg
moz-screenshot-3.jpg
 

Adjuntos

  • MemoryUseChanCode.JPG
    MemoryUseChanCode.JPG
    64.5 KB · Visitas: 93
La verdad que no se, mi tiempo es muy escaso pero mas adelante voy a seguir con mi manual que dentro de poco voy a terminar con la parte teórica que me tiene aburrido pero es esencial para entender de que se trata ese puerto y luego voy a seguir con mis experimentos.
 
Eso espero del manual. Por ahora y sólo por ahora tengo tiempo para hacer el proyecto que gracias con la ayuda de algunos del foro estoy trabajando rápido.

Siguiendo este tema. ¿Lo vas hacer con el fAT16 o FAT32?
 
Hice el intento de montar el FATFS de chan en un PIC18F4550.
El problema con este microcontrolador en específico es que no tiene más que un puerto UART y un Puerto SPI y para completar tienen pines compartidos.
Siendo que me estaba comunicando con la tarjeta decidí dejar el SPI de hardware para la SD e implementar un UART por software.
El requerimiento de trabajo con SPI requiere que tengas una velocidad para la inicialización de la tarjeta y después una mucho mayor para la transferencia de datos. El SPI por hardware hace esto pero no así el de software, de hecho en ninguna documentación de microchip se encuentra el manejo de la velocidad para el SPI por software, incluso al revisar las librerias .h del SPI por hardware encontre los delays con los que trabaja pero no tienen documentación como para saber como modificarlos. En fin, el SPI por software esta mal documentado, no que no funcione, solo que no tienes mucho control sobre el.
Monté entonces el UART por software, funciona bien en sentido de temporización y de que lo que envias lo recibes, sin embargo es la librería más mal hecha que existe!

Para imprimir tienes que crear una variable de memoria
char cadena [] = "Hola Mundo";
printSoftware(cadena);

no puedes simplemente hacer:
printSoftware("Hola mundo");
No lo compila!!!!

si no puedes hacer esto último entonces no puedes usar comandos para imprimir enteros, caracteres, cadenas etc. ex print("hola %l %c", numerolong,caracter)
por lo que te toca hacer tus propias rutinas para hacerlo.

En fin, las hice!!!!! pero el consumo de memoria es altisisimo, si ya tenías problemas con la memoria del chip esto lo hace mucho peor aun si implementas esas variables en memoria de programa
rom char cadena [] = "Hola mundo";

todavía así es demasiado el uso de la memoria de programa.

Sin embargo solo por que ya había trabajado mucho en eso y quería ver el FAT32 de chan funcionando lo monté. La verdad solo monte las rutinas de inicialización de la SD (me funciono con todo tipo de tarjetas, yo uso tarjetas micro SD y lo use con tarjetas desde 128 MB hasta 8GB), solo tuve que hacer modificaciones de temporización para hacerlas correr.

Finalmente monte el fat32, lo inicialice, después revise el número de sectores, tamaño de sector, etc. Y funcionó...............

Pero eso fue todo, para ese punto ocupe toda la memoria de programa y toda la ram, fue triste solo llegar hasta eso, jejeje.

Ya lo monte en el PIC24F como está en el ejemplo y funciona de maravillas, tengo que aprender a usar todas las rutinas pero a este momento ya puedo hacer el listado de todos los archivos de mi tarjeta micro de 8GB.
Solo me falta leerlos pero estoy en esas y no creo que tome mucho tiempo.
Solo estoy usando la mitad de la memoria de programa del Chip y un 60% de la ram!!!

Mi conclusión después de esta odisea es que ya es hora de empezar a trabajar con PIC24s PICds y PIC30, tienen muchisima más memoria, son más baratos, los encuentras en presentación DIP y puedes remapear los puertos por lo que el impreso es más facil de hacer.
El único problema que me he encontrado es una documentación algo deficiente.

Espero esta información sea útil!!!

Por cierto, el 30 de septiembre microchip lanzó su versión del FAT32, antes solo tenían soporte de FAT16. eso puede ser una opción viable para muchos, por mi parte me parece que el FAT32 de chan lleva mucho tiempo funcionando y ya han corregido muchas pulgas que pueden aparecer con microchip.
 
Última edición:
Para imprimir tienes que crear una variable de memoria
char cadena [] = "Hola Mundo";
printSoftware(cadena);

no puedes simplemente hacer:
printSoftware("Hola mundo");
No lo compila!!!!

si no puedes hacer esto último entonces no puedes usar comandos para imprimir enteros, caracteres, cadenas etc. ex print("hola %l %c", numerolong,caracter)
por lo que te toca hacer tus propias rutinas para hacerlo.

David, el compilador no tiene la funcion sprintf.....?

sprintf te envia un mensaje a variable en memoria....

por ejemplo asi,

sprint(buffer, "hola %l %c", numerolong,caracter);

y ya luego solo mandar imprimir el buffer.

printSoftware(buffer);

Si el compilador la tiene, no hay por que escribirla tu mismo y tal vez ahorres un poco de memoria (pensando en que la implementacion es muy eficiente)
 
¿No puedes usar otro sistema de archivo?
Estoy dando sobre el tema de sistemas de archivo en informática y FAT ya no es gran cosa (Excepto para poca memoria). Mejor usar NTFS o ext4. Los PenDrive del futuro a parte de ser USB 3.0 serán de WinFS.

Lo curioso es que ya están hablando de Windows 8 y 9 ya para 128 Bits. ¿A acaso 64 Bits ya no es gran cosa? La verdad que no noto mucho para ser 64 Bits.

Fuente:
http://www.muycomputer.com/Actualid...QPbxsvkzsCfueFLF7l9K830bxfJ_Dre2iY0cZZT9-nYEs
 
¿No puedes usar otro sistema de archivo?
Estoy dando sobre el tema de sistemas de archivo en informática y FAT ya no es gran cosa (Excepto para poca memoria). Mejor usar NTFS o ext4. Los PenDrive del futuro a parte de ser USB 3.0 serán de WinFS.

Lo curioso es que ya están hablando de Windows 8 y 9 ya para 128 Bits. ¿A acaso 64 Bits ya no es gran cosa? La verdad que no noto mucho para ser 64 Bits.

Fuente:
http://www.muycomputer.com/Actualid...QPbxsvkzsCfueFLF7l9K830bxfJ_Dre2iY0cZZT9-nYEs

Meta, creo que te has olvidado que estamos hablando de microcontroladores o microprocesadores de 8 y 16 bits principalmente, y en pocos casos de 32 bits.

Asi que implementar un sistema de archivos así consume muchos recursos, que es precisamente de lo que se esta discutiendo.

Se implementa un sistema de archivos FAT por que este lo puede leer cualquier equipo con Windows o Linux, hay sistemas mucho mas sencillos pero que un sistema de escritorio no puede leer.
 
David, el compilador no tiene la funcion sprintf.....?

sprintf te envia un mensaje a variable en memoria....

por ejemplo asi,

sprint(buffer, "hola %l %c", numerolong,caracter);

y ya luego solo mandar imprimir el buffer.

printSoftware(buffer);

Si el compilador la tiene, no hay por que escribirla tu mismo y tal vez ahorres un poco de memoria (pensando en que la implementacion es muy eficiente)

Jejeje, que buena idea, la verdad no la pense al momento, estaba cansado de optimizar para bajar unos cuantos bytes aqui y allá. De esa manera tal vez podría retomar ese proyecto en algún otro momento usando el petit FAT de chan sin embargo ahora estoy muy feliz trabajando con el PIC24, es mucho mejor que el PIC18 aunque como mencione antes no hay mucha documentación.

Con respecto al FAT32 de Chan ya puedo leer y escribir archivos y es muy muy bueno.

Moyano No creo que haya necesidad de usar la carpeta de fat de microC, yo tengo ese compilador en la versión profesional y la verdad solo tienen soporte de FAT16 según veo en mi documentación.

La versión de Chan esta escrita en ANSI C lo que quiere decir que se puede usar con cualquier compilador que soporte este estandar. el CCS no lo hace por cierto.

Meta la Razón de haber hecho esto es por que necesitaba leer datos de la tarjeta SD. Según la SD card association ellos van a usar el FAT32 por lo menos para tarjetas de hasta 2Teras. ahora van como por 32GB y todavía lo están usando.

Con respecto a otros sistemas de archivo como NTFS la verdad no me parece conveniente usarlos debido a que son unicamente para una plataforma. El FAT32 te funciona independientemente del sistema operativo. Yo tengo un disco duro externo de 1 TB y lo tengo formateado en FAT32 por lo mismo (ya que a veces hay que usarlo en MAC y para LINUX) si es un disco duro interno pues si, sin embargo en mi caso ni aún así lo hago por que tengo montado el LINUX en la misma compu y me daría problemas.

Por cierto yo uso la versión gratuita de MPLAB con el compilador para C18 cuando usaba pic18 y con el compilador para C30 ahora.
 
Última edición:
Tendremos que aprender a manejar C18 y C30 entonces...
Ahora usando la minima expresión de la librería para PIC18F4550.. te quedás sin memoria ??

Nunca intente con el PetitFat que es la minima expresión, siempre intente con el otro,
acá mando el uso de memoria que tenía para un buffer de trabajo de 512 bytes.
Con el otro logré inicializar la SD, inicializar el FAT y mostrar el estatus del FAT,

Tipo de FAT
Bytes por Cluster
Numero de sectores
Numero de archivos
tamaño del disco
espacio libre
después de eso ya la memoria no me alcanzaba para usar el resto, es muy probable que si se pueda usar el petit fat!!!

Yo antes solo usaba el CCS como compilador pero después de encontrar el C18 lo prefiero por mucho, da mucho más control sobre todo, hay mucha documentación al respecto y uno tiene acceso a todos los registros del pic por lo que tiene mucho control sobre todo.
 

Adjuntos

  • Uso de memoria.JPG
    Uso de memoria.JPG
    100.8 KB · Visitas: 48
Última edición:
Atrás
Arriba