标签: fatfs

stm32 CubeMx 实现SD卡/sd nand FATFS读写测试。 　　材料：stm32F407ZGT6开发板、雷龙公司的SD_NAND 测试板（CSNP1GCR01-AOW）。（一开始是使用 Nandflash的操作起来不太方便而且 stm32cubemx自带的 fatfs还没有磨损平衡算法，很是难受。） 　　CSNP1GCR01-AOW的优势： 　　不用写驱动程序自带坏块管理的NAND Flash（贴片式TF卡），尺寸小巧，简单易用，兼容性强，稳定可靠，固件可定制，LGA-8封装，标准SDIO接口，兼容SPI/SD接口，兼容各大MCU平台，可替代普通TF卡/SD卡，尺寸6x8mm毫米，内置SLC晶圆擦写寿命10万次，通过1万次随机掉电测试耐高低温，支持工业级温度-40°~+85°，机贴手贴都非常方便，速度级别Class10（读取速度23.5MB/S写入速度12.3MB/S）标准的SD 2.0协议使得用户可以直接移植标准驱动代码，省去了驱动代码编程环节。支持TF卡启动的SOC都可以用SD NAND，提供STM32参考例程及原厂技术支持，主流容量：128MB/512MB/4GB/8GB，比TF卡稳定，比eMMC便宜，样品免费试用（可到官网找客服小姐姐领取样品哦）。雷龙官网 　　话不多说开始正文： 　　stm32cubeMX 版本：6.6.1 　　MDK5 版本5.35 　　开始配置STM32 　　1、 配置时钟： 　　系统时钟树配置（我这里直接拉满，实际使用根据功耗要求作相应的调整） 　　2、 配置调试接口 　　注意DEBUG这个一定要配置，如果是默认的那下载一次程序之后第二次就下载不进去了. 　　3、配置SDIO: 　　(我这里还是用了DMA 减少mcu的资源开销) 　　配置完成之后随便选一个IO口作为SD_NAND的插入检测引脚（没有检测脚的也选上不然在生成代码的时候会有警告，看着很不舒服，我这里选的是 PE4 引脚） 　　4、配置SDIO的DMA 　　5、添加文件系统 　6、配置堆栈大小（稍微调大一点，不然在读写大一点的数据的时候可能会出错） 　　7、生成代码 　　8、生成代码后在 bsp_driver_sd.c这个文件中将这三行代码注释（这是检测SD卡是否接入的引脚 如果不注释在挂载sdnand的时候会提示 not_ready） 　　9、在main.c中 添加测试代码 */ /* USER CODE END Header */ /* Includes ------------------------------------------------------------------*/ #include "main.h" #include "dma.h" #include "fatfs.h" #include "sdio.h" #include "gpio.h" /* Private includes ----------------------------------------------------------*/ /* USER CODE BEGIN Includes */ /* USER CODE END Includes */ /* Private typedef -----------------------------------------------------------*/ /* USER CODE BEGIN PTD */ FATFS fs; /* FatFs 文件系统对象 */ FIL file; /* 文件对象 */ FRESULT f_res; /* 文件操作结果 */ UINT fnum; /* 文件成功读写数量 */ BYTE ReadBuffer = {0}; /* 读缓冲区 */ BYTE WriteBuffer */ void* work, /* Pointer to working buffer */ UINT len /* Size of working buffer */ ) 　f_mkfs 这个函数有五个参数，老版本的只有三个参数 　　所以在格式化的时候得这么来操作 f_res = f_mkfs("0:/",FM_FAT|FM_SFD,0,&ReadBuffer,sizeof(ReadBuffer));

