cancel
Showing results for 
Search instead for 
Did you mean: 

DMA performance gain on SDIO

ASay.1
Associate II

I am using STM32CUBE ide and my project has SD card access via SDIO peripheral.

I am using FatFS middleware. To use FreeRTOS I enabled DMA and system works fine.

After enabling the DMA I wanted to see how much read/write performance the system gained.

I measured disk access time with oscilloscope by set-reset a gpio pin in SD_read and SD_write functions. To my surprise system that use DMA for SDIO peripheral was slightly slower.

Following table is the access times with and without DMA:

 

 ReadWrite
with DMA1.31ms2.062ms
without DMA1.23ms1.965ms

 

Am I doing something wrong or in this case the purpose of DMA is to help FreeRTOS to be able to run multiple threads?

2 REPLIES 2
STOne-32
ST Employee

Dear @ASay.1 ,

I can not comment the exact code speed as we need to replicate and see example , But this is expected - You already gain a lot of performance by freeing CPU / Cortex for other critical tasks as heavy computing in parallel while DMA transferring basic data from SDCard to memories .  In terms of speed if running on same frequency and moving single Data it should be in same range CPU/DMA , Then to add all overhead.

you can stress your application by firing IRQ in parallel and see again the performance.

Hope it helps you.

STOne-32

Speed improvement is likely to be negligible, but it might be critical as the data transfer is *not* interruptable. The FIFO can cover some latency, but the cards are not going to be tolerant to you wandering off mid sector transfer.

Where you will gain speed is LARGE transfers, of aligned blocks. FATFS can allow for cluster level transfers. Assume 32KB will be the sweet-spot. All your f_read / f_write should be large and aligned, ie file offsets and lengths modulo 512 bytes. Small and sector misaligned operations will be slow and cause thrashing.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..