¿Ficheros indexados con PIC (18F) y MMC?

[RedPic]

Buenoooo ... Houston, tenemos un problema.

La pregunta principal que os tengo que hacer las podemos resumir con el título del hilo: ¿Alguno de ustedes, queridos compañeros, ha trabajado alguna vez con Ficheros indexados utilizando un PIC (18F) para su gestión y una MMC (o similar) para los datos?

Y ahora os detallo un poco mas a lo que me enfrento y ya me decís algo ... o calláis para siempre.

Veréis, hasta ahora he estado utilizando como almacenamiento masivo una serie de EEPROM 24AA1025 (Circuito y Driver C para 4 Memorias EEPROM 24AA1025 con un total de 512 Kbytes), hasta 4 de ellas, pero ya se me quedan cortas en capacidad.

Así que voy a utilizar, o intentarlo al menos, un dispositivo intermedio que implementa las FAT32 para poder trabajar con una MMC (o similar) ... concretamente el que fabrica nuestro querido y buen amigo J1M (Microingenia).

Con este cacharro tenemos a nuestra disposición "gigas" de capacidad ... el problema está en que el PIC (18F) dispone de poca memora ROM y RAM y tengo la necesidad de encontrar un "registro" guardado en la MMC (o similar) en pocos milisegundos. O sea que además de poder leer y/o escribir "a lo bruto" datos desde y hacia la MMC (o similar) debo hacerlo lo mas rápida y controladamente que pueda.

O sea montar un Fichero de Datos A con Registros de Longitud L con un Campo Clave C de longitud l para ser accedido mediante su posición física dentro del Fichero y en paralelo un Fichero Índice B con registros de Clave C y punteros al Fichero de datos organizado por dicho campo Clave, imagino que en Árbol, para poder realizar una búsqueda ordena ... y todo eso con un PIC (18F) que además tiene que hacer otras cosas .... ufffff.

¿Alguien ha hecho algo de esto? ¿Alguien lo ha intentado? ¿Alguien tiene algún consejo que darme?

Ea, ahí queda eso.

Besos y abrazos.

[Suky]

Hola! No se que tan estricto son lo tiempos que necesitas, pero te comento algunos detalles.

• Con un PIC18F y una buena PCB seguramente llegas a 10MHz de SPI.
• En una SD Card solo se pueden escribir bloques de 512 bytes según especificación de SanDisk.
• En los tiempos de trabajo hay que tener en cuenta que para leer o escribir un sector se debe enviar un comando y esperar respuesta por parte de la tarjeta.

Saludos!

[RICHI777]

Hola Red, algunas sugerencias vos me vas corrigiendo si lo crees necesario. Cuando las memorias EEPROM nos quedan chicas antes de pasar a otros medios de almacenamiento mas masivos ( MMC, SD, Compact Flash ) existen memorias NOR-FLASH con capacidades interesantes.

Te paso links de memorias NOR-FLASH series ( SPI ) de 8 Mbytes

http://www.sst.com/products/?inode=42389
http://www.eonssi.com/products/products.aspx
http://www.spansion.com/Products/Pages/ProductDetails.aspx?ProdID=S25FL064A


También existen una nueva tegnologia llamada PCM ( Phase Change Memory ) que tienen muchas ventajas sobre las tradicionales EEPROM, estas son de 16 Mbytes

http://numonyx.com/en-US/MemoryProducts/PCM/Pages/P5Q.aspx

Desde el punto de vista del firmware es mas facil migrar una aplicación escrita para usar EEPROM que pasar a otro esquema.

Si igual te quedas corto y tenes problemas de perfomance, entonces la mejor opción son las Compact Flash, son mas caras pero son parelelo y pueden trabajar en modo true-ide, no por nada las maquinas fotograficas profesionales las usan. Por ahora esto, si vos queres la seguimos.

Saludos !

[RedPic]

Muchas gracias, Suky y Richi.

Si, me interesa estudiar estas memorias, como dices es mucho mas fácil migrar de EEPROM a otro sistema ya que las rutinas a alto nivel son las mismas y solo tendría que modificar las específicas de escritura y lectura hardware.

Le echo un vistazo a los links que me has puesto y después comentamos. 

[J1M]

Vale este era 'el post'...

Tienes toda la razón del mundo, es un tema complicado...

Yo estuve trabajando en un proyecto, con la uAlfat y optamos por una solución 'chapucera'... creamos varios ficheros. De esta forma reduces el tiempo de acceso, además del tiempo de apertura. Cuando trabajes con ella, te darás cuenta que cuanto mayor sea el tamaño, mayor será el tiempo para abrir el archivo. Tiene una cosa buena, y es que puedes tener abiertos varios archivos, eso se encarga de gestionarlo el propio chip.

Implementamos un pseudo-sistema operativo; Lleno de if anidados, de temporizadores y de flags, de tal forma que con el PIC podíamos hacer varias cosas 'a la vez', mientras esperabamos a que se escribiera/leyera/abriera un determinado archivo. Lo bonito del código, es que el PIC hacía varios procesos a la vez y estos a su vez tenían distintos subprocesos que también se iban ejecutando de forma autónoma.

Resumiendo, lo que necesitas hacer, es posible hacerlo con un PIC18F y una uAlfat... pero la programación en C no va a ser nada comoda hacerla.

Y efectivamente, tal y como comenta Suky, todo depende del tiempo, nosotros con la uAlfat hemos trabajado con tiempos de milisegundos para gestionar la apertura/escritura/guardado/cerrado del archivo. Si el archivo lo mantienes abierto, ese tiempo lo ahorras, y normalmente es el mayor...

un saludo!