原理概图
由图知,通过用户层调用 标准文件IO函数 f_open() --> disk_read()
在函数中的 disk_reak() 实现如下 (在disio.c中可以找到)
DRESULT disk_read (
BYTE pdrv, /* Physical drive nmuber to identify the drive */
BYTE *buff, /* Data buffer to store read data */
DWORD sector, /* Sector address in LBA */
UINT count /* Number of sectors to read */
)
{
DRESULT res;
//从这里调用disk_read接口: disk.drv[pdrv]里面保存了函数指针
res = disk.drv[pdrv]->disk_read(disk.lun[pdrv], buff, sector, count);
return res;
}
上面说到 disk.drv[pdrv]里面保存了disk_read函数指针,那函数指针从哪里来, 所以要看一下disk这个结构体类型,那个函数指针就保存在drv中( 在ff_gen_drv.h中可以找到)
所以必然有一个操作会把底层read 函数接口指针赋值给drv , 然而 drv 又是一个结构体( 在ff_gen_drv.c 中可以找到)
可以看到 Diskio_drvTypeDef 结构体类型里面全是函数指针
所以disk_read 被层层封装了一下
res = disk.drv[pdrv]->disk_read(disk.lun[pdrv], buff, sector, count);
FATFS有一个特点就是 ,应用层和底层分开,所以在STM32中,肯定disk_read 最后还是调用了 HAL 库,那究竟实在哪里调用呢
最关键的一步操作 ,定义了一个
Diskio_drvTypeDef SD_Driver
对象并且赋初值为已经实现的函数的指针
但这是一个新的结构体变量, SD_Driver 和disk.drv[pdrv] 是不同的两个变量,但类型一致,所以需要在使用FATFS的时候调用 链接接口去连接函数地址
//链接函数
uint8_t FATFS_LinkDriver(const Diskio_drvTypeDef *drv, char *path)
链接过后,disk_read就获得了SD_read的指针
所以mount挂载操作必须实在链接过后,这样才能操作底层
所以disk_read 结果还是调用了SD_read
所以直接看函数 SD_read 实现代码(在sd_diskio.c中可以找到)
注意图中的 BSP_SD_ReadBlocks
//就是这个接口 BSP就是板子支持包的意思,这里马上就要进入底层HAL库了
BSP_SD_ReadBlocks((uint32_t*)buff, (uint32_t) (sector),count, SD_TIMEOUT)
接着往下追(进入"bsp_driver_sd.c中")
看到HAL库函数了
所以这里(“bsp_driver_sd.h”)就是 链接底层HAL库的桥梁了
FATFS的大概实现
接下是新版 CubeMX6.5.0 生成FATFS时带FreeRTOS的一些原理概述
新版的CubeMX下生成的FATFS 依赖于RTOS
所以初始化FATFS 必须是在RTOS启动之后,挂载也是一样
在第一次mount 挂载中,FATFS会去初始化SDIO硬件层,结构体对象等
初始化完成后,会紧接着查询SD卡的状态
查询的操作采用 DMA写入 DMA读出 ,成功以后把消息放入消息队列
所以在调用查询状态之后会阻塞等待一会儿
如果很久未mount 成功,有可能就是DMA出了问题,检查DMA中断是否打开
查询状态成功之后,接下来就是挂载成功了
试一试f_open等操作看能不能成功