STM32Cube SDIO better SD driver

仅作个人纪录

st写的sd卡bsp就是一坨大的，遇上了cache跟dma全是灾难

包括但不限于：

因为源地址并没有dma对齐，所以需要scratch缓冲区，结果scratch缓冲区没有对齐，幽了个大默
cache的数据需要32字节对齐，这厮用memcpy操作了数据，最后缓冲区维护的办法还错了

ff更新到0.15-patch3了，还在0.12c

故自行移植ff，参考sd_driver写的sd驱动，仅在h7 sdmmc dma下测试：

## FATFS的buffer并没有保证STM32的对齐要求  建议不要启用CACHE  或传入的数据32字节对齐

启用CACHE后有许多乱七八糟的问题，比如CACH需要为32Byte对齐，所以app传入的缓冲区也需要32byte对齐，同时鉴于fatfs内部也有自己的缓冲区，很难控制缓冲区的32b对齐一致性，故建议关闭DCACHE。

比较麻烦的办法是在底层处理对齐问题，根据不同的大小、对齐选择不同的传输方式，并进行一次memcpy来对上层透明。在这里就不搞了

不方便粘贴代码，仅粘贴readme

## FATFS的buffer并没有保证STM32的对齐要求  建议不要启用CACHE  或传入的数据32字节对齐

启用CACHE后有许多乱七八糟的问题，比如CACH需要为32Byte对齐，所以app传入的缓冲区也需要32byte对齐，同时鉴于fatfs内部也有自己的缓冲区，很难控制缓冲区的32b对齐一致性，故建议关闭DCACHE。

比较麻烦的办法是在底层处理对齐问题，根据不同的大小、对齐选择不同的传输方式，并进行一次memcpy来对上层透明。在这里就不搞了

## 在启动了DCACHE的平台上，兼容的办法是启用SCRAH缓冲区，反而效率变低了

## CACHE 写的只写  读的只读  就可以避免写回擦除  用户层注意

## 说明：

SCRATCH缓冲区：DMA对齐需要

CACHE_MAINTEIN: CACHE需要

## 区别：

SCRATCH 4字节改成了32字节对齐

FATFS对象和FIL对象新增对齐（未验证可行性）

SD_write slow path 对缓冲区操作有问题 删除invalid，增加每个的clean

## 附：

CACHE的维护在最底层实现，维护scratch或者用户传入的数组。

用户层传入数据的时候，依然需要注意读的只读，写的只写。若不满足自行clean,invalid