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.
One thing to note, the F103C series don’t have SDIO e.g. Maple Mini , or Blue Pill etc don’t have this capability, nor does the Maple Rev 3 (which uses an F103RB)
The minimum hardware is a Maple RET6, or in terms of generic boards the F103RC is the minimum hardware requirement.
I’m interested in this as I have a F103V and a F103Z boards, both with sd cards on them, which I suspect are connected via SDIO (but I’ll need to verify the connections)
If I get chance I’ll see if I can get the code (see link above) to compile in em:blocks or CooCox, just to see if it actually works
PS. I’m sure there is other code out there that does this.
PPS. I know it uses the std peripheral lib, but the peripheral lib has now been released with favorable licensing terms via the STM32Cube.
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/
the gplv3 listed libraries for STM32F4 looks rather useful for glue code as well.
stephen
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.
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. 
I believe that it’s better to use a RaspberryPI alone or as a data collector.
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 (83.31 KiB) Viewed 6449 times
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?
(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 
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.
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!