SD card SDIO

Was any test done on this?

I just found out a nice STM32F103VET6 board and its schematic: http://www.stm32duino.com/viewtopic.php?f=28&t=821 and would like to know if I can use the SDIO port or better rely on SPI SD

EDIT: found another implementation (for F4, but this one seems to be more complete, supports SPI and SDIO 1 and 4 bit, and implements complete functionality) http://stm32f4-discovery.com/2014/07/li … x-devices/

that site is worth visiting it for the information it has on that page!

the gplv3 listed libraries for STM32F4 looks rather useful for glue code as well.

stephen

Ahh Good ol’ reliable FATFS

I have been using this for years on AVR, There is a version that runs on a Tiny88! I suspect that there are many Arduino libs that include FATFS as well.

FATFS is also the Included SDIO overlay that CUBEMX includes when the File system section is clicked upon. All one has to do is create the bridge between the hardware/software SPI and the rest of the library. When I was playing about with the Nucleo and discovery example code, even this bridge code was included.

All the puzzle pieces are here, They just have to be assembled in the right order.

Hey guys,

when you say the F103C does not have SDIO, d’you mean that I cannot use an SD card at all with it? SDIO is just the interface for the SD card isn’t it? If this is so, then shouldn’t I be able to use the F103C series (to be specific, the ‘blue pill’) to store values I’m getting from the ADC?
Presently, I’m getting around 130,000 samples per second, but I have no means of storing them.

The SD library uses SPI but I am not sure if it is very fast for 130.000 samples per second.

Theoretically you should be able to push 130,000 samples to an external flash device via SPI especially of you can hack dma into the mix, but I’m not so confident that you will get them on an SD card so easily. Not because the theoretical speed of the card is the bottlneck, more because I suspect the overheads of writing to FATFS with a 72MHz processor may be a stretch. That all depends on how well optimized the arduino lib is. I think it is a challenge worth accepting though, in the interests of educating an ignoramus like me, if for no other reason.

Among the examples of SDfat on Arduino there is one of a fast datalogger, LowLatencyLogger, but on Due it seems that it reach only 4000 samples per second.

I believe that it’s better to use a RaspberryPI alone or as a data collector.

It is not about a raw SPI or SDIO speed bottleneck – IT IS ALL ABOUT SDCARD’S WRITE LATENCIES.
You can easily write 3 megabytes/sec via SPI (or SDIO), BUT, the sdcard’s write latency WL could hit anytime (every few msecs and randomly) and WL itself can last for up to 250msecs (most WLs are 3-100ms long, it could last even longer than 250ms with latest cards).

The WL is the time your sdcard DOES NOT accept any incoming data, as it does its internal housekeeping.
The WL hits are very often, random in occurrence and random in duration.

So in order to write to an sdcard a sustained stream of data, you must somehow overcome the WL.

Do not expect writing to an sdcard works similarly as writing to a serial SRAM.

A possible solution is to use a FIFO buffer, where you write from a source into the FIFO (when the FIFO is not full) with the required speed a sustained stream of data records. And, in parallel, you read the data out of FIFO and when the FIFO is not empty you write the data into SDcard.
When you observe the watermark of the FIFO, you will see how the writing into the sdcard is quite often interrupted by randomly coming bursts (because of WL).

The size of the FIFO = sample_record_size * sampling_rate * max_expected_WL
Example:
When you want to store 1kB of data 500x per second (500kB/sec) you need 500kB/sec * 250msec = 125kB large FIFO buffer to compensate the max possible WL (here max expected WL set to 250ms).

This is how I recorded write latency hits/events with a standard 4GB microsdhc card with NilRtos while writing data in past.
X is the data capture/recording time in msecs, Y is the duration of a WL hit in usecs. You may see the number of WL hits during the 32secs of data capture is enormous.
The data records sampling rate is 1000Hz (1ms sampling period).

write latency.JPG

write latency.JPG (83.31 KiB) Viewed 6449 times

Thank you Pito That makes so much sense, and is very useful!

You said “parallel” transfer of data from the FIFO buffer to the SD card would make things simpler and increase the transfer speed. How can I achieve this? Isn’t the STM single-threaded?
To be more specific, I can only write data from the buffer to the SD card AFTER storing it in the buffer, and during the time it takes to move the data from buffer to SD card, I cannot get new ADC values. Would this not essentially be the same as writing directly to the SD card?

In parallel means you use the rtos – above was done with NilRtos, but it could be any rtos you have got handy.
(You may use a standard coding as well but I never have done it that way.)

Task 1 – Producer – sample sensors and write data records to FIFO at required sampling rate (ie 100bytes 500x per second = 50kB/sec)
Do it while FIFO not full (if FIFO properly sized the Task 2 will be emptying it in time despite the write latencies, here the worst case size of the FIFO would be 50kB/sec * 250msecs = 12.5kB, the 250msecs is the max write latency according to the SDcard Specification dated few years back)

Task 2 – Consumer – while FIFO is not empty read data records from FIFO and write data records to SDcard full sdcard’s speed (ie 800kB/sec).

Both task run in “parallel” and using 2 semaphores to signal each other.

There is a demo in NilRtos distro how to use the FIFO for writing to an Sdcard. NilRtos is chibios or arduino related (no port to stm32duino planned yet).

https://github.com/greiman/NilRTOS-Ardu … Logger.ino

When time permits I will create a simple demo in FreeRtos as this is something not well understood among the folk yet

RogerClark wrote:Just in case this is handy,

I found some code that we may be able to port to Maple to do the SD Card SDIO

https://bitbucket.org/antlabs_dev/fatfs … 32f103/src

But I better check it works first.

I m quite sure that the well know sdfat already implemented the sdio

There is already a working version for the STM32generic core: viewtopic.php?f=51&t=2036

Meanwhile I am also trying to implement a non-HAL (libmaple based) version of the SDIO driver for SdFat lib, similar to the Teensy driver.
My progress is documented here, work is ongoing (problems with debugging with Eclipse). Any contribution is welcome!