Hi Guys,

I am having some trouble with the FAT filesystem on my MBED. I use it to log sensor data to a rather big file.

My problem is that the file operations get slower and slower when the size of the file increases. I reach around 10000 B/S with small files, and worse when the file grows. I imagine a digital camera writes around 0.5MB in under a second on similar media.

I am therefore thinking about ways to speed up the process. Please comment.

1) Can I speed up the SPI interface to the SD card.

2) Can I format the card in a different way? (block size etc)

3) Are there faster SD cards available.

4) I have heard about people using a usb flash stick as an alternative, but thats not really possible in my prototype because of tight space limitations and an imminent testing deadline.

Kind regards

Jesper Taxbøl

I successfully managed to speed up the SPI interface to 12MHz with my card. Unfortunately, the card then seemed to be the bottleneck and was buffering data.

There are faster cards available, as well as the ability to use a 4 bit parallel input instead of just SPI. Don't think anyone has done that with the mbed yet though.

What did you do to speed the SPI up?

Jesper

I am guessing, that as you keep re-opening the file, the MBED reads in and buffers the whole file. Which is growing. And takes longer to read, append, and final write.

Just a thought, can you make several smaller, sequential files, Assuming you are using PC to process data.

Ceri.

Thanx for the input. I will look into buffering and how I read from the file first thing tomorrow.

What im doing now is logging data into a RAM based ringbuffer. When it is close to be filled up, I empty it into a file based ringbuffer. (I use the RAM buffer to reduce the number of writes on the SD card which has around 100000 writecycles in its lifetime)

The file is opened and closed by every write, to reduce the risk of corrupting the filesystem if the device is powered off.

As a fallback solution I could loose the FAT filesystem and just use the SD card as a raw device. (Im not sure how to do this but I guess it is doable and would eliminate the FAT overhead. Im not writing other files anyway.)

Thanx again

Jesper

I just sped the SPI up using the spi.frequency(int freq) function. The maximum speed is defined by the peripheral clock speeds. Have a look in the lpc1768 user manual if you want to change these too, although that may have repercussions on other peripherals.

A friend of mine used the SD card as a raw device as you suggest. He then used a python script to recover the data in windows, although I'm sure it could also be easily done through the mbed.

I don't believe that reopening the file would buffer the whole thing in though.

Is there an example available on how to write to a SD card as a raw device?

I don't know mbed well enough to know how it would be done there, but on a PIC controller I can log data with acceptable speed, with 'some' FAT-compatibility. The trick is to pre-allocate a file on the card, find out on which physical block it starts, and then just write to the card directly. In that way, you lose the FAT-overhead on the embedded system, while the file will remain being readable directly on the PC afterwards.

Another thing to look out for, is that overwriting blocks that already contain data can take a long time, because they will need to be erased first. I circumvent this by giving the card an erase command for the blocks that comprise the file before I start logging. In that way, logging can proceed at full speed. I have successfully written 32 channels of 16-bit data at 1000 samples/second, that is 64 kByte/second. I have not tested where my limit currently lies, but I know that my SPI code was far from efficient (no DMA, used polling subroutines for every byte). I'm working on better code, where I hope to reach >500 kByte/sec, still without using DMA (and using approx. 25% processor time on a 16 MHz PIC24). All communication with the card will be under relatively low latency/duration interrupt code in the new version, so you can max out the card bandwidth, and still have enough computing power remaining to sample and process the data.

I think with the 96 MHz of the mbed and using DMA, >500 kByte/sec should be attainable without problem using these techniques.

This is the document that I used for info on how to access an SD-card directly: http://www.sdcard.org/developers/tech/sdcard/pls/Simplified_Physical_Layer_Spec.pdf