最早做数据采集项目的时候，我特别天真：传感器数据直接往Flash固定地址写，记录一趟下来自己记着一份“偏移量表”，什么时候满了就整体擦掉重来。结果有次要导数据给客户，插上读卡器才发现——Windows根本不认这块裸Flash，最后只能拆板子焊线用串口把数据一点一点导出来。从那天起我彻底明白一件事：在STM32上做数据存储，早晚都得过文件系统这一关。而谈到文件系统，STM32圈子里最成熟的方案就是FatFs移植。这篇文章把我反复移植FatFs到大大小小嵌入式项目里沉淀下来的完整链路写清楚，包括配置、底层接口实现、各类翻车点和排查思路，给正要上手或者被挂载问题折磨的同行一个可复现的路线。
1. 为什么要给STM32移植文件系统：从“裸写地址”的痛点说起
1.1 直接操作存储介质的三个麻烦
很多工程师一开始都觉得：我不需要文件系统，自己管理地址就够了。小数据量时确实可以，一旦痛点积累起来，这方案会活活把人逼疯。
第一个麻烦是内存和地址的管理成本。用SD卡存数据，如果只用底层扇区读写，就要自己记录每一份数据对应哪个扇区、写了多少字节、还剩多少空间。这个“索引表”放哪里？放在内存里掉电丢失，放在存储介质里又牵扯磨损、掉电一致性问题。数据量一上去，纯裸读写就是给自己挖坑。
第二个麻烦是数据无法在PC上直接查看。裸设备没有目录结构，插到电脑上就是一个未格式化磁盘，或者干脆不识别。我们在实际项目里经常要把采集数据交给别人分析，总不能每次都写个小工具去读原始扇区。文件系统解决了跨设备交换的问题——拔卡，插读卡器，直接拷出来。
第三个麻烦是数据的追加、删除、覆盖。裸设备上要删掉一段旧数据再插入新数据，位置管理非常痛苦。而有文件系统的时候，f_open / f_write / f_read 三个接口就把所有路径、权限、空间回收都封装好了。你只关心“我要写一个叫log.txt的文件”，完全不用关心它在物理介质上哪个位置。
1.2 文件系统究竟在帮你管理什么
FAT文件系统能成为单片机上的事实标准，不是因为它快，而是因为它结构简单、协议公开、Windows/Linux都能原生识别。它用三个核心结构管理整个存储介质：
- 引导扇区（Boot Sector）：记录文件系统类型、扇区大小、簇大小、FAT表位置等元信息。
- 文件分配表（FAT表）：以“簇”为单位记录每个文件占用了哪些存储块。如果把整个存储器比作一座图书馆，FAT表就是索引卡片，告诉你一本书的内容分放在哪几格书架上。
- 目录项（Directory Entry）：记录文件名、起始簇号、文件长度、时间戳。相当于图书馆的书目台账。
写入文件时，系统先在FAT表里找空闲簇，把数据按簇写入，再更新FAT表的前向链接和目录项。删除文件时，只把目录项标记为删除、FAT表对应簇标记为空闲。这个设计极其简洁，非常适合资源受限的MCU环境。
1.3 移植FatFs的本质：隔离驱动层与应用层
FatFs的作者把整个库分成了三层：应用层（f_open、f_write、f_mount这些API）、FAT逻辑层（库内部处理目录、簇链、FAT表）、底层驱动接口（diskio.c）。移植时完全不需要动FAT逻辑层的代码，你要做的只是提供若干标准接口，让FAT逻辑层能够访问你的物理存储设备。
换句话说，FatFs移植包了一层“适配器”，核心工作全部集中在diskio.c这个文件上。搞清楚了这一点，整个移植过程就有了主线，剩下的就是往几个固定的函数壳里填硬件驱动的代码。
2. 动手前的三个选择：存储介质、硬件接口与文件系统版本
2.1 SD卡选SPI模式还是SDIO模式
如果你用的是STM32和SD卡，首先要回答一个问题：SD卡走SPI通信还是SDIO通信？
对于大多数第一次做移植的开发者，我强烈建议用SPI模式起步。SPI模式兼容性极好，几乎任何带SPI外设的单片机都能操作SD卡，引脚占用少（4根信号线加片选），时序相对宽松。缺点是速度慢，SPI模式理论最高也就25MHz左右，实际文件读写吞吐通常只有1~2MB/s。但用来做数据记录、配置存储、静态资源读取，完全够用。
SDIO模式带宽更大，能跑SD读写多块、DMA传输，适合音频播放、视频缓存这类高速应用。但SDIO模式对硬件布线、上拉电阻、卡座质量更敏感，调试难度明显上了一个台阶。
一个常见的折中思路：初期先用SPI模式把整个FatFs通道跑通，确认文件系统逻辑没问题后，再根据性能需求决定要不要切到SDIO。这样排查问题时，文件系统和硬件接口两个变量不会混在一起，定位问题会轻松很多。
2.2 SPI NOR Flash的移植差异：没有命令协议的存储介质
如果用的不是SD卡而是W25Q64这类SPI NOR Flash，移植层面的思路完全不一样。
SD卡本身实现了完整的Block Device协议，你发CMD17/CMD18/CMD24等命令就可以直接读写扇区；而SPI NOR Flash没有“扇区”和“文件系统”的原生概念，它只有擦除、读、写指令。更麻烦的是它有三个特性必须正视：
- 写前必须先擦除：Flash的写入只能把1变0，把0变1必须整块擦除。
- 擦除最小单位是扇区：W25Q64一个扇区4096字节，想改任何一个字节都得先擦掉整个扇区。
- 连续写入不能跨页：W25Q64一个页256字节，连续写数据超过页边界就会包裹回写，产生数据覆盖。
所以在SPI Flash上做FatFs，必须在disk_write里实现“读-改-写”流程：如果写入范围不是一个完整扇区，就需要先把对应Flash扇区读进缓冲区，修改后再擦除再写回。如果不处理这一点，哪怕FatFs逻辑完全正确，读写数据也会莫名其妙地丢。
2.3 FatFs版本与工程结构
下载FatFs源码时，现在一般都是R0.15系列，整个包包含这几个关键文件：
- ff.h / ff.c —— FatFs核心逻辑，不需要改动。
- ffconf.h —— 整个移植的配置中枢，需要重点修改。
- diskio.h / diskio.c —— 底层驱动接口，移植的核心战场。
- ffsystem.c —— OS相关和内存分配相关支持，裸机一般只用到microtime部分，或者直接摆着。
- ffunicode.c —— 文件名Unicode与OEM编码转换，中文字符支持时需要。
有些老工程还在用R0.12、R0.13，接口上最大的区别就是LBA数据类型换成了64位的LBA_t，以及disk_ioctl获取扇区数的宏名称略有调整。新版代码内部越写越严谨，但使用上依然保持最大的向后兼容，我个人建议直接用最新版，遇到兼容问题按新标准改接口就行。
3. 移植完整链路：配置ffconf.h、编写diskio接口、跑通f_mount
3.1 工程文件组织与ffconf.h关键配置
把源码文件加进工程这一步没什么难度，真正决定移植质量的是ffconf.h里的几个开关。很多人挂载失败或者文件名乱码，十有八九是这里的宏没打开。
我每次新建项目都会先把这几个配置项过一遍：
| 配置宏 | 推荐值 | 说明 |
|---|---|---|
| FF_USE_LFN | 1或2 | 0表示只支持8.3短文件名，文件操作超过8个字符或带中文会失败；填1用静态缓冲区，填2用malloc分配，建议先用1 |
| FF_MAX_SS | 512 | 逻辑扇区大小，绝大多数SD卡都是512，用SPI Flash时也按512对齐 |
| FF_USE_MKFS | 1 | 开启格式化功能，换新卡时可以直接用程序格式化，不然必须先插电脑格一下 |
| FF_USE_STRFUNC | 1 | 允许用f_printf往文件里写格式化文本，做日志记录超级方便 |
| FF_USE_FASTSEEK | 1 | 大文件随机读写时开启快速定位，如果是日志追加写场景可以先不开 |
| FF_VOLUMES | 1 | 只有一个存储设备时保持1即可 |
| FF_FS_NORTC | 0 | 关闭（设置为0代表使用get_fattime获取时间），否则文件时间戳全是固定值 |
配置好之后，最直观的检查点：把FF_USE_LFN打开并设置为1或2，FF_USE_MKFS打开。这两步不做，后面会遇到诡异的长文件名问题和无法格式化的尴尬。
3.2 diskio接口函数逐个实现
在FatFs里，disk_initialize、disk_read、disk_write、disk_ioctl、get_fattime这五个函数是移植主战场。我以SPI模式操作SD卡为例，把核心逻辑拆开讲。
先看disk_initialize。这个函数要做的是把SD卡从“上电状态”拉到“SPI模式并且完成初始化”。SD卡上电后默认是SD模式，需要一段常规时序把它切换进SPI模式：
DSTATUS disk_initialize(BYTE pdrv) { uint8_t resp; uint8_t cmd[6]; if (pdrv != DEV_SD) return STA_NOINIT; /* 片选拉高，先让SD卡上电稳定 */ SD_CS_HIGH(); HAL_Delay(5); /* 至少发送74个时钟脉冲，让卡完成上电同步 */ for (int i = 0; i < 10; i++) { spi_read_write_byte(0xFF); } /* 片选拉低，开始发送命令 */ SD_CS_LOW(); /* CMD0：进入SPI模式。连续发送，直到卡返回0x01（IDLE状态） */ uint8_t try_count = 0; do { sd_send_cmd(0, 0, 0x95); resp = sd_get_r1(); try_count++; } while (resp != 0x01 && try_count < 0x10); if (resp != 0x01) return STA_NOINIT; /* CMD8：区分SD V1和SD V2卡，SPI模式下返回固定校验值 */ sd_send_cmd(8, 0x000001AA, 0x87); resp = sd_get_r1(); if (resp == 0x01) { /* SD V2卡，继续ACMD41 */ try_count = 0; do { HAL_Delay(1); sd_send_cmd(55, 0, 0x00); /* CMD55是ACMD的前缀 */ sd_get_r1(); sd_send_cmd(41, 0x40000000, 0x00); /* ACMD41带HCS位 */ resp = sd_get_r1(); try_count++; } while (resp != 0x00 && try_count < 0x100); /* 等待卡退出IDLE */ } else { /* SD V1卡，老协议，ACMD41不带HCS */ } if (resp != 0x00) return STA_NOINIT; /* 初始化完成，把SPI速率从低速切到高速 */ spi_set_clock_speed(SPI_HIGH_SPEED); SD_CS_HIGH(); return RES_OK; }这里有一个必须刻在脑子里的细节：初始化的前几十个字节必须用低速SPI时钟。很多人在这一步翻车，就是因为把SPI配置成了最高速率。SD卡上电时还没稳定，在高速率下根本收不到CMD0的响应，返回状态一直是超时。
再看disk_read和disk_write。FatFs一次调用可能只读一个扇区，也可能一次读连续的多个扇区（比如exFAT的簇就是64KB），所以底层驱动不但要支持单扇区读写，还要支持多扇区连续传输：
DRESULT disk_read(BYTE pdrv, BYTE* buff, LBA_t sector, UINT count) { if (pdrv != DEV_SD) return RES_PARERR; SD_CS_LOW(); /* CMD17读单扇区，CMD18读多扇区 */ if (count == 1) { sd_send_cmd(17, sector, 0); } else { sd_send_cmd(18, sector, 0); } uint8_t resp = sd_get_r1(); if (resp != 0x00) { SD_CS_HIGH(); return RES_ERROR; } /* 等待数据起始令牌0xFE */ uint16_t wait_cnt = 0; while (spi_read_write_byte(0xFF) != 0xFE) { if (++wait_cnt > 0xFFFF) { SD_CS_HIGH(); return RES_ERROR; } } /* 读取数据 + 2字节CRC（SPI模式下CRC可以不校验，但字节还是要收掉） */ for (uint32_t i = 0; i < count * 512UL; i++) { buff[i] = spi_read_write_byte(0xFF); } spi_read_write_byte(0xFF); spi_read_write_byte(0xFF); /* 多扇区传输结束发CMD12 */ if (count > 1) { sd_send_cmd(12, 0, 0); sd_get_r1(); } SD_CS_HIGH(); return RES_OK; }disk_write的结构类似，区别在于要记得在数据前发送写起始令牌0xFE，写完一个扇区后轮询卡返回的写状态字节，直到0x05表示写入成功。多扇区连续写时，每次写完还要继续等待0xFF空闲状态，不能连续发数据。
disk_ioctl这个函数用到的场景比较集中：f_mkfs格式化时需要查询整个磁盘的扇区总数，FAT表创建时需要查询每个擦除块的大小，还有可能查询卡是否支持掉电保护。所以至少GET_SECTOR_COUNT和GET_BLOCK_SIZE这两个命令要支持：
DRESULT disk_ioctl(BYTE pdrv, BYTE cmd, void* buff) { if (pdrv != DEV_SD) return RES_PARERR; switch (cmd) { case GET_SECTOR_COUNT: *(LBA_t*)buff = sd_get_sector_count(); /* 通过CMD9读取CSD寄存器解析 */ return RES_OK; case GET_BLOCK_SIZE: *(DWORD*)buff = sd_get_block_size(); /* 通常返回16或32（单位是扇区） */ return RES_OK; case GET_SECTOR_SIZE: *(WORD*)buff = 512; return RES_OK; case CTRL_SYNC: return RES_OK; default: return RES_PARERR; } }最后是get_fattime。这个函数返回一个DWORD类型的时间戳，分别用不同位域存放年、月、日、时、分、秒。如果没接RTC芯片，最简单的做法是返回一个固定的初始时间，比如2024年1月1日对应的编码。这样文件时间戳不会导致系统崩溃，只是时间不准而已。等项目后期加了RTC再回来补填这个函数。
3.3 文件读写API的实际调用方式
底层驱动写完后，先不要急着铺开业务逻辑，用一段最简测试代码验证通道：
FIL file; FRESULT res; char buf[64]; /* 挂载文件系统，第5个参数1表示立即挂载 */ res = f_mount(&fs, "", 1); if (res != FR_OK) { /* 如果返回FR_NO_FILESYSTEM，先格式化 */ res = f_mkfs("", FM_FAT32, 0, work, sizeof(work)); if (res != FR_OK) return; res = f_mount(&fs, "", 1); } /* 创建并写入文件 */ res = f_open(&file, "test.txt", FA_CREATE_ALWAYS | FA_WRITE); if (res == FR_OK) { UINT written = 0; f_write(&file, "hello fatfs\r\n", 13, &written); f_close(&file); } /* 再读回来 */ res = f_open(&file, "test.txt", FA_READ); if (res == FR_OK) { UINT bytes_read = 0; f_read(&file, buf, sizeof(buf), &bytes_read); f_close(&file); }跑通这个最小例子，文件系统的“高速公路”就算通了。后面要做的所有事——记录传感器数据、播放音频、保存配置文件——都是在此基础上组合API而已。
3.4 日志落盘的完整流程
实际项目里最常见的应用是日志记录。把上面API组合成一个循环写文件的逻辑，注意定期f_sync把缓存刷进介质，防止突然掉电丢失数据：
FIL log_file; while (1) { sensor_data_t data = sensor_read(); char line[64]; int len = snprintf(line, sizeof(line), "%lu,%d,%d\r\n", (unsigned long)get_ticks(), data.temp, data.humidity); f_write(&log_file, line, len, &written); /* 每写一条数据同步一次，掉电最多丢一条 */ f_sync(&log_file); HAL_Delay(1000); }注意f_sync不能调用太频繁，因为每次都会触发底层的扇区写入和FAT表更新，太多同步操作会导致Flash或者SD卡磨损加剧、写入吞吐下降。日志场景通常每几条或者固定时间间隔同步一次就够了。
4. 实测中最容易翻车的七个环节与完整排查思路
4.1 SD卡SPI模式初始化失败：上电时序与时钟速率
最典型的现象是f_mount一直返回FR_NOT_READY，或者disk_initialize里面卡在CMD0响应循环里永远收不到0x01。
我见过太多人把问题归结于“卡坏了”，其实十有八九是时序问题。SD卡在上电后需要至少1ms稳定时间，CMC0发送前又需要至少74个时钟周期的同步信号。另外上电时MOSI必须保持高电平，如果CS引脚拉低之前MOSI处于低电平状态，SD卡会认为收到一个非法命令而直接卡死。
排查这类问题建议按这个顺序来：
- 用逻辑分析仪抓取CMD0的波形，确认命令字节、参数、CRC是否正确（CMD0的CRC是固定0x95）。
- 确认初始化阶段SPI时钟是否压到了400kHz以下，而不是用芯片的最高主频直接跑。
- 确认片选时序：发送命令时CS必须为低，两个命令之间需要保持CS为高，至少等8个时钟周期。
SPI模式下SD卡是不校验命令CRC的，但CMD0特殊，因为它是卡在进入SPI模式前唯一需要指定CRC的命令。CMD0的CRC固定值0x95写错，卡就永远没反应。
4.2 长文件名和中文字符支持没开
这个坑特别隐蔽。如果把FF_USE_LFN设为0，FatFs一律按8.3短文件名规则处理。经典表现是：程序里写的是log_data_20250101.txt，实际在卡上看到的是LOG_DATA.TXT这种短名称，后面字符全部被截断。更麻烦的是，如果你用f_open去查找SD卡上由PC创建的中文文件名，返回FR_NOT_FOUND。
解决方式就是在ffconf.h里把FF_USE_LFN设成1或者2。设成1时由FatFs内部静态缓冲区处理，不需要额外内存；设成2时用malloc动态分配，适合内存紧张但要开多个文件句柄的场景。还有配套的FF_MAX_LFN控制最长文件名长度，默认255一般不用动。
4.3 多扇区读写的片选与传输管理
在disk_read和disk_write的多扇区分支里，很多人犯错的地方是：多扇区传输期间把CS拉高了。SD卡在SPI模式下，一旦CS拉高就认为本次传输结束，再拉低继续读数据时，收到的全是0xFF填充，数据全部错位。
正确做法是：在发送CMD18之后、直到读完全部数据并发送CMD12结束命令之前，CS全程保持低电平。写多扇区也是一样的道理，写完最后一个扇区，收到0x05写成功标志后，才能把CS拉高。
这个问题一旦出现，现象非常迷惑——单扇区读写正常，文件系统挂载正常，但一旦拷贝大文件或者持续追加日志几百条，就会周期性出现错误数据。因为FatFs只有在读取超过一个扇区的数据时才会调用多扇区分支。
4.4 SPI Flash的擦除对齐问题
用W25Q64这类NOR Flash时，disk_write和SD卡完全不同。FatFs认为底层的块设备是“写前不需要擦除、写入粒度是扇区”的，但NOR Flash不是。
如果直接把收到的缓冲区写到Flash上，不去擦除或者不考虑部分扇区覆盖，数据第一天正常，第二天再写入时底层数据就会错乱。这就是Flash写前必须先擦、擦除单元比扇区大的物理特性在施加惩罚。
可靠的实现思路：在移植层加一个小型“读-改-写”映射算法。FatFs要写第N个逻辑扇区时，先把对应的Flash扇区整体读进SRAM缓冲区，把要修改的部分覆盖进去，然后整片擦除再整片写回。同时需要自己的逻辑扇区到物理Flash扇区的映射表，因为逻辑扇区边界（512字节）和Flash擦除扇区边界（4096字节）不一致，不做映射没办法高效管理。
4.5 f_mount挂载失败的返回码排查
挂载失败常见的返回码有三个，把这三个弄清楚，大半问题已经解决了：
| 返回码 | 含义 | 常见原因 |
|---|---|---|
| FR_NOT_READY | 设备未就绪 | disk_initialize失败，硬件时序、GPIO配置、SPI引脚错误 |
| FR_NO_FILESYSTEM | 介质上没有有效文件系统 | 卡没格式化、格式化格式不对（比如NTFS）、MBR分区表缺失 |
| FR_INVALID_OBJECT | 无效文件句柄 | 文件路径没加卷标前缀、f_mount没先执行、FIL结构体未清零 |
遇到FR_NO_FILESYSTEM，先别急着怀疑移植代码有问题。把SD卡插到读卡器上，用Windows自带工具格式化成FAT32再试。如果STM32能读但卡在Windows上格式化成NTFS，FatFs默认是不认NTFS的，必须用FF_FS_EXFAT打开exFAT支持或者干脆格式成FAT32。
如果格式化之后还是FR_NO_FILESYSTEM，优先检查disk_read是否能正确读出扇区0，以及disk_ioctl的GET_SECTOR_COUNT返回值是否和卡容量匹配。FatFs需要靠这两个值计算文件系统的边界。
4.6 逻辑扇区与物理扇区大小不一致
现在很多大容量SD卡虽然物理扇区是512字节，但底层Flash的擦除块很大。还有些高级卡支持4KB物理扇区。FatFs里FF_MAX_SS设成了4096但实际读写还是512，挂载时计算出来的FAT表位置会偏移，导致读写出来的数据完全错乱。
排查方法很简单：disk_ioctl的GET_SECTOR_SIZE分支里把实际扇区大小返回出来，然后在挂载后打印一下FatFs自己算出来的总量，看是否在合理范围内。最简单粗暴的方案就是统一用512字节逻辑扇区，把FF_MIN_SS和FF_MAX_SS都设成512，性能损失一些但兼容性最好。
4.7 调试手段：从返回码到逻辑分析仪
排查移植问题最重要的调试手段是先分层，再定位。我个人的习惯是三层逐步收窄：
第一层，只看硬件。写一个完全绕开FatFs的裸读写测试程序，直接调用disk_read和disk_write读写某个已知扇区，再用读卡器插PC确认数据是否正确。如果这层都过不了，别去折腾FatFs配置。
第二层，看FatFs的API返回。每个f_open、f_read、f_mount都把返回码打印出来。把返回码对应到ff.h里定义的枚举值，就知道挂在哪一步。
第三层，如果数据错乱但返回码正常，插逻辑分析仪抓SPI波形。重点看数据起始令牌、片选时序、多扇区传输结束信号。逻辑分析仪一上去，硬件时序问题基本都是原形毕露。
5. 验证、性能优化与后续演进
5.1 一套可复现的验证流程
移植完成后，我建议按照下面的顺序做一轮系统验证，而不是直接接入业务代码：
第一步，写入一个超过10MB的连续大文件，再用f_read顺序读取并逐字节校验。这能验证多扇区读写链路和FAT表簇链的遍历逻辑。
第二步，创建几十个文件再逐一删除，循环几轮。这能验证目录项空间回收和FAT表碎片管理。删除后检查可用文件系统容量是否逐渐恢复。
第三步，在写入过程中随机断电，重新上电后挂载文件系统，检查已经f_sync过的数据是否完整、未同步的数据是否丢弃。这能看掉电保护逻辑是否影响了文件系统的一致性。
第四步，格式化完成后，把卡插到PC上，查看目录结构、文件名、文件内容是否和预期一致。这一步是检验移植正确性最直观的“土办法”。
5.2 性能优化方向
性能优化优先级最高的永远是减少底层读扇区次数。FatFs每次操作文件都会访问FAT表，如果FAT表所在扇区没有缓存在内部缓冲区，每次都要重新读一次磁盘，这种开销在高频写日志时非常明显。
实践中可以做的优化有：
- 调大
FF_FS_TINY相关缓存配置前先测一下内存，确实是写多读少的场景再动。 - 写日志时尽量凑满一个扇区再写，不要每次写个三五字节就触发一次底层的读改写周期。FatFs本身有缓存机制，但用户层的写入模式直接影响效率。
- 如果有多个存储卷，尽量让FAT表所在卷处于常挂载状态，避免切换卷时频繁重新读取引导扇区。
- 对SD卡SPI通信，如果硬件支持DMA，给
disk_read和disk_write的数据传输阶段加上DMA，吞吐能提升明显。
5.3 要不要换用更现代的文件系统
近两年随着掉电保护、磨损均衡、加密固件升级这类需求增多，我开始在一些项目上把FatFs换成了更现代的日志型文件系统。
FatFs最大的软肋是掉电场景下的目录和FAT表一致性——掉电瞬间刚好在更新FAT表，大概率整个簇链会断，轻则丢文件，重则整个卷只剩只读。相比之下，日志结构文件系统靠顺序追加写和定期checkpoint，掉电一致性要好得多。另外Flash均匀磨损也是FatFs不具备的能力，长期挂在SPI Flash上做频繁写入，不自己加一层均衡算法的话，某些块会先于整体寿命完蛋。
但FatFs也不会被完全替代。体积小、内存占用低、PC兼容性极好这三条是它不可替代的理由。如果你的产品需要“把卡拔出来插电脑就能读”，那FAT就是绕不开的格式，用FatFs依然是不二选择。如果以可靠性为首要目标，允许多做一层转换，LittleFS这类新方案值得纳入选型对比。
从我个人的项目经验看，实际上很少有人一次就能把移植全部跑通。第一次移植完，先写个最小测试程序，确认挂载成功、能写能读，再逐步往业务上靠。遇到问题和网上文章描述不符时，优先怀疑硬件电路而非FatFs代码——毕竟这个库被用了几十年，逻辑出问题的概率比你自己接线出问题的概率低几个数量级。把底层裸读写验证跑扎实，后面文件系统的路会顺畅得多。
