Posted on December 25, 2015 at 23:20Write speeds of different SD cards are highly variable, even ones claiming to be in the same class. I would look seriously at SanDisk Ultra cards, UHS-1 rather than Class 10.
The predominant drivers of write speed are the card, the size of the ''block'' of data being written, and it's alignment against the intrinsic erase size of the of media. I would always try to write at least 32KB, the erase block is probably 128KB but check the reported characteristics.
Writing is always significantly slower than Reading. The controller on the media ''hides'' the underlying behaviour of the media, where a write of your new data typically goes to a freshly erased block, along with the existing data on the old block outside the area you are changing.
FatFs can work quite efficiently if you write smartly. If you write lots of small bits of data it will be slow. Some time invested in your buffering in the application will help significantly. Failing that the diskio.c layer needs to implement some caching, people generally avoid this because their systems are resource constrained. Better to fix on the app side.
A PC can given some feeling of a cards upper rates, but trying to compare the bandwidth and memory depth of a 3 GHz PC against an STM32 has some pretty obvious flaws.
Reading 32KB blocks should post numbers that correlate well against the SDIO clock, and the maximum you see there. The SDIO peripheral clock is specified to top out at 75 MHz (37.5 MHz on the wire). There's an errata with BYPASS mode, so DIV2 is the quickest setting available.
I wire-wrapped microSD sockets so I could evaluate different cards when I first added functionality to the STM32F4-DISCO, though I have custom boards, and other eval boards now with micro and full-size sockets. As I recall the microSD should support 50MHz clocks, but up there wire length, impedance and cross-talk are issues.
