【疑问】为什么SDMMC+DMA在f_write函数里面还是死等？

852050675

工程设置：SDMMC+DMA+FATFS+裸机

通过用示波器测试发现，即使使用了SDMMC自带的IDMA来进行读写，f_write函数还是处于死等状态，写入20482*40byte数据花了一百多ms。

按道理来说用了IDMA，不是应该不用cpu等待，只需要处理回调中断就好了吗?

dengxiaojundink

不用DMA,过程就是这段写入过程,CPU一直处于发送数据状态,发送数据这个工作是CPU自己在干,没空干别的.用了DMA,过程就是CPU把数据放在一个缓冲区里面,然后说,DMA你去把活干了,干完通知我,然后CPU就想干嘛干嘛,至于等通知这段时间CPU去干嘛,是由安排项目的工头也就是程序开发者说了算.只有一个要求,下一次让DMA干活的时候,上次一次活必须得干完了或者报错了.

emwin

按道理来说用了IDMA，不是应该不用cpu等待，只需要处理回调中断就好了吗?

这句说的是对的，但实现这个是由软件完成的，不是水到渠成的。

kingdjh

假设它立刻返回，那么你这个返回值代表什么意思呢？
如果DMA中途出错了，你程序都往下执行了，又如何回正这个错误呢？

eric2013

此贴深入探讨了这个问题。

【深入探讨】DMA到底能不能起到加速程序执行的作用，DMA死等操作是否合理，多个DMA数据流同时刷是否处理过来
https://www.armbbs.cn/forum.php?mod=viewthread&tid=109765



这个问题也谈的非常多，这里从DMA的两个方向讨论：

1、一类是直接在DMA中断里面处理消息，像H7自带的ADC，DAC，串口等。

这类应用我们可以直接在中断里面处理消息或者搞个双缓冲。

这种应用在RTOS下和裸机下使用都比较简单，这类应用不需要死等。

裸机下：
适合直接在中断里面处理，搞个外置标志效果不是很理想，不方便性能最大化。

RTOS下：
可以中断里面处理，也可以发送信号量等消息，通知任务里面处理，性能可以最大化。

2、还有一类就是图形加速DMA2D，QSPI Flash DMA，SDIO DMA等

这类DMA应用，我们一般都需要配合GUI，FAT文件系统等一起使用。

这种情况下，要分裸机和RTOS两种做分析，这类应用使用死等（可以加超时溢出）比较方便。

裸机情况下：
如果不做死等，而做个中断，做个变量标识什么的做等待，应用层代码基本没有办法写了，比如一个简单的GUI桌面背景部分重绘，需要进入DMA2D加速接口函数等待中断标志完成，应用层代码实现非常麻烦。

RTOS下：
这种情况下，在RTOS下里才能发挥威力，以GUI为例，我们都是直接将其丢到最低优先级任务里面跑。文件系统类的QSPI Flash，SD卡，eMMC，NAND等，也可以直接丢到低优先级任务，或者其他稍高优先级任务，完全不影响其他高优先级任务运行。
其实这也是使用RTOS相比裸机的一个重要优势。