Mi tablero incorpora unSTM32 microcontrolador con unTarjeta SD / MMC enSPI y muestras de datos analógicos a 48 k muestras / s. Estoy usando el kernel Keil Real-time Library RTX, yELM FatFs.

Tengo una tarea de alta prioridad que captura datos analógicos a través de DMA en bloques de 40 muestras (40 x 16 bits); los datos se pasan a través de una cola de longitud 128 (que constituye aproximadamente 107 ms de almacenamiento en búfer de muestra) a una segunda tarea de baja prioridad que recopila bloques de muestra en un búfer de 2560 bytes (esto es un múltiplo tanto del tamaño del sector SD de 512 bytes como del Tamaño de bloque de 40 muestras). cuando este búfer está lleno (32 bloques o aproximadamente 27 ms), los datos se escriben en el sistema de archivos.

Al instrumentar el código, puedo ver que cada 32 bloques, los datos se escriben y que la escritura tarda unos 6 ms. Esto se mantiene hasta que (en FAT16) el tamaño del archivo llega a 1 MB, cuando la operación de escritura tarda 440 ms, momento en el que la cola se llena y se anula el registro. Si formateo la tarjeta comoFAT32, el tamaño del archivo antes del evento 'escritura larga' es de 4 MB.

El hecho de que el tamaño del archivo en el que esto ocurre cambia entre FAT16 y FAT32 me sugiere que no es una limitación de la tarjeta, sino algo que el sistema de archivos hace en los límites de 1 MB o 4 MB que requiere tiempo adicional.

También parece que mis tareas se programan de manera oportuna y que el tiempo se consume en el ELMFatFs códigosolamente en el límite de 1 MB (o 4 para FAT32).

¿Hay una explicación o una solución? ¿Es un problema de FAT, o más bien específico del código FatFs de ELM?

He considerado usar varios archivos, pero en mi experiencia FAT no maneja muy bien grandes cantidades de archivos en un solo directorio y esto simplemente fallaría también. Sería una posibilidad no utilizar un sistema de archivos y escribir en la tarjeta sin procesar, pero idealmente me gustaría leer los datos en una PC con controladores estándar y sin software especial.

Se me ocurrió probar las optimizaciones del compilador para reducir el tiempo de escritura; Esto parece tener un efecto, pero los tiempos de escritura parecían mucho más variables. En -O2 obtuve un archivo de 8 MB, pero los resultados fueron inconsistentes. Ahora no estoy seguro de si existe una correlación directa entre el tamaño del archivo y el punto en el que falla; Lo he visto fallar de esta manera en varias longitudes de archivo sin límite particular. Tal vez es un problema de rendimiento de la tarjeta.

Además instrumenté el código y apliqué un enfoque de divide y vencerás. Esta observación probablemente hace que la pregunta sea obsoleta y todas las observaciones anteriores son erróneas o son falsas.

Finalmente lo reduje a una instancia de una escritura multisector (CMD25) donde ocasionalmente el sondeo "esperar listo" de la tarjeta toma 174 ms para los primeros tres sectores de un bloque de 5. El tiempo de espera para esperar listo se establece en 500 ms, por lo que estaría felizmente ocupado, espera tanto tiempo. Usar CMD24 (escritura de un solo sector) de forma iterativa esmucho más lento en el caso general, 140 ms por sector, en lugar de solo ocasionalmente.

Entonces parece un comportamiento de la tarjeta después de todo. Me esforzaré por probar una gama de tarjetas SD y MMC.