文章目录 FATFS文件系统详解 1. 简介 2. 基础概念 3. FAT文件系统组成介绍 4. FAT文件系统分析 4.1 采用FAT格式格式化SD nand/sd卡 4.2 引导扇区分析 4.3 分区偏移及大小计算 4.4 FAT子类型确认 4.4 访问FAT条目 4.5 文件与簇之间的关系 4.6 FSInfo扇区结构及备份引导扇区 4.7 FAT目录 4.7.1 SFN 短文件名目录 4.7.2 LFN长文件名 4.7.3 LFN系统对于SFN的兼容 5. 分区分析 5.1 保留分区分析 5.2 FAT区分析 5.3 根目录区分析 5.4 数据区分析 5.5 新增文件测试 6. 总结 1. 简介 在早期计算机刚发展的时候，那时候硬盘大小、flash设备容量都比较小，随着技术的不断迭代更新，硬盘容量越来越大。在早期，面对小容量的硬盘/flash，往往采用对应地址存放对应数据的方案，由于数据量不大，操作起来尚还可以。但是发展到今天，随着硬盘/flash容量不断增大，存储的数据也越来越多，早期单一的对应地址存放对应数据的方案已经无法满足我们的需求，操作硬盘/flash会变得异常的困难复杂。 因此针对上述问题，一群大佬们便开始设计文件系统这样一个东西，用来管理硬盘/flash上的数据信息，像我们电脑上打开文件夹，访问里面的文件，这其实就是基于文件系统访问电脑硬盘上数据的一个操作。 发展至今，文件系统已有众多版本，本文主要分享 关于FAT文件系统的详细设计， FAT文件系统适用于嵌入式设备，如SD卡、SD nand、spi nor flash等众多存储设备，同时基于此文件系统的文件亦能被电脑正常读取。 2. 基础概念 在研究文件系统之前，我们需要首先弄清楚关于内存这块的几个基本概念： 2.1.区分 扇区、块、簇的概念 扇区（sector）：flash可操作的最小单元，通常指我们擦除的最小单元大小，以sd nand举例，通常最小为512Byte 块（block） 以及 簇（cluster）：其实这是两个相同的概念，只是由于历史原因，在不同系统上的不同称呼，在windows中称簇，而在linux中称块。一个簇/块由多个扇区组成，由于一个扇区的空间较小，因此文件系统通过会将多个扇区组合在一起形成一个簇，并以簇为单位进行读写操作！ 一个簇通常可以由 2、4、8、… 、2的n次方个扇区组成。 2.2.FAT文件系统总共由FAT12、FAT16以及FAT32三个版本，这是由于随着存储技术不断发展，FAT文件系统迭代导致，数字越大，版本越新，新版本对老版本完全兼容！ 3. FAT文件系统组成介绍 Fat文件系统官方文档： http://elm-chan.org/docs/fat_e.html FAT文件系统在flash上的布局如下图所示，总共由四个区域组成： 保留区 FAT区 根目录区 （FAT32类型不包含此区域） 数据区 编辑 ​ 编辑 ​ 接下来，我们对一张格式化为FAT格式的SD卡进行分析，理解FAT文件系统的实现细节： 4. FAT文件系统分析 4.1 采用FAT格式格式化SD nand/sd卡 1.使用win10格式化一张118.5M的SD nand / sd卡，我这里用的是手上的一颗 创世CS 家的sd nand加一块转接板，和SD卡完全没有区别，且SD nand在稳定性上比SD卡具有优势。 编辑 ​ 编辑 ​ 此处由于SD nand（SD卡）大小原因，默认采用FAT16进行了格式化！因此在下文中我们先以FAT16进行分析，之后再重新格式化为FAT32进行分析，就很容易懂了！ 4.2 引导扇区分析 1.使用 winhex 工具打开对应磁盘，注意需使用管理员权限运行 编辑 ​ 2.打开后我们可以以二进制的格式查看SD卡上所有数据，首先看到第一个扇区，也就是对应的引导扇区 boot sector，注意引导扇区位于保留区！ 编辑 ​ 3.接下来我们根据 官方文档 对引导扇区进行分析 注意，FAT文件系统数据均采用小端格式！ a) 首先是FAT12/16/32公共部分，（偏移值 0 - 35）： EB 3C 90：BS_JmpBoot，跳转指令 4D 53 44 4F 53 35 2E 30：BS_OEMName，MSDOS 5.0，一个名字，指示创建此卷的操作系统，无其他作用 00 02：BPB_BytsPerSec，扇区大小 512 字节 04：BPB_SecPerClus，每次操作的最小扇区数，簇 Cluster，4 (与格式化时选择的大小匹配 2048 = 512 * 4) 06 00：BPB_RsvdSecCnt，保留区的扇区数，6 (通过此可计算，FAT区起始地址为 6 * 512 = 0xC00) 02：BPB_NumFATs，FATs的个数，2（一般此值为2，多一个用来做冗余备份，解决系统异常导致第一个损坏时，增大恢复的可能性，表示FAT区有两个FATs备份） 00 02：BPB_RootEntCnt，512，在FAT12/16系统中，此字段表示根目录中32字节目录条目数量，设置此值时需注意对齐，为了最大的兼容性，FAT16系统上此值应设置为512，FAT32系统上此值应设置为0 65536，所以此字段为0) F8：BPB_Media 媒体类型 ED 00：BPB_FATSz16，237，一个FAT占用的扇区数，此字段仅在FAT12/16系统使用；FAT32系统，此字段必须为0，使用BPB_FATSz32字段替代。FAT区总大小等于 BPB_FATSz?? * BPB_NumFATs 扇区（2372512=242688=0x3B400，由此可推算根目录区起始地址：0x3B400+0xC00=0x3C000）。 3F 00：BPB_SecPerTrk，每个磁道的扇区数，此字段仅与具有几何形状且仅用于 IBM PC 的磁盘 BIOS 的介质相关，不用管。 FF 00：BPB_NumHeads，头数量，此字段仅与具有几何形状且仅用于 IBM PC 的磁盘 BIOS 的介质相关，不用管。 00 00 00 00：BPB_HiddSec，0，FAT 卷之前的隐藏物理扇区数（当磁盘被分区之后，当前分区并不一定是从扇区头开始的） 00 B4 03 00：BPB_TotSec32，242688，32位大小区域描述FAT卷扇区总数（整个卷空间大小）。 FAT12/16系统，扇区总数小于0x10000时，此字段必须为0，真实值存放在BPB_FATSz16；FAT32系统，此字段一直有效。（118.5M = 512 * 242688） b) 接下来是FAT12/16特有字段（偏移值36） 80：BS_DrvNum，IBM PC 的磁盘 BIOS 使用的驱动器号，00h代表软盘，80h代表固定磁盘 00：BS_Reserved，保留字段，0 29：BS_BootSig，扩展引导签名，表示以下存在三个字段 83 3E 07 E4：BS_VolID，与 BS_VolLab 一起构成卷序列号，一般在格式化的时候结合时间生成 4E 4F 20 4E 41 4D 45 20 20 20 20：(解析为:"NO NAME “)，BS_VolLab，11byte卷标，当卷标不存在时，此值应设置为"NO NAME” 46 41 54 31 36 20 20 20：(解析为:"FAT16 ")，BS_FilSysType文件系统类型，支持字段有："FAT12 ", "FAT16 " or "FAT "，注意很多人认为是通过此字段区分FAT12/16/32系统类型，实际是错误的，文件系统类型实际上是根据磁盘大小确定的，官方文档 “Determination of FAT sub-type” 章节或本博文后文有描述，不过为了最大的兼容性考虑，此字段应设置为对应文件系统的名字。 33 C9 ~ CB D8：BS_BootCode，引导启动程序，与平台有关，不使用时填充为0 55 AA：BS_BootSign，0xAA55，引导签名，指示这是一个有效的引导扇区当扇区大小大于512字节时，剩余的字段应全部使用0x0填充。 c) 如果是FAT32，则采用FAT32特有字段解析（偏移值和FAT12/16特有字段一致为36） 虽然此处我们的是FAT16格式，不过此处也将FAT的字段进行描述，方便理解。 BPB_FATSz32：一个FAT占用的扇区数，此字段仅在FAT32系统有效。FAT区总大小等于 BPB_FATSz?? * BPB_NumFATs 扇区。 BPB_ExtFlags：扩展标识字段，bit7=0，表示所有FAT都是镜像的和活跃的；bit7=1，表示只有bit3-0表示的FAT是有效的。 BPB_FSVer：FAT32版本，高字节是主版本号，低字节是次版本号。 BPB_RootClus：根目录的第一个簇号，此值通常为2，因为前两个簇一般用于保留。 BPB_FSInfo：FSInfo结构扇区与FAT32卷顶部的偏移扇区值。此值通常为1，因为其通常位于引导扇区旁边。 BPB_BkBootSec：备份引导扇区与FAT32卷顶部的偏移扇区值。此值通常为6，考虑最大的兼容性，此值不建议为其他值。 BPB_Reserved：保留 BS_DrvNum：含义与FAT12/16字段一样 BS_Reserved：含义与FAT12/16字段一样 BS_BootSig：含义与FAT12/16字段一样 BS_VolID：含义与FAT12/16字段一样 BS_VolLab：含义与FAT12/16字段一样 BS_FilSysType：始终为"FAT32 "，对FAT类型的确定没有任何影响。 BS_BootCode32：引导启动程序，与平台有关，不使用时填充为0 BS_BootSign：0xAA55，引导签名，指示这是一个有效的引导扇区当扇区大小大于512字节时，剩余的字段应全部使用0x0填充。 以上就是引导扇区内容的详细分析了，通过引导扇区的内容，我们即可知道FAT文件系统依赖的硬件存储空间大小、簇大小、扇区大小以及以及FAT系统版本等重要信息。 同时通过引导扇区的内容，我们便可计算出对应的FAT的四个区域的大小及起始偏移位置等重要信息，接下来计算FAT四个分区的起始位置及大小。 4.3 分区偏移及大小计算 FAT卷总共分为以下四个区域： 保留区 1.第一个扇区为引导扇区，存放BPB(BIOS Parameter Block)数据，存放的是FAT卷的配置参数。 2.上述参数中以 BPB_ 命名的字段都是 BPB 的一部分，而以 BS_ 标题命名的字段都不是 BPB 的一部分，而只是引导扇区的一部分 FAT区（分区表装载区） 根目录区 数据区 各分区偏移地址及大小如下： 编辑 ​ 此外，关于FAT区，通常存在一个以上的FAT，如此处所格式化的sd卡便存在两个FAT，对应的偏移地址和大小如下： 编辑 ​ 4.4 FAT子类型确认 关于FAT的类型是FAT12/16/32确认：FAT类型由数据区内簇的数量决定，除此之外无其他办法！ 当一个卷，簇的数量 ≤4085 时，为FAT12 当一个卷，簇的数量 ≥4086 且 ≤65525 时，为FAT16 当一个卷，簇的数量 ≥65526 时，为FAT32 簇的数量计算公式：CountofClusters = DataSectors / BPB_SecPerClus; 如我们这里：CountofClusters = 242176 / 4 = 60544，所以为 FAT16！ 当簇的大小从 512 ~ 32768字节的各种条件下，不同类型FAT对应卷的大小范围如下： 编辑 ​ 4.4 访问FAT条目 FAT区由一条条FAT条目构成，关于FAT 对应的条目具体位置计算如下： 编辑 ​ FAT16： FAT32： 编辑 ​ 格外需要注意的是，不同格式，对应的FAT条目的长度和格式不一样： 此外对于FAT32格式，高4位是保留位，只有低28位有效！ 具体如下图所示： 编辑 ​ 4.5 文件与簇之间的关系 那么文件和簇之间的相互关系又是怎样的呢？我们又是如何准确的找到存放在flash上的文件的呢？接下来让我们看下文件与簇之间的关系映射。 在FAT卷上文件通过目录管理，目录是一个32字节数组组成的目录条目结构，此目录结构包含：文件名、文件大小、时间戳以及文件所在的第一个簇号。 簇号为0和1的簇被保留，由参数BPB_RootClus可知，有效簇从第2号簇开始。FAT (2号簇)对应数据区的第一个簇。 因此第N个簇的位置计算公式如下： FirstSectorofCluster = DataStartSector + (N - 2) * BPB_SecPerClus 每个条目所在的位置，对应一个簇。当文件长度大于一个簇长度时，条目内的值为下一个条目的索引，直到文件所在的最后一个簇，由此构成簇链！文件所在的最有一个簇所对应的FAT条目内的值由一个特殊的值（EOC）组成，它永远不会匹配任何有效的簇号，如下： FAT12: 0xFF8 - 0xFFF (typically 0xFFF) FAT16: 0xFFF8 - 0xFFFF (typically 0xFFFF) FAT32: 0x0FFFFFF8 - 0x0FFFFFFF (typically 0x0FFFFFFF) 存在一些特殊的值被用来做损坏簇的标记，如下： FAT12： 0xFF7 FAT16：0xFFF7 FAT32：0xFFFFFFF7 不过此处需要注意，在FAT12/16系统上，上述特殊值绝不会和任何有效簇匹配，但是在FAT32上有可能，因此为了防止混淆，你在创建FAT32系统的时候应该避免这种情况发生！因此FAT32系统上簇的上限为268435445（大于256M个簇） FAT条目初始化的时候，FAT 及以后的数据应被初始化为0，指示未被使用处于空闲状态，如果值不为0，则意味着簇被损坏或被使用状态。在FAT12/16系统上，空闲簇的数量未被记录，而在FAT32系统上，FAT32支持FSInfo结构体，里面记录了空闲簇的数量。 关于FAT 和FAT ： 此两个保留的条目，没有与任何簇有联系；不过具有其他意义，如下： FAT12: FAT = 0xF??; FAT = 0xFFF; FAT16: FAT = 0xFF??; FAT = 0xFFFF; FAT32: FAT = 0xFFFFFF??; FAT = 0xFFFFFFFF; FAT 中的?? 与 BPB_Media 相同； FAT 记录了错误历史记录：卷脏标志（FAT16：bit15、FAT32：bit31），系统在启动的时候清除此位，正常关闭的时候恢复。 如果此位已经清除，表明上次未被正常关闭，可能存在逻辑卷错误；硬件错误标志（FAT16：bit14、FAT32：bit30）当出现无法恢复的读写错误时清除，表明需要进行全面检查。 关于FAT区域，有两个重点注意事项： 第一个是FAT的最后一个扇区可能没有被完全使用。在大多数情况下，FAT在扇区的中间结束。FAT驱动程序不应该对未使用的区域做出任何假设。在格式化卷时，应该用零填充它，并且在此之后不应更改它。 另一个是BPB_FATSz16/32可以指示比卷需要的值大的值。换句话说，未使用的扇区可以跟随每个FAT。这可能是数据区域对齐或其他原因导致的。同时，在格式化时这些扇区也会被用零填充。 下表展示了不同FAT类型中FAT值所对应的含义解释： 编辑 ​ 4.6 FSInfo扇区结构及备份引导扇区 此部分内容只在FAT32系统上存在，对于FAT12系统FAT区域大小最大6KB，对于FAT16系统FAT区域最大128KB，但是在FAT32系统上FAT区域通常上达数MB，这是因为FAT32系统支持FSInfo数据结构。 在FAT32系统上新增FSInfo数据结构的原因是：在FAT12/16系统上，想要知道flash上剩余的簇数需要扫描整个FAT区才能计算出来，但随着flash容量的不断扩大，扫描花费的时长越来越长，为了避免扫描浪费过多的时间，因此在FAT32系统上增加了FSInfo结构，用于记录flash上剩余的簇数。 FSInfo数据结构如下： 编辑 ​ 注意：当扇区大小大于512字节时， 剩余空间采用0x00填充 4.7 FAT目录 FAT目录分为长文件名目录（LFN）以及短文件名目录（SFN），长文件目录是在短文件名目录上的一个扩展，具体采用长文件名还是短文件名由读取FAT文件系统的操作系统决定，如windows；设置长文件名时短文件名也被设置，具有兼容性。 此外，有一个很重要的概念：在FAT文件系统上目录也是一个文件，只是此文件的属性不一样而已。 在所有目录中，有一个比较特殊的是根目录，且根目录作为顶层目录必须存在。 在FAT12/16系统中，根目录不是一个文件，且放在根目录区，根目录的最大条目数由 BPB_RootEntCnt 参数指示； 在FAT32系统中，根目录与子目录没有什么区别，且根目录的起始簇由 BPB_RootClus 参数指示。 根目录与子目录的另外一个区别是，根目录不包含 . .. 此两个点目录，且它可以包含卷标（具有ATTR_VOLUME_ID属性的条目） 4.7.1 SFN 短文件名目录 目录条目结构如下： 编辑 ​ 关于目录结构的第一个字段 DIR_Name 的第一个元素 DIR_Name 在目录表中有着特殊作用，如下： 当此值为 0xE5 时，代表此目录条目未被使用（或已废弃） 当此值为 0x00 时，也代表此目录条目未被使用；此外还提示后续目录条目也未被使用，因为后续的目录条目 DIR_Name 都会是 0x00 如果文件名的第一个字符为 0xE5 这个特殊值，则使用 0x05 替代。 这么设计的意义是什么呢？将 DIR_Name 用作特殊字符，其目录在于方便文件删除！当我们删除一个文件的时候，文件系统并不会将此文件所对应的数据全部删除，因为那样太费时间了，也没有必要，而是直接将对应文件的目录项中的 DIR_Name 修改为 0xE5 即可！ 关于文件名字段 DIR_Name，在FAT文件系统中还有如下规定： DIR_Name 字段的11字节的文件名分为两个部分：8 字节的主文件名 + 3字节的扩展名； 文件名中主文件名与扩展名中间的 . 被省略，不在此记录 如果主文件名长度不够，小于8字节，则使用 0x20 空格填充 用于设置文件名的字符也有限制，支持的字符有 0～9 A～Z ! # $ % & ’ ( ) - @ ^ _ ` { } ~ 主文件名和扩展名中的(a~z)ASCII字符都会被转化成大写字符保存 以下为文件名存储示例： 编辑 ​ 4.7.2 LFN长文件名 长文件名是文件名的另外一种存储方式，由于SFN短文件名具有长度、字符等限制，在一些场景下不能很好的满足需求，因此就需要使用到长文件名，关于长文件名的具体内容如下： 长文件名是一个具有特殊属性的目录条目。长文件名目录属性 DIR_Attr 字段的值 ATTR_LONG_NAME = (ATTR_READ_ONLY | ATTR_HIDDEN | ATTR_SYSTEM | ATTR_VOLUME_ID) = 0x0F； 编辑 ​ 关于长文件名的目录属性如下： 编辑 ​ 关于长文件名，有以下几点重要概念： 一个文件一定有短文名SFN，但不一定有长文件名LFN 长文件名LFN字段中仅包含文件名信息，不包含其他内容，其他内容需要通过短文件名SFN查看 如果一个文件既有长文件名也有短文件名，则长文件名是其主要名字，而短文件名则为附加名字 长文件名LFN条目在对应的短文件名SFN条目前面 一个文件的长文件名最长255字符，对应最多20个长文件名LFN条目 长文件名简单理解起始就是存储一个字符串，因此没有类似SFN的限制，允许有空格、支持大小写、允许多个.符号等 LFN条目文件名长度不够，仍然采用0x20填充 下图是官方关于一个名为 “MultiMediaCard System Summary.pdf” 的长文件名在flash上的长文件名条目，如下所示，一眼没看明白也没关系，后文有实例说明，对长文件名有概念了就行！ 编辑 ​ 关于长文件名的checksum字段和计算，算法如下： uint8_t create_sum (const DIR* entry) { int i; uint8_t sum; for (i = sum = 0; i < 11; i++) { /* Calculate sum of DIR_Name ; } return sum; } 4.7.3 LFN系统对于SFN的兼容 在使用LFN长文件名的系统中，会自动生成SFN短文件名已确保此文件在短文件名的文件系统中可使用。同时为了防止生成的短文件名冲突，SFN的生成采用 名称+数字后缀+扩展 的格式，同时采用以下规则生成SFN： 小写自动转大写 如果存在空格，则删去空格，设置有损转换标识 已.开头的文件删除头部的.，并设置有损转换标识 存在多个.的文件名，仅保留最后一个作为文件名与扩展的分隔，并设置有损转换标识 其他不支持的字符，采用_代替，并设置有损转换标识 文件名如果是Unicode编码，则转化为ANSI/OEM编码；不能转换的字符采用_代替，并设置有损转换标识 长度超过8字节的部分，截断，并设置有损转换标识 扩展名字段超过3字节的，截断，并设置有损转换标识 有损转转换标识为：~，ASCII值为0x7E，十进制126 示例如下： 编辑 ​ 至此，FAT文件系统的理论部分已经描述完了，接下来我们继续使用winhex对数据进行分析。 5. 分区分析 继续回顾我们一开始的这张布局图 编辑 ​ 5.1 保留分区分析 保留分区为第一个分区，其中引导扇区位于保留分区的第一个扇区。 根据 4.3 章节计算结果可知，保留分区起始地址为 0x00，大小 0xC00 保留分区数据如下，保留分区内最重要的内容即为引导扇区，除引导扇区外，其他剩余空间全部保留，采用0x00覆盖。关于引导扇区已在 4.2 章节详细分析，此处不再做介绍。 编辑 ​ 5.2 FAT区分析 根据 4.3 章节描述，FAT区的起始地址为0xC00，大小为0x3B400，此外存在两个FAT区，FAT1和FAT2，起始地址分别为：0xC00、0x1E600，对应地址数据如下： FAT1 数据： 编辑 ​ FAT2 数据如下： 编辑 ​ 由于此处采用FAT16格式，所以每个FAT条目占据两个字节！ 根据上述数据进行分析： 确认 FAT2 为 FAT1 的备份； 存在5个FAT条目其中 FAT 和 FAT 为保留条目，FAT 的内容与 BPB_Media 媒体类型字段一致，FAT 用来记录错误历史记录 （详见 4.5 章节描述） 根据4.5章节描述，FAT (2号簇)对应数据区的第一个簇，又FAT 、FAT 、FAT 数据均为 0xFF，表明存在三个文件，且每个文件的大小小于等于一个簇的空间；且分别存放在数据区第1到第3个簇上！ 此处可能大家会由疑问，刚刚格式化的sd卡为什么会存在文件内，其实这个是系统文件，格式化后自带的，默认是隐藏的，只有使用winhex才能看到，也就是对应的System Volume Information文件夹。 5.3 根目录区分析 注意，根目录区只有 FAT12 / FAT16 系统上存在，在FAT32系统上不存在此区域。 根目录区用来记录根目录下的文件内容，根据 4.3 章节计算可知，根目录区起始地址为：0x3C000，大小为0x4000，数据内容如下： 编辑 ​ 以下是对数据字段进行分析后的内容，如下图所示： 编辑 ​ 格式化之后，默认会生成一个System Volume Infomation的系统文件夹，同时此文件夹是根目录下唯一的一个文件，因此在根目录的数据如上图所示。 此文件夹为目录属性，是隐藏的系统目录 长文件名为System Volume Information，短文件名为SYSTEM~1 此目录指向存放的数据在2号簇（对应数据区第一个簇），文件大小字段，由于此文件为目录属性，此字段无意义，因此强制为0 至此，根目录区分析完了，同时根目录区的 System Volume Information文件指向数据区第一个簇（2号簇），接下来我们便进入数据区进行分析。 5.4 数据区分析 根据 4.3 章节计算可知，数据区起始地址为：0x40000，大小为242176 * 512 = 0x764 0000，数据内容如下： 编辑 ​ 对应数据字段分析如下： 编辑 ​ System Volume Information 目录下存在两个文件，分别是IndexerVolumeGuid 和 WPSettings.dat。根据上述分析可知： IndexerVolumeGuid文件的数据存放在 FAT ，3号簇上，即数据区的第3个簇（数据区的第1个簇为2号簇）； WPSettings.dat 文件的数据存放在 FAT ，4号簇上，即数据区的第2个簇（数据区的第1个簇为2号簇）； 首先，我们跳转到4号簇上查看IndexerVolumeGuid的数据，对应地址计算方式为： FirstSectorofCluster = DataStartSector + (N - 2) * BPB_SecPerClus = 512 + (4 - 2) * 4 = 520; 对应地址为： FirstSectorofCluster * BPB_BytsPerSec = 520 * 512 = 0x0004 1000 编辑 ​ 接着跳转到3号簇上查看WPSettings.dat的数据，对应地址计算方式为： FirstSectorofCluster = DataStartSector + (N - 2) * BPB_SecPerClus = 512 + (3 - 2) * 4 = 516; 对应地址为： FirstSectorofCluster * BPB_BytsPerSec = 520 * 512 = 0x0004 0800 编辑 ​ 5.5 新增文件测试 1.在根目录下新增 test 目录，使用winhex更新磁盘数据，观察各数据区变化 保留区无变化 FAT区变化如下： 编辑 ​ 编辑 ​ 根目录区变化如下： 编辑 ​ 数据区变化： 编辑 ​ 2.新增long file test文件夹，里面存入一个长度为 2050 Byte（占据两个簇的空间）的test.txt文件，使用winhex重新打开磁盘进行分析。 编辑 ​ 保留区无变化 FAT区变化如下： 编辑 ​ 编辑 ​ 根目录区变化如下： 数据区变化如下： long file test目录数据指向6号簇，跳转至6号簇，地址DataStartSector + (N - 2) * BPB_SecPerClus = 0x40000 + (6-2) * 4 * 512 = 0x420000 编辑 ​ test.txt文件指向 7号簇，跳转至7号簇，地址DataStartSector + (N - 2) * BPB_SecPerClus = 0x40000 + (7-2) * 4 * 512 = 0x428000，均为test.txt的实际有效数据，如下： 编辑 ​ 编辑 ​ 6. 总结 以上便是关于FAT文件系统的全部分析了，通过上述分析，外加新增文件辅助理解，对于文件在FAT文件系统下如何管理、存储，相信已经有了非常深入的了解。 FAT文件系统分为四个区： 保留区最重要的是里面包含引导扇区，引导扇区内存放着BIOS参数信息，通过此参数可以知道FAT文件系统的flash布局，以及flash大小，fat块大小、簇大小等关键信息； FAT区，记录了文件所占用簇的情况，以及对于文件大小大于一个簇的文件，在FAT区内形成簇链，记录文件由哪几个簇组成 根目录区，只有FAT12/16系统所有，记录了根目录下的文件/目录条目信息 数据区，记录数据分为两个部分，第一部分为目录信息，除根目录外，每个文件夹需要占据一个及以上的簇描述对应目录下的文件情况；第二部分为具体文件数据。两部分数据通过短文件名SFN字段进行关联！ 以上就是FAT文件系统的简单概括，由于本文使用的是FAT16文件系统作为实例分析，关于FAT32文件系统，在下一篇博文中进行补充，敬请关注！

  第四十八章 照相机实验 上一章，我们学习了图片解码，本章我们将学习bmp编码，结合前面的摄像头实验，实现一个简单的照相机。本章分为如下几个部分： 48.1 BMP编码简介 48.2 硬件设计 48.3 软件设计 48.4 下载验证 48.1 BMP编码简介        上一章，我们学习了各种图片格式的解码。本章，我们介绍最简单的图片编码方法：BMP图片编码。通过前面的了解，我们知道BMP文件是由文件头、位图信息头、颜色信息和图形数据等四部分组成。我们先来了解下这几个部分。 1、BMP文件头（14字节）：BMP文件头数据结构含有BMP文件的类型、文件大小和位图起始位置等信息。 //BMP文件头 typedef __packed struct {     u16  bfType ;           //文件标志.只对'BM',用来识别BMP位图类型     u32  bfSize ;            //文件大小,占四个字节     u16  bfReserved1 ;       //保留     u16  bfReserved2 ;       //保留     u32  bfOffBits ;                //从文件开始到位图数据(bitmap data)开始之间的的偏移量 }BITMAPFILEHEADER ; 2、位图信息头（40字节）：BMP位图信息头数据用于说明位图的尺寸等信息。 typedef __packed struct {     u32 biSize ;                //说明BITMAPINFOHEADER结构所需要的字数。     long  biWidth ;            //说明图象的宽度，以象素为单位     long  biHeight ;         //说明图象的高度，以象素为单位     u16  biPlanes ;           //为目标设备说明位面数，其值将总是被设为1     u16  biBitCount ;       //说明比特数/象素，其值为1、4、8、16、24、或32     u32 biCompression ;    //说明图象数据压缩的类型。其值可以是下述值之一：        //BI_RGB：没有压缩；        //BI_RLE8：每个象素8比特的RLE压缩编码，压缩格式由2字节组成     //BI_RLE4：每个象素4比特的RLE压缩编码，压缩格式由2字节组成       //BI_BITFIELDS：每个象素的比特由指定的掩码决定。     u32 biSizeImage ;//说明图象的大小,以字节为单位。当用BI_RGB格式时,可设置为0      long  biXPelsPerMeter ;//说明水平分辨率，用象素/米表示     long  biYPelsPerMeter ;//说明垂直分辨率，用象素/米表示     u32 biClrUsed ;             //说明位图实际使用的彩色表中的颜色索引数     u32 biClrImportant ;    //说明对图象显示有重要影响的颜色索引的数目， //如果是0，表示都重要。 }BITMAPINFOHEADER ; 3、颜色表：颜色表用于说明位图中的颜色，它有若干个表项，每一个表项是一个RGBQUAD类型的结构，定义一种颜色。 typedef __packed struct {     u8 rgbBlue ;       //指定蓝色强度     u8 rgbGreen ;        //指定绿色强度     u8 rgbRed ;          //指定红色强度     u8 rgbReserved ;    //保留，设置为0 }RGBQUAD ; 颜色表中RGBQUAD结构数据的个数由biBitCount来确定：当biBitCount=1、4、8时，分别有2、16、256个表项；当biBitCount大于8时，没有颜色表项。 BMP文件头、位图信息头和颜色表组成位图信息（我们将BMP文件头也加进来，方便处理），BITMAPINFO结构定义如下: typedef __packed struct {        BITMAPFILEHEADER bmfHeader;        BITMAPINFOHEADER bmiHeader;           RGBQUAD bmiColors ;  }BITMAPINFO;    4、位图数据：位图数据记录了位图的每一个像素值，记录顺序是在扫描行内是从左到右，扫描行之间是从下到上。位图的一个像素值所占的字节数:  当biBitCount=1时，8个像素占1个字节;  当biBitCount=4时，2个像素占1个字节; 当biBitCount=8时，1个像素占1个字节; 当biBitCount=16时，1个像素占2个字节; 当biBitCount=24时，1个像素占3个字节; 当biBitCount=32时，1个像素占4个字节; biBitCount=1 表示位图最多有两种颜色，缺省情况下是黑色和白色，你也可以自己定义这两种颜色。图像信息头装调色板中将有两个调色板项，称为索引0和索引1。图象数据阵列中的每一位表示一个象素。如果一个位是0，显示时就使用索引0的RGB值，如果位是1，则使用索引1的RGB值。    biBitCount=16 表示位图最多有65536种颜色。每个色素用16位（2个字节）表示。这种格式叫作高彩色，或叫增强型16位色，或64K色。它的情况比较复杂，当biCompression成员的值是BI_RGB时，它没有调色板。16位中，最低的5位表示蓝色分量，中间的5位表示绿色分量，高的5位表示红色分量，一共占用了15位，最高的一位保留，设为0。这种格式也被称作555 16位位图。如果biCompression成员的值是BI_BITFIELDS，那么情况就复杂了，首先是原来调色板的位置被三个DWORD变量占据，称为红、绿、蓝掩码。分别用于描述红、绿、蓝分量在16位中所占的位置。在Windows 95（或98）中，系统可接受两种格式的位域：555和565，在555格式下，红、绿、蓝的掩码分别是：0x7C00、0x03E0、0x001F，而在565格式下，它们则分别为：0xF800、0x07E0、0x001F。你在读取一个像素之后，可以分别用掩码“与”上像素值，从而提取出想要的颜色分量（当然还要再经过适当的左右移操作）。在NT系统中，则没有格式限制，只不过要求掩码之间不能有重叠。（注：这种格式的图像使用起来是比较麻烦的，不过因为它的显示效果接近于真彩，而图像数据又比真彩图像小的多，所以，它更多的被用于游戏软件）。 biBitCount=32 表示位图最多有4294967296(2的32次方)种颜色。这种位图的结构与16位位图结构非常类似，当biCompression成员的值是BI_RGB时，它也没有调色板，32位中有24位用于存放RGB值，顺序是：最高位—保留，红8位、绿8位、蓝8位。这种格式也被成为888 32位图。如果 biCompression成员的值是BI_BITFIELDS时，原来调色板的位置将被三个DWORD变量占据，成为红、绿、蓝掩码，分别用于描述红、绿、蓝分量在32位中所占的位置。在Windows 95(or 98)中，系统只接受888格式，也就是说三个掩码的值将只能是：0xFF0000、0xFF00、0xFF。而在NT系统中，你只要注意使掩码之间不产生重叠就行。（注：这种图像格式比较规整，因为它是DWORD对齐的，所以在内存中进行图像处理时可进行汇编级的代码优化（简单））。 通过以上了解，我们对BMP有了一个比较深入的了解，本章，我们采用16位BMP编码（因为我们的LCD就是16位色的，而且16位BMP编码比24位BMP编码更省空间），故我们需要设置biBitCount的值为16，这样得到新的位图信息（BITMAPINFO）结构体： typedef __packed struct {        BITMAPFILEHEADER bmfHeader;        BITMAPINFOHEADER bmiHeader;         u32 RGB_MASK ;                   //调色板用于存放RGB掩码. }BITMAPINFO; 其实就是颜色表由3个RGB掩码代替。最后，我们来看看将LCD的显存保存为BMP格式的图片文件的步骤： 1 ）创建BMP 位图信息，并初始化各个相关信息 这里，我们要设置BMP图片的分辨率为LCD分辨率（240*320）、BMP图片的大小（整个BMP文件大小）、BMP的像素位数（16位）和掩码等信息。 2 ）创建新BMP 文件，写入BMP 位图信息 我们要保存BMP，当然要存放在某个地方（文件），所以需要先创建文件，同时先保存BMP位图信息，之后才开始BMP数据的写入。 3 ）保存位图数据。 这里就比较简单了，只需要从LCD的GRAM里面读取各点的颜色值，依次写入第二步创建的BMP文件即可。注意：保存顺序（即读GRAM顺序）是从左到右，从下到上。 4 ）关闭文件。 使用FATFS，在文件创建之后，必须调用f_close，文件才会真正体现在文件系统里面，否则是不会写入的！这个要特别注意，写完之后，一定要调用f_close。 BMP编码就介绍到这里。 48.2 硬件设计 本章实验功能简介：开机的时候先检测字库，然后检测SD卡根目录是否存在PHOTO文件夹，如果不存在则创建，如果创建失败，则报错（提示拍照功能不可用）。在找到SD卡的PHOTO文件夹后，开始初始化OV7670，在初始化成功之后，就一直在屏幕显示OV7670拍到的内容。当按下WK_UP按键的时候，即进行拍照，此时DS1亮，拍照保存成功之后，蜂鸣器会发出“滴”的一声，提示拍照成功，同时DS1灭。DS0还是用于指示程序运行状态。 所要用到的硬件资源如下： 1）  指示灯DS0和DS1 2）  WK_UP按键 3）  蜂鸣器 4）  串口 5）  TFTLCD模块 6）  SD卡 7）  SPI FLASH 8）  摄像头模块 这几部分，在之前的实例中都介绍过了，我们在此就不介绍了。 48.3 软件设计 打开上一章的工程，然后打开PICTURE组下的bmp.c文件，在该文件里面添加bmp编码函数bmp_encode，该函数代码如下： //BMP编码函数 //将当前LCD屏幕的指定区域截图,存为16位格式的BMP文件 RGB565格式. //保存为rgb565则需要掩码,利用原来的调色板位置增加掩码.这里我们已经增加了掩码. //保存为rgb555格式则需要颜色转换,耗时间比较久,所以保存为565是最快速的办法. //filename:存放路径 //x,y:在屏幕上的起始坐标 //mode:模式.0,仅仅创建新文件的方式编码;1,如果之前存在文件,则覆盖之前的文件. //如果没有,则创建新的文件. //返回值:0,成功;其他,错误码.  u8 bmp_encode(u8 *filename,u16 x,u16 y,u16 width,u16 height,u8 mode) {                                 FIL* f_bmp;        u16 bmpheadsize;                 //bmp头大小             BITMAPINFO hbmp;           //bmp头        u8 res=0;        u16 tx,ty;                                 //图像尺寸        u16 *databuf;                       //数据缓存区地址              u16 pixcnt;                          //像素计数器        u16 bi4width;                 //水平像素字节数            if(width==0||height==0)return PIC_WINDOW_ERR;               //区域错误        if((x+width-1)lcddev.width)return PIC_WINDOW_ERR;        //区域错误        if((y+height-1)lcddev.height)return PIC_WINDOW_ERR;      //区域错误      #if BMP_USE_MALLOC == 1     //使用malloc         databuf=(u16*)mymalloc(SRAMIN,1024);  //开辟至少bi4width大小的字节的内存区域 //对240宽的屏,480个字节就够了.        if(databuf==NULL)return PIC_MEM_ERR;              //内存申请失败.        f_bmp=(FIL *)mymalloc(SRAMIN,sizeof(FIL)); //开辟FIL字节的内存区域        if(f_bmp==NULL)                                           //内存申请失败.        {                          myfree(SRAMIN,databuf);               return PIC_MEM_ERR;                             }       #else        databuf=(u16*)bmpreadbuf;        f_bmp=f_bfile; #endif                  bmpheadsize=sizeof(hbmp);//得到bmp文件头的大小          mymemset((u8*)hbmp,0,sizeof(hbmp));//置零空申请到的内存.               hbmp.bmiHeader.biSize=sizeof(BITMAPINFOHEADER);//信息头大小        hbmp.bmiHeader.biWidth=width;       //bmp的宽度        hbmp.bmiHeader.biHeight=height;      //bmp的高度        hbmp.bmiHeader.biPlanes=1;                   //恒为1        hbmp.bmiHeader.biBitCount=16;       //bmp为16位色bmp        hbmp.bmiHeader.biCompression=BI_BITFIELDS;//每个象素的比特由指定的掩码决定。     hbmp.bmiHeader.biSizeImage=hbmp.bmiHeader.biHeight*hbmp.bmiHeader.biWidth* hbmp.bmiHeader.biBitCount/8;//bmp数据区大小                                     hbmp.bmfHeader.bfType=((u16)'M'8)+'B';//BM格式标志        hbmp.bmfHeader.bfSize=bmpheadsize+hbmp.bmiHeader.biSizeImage;//整个bmp的大小      hbmp.bmfHeader.bfOffBits=bmpheadsize;//到数据区的偏移        hbmp.RGB_MASK =0X00F800;                  //红色掩码        hbmp.RGB_MASK =0X0007E0;                  //绿色掩码        hbmp.RGB_MASK =0X00001F;                  //蓝色掩码        if(mode==1)res=f_open(f_bmp,(const TCHAR*)filename,FA_READ|FA_WRITE); //尝试打开之前的文件       if(mode==0||res==0x04)res=f_open(f_bmp,(const TCHAR*)filename,FA_WRITE| FA_CREATE_NEW);//模式0,或者尝试打开失败,则创建新文件                     if((hbmp.bmiHeader.biWidth*2)%4)//水平像素(字节)不为4的倍数        {               bi4width=((hbmp.bmiHeader.biWidth*2)/4+1)*4; //实际要写入的宽度像素,必须为4的倍数.              }else bi4width=hbmp.bmiHeader.biWidth*2;              //刚好为4的倍数       if(res==FR_OK)//创建成功        {               res=f_write(f_bmp,(u8*)hbmp,bmpheadsize,bw);//写入BMP首部               for(ty=y+height-1;hbmp.bmiHeader.biHeight;ty--)               {                      pixcnt=0;                     for(tx=x;pixcnt!=(bi4width/2);)                      { if(pixcnt //读取坐标点的值                             else databuf =0Xffff;//补充白色的像素.                              pixcnt++; tx++;                      }                      hbmp.bmiHeader.biHeight--;                      res=f_write(f_bmp,(u8*)databuf,bi4width,bw);//写入数据               }               f_close(f_bmp);        }         #if BMP_USE_MALLOC == 1     //使用malloc         myfree(SRAMIN,databuf);           myfree(SRAMIN,f_bmp);            #endif            return res; } 该函数实现了对LCD屏幕的任意指定区域进行截屏保存，用到的方法就是48.1节我们所介绍的方法，该函数实现了将LCD任意指定区域的内容，保存个为16位BMP格式，存放在指定位置（由filename决定）。注意，代码中的BMP_USE_MALLOC是在bmp.h定义的一个宏，用于设置是否使用malloc，本章我们选择使用malloc。 保存bmp.c，然后在bmp.h里面添加bmp_encode函数的申明，并保存bmp.h文件。 剩下的，我们就只需要修改主函数即可了，打开test.c，修改该文件代码如下： //省略部分代码  此部分代码，和第四十一章的代码有点类似，只是这里我们多了一个camera_new_pathname函数，用于获取新的bmp文件名字（不覆盖旧的）。在main函数里面，我们通过WK_UP按键控制拍照（调用bmp_encode函数实现），其他部分我们就不多介绍了，至此照相机实验代码编写完成。 最后，本实验可以通过USMART来测试BMP编码函数，将bmp_encode函数添加到USMART管理，即可通过串口自行控制拍照，方便测试。 48.4 下载验证 在代码编译成功之后，我们通过下载代码到ALIENTEK战舰STM32开发板上，得到如图48.4.1所示界面：   图48.4.1 程序运行效果图 随后，进入监控界面。此时，我们可以按下WK_UP即可进行拍照。拍照得到的照片效果如图48.4.2所示：   图48.4.2 拍照样图        最后，我们还可以通过USMART调用bmp_encode函数，实现串口控制拍照，还可以拍成各种尺寸哦（不过必须小于240*320）！   )databuf =lcd_readpoint(tx,ty)      

  第四十七章 图片显示实验 数码相框日渐流行，数码相框显示的图片一般为 BMP/JPG/JPEG/GIF 等格式，其实用我们的战舰 STM32 开发板也可以显示图片。在本章中，我们将向大家介绍如何通过 STM32 来解码 BMP/JPG/JPEG/GIF 等图片，并在 LCD 上显示出来。本章分为如下几个部分： 47.1   图片格式简介 47.2   硬件设计 47.3   软件设计 47.4   下载验证 由于含敏感词的原因，无法发表，请大家看附件，抱歉！

         以前做过SD卡移植fatfs文件系统，现在想将fatfs文件系统移植到AT45DB161串行flash上，在使用SD卡移植fatfs文件系统时，可以不用考虑f_mkfs()格式化函数，可以直接用PC格式化即可，而且测试API函数的时候也可以很方便通过PC机来查看效果，增加了程序的透明度，但是在AT45DB161上面移植fatfs文件系统的时候显然面对的情况要复杂一些，不过通过一些手段我们还是可以更透明的了解API函数的执行效果的。在使用仿真器跟踪程序的过程中我发现对AT45DB161格式化时0~62扇区被作为了保留扇区，63扇区是引导扇区，64扇区属于FAT表区，FAT表区总共有多少扇区我也忘了，不过通过读取特定扇区的物理数据并结合FAT文件系统的数据存储格式不难看出格式化是否成功，在确保了格式化成功之后便可以测试文件的创建、读取、写入等一些基本的操作了，还可以通过f_getfree()来查看剩余空间，以确保格式化之后flash空间是否正确。在格式化时参数设置为f_mkfs(0,0,512)，下面将我的相关程序上传上来供网友分享！