microSD card FAT module

Question

I have recently been using a uALFAT microSD board by GHI Electronics for data logging, but I have been having problems with its reliability; some of its function calls, at times, take far longer than I can handle. I am currently using an MSP430 microcontroller to talk to the uALFAT.

What similar boards are out there that I could possibly use instead of the uALFAT that would hopefully be more reliable?

OR

What would be the most favorable OEM solution if I needed to design my own interface board to work with an MSP430?

Answer 1

I would think about this a bit differently. Any flash based storage device is likely to have variable timing on writes. Especially one with a file system and wear leveling and features like that. It tends to be the nature of flash since you have to erase whole blocks and move things around. If you can't live with the variable timing, what I've done in the past is to move this piece out of the time critical portion of the code.

Typically I add a queue which the time critical code writes to, and then in the background pull from the queue and write to the SD card. In a RTOS, this would be a lower priority task. In a polling loop, it would be a function called when the system is Idle.

This changes the constraint from being the worst case timing for a function call to simply being able to meet the average throughput requirements for logging. The worst case latency and throughput determine how big the queue must be; typically this can be small.

Answer 2

It is probably more complex than that and the best solution is as @sbass has advised, even if you do choose to change the file-system. You need to determine exactly where and why the latency is occurring before you blame uALFAT.

However for the record, I have successfully used ELM FatFs, and its cut-down ELM Petit FatFs, and also EFSL.

With respect to latency, while for example with ELM I have achieved write speeds of up-to 300 kbit per second using SPI (the speed is largely dependent on the card, and speeds can range from 30 kbit/s to 1 Mbit/s), I could not successfully use it to log a data stream of 96 kbit/s for any sustained length of time, even with optimised buffer sizes (multiples of a sector size), and a 50 kbit queue of 512 byte sectors. This was not down to the library, but rather the nature of the SD card, which apparently on 1 Mbit boundaries, would stall for up to 128 milliseconds, which was enough to exhaust the buffering provided by the queue. The solution is of course to increase the buffering as @sbas has said, but in this case the total system RAM was only 64 kbit so that was not possible.

If you can throw memory and an RTOS task (probably TI's own SYS/BIOS in your case) at the problem you should be able to get it working with the library you have. The amount of RAM necessary depends on the data rate and whether it bursts or is continuous.

Answer 3

Thanks guys, I ended up implementing a circular buffer of sorts with additional memory and that seems to have done the trick. Thanks for the good input!