STM32 FATFS文件系统实现流程分析

原理概图

由图知,通过用户层调用 标准文件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等操作看能不能成功