裸机系列写到这里已经是第10篇了。前几篇我们把树莓派的GPIO、UART调试串口、SPI总线上的SD卡驱动都跑通了但冷静下来看之前所有代码都有一个共同的尴尬数据全靠硬编码在C数组里。哪怕只是想改一个启动参数都要重新编译烧录一次两次能忍次数一多是真的烦躁。这第10篇解决的就是这个问题在裸机环境下直接解析SD卡上的FAT文件系统让程序自己从TF卡里把指定文件找出来、读进内存。没有操作系统没有驱动框架没有现成的文件系统函库一切从字节层面开始抠。适合已经写过裸机UART或SPI、想往存储方向深入的同学也适合正在用树莓派做软核CPU项目、需要在板子上加载外部数据的人。我会按五块来讲先明确设计取舍为什么是FAT而不是别的文件系统然后完整拆解FAT32的磁盘布局和关键数据结构接着串一遍SD卡SPI模式的初始化与扇区读取再给出从扇区到文件的核心解析实现最后把一路踩过的坑整理成排查清单方便你直接对照。1. 设计取舍为什么裸机项目选择FAT并坚持手写解析1.1 FAT是SD卡的官方语言选择FAT不是因为它多先进恰恰是因为它足够笨。第一个原因非常现实SD卡物理规范在制定之初就把FAT列为默认文件系统市面上的卡出厂格式化基本都是FAT32或FAT16这意味着你的代码不需要做任何转换插一张普通TF卡就能跑。第二个原因更重要FAT的结构天生适合裸机环境。它没有复杂的日志没有ext系列那种inode位图没有权限系统整个文件系统的元数据就是一张簇号链加一组32字节的目录项逻辑上完全是线性的拿到扇区地址就能直接算。第三个原因和可验证性有关。ext4这类现代文件系统在断电恢复、碎片管理上做了大量工作复杂度远超一个裸机项目能承受的范畴。而FAT32的布局规则是公开且固定的你在电脑上格式化出来的卡片和你的裸机代码看到的字节结构完全一致。调试时可以把任何一个扇区拿到主机上对照这种能力对裸机开发来说是致命的友好。当然SPI模式下SD卡的理论速率只有25MHz谈不上性能但这套解析逻辑跑通后完全可以直接复用到更高速的SDHOST模式上。所以这步投入不亏它是后面所有存储相关功能的地基。1.2 分层架构让调试和扩展都轻松我把整套代码分成三层同心圆结构从里往外是SD卡扇区驱动、扇区缓存层、FAT解析层。为什么非要分层因为三层职责完全不同。SD驱动只负责给我第N个512字节块它不知道FAT是什么FAT解析层只负责给我文件XXX的内容它不关心数据是通过SPI轮询还是DMA搬回来的。这种拆分带来一个直接好处调试时可以单独替换任意一层。我一开始用的SD读取是纯轮询SPI后来优化成DMA传输FAT解析层一行没改重新编译后文件读取就正常工作了。反过来也一样如果FAT解析有bug完全可以在扇区缓存层打桩用一个内存数组模拟SD卡内容把解析逻辑单独验证清楚。分层的同时还要准备一个全局的扇区缓存池。FAT表项和目录项会被反复访问而SPI读取的代价相对高裸机下没有malloc我直接开了一个固定大小的二维数组uint8_t sd_cache[4][512]用最简单的多路组缓存思路来消抖。这个缓存的实现放在后面的代码里它虽然简陋但对性能提升是立竿见影的。1.3 先只读后写入风险可控第一版我坚持只做只读原因非常单纯写入需要处理FAT表项分配、目录项修改、写后校验还要考虑突然断电会不会破坏目录链这已经远远超出验证文件系统解析这个目标。只读方案面对的最坏情况就是读不到文件不会毁掉卡上的数据开发风险完全可控。等只读逻辑稳定后再扩展写入就顺理成章了。写入时需要的空闲簇扫描、FAT表修改、目录项更新本质上都建立在读的正确性之上——你得先能正确地定位一个空闲簇才能去修改FAT表项。所以这篇的只读实现是后续所有操作的地基花力气把它做扎实绝对值得。1.4 为什么不直接套用现成库有人可能会问明明有现成的开源FAT库直接移植过来不就行了这里有个容易被忽略的点那些库为了让代码跨平台内部大量使用堆内存、回调函数和多层抽象在裸机这种没有操作系统、没有动态内存分配的环境里移植成本往往比想象中高。而且它底层的disk_read接口还是得你自己写SD卡初始化、SPI时序这些真正容易出问题的部分一点都省不掉。自己做一遍还有个额外收益你可以完全控制代码的体量和行为。裸机Bootloader的场景通常只需要从固定路径读几个文件几十KB的精简实现比动辄几百KB的通用库好用得多。理解代价是必须把FAT的每个字段、每次偏移都抠清楚这个痛苦过程换来的底层认知是长期的资产。2. FAT32磁盘布局拆解BPB、FAT表、目录项2.1 BPB参数区动手前的体检表FAT32的一切都要从引导扇区说起。这个扇区开头是三字节跳转指令后面是一套被称为BPB的参数区。真正在裸机解析时需要读出来的参数其实不多就下面几个偏移长度字段典型值说明0x0B2每扇区字节数512基本固定但必须校验0x0D1每簇扇区数1/8/16/32决定簇大小0x0E2保留扇区数32第一个FAT表之前的扇区数0x101FAT表数量2一般有两份备份0x204总扇区数视容量FAT32必须从这读32位值0x244每FAT表扇区数视容量算FAT区域大小0x2C4根目录起始簇2FAT32才有比FAT16复杂在这这里有个典型新手坑FAT32的总扇区数必须从偏移0x20读32位而FAT16是从偏移0x13读16位两者位置完全不同。网上很多示例代码只读其中一个换一张大容量卡就翻车。我自己在代码里做了个判断如果0x13处是0且0x20不为0就按FAT32处理否则按FAT16处理。实际项目中需要同时兼容两种格式因为小容量卡出厂可能是FAT16。2.2 三个区域和簇链的核心公式拿到BPB参数后整个分区就被切成三段保留区、FAT区、数据区。保留区从分区起点开始连续reserved_sectors个扇区引导扇区和FSInfo扇区都在里面。接着是FAT区从reserved_sectors起共num_fats × sectors_per_fat个扇区。数据区则从FAT区末尾一直延伸到分区尽头。这三个区域的起止地址一旦算错后面所有簇计算全会偏所以我把它们作为结构体字段提前算好而不是每次都重新算。FAT表本身是一个巨大的数组每个表项在FAT32里占4字节但实际只用了低28位。一个簇号对应表项里存放的是这个簇的下一个簇号。这就是文件系统最核心的思想文件不是一块连续的数据而是一条通过FAT表串联起来的簇链。链的终点是0x0FFFFFF8以上的值读到这个范围就知道文件结束了。表中还有一些特殊值需要认识0x00000000表示空闲簇0x0FFFFFF7表示坏簇0x0FFFFFF8到0x0FFFFFFF都表示链结束。注意链结束不是只有一个值是一个区间代码里必须按范围判断不能只判断等于0x0FFFFFFF否则读到某些格式化工具写出的0x0FFFFFF8就会误判成错误。簇号到扇区地址的换算公式必须烂熟于心数据区起始扇区 (簇号 - 2) × 每簇扇区数。为什么要减2因为簇号0和1是保留的数据区第一个可用簇的编号从2开始。这个-2在刚写代码时很容易漏掉漏掉的结果就是所有文件内容整体偏移几个簇读出来的数据像乱码又像偏移特别迷惑。2.3 目录项与8.3文件名匹配规则目录本质上也是一个文件它的内容就是一条条32字节的目录项。FAT32的根目录不再是固定区域而是从BPB读到的根目录簇开始像普通文件一样通过FAT链串联。这就意味着目录可以无限增长也意味着遍历目录的逻辑和读取文件内容几乎一模一样。一个标准短文件名目录项的布局是这样的偏移长度字段0x008文件名主体不足8字节用空格补齐0x083扩展名同样补空格0x0B1属性字节0x0C1NT标志存放大小写信息0x142起始簇高16位FAT32使用0x1A2起始簇低16位0x1C4文件大小字节在裸机匹配文件名时比较的是原始的83字节。比如建立hello.txt目录里实际保存的是HELLO TXT文件名部分补了三个空格。如果你的查询字符串是helloTXT直接按字节比较必然失败这是最常见的匹配bug来源。正确做法是把查询名拆成主体和扩展名分别按8字节和3字节逐字节比较遇到空格就当成字符串结束处理。属性字节0x0B同样关键0x10表示目录0x20表示归档0x0F是长文件名条目。匹配文件时必须先检查这个字节否则会把长文件名条目误当成真实文件。另外要注意一件事目录项里的文件大小字段对目录来说通常是0遍历目录时不能迷信这个字段必须沿着FAT链一直走到链结束而不是读够多少字节就停。目录项第一个字节有特殊含义0x00表示目录到此结束后面不用看了0xE5表示这个目录项已被删除0x05表示历史上多字节字符的兼容标记要按0xE5处理。扫描目录时不处理这三种状态很容易在删除过文件的目录里反复捞到垃圾数据。2.4 长文件名条目识别出来然后跳过现代操作系统格式化出来的卡几乎每个文件都带长文件名条目。一个长文件名最多会被拆成若干条伪目录项每条固定32字节用UTF-16LE编码存13个字符第一个字节是序列号属性固定为0x0F排在对应短文件名目录项的前面。对于裸机只读场景我的建议是不解析只跳过。扫描目录时看到属性0x0F就跳过这条目录项一直扫到真正的短文件名目录项为止。这样简单可靠符合8.3规则的短名字在绝大多数场景下都能匹配到目标文件。真要完整解析长文件名还得处理UTF-16到UTF-8的转换、跨条目字符拼接、序列号排序和校验和验证投入产出比非常低。3. SD卡SPI模式初始化与扇区读取3.1 硬件连接与SPI参数准备树莓派的SPI0接口对应GPIO 8到11分别是CE0、MISO、MOSI、SCLK。SD卡工作电平是3.3V树莓派的GPIO恰好也是3.3V可以直接相连不需要电平转换。电源引脚需要注意用TF卡座时3.3V和GND线尽量粗短卡在读写瞬间电流比较大供电不良会造成初始化时好时坏这类硬件问题在软件层面几乎无法定位。这一篇直接复用前一篇已经调通的硬件SPI驱动模式选SPI Mode 0SPI时钟在初始化阶段先压到400kHz等卡片状态稳定后再提高到25MHz。为什么初始化必须慢SD卡上电后内部需要时间稳定SPI模式下对时钟频率有严格限制贸然用高速时钟发CMD0很多卡会直接无响应。这里的慢初始化、快传输是SD卡驱动的一个通用铁律建议做成两个独立的函数设置时钟方便切换。3.2 卡片初始化状态机SD卡的SPI模式初始化是一个状态机推进的过程顺序不能乱而且每个步骤都要有超时保护。标准序列如下拔高CS连续发送至少74个时钟脉冲让卡完成上电复位。多张卡共用SPI总线时这一步尤为关键。拉低CS发送CMD0参数0CRC 0x95这是唯一必须带正确CRC的命令因为此时卡还处在SD模式要靠这个命令切到SPI模式。收到响应0x01表示进入空闲状态。发送CMD8参数0x1AACRC 0x87用来识别SD V2.0以上卡。响应里会回传操作电压信息和check pattern必须和0x1AA对得上。循环发送CMD55加ACMD41参数带HCS位置位直到收到0x00表示初始化完成。这一步对老卡尤其容易超时必须设置合理的重试次数上限。发送CMD58读OCR寄存器确认工作电压范围和CCS标志确保操作的是SDHC卡而不是老式SDSC。发送CMD16设置扇区长度512字节。基础命令发送函数可以这么写static int sd_cmd(uint8_t cmd, uint32_t arg, uint8_t crc, uint8_t *resp) { uint8_t buf[6]; buf[0] cmd | 0x40; buf[1] arg 24; buf[2] arg 16; buf[3] arg 8; buf[4] arg; buf[5] crc; spi_tx(buf, 6); // 跳过前导0xFF等待有效响应最高位为0 for (int i 0; i 8; i) { uint8_t b spi_rw(0xFF); if ((b 0x80) 0) { *resp b; return 0; } } return -1; }注意进入SPI模式后CRC校验就关闭了后续命令的CRC字节可以随便填习惯上填0xFF。但CMD0和CMD8必须填正确的CRC值因为这时候卡还在SD模式错误CRC会直接导致命令无效。这个细节我建议在代码注释里写清楚防止日后重构时误删。ACMD41的循环等待是初始化里最容易出问题的地方。我的做法是给它一个独立的重试上限比如5000次每次间隔里发送CMD55再发ACMD41。如果超过上限还收不到0x00就拉高CS重新从CMD0开始整套流程而不是直接宣告失败。实际使用中个别卡第一次初始化确实会失败重新上电复位一次就能成功。3.3 单扇区读取与0xFE令牌陷阱初始化完成后读扇区就简单了。发送CMD17带目标扇区号等待0x00响应然后读取数据起始令牌0xFE接着连续读512字节最后再读2字节CRC丢掉。SPI模式下CRC由卡端计算裸机代码不需要校验。int sd_read_block(uint32_t block, uint8_t *dst) { uint8_t r, token; if (sd_cmd(0x11, block, 0xFF, r) ! 0 || r ! 0x00) return -1; // 等待数据起始令牌0xFE跳过所有0xFF填充字节 for (int i 0; i 20000; i) { token spi_rw(0xFF); if (token 0xFE) break; if (token 0x0F) return -1; // 数据错误错误卡 } if (token ! 0xFE) return -1; for (int i 0; i 512; i) dst[i] spi_rw(0xFF); spi_rw(0xFF); // CRC高字节丢弃 spi_rw(0xFF); // CRC低字节丢弃 return 0; }这个函数有一个非常容易踩的坑卡片在发送实际数据之前可能会插入若干个0xFF填充字节。所以你等0xFE令牌时必须用超时循环逐字节读把所有0xFF跳过去。如果天真地发完命令后立刻连读512字节整个扇区内容就会因为错开一两个字节而全部歪掉而且歪得毫无规律极难排查。我之前被这个问题坑了一个晚上最后是拿逻辑分析仪看波形才意识到少了跳过滤波的步骤。3.4 为什么不直接用GPIO模拟SPI有同学会问树莓派GPIO这么多直接软件模拟SPI不也能读卡吗确实能但没必要。软件模拟SPI每个字节要逐位翻转时钟和数据线在树莓派的CPU频率下虽然也能跑到几兆但占用的CPU时间非常多而且时钟抖动较大。SD卡这类设备对时序要求不算苛刻但数据量大时性能差距会很明显。更关键的是树莓派自带的硬件SPI外设配置起来并不复杂寄存器就那么几个前一篇已经准备好了。用硬件SPI还有一堆额外好处可以配置DMA自动搬运数据可以调整时钟极性相位可以设置片选极性。这些在后续做高速读取时都不用改上层代码只需要替换最底层的传输函数就行。4. FAT解析核心代码从扇区到文件的完整链路4.1 第一步识别MBR分区还是整体FAT进入FAT解析层第一件事是搞清楚手上的卡是什么布局。市面上有两种情况一种是大容量TF卡出厂带了MBR分区表FAT32分区从偏移2048扇区开始另一种是小容量卡或某些设备格式化出来的超级软盘整个卡就是一套FAT文件系统没有分区表。区分方法很简单读扇区0如果第511和512字节是0x55 0xAA再看偏移0x00到0x02是不是跳转指令头。如果是0xEB 0x?? 0x90或者0xE9那扇区0就是FAT引导扇区属于第二种如果不是跳转指令而是分区代码字节那就是MBR需要从偏移0x01BE开始读4个16字节的分区表项找到类型为0x0B或0x0C的条目FAT32对应类型用它的起始LBA作为FAT分区的起点。int detect_partition(uint32_t *part_lba) { uint8_t mbr[512]; if (sd_read_block(0, mbr) ! 0) return -1; // 直接就是FAT引导扇区跳转指令头 结束标志 if ((mbr[0] 0xEB mbr[2] 0x90) || mbr[0] 0xE9) return 0; // 否则按MBR解析找FAT32分区 for (int i 0; i 4; i) { uint8_t *pe mbr 0x1BE i * 16; if (pe[4] 0x0B || pe[4] 0x0C) { *part_lba rd_u32(pe 8); return 1; } } return -1; }这里必须强调MBR里的起始LBA是四字节小端而且单位是扇区不是字节偏移。很多新手直接把分区表里的数字当字节地址用结果读出来的全是空白。正确的做法是扇区号乘以512或者直接把扇区号传给接下来的读取函数。4.2 第二步BPB解析和小端读取确认分区起点后从起点读取引导扇区并解析BPB。我强烈建议用函数按字节拼接字段而不是把结构体指针强转成一个uint8_t*缓冲区。原因有两个一是ARM上未对齐的4字节读取会产生总线异常或者拿到错位值二是编译器结构体对齐规则可能导致从偏移0x20开始字段错位这种bug极难排查。手工拼字段哪怕多写两行换来的是稳定和可读。static uint16_t rd_u16(const uint8_t *p) { return (uint16_t)(p[0] | (p[1] 8)); } static uint32_t rd_u32(const uint8_t *p) { return (uint32_t)p[0] | ((uint32_t)p[1] 8) | ((uint32_t)p[2] 16) | ((uint32_t)p[3] 24); } typedef struct { uint16_t bytes_per_sector; uint8_t sectors_per_cluster; uint16_t reserved_sectors; uint8_t num_fats; uint32_t total_sectors; uint32_t sectors_per_fat; uint32_t root_cluster; uint32_t fat_start; uint32_t data_start; } fat32_t; int fs_init(fat32_t *fs, const uint8_t *bpb) { fs-bytes_per_sector rd_u16(bpb 0x0B); fs-sectors_per_cluster bpb[0x0D]; fs-reserved_sectors rd_u16(bpb 0x0E); fs-num_fats bpb[0x10]; fs-total_sectors rd_u32(bpb 0x20); fs-sectors_per_fat rd_u32(bpb 0x24); fs-root_cluster rd_u32(bpb 0x2C); if (fs-bytes_per_sector ! 512) return -1; fs-fat_start fs-reserved_sectors; fs-data_start fs-fat_start fs-num_fats * fs-sectors_per_fat; return 0; }注意FAT规范里几乎所有多字节字段都是小端序rd_u16和rd_u32直接按小端拼字节是对的。这个结构体把后续所有计算需要的参数都装好了fat_start和data_start都是相对分区起点的偏移后面所有读操作都要再加上分区起点重新定位。每簇扇区数决定了文件读取的批处理粒度FAT32大分区普遍是32个扇区一簇也就是16KB一簇读取大文件时以簇为单位连续读会比较高效。4.3 第三步FAT表项与簇链前进接下来是FAT表项读取也就是沿着簇链往下走的寻路函数。输入当前簇号输出下一个簇号。如果返回的值落在0x0FFFFFF8到0x0FFFFFFF之间说明链结束了。static const uint8_t *sd_get_sector(uint32_t sector) { static uint8_t cache[4][512]; static uint32_t tag[4]; static int way; for (int i 0; i 4; i) { if (tag[i] sector) return cache[i]; } if (sd_read_block(sector, cache[way]) ! 0) return NULL; tag[way] sector; const uint8_t *p cache[way]; way (way 1) 3; return p; } uint32_t fat_next_cluster(const fat32_t *fs, uint32_t part_base, uint32_t cluster) { uint32_t off cluster * 4; // FAT32表项4字节 uint32_t sec fs-fat_start part_base off / 512; const uint8_t *p sd_get_sector(sec); if (!p) return 0xFFFFFFFF; return rd_u32(p (off 511)) 0x0FFFFFFF; }这段代码里有几个关键点。第一FAT32表项虽然是4字节但一个扇区有512字节是128个表项的整数倍所以表项不会跨扇区边界off 511可以直接定位扇区内的字节偏移。第二 0x0FFFFFFF把高4位屏蔽掉因为FAT32规定只使用低28位。有些卡在高4位写了脏数据不屏蔽的话会把正常值污染成巨大数字。第三sd_get_sector做成返回缓存指针而不是拷贝数据可以减少一次内存复制但调用方要注意在再次调用sd_get_sector之前用完数据否则缓存可能被覆盖。4.4 第四步目录遍历与文件读取目录遍历本质上和读文件一样只是把目录当作数据内容来解析。先定位根目录簇uint32_t cluster fs-root_cluster;然后在一个循环里做三件事读取当前簇的全部扇区逐条扫描32字节目录项如果碰到0x00就返回目录结束遇到0xE5或0x0F就跳过遇到匹配的短文件名条目就取出起始簇号和文件大小。扫完整个簇还没有匹配项就沿FAT链取下一个簇继续直到链走到终点。typedef struct { uint32_t cluster; uint32_t size; } dir_entry_t; static int name8_match(const uint8_t *e, const char *name8, const char *ext3) { for (int i 0; i 8; i) { uint8_t c e[i]; if (c ) c 0; if (c ! (uint8_t)name8[i]) return 0; } for (int i 0; i 3; i) { uint8_t c e[8 i]; if (c ) c 0; if (c ! (uint8_t)ext3[i]) return 0; } return 1; } int fs_dir_find(const fat32_t *fs, uint32_t part_base, uint32_t dir_cluster, const char *name8, const char *ext3, dir_entry_t *out) { uint32_t cluster dir_cluster; while (cluster 0x0FFFFFF8) { uint32_t sec fs-data_start part_base (cluster - 2) * fs-sectors_per_cluster; for (uint32_t i 0; i fs-sectors_per_cluster; i) { const uint8_t *p sd_get_sector(sec i); if (!p) return -1; for (int off 0; off 512; off 32) { const uint8_t *e p off; if (e[0] 0x00) return 0; // 目录结束 if (e[0] 0xE5) continue; // 已删除条目 if (e[0x0B] 0x0F) continue; // 长文件名条目跳过 if (name8_match(e, name8, ext3)) { out-cluster (rd_u16(e 0x14) 16) | rd_u16(e 0x1A); out-size rd_u32(e 0x1C); return 1; } } } cluster fat_next_cluster(fs, part_base, cluster); if (cluster 0xFFFFFFFF || cluster 0) return -1; } return 0; }这个函数有几个细节值得琢磨。第一目录项第一字节是0x00代表整个目录结束注意返回0而不是返回-1表示目录正常但没有找到调用方可以把这两种情况区分开。第二文件名匹配把空格当结束符查询名在调用前需要拆好并转成大写因为卡上存的就是大写。第三起始簇号由高16位和低16位拼起来这在FAT32里才是正确的32位值只看低16位是最常见的错误。找到目录项后文件内容就是一条簇链。读取文件的方法也是一层循环先在内存里准备好目标缓冲然后从起始簇开始逐簇读取int file_to_buffer(const fat32_t *fs, uint32_t part_base, uint32_t cluster, uint32_t size, uint8_t *dst) { uint32_t remain size; while (remain 0) { uint32_t sec fs-data_start part_base (cluster - 2) * fs-sectors_per_cluster; uint32_t n remain; if (n fs-sectors_per_cluster * 512) n fs-sectors_per_cluster * 512; for (uint32_t i 0; i n; i 512) { const uint8_t *p sd_get_sector(sec i / 512); if (!p) return -1; memcpy(dst, p, 512); dst 512; } remain - n; if (remain 0) break; cluster fat_next_cluster(fs, part_base, cluster); if (cluster 0xFFFFFFFF || cluster 0x0FFFFFF8) return -1; } return 0; }这个函数的健壮性体现在两个边界一是文件大小按簇对齐最后一簇可能不满整簇长度但读取时按扇区整读拷贝到目标缓冲区时靠n控制数量避免越界写二是FAT链提前断了或者簇号异常必须给出明确错误返回而不是默默读完一串垃圾。路径解析建议做成最简单的逐级查找单级路径直接匹配根目录多级路径就先在根目录找到子目录项再以子目录的起始簇作为下一级目录的起点继续扫描。树莓派裸机场景通常只需要单级文件但保留逐级扩展对后续加载配置模块很有帮助。4.5 缓存层把读扇区次数降下来前面代码里反复用了sd_get_sector这里再单独讲一下缓存的设计。我的实现只有四路、每路512字节命中时直接返回缓存指针未命中才真正发起SPI读。为什么四路就够因为FAT解析的访存模式非常局部同一时刻你只会在若干个位置之间跳来跳去——当前数据扇区、当前FAT扇区、当前目录扇区。四路缓存能覆盖绝大多数场景。实际测试中读取一个分布在几百个簇的文件FAT扇区的读取次数从几百次降到了十几次提升非常明显。但要注意这个缓存没有处理脏数据的概念纯只读场景完全没问题一旦要写文件缓存就需要加入写回或失效机制否则会出现读到旧数据的诡异问题。写实现之前一定要先把这层想清楚。5. 踩坑记录问题速查与调试三板斧5.1 最常见的六个问题实操过程中遇到的问题我整理成一张速查表你遇到类似现象可以直接对照现象直接原因解决思路初始化卡在ACMD41重试超时上电时序不够或供电不稳增加74时钟脉冲检查3.3V供电电容降低初始化时钟读扇区返回数据全部错位没跳过0xFF填充字节读0xFE令牌时用超时循环逐字节处理文件匹配失败8.3名字的空格补齐没处理查询名拆成83空格视为结尾读出的内容缺少后半段FAT链断在0x0FFFFFFF之前打印每次fat_next_cluster返回值对照卡上实际FAT表读到全是0xFFCS引脚时序或SPI模式错误确认SPI Mode 0检查CS是否在命令期间保持低电平大容量卡解析不正确按FAT16偏移读了FAT32字段总扇区数必须从0x20读32位从0x13只适合FAT16这里面最隐蔽的是第一个问题。卡的初始化失败不一定是你代码错多半是上电时序不满足要求或者SPI时钟在初始化阶段就拉得太高。有一张老卡25MHz下ACMD41永远超时改成400kHz初始化后一次通过之后再提频到25MHz做数据传输完全正常。所以慢初始化、快传输不是一句空话。5.2 调试三板斧对拍、日志、最小测试卡遇到解析问题我最常用的手段不是单步调试而是三方对拍。所谓三方就是裸机端的十六进制输出、主机端挂载后读出的同一扇区、以及代码里实际的解析结果。具体操作分三步先在裸机端把怀疑出错的扇区内容通过UART打出来然后在主机上把这张卡挂载后用十六进制工具直接查看同一个物理扇区的原始字节最后比对两份数据。哪边不一样问题就锁定在哪一侧。这个方法在定位FAT表项计算和目录项偏移问题时效率极高基本上一次对拍就能确认是读错了扇区还是算错了偏移。第二个技巧是给每一步关键计算结果加断言式日志。解析BPB后把fat_start、data_start、root_cluster全部打印出来和主机上看到的数值比对一遍。很多看起来玄妙的找不到文件问题最后都是data_start算错了一位导致所有簇地址整体偏移。日志打印会占用不少UART带宽但对调试的回报远超这点开销。第三个技巧是准备一张最小测试卡。我专门准备了一张200MB左右的小卡格式化后只在根目录放一个文件名极短、内容极简单的测试文件。小卡结构简单没有长文件名干扰簇数量也少非常适合作为初始验证环境。等裸机代码在这张卡上跑通了再换真实场景的大卡和复杂目录结构。如果你直接拿一张128GB的卡上来就调LFN条目和巨大FAT表会让每个问题都叠加在一起根本没法定位。5.3 性能优化方向和写入扩展最后聊一点性能。SPI模式下单扇区读取本身已经很快瓶颈主要在逐字节的状态轮询上。如果对速度有更高要求可以把底层的sd_read_block换成DMA驱动的多块读取一次读多个扇区FAT解析逻辑完全不用动。树莓派硬件SPI支持DMA请求配置好后CPU几乎不参与数据搬运大文件读取性能能翻好几倍。后续如果要做文件写入需要补三块内容空闲簇扫描、FAT表项回写、目录项追加。空闲簇扫描就是遍历FAT表找到值为0的表项回写FAT表要注意规范里的先写第一份再写第二份备份的顺序目录项追加则要处理目录已满就扩展新簇的逻辑。这三块全部建立在本文的只读解析之上先把读取链路理解透彻写操作只是在骨架上添肉。我个人在这套代码实现完后最大的体会是文件系统真不神秘剥开层层封装后就是一张表加一堆编号。裸机环境下没有现成库可用反而逼着你把FAT的每一个字节、每一次偏移都抠清楚这个过程虽然痛苦但对底层理解的好处是长期的。以后不管是给软核CPU写启动加载器还是做裸机数据采集存储这套读扇区、查FAT、取文件的思路都能直接复用。如果还想继续往下玩建议试试给代码加上递归目录遍历实现一个基础的ls命令或者更进一步把FAT写入实现出来让裸机程序拥有在SD卡上记录运行日志的能力。那样的话这个裸机系列才真正算是在存储方向上开出花来了。
裸机系列写到这里已经是第10篇了。前几篇我们把树莓派的GPIO、UART调试串口、SPI总线上的SD卡驱动都跑通了但冷静下来看之前所有代码都有一个共同的尴尬数据全靠硬编码在C数组里。哪怕只是想改一个启动参数都要重新编译烧录一次两次能忍次数一多是真的烦躁。这第10篇解决的就是这个问题在裸机环境下直接解析SD卡上的FAT文件系统让程序自己从TF卡里把指定文件找出来、读进内存。没有操作系统没有驱动框架没有现成的文件系统函库一切从字节层面开始抠。适合已经写过裸机UART或SPI、想往存储方向深入的同学也适合正在用树莓派做软核CPU项目、需要在板子上加载外部数据的人。我会按五块来讲先明确设计取舍为什么是FAT而不是别的文件系统然后完整拆解FAT32的磁盘布局和关键数据结构接着串一遍SD卡SPI模式的初始化与扇区读取再给出从扇区到文件的核心解析实现最后把一路踩过的坑整理成排查清单方便你直接对照。1. 设计取舍为什么裸机项目选择FAT并坚持手写解析1.1 FAT是SD卡的官方语言选择FAT不是因为它多先进恰恰是因为它足够笨。第一个原因非常现实SD卡物理规范在制定之初就把FAT列为默认文件系统市面上的卡出厂格式化基本都是FAT32或FAT16这意味着你的代码不需要做任何转换插一张普通TF卡就能跑。第二个原因更重要FAT的结构天生适合裸机环境。它没有复杂的日志没有ext系列那种inode位图没有权限系统整个文件系统的元数据就是一张簇号链加一组32字节的目录项逻辑上完全是线性的拿到扇区地址就能直接算。第三个原因和可验证性有关。ext4这类现代文件系统在断电恢复、碎片管理上做了大量工作复杂度远超一个裸机项目能承受的范畴。而FAT32的布局规则是公开且固定的你在电脑上格式化出来的卡片和你的裸机代码看到的字节结构完全一致。调试时可以把任何一个扇区拿到主机上对照这种能力对裸机开发来说是致命的友好。当然SPI模式下SD卡的理论速率只有25MHz谈不上性能但这套解析逻辑跑通后完全可以直接复用到更高速的SDHOST模式上。所以这步投入不亏它是后面所有存储相关功能的地基。1.2 分层架构让调试和扩展都轻松我把整套代码分成三层同心圆结构从里往外是SD卡扇区驱动、扇区缓存层、FAT解析层。为什么非要分层因为三层职责完全不同。SD驱动只负责给我第N个512字节块它不知道FAT是什么FAT解析层只负责给我文件XXX的内容它不关心数据是通过SPI轮询还是DMA搬回来的。这种拆分带来一个直接好处调试时可以单独替换任意一层。我一开始用的SD读取是纯轮询SPI后来优化成DMA传输FAT解析层一行没改重新编译后文件读取就正常工作了。反过来也一样如果FAT解析有bug完全可以在扇区缓存层打桩用一个内存数组模拟SD卡内容把解析逻辑单独验证清楚。分层的同时还要准备一个全局的扇区缓存池。FAT表项和目录项会被反复访问而SPI读取的代价相对高裸机下没有malloc我直接开了一个固定大小的二维数组uint8_t sd_cache[4][512]用最简单的多路组缓存思路来消抖。这个缓存的实现放在后面的代码里它虽然简陋但对性能提升是立竿见影的。1.3 先只读后写入风险可控第一版我坚持只做只读原因非常单纯写入需要处理FAT表项分配、目录项修改、写后校验还要考虑突然断电会不会破坏目录链这已经远远超出验证文件系统解析这个目标。只读方案面对的最坏情况就是读不到文件不会毁掉卡上的数据开发风险完全可控。等只读逻辑稳定后再扩展写入就顺理成章了。写入时需要的空闲簇扫描、FAT表修改、目录项更新本质上都建立在读的正确性之上——你得先能正确地定位一个空闲簇才能去修改FAT表项。所以这篇的只读实现是后续所有操作的地基花力气把它做扎实绝对值得。1.4 为什么不直接套用现成库有人可能会问明明有现成的开源FAT库直接移植过来不就行了这里有个容易被忽略的点那些库为了让代码跨平台内部大量使用堆内存、回调函数和多层抽象在裸机这种没有操作系统、没有动态内存分配的环境里移植成本往往比想象中高。而且它底层的disk_read接口还是得你自己写SD卡初始化、SPI时序这些真正容易出问题的部分一点都省不掉。自己做一遍还有个额外收益你可以完全控制代码的体量和行为。裸机Bootloader的场景通常只需要从固定路径读几个文件几十KB的精简实现比动辄几百KB的通用库好用得多。理解代价是必须把FAT的每个字段、每次偏移都抠清楚这个痛苦过程换来的底层认知是长期的资产。2. FAT32磁盘布局拆解BPB、FAT表、目录项2.1 BPB参数区动手前的体检表FAT32的一切都要从引导扇区说起。这个扇区开头是三字节跳转指令后面是一套被称为BPB的参数区。真正在裸机解析时需要读出来的参数其实不多就下面几个偏移长度字段典型值说明0x0B2每扇区字节数512基本固定但必须校验0x0D1每簇扇区数1/8/16/32决定簇大小0x0E2保留扇区数32第一个FAT表之前的扇区数0x101FAT表数量2一般有两份备份0x204总扇区数视容量FAT32必须从这读32位值0x244每FAT表扇区数视容量算FAT区域大小0x2C4根目录起始簇2FAT32才有比FAT16复杂在这这里有个典型新手坑FAT32的总扇区数必须从偏移0x20读32位而FAT16是从偏移0x13读16位两者位置完全不同。网上很多示例代码只读其中一个换一张大容量卡就翻车。我自己在代码里做了个判断如果0x13处是0且0x20不为0就按FAT32处理否则按FAT16处理。实际项目中需要同时兼容两种格式因为小容量卡出厂可能是FAT16。2.2 三个区域和簇链的核心公式拿到BPB参数后整个分区就被切成三段保留区、FAT区、数据区。保留区从分区起点开始连续reserved_sectors个扇区引导扇区和FSInfo扇区都在里面。接着是FAT区从reserved_sectors起共num_fats × sectors_per_fat个扇区。数据区则从FAT区末尾一直延伸到分区尽头。这三个区域的起止地址一旦算错后面所有簇计算全会偏所以我把它们作为结构体字段提前算好而不是每次都重新算。FAT表本身是一个巨大的数组每个表项在FAT32里占4字节但实际只用了低28位。一个簇号对应表项里存放的是这个簇的下一个簇号。这就是文件系统最核心的思想文件不是一块连续的数据而是一条通过FAT表串联起来的簇链。链的终点是0x0FFFFFF8以上的值读到这个范围就知道文件结束了。表中还有一些特殊值需要认识0x00000000表示空闲簇0x0FFFFFF7表示坏簇0x0FFFFFF8到0x0FFFFFFF都表示链结束。注意链结束不是只有一个值是一个区间代码里必须按范围判断不能只判断等于0x0FFFFFFF否则读到某些格式化工具写出的0x0FFFFFF8就会误判成错误。簇号到扇区地址的换算公式必须烂熟于心数据区起始扇区 (簇号 - 2) × 每簇扇区数。为什么要减2因为簇号0和1是保留的数据区第一个可用簇的编号从2开始。这个-2在刚写代码时很容易漏掉漏掉的结果就是所有文件内容整体偏移几个簇读出来的数据像乱码又像偏移特别迷惑。2.3 目录项与8.3文件名匹配规则目录本质上也是一个文件它的内容就是一条条32字节的目录项。FAT32的根目录不再是固定区域而是从BPB读到的根目录簇开始像普通文件一样通过FAT链串联。这就意味着目录可以无限增长也意味着遍历目录的逻辑和读取文件内容几乎一模一样。一个标准短文件名目录项的布局是这样的偏移长度字段0x008文件名主体不足8字节用空格补齐0x083扩展名同样补空格0x0B1属性字节0x0C1NT标志存放大小写信息0x142起始簇高16位FAT32使用0x1A2起始簇低16位0x1C4文件大小字节在裸机匹配文件名时比较的是原始的83字节。比如建立hello.txt目录里实际保存的是HELLO TXT文件名部分补了三个空格。如果你的查询字符串是helloTXT直接按字节比较必然失败这是最常见的匹配bug来源。正确做法是把查询名拆成主体和扩展名分别按8字节和3字节逐字节比较遇到空格就当成字符串结束处理。属性字节0x0B同样关键0x10表示目录0x20表示归档0x0F是长文件名条目。匹配文件时必须先检查这个字节否则会把长文件名条目误当成真实文件。另外要注意一件事目录项里的文件大小字段对目录来说通常是0遍历目录时不能迷信这个字段必须沿着FAT链一直走到链结束而不是读够多少字节就停。目录项第一个字节有特殊含义0x00表示目录到此结束后面不用看了0xE5表示这个目录项已被删除0x05表示历史上多字节字符的兼容标记要按0xE5处理。扫描目录时不处理这三种状态很容易在删除过文件的目录里反复捞到垃圾数据。2.4 长文件名条目识别出来然后跳过现代操作系统格式化出来的卡几乎每个文件都带长文件名条目。一个长文件名最多会被拆成若干条伪目录项每条固定32字节用UTF-16LE编码存13个字符第一个字节是序列号属性固定为0x0F排在对应短文件名目录项的前面。对于裸机只读场景我的建议是不解析只跳过。扫描目录时看到属性0x0F就跳过这条目录项一直扫到真正的短文件名目录项为止。这样简单可靠符合8.3规则的短名字在绝大多数场景下都能匹配到目标文件。真要完整解析长文件名还得处理UTF-16到UTF-8的转换、跨条目字符拼接、序列号排序和校验和验证投入产出比非常低。3. SD卡SPI模式初始化与扇区读取3.1 硬件连接与SPI参数准备树莓派的SPI0接口对应GPIO 8到11分别是CE0、MISO、MOSI、SCLK。SD卡工作电平是3.3V树莓派的GPIO恰好也是3.3V可以直接相连不需要电平转换。电源引脚需要注意用TF卡座时3.3V和GND线尽量粗短卡在读写瞬间电流比较大供电不良会造成初始化时好时坏这类硬件问题在软件层面几乎无法定位。这一篇直接复用前一篇已经调通的硬件SPI驱动模式选SPI Mode 0SPI时钟在初始化阶段先压到400kHz等卡片状态稳定后再提高到25MHz。为什么初始化必须慢SD卡上电后内部需要时间稳定SPI模式下对时钟频率有严格限制贸然用高速时钟发CMD0很多卡会直接无响应。这里的慢初始化、快传输是SD卡驱动的一个通用铁律建议做成两个独立的函数设置时钟方便切换。3.2 卡片初始化状态机SD卡的SPI模式初始化是一个状态机推进的过程顺序不能乱而且每个步骤都要有超时保护。标准序列如下拔高CS连续发送至少74个时钟脉冲让卡完成上电复位。多张卡共用SPI总线时这一步尤为关键。拉低CS发送CMD0参数0CRC 0x95这是唯一必须带正确CRC的命令因为此时卡还处在SD模式要靠这个命令切到SPI模式。收到响应0x01表示进入空闲状态。发送CMD8参数0x1AACRC 0x87用来识别SD V2.0以上卡。响应里会回传操作电压信息和check pattern必须和0x1AA对得上。循环发送CMD55加ACMD41参数带HCS位置位直到收到0x00表示初始化完成。这一步对老卡尤其容易超时必须设置合理的重试次数上限。发送CMD58读OCR寄存器确认工作电压范围和CCS标志确保操作的是SDHC卡而不是老式SDSC。发送CMD16设置扇区长度512字节。基础命令发送函数可以这么写static int sd_cmd(uint8_t cmd, uint32_t arg, uint8_t crc, uint8_t *resp) { uint8_t buf[6]; buf[0] cmd | 0x40; buf[1] arg 24; buf[2] arg 16; buf[3] arg 8; buf[4] arg; buf[5] crc; spi_tx(buf, 6); // 跳过前导0xFF等待有效响应最高位为0 for (int i 0; i 8; i) { uint8_t b spi_rw(0xFF); if ((b 0x80) 0) { *resp b; return 0; } } return -1; }注意进入SPI模式后CRC校验就关闭了后续命令的CRC字节可以随便填习惯上填0xFF。但CMD0和CMD8必须填正确的CRC值因为这时候卡还在SD模式错误CRC会直接导致命令无效。这个细节我建议在代码注释里写清楚防止日后重构时误删。ACMD41的循环等待是初始化里最容易出问题的地方。我的做法是给它一个独立的重试上限比如5000次每次间隔里发送CMD55再发ACMD41。如果超过上限还收不到0x00就拉高CS重新从CMD0开始整套流程而不是直接宣告失败。实际使用中个别卡第一次初始化确实会失败重新上电复位一次就能成功。3.3 单扇区读取与0xFE令牌陷阱初始化完成后读扇区就简单了。发送CMD17带目标扇区号等待0x00响应然后读取数据起始令牌0xFE接着连续读512字节最后再读2字节CRC丢掉。SPI模式下CRC由卡端计算裸机代码不需要校验。int sd_read_block(uint32_t block, uint8_t *dst) { uint8_t r, token; if (sd_cmd(0x11, block, 0xFF, r) ! 0 || r ! 0x00) return -1; // 等待数据起始令牌0xFE跳过所有0xFF填充字节 for (int i 0; i 20000; i) { token spi_rw(0xFF); if (token 0xFE) break; if (token 0x0F) return -1; // 数据错误错误卡 } if (token ! 0xFE) return -1; for (int i 0; i 512; i) dst[i] spi_rw(0xFF); spi_rw(0xFF); // CRC高字节丢弃 spi_rw(0xFF); // CRC低字节丢弃 return 0; }这个函数有一个非常容易踩的坑卡片在发送实际数据之前可能会插入若干个0xFF填充字节。所以你等0xFE令牌时必须用超时循环逐字节读把所有0xFF跳过去。如果天真地发完命令后立刻连读512字节整个扇区内容就会因为错开一两个字节而全部歪掉而且歪得毫无规律极难排查。我之前被这个问题坑了一个晚上最后是拿逻辑分析仪看波形才意识到少了跳过滤波的步骤。3.4 为什么不直接用GPIO模拟SPI有同学会问树莓派GPIO这么多直接软件模拟SPI不也能读卡吗确实能但没必要。软件模拟SPI每个字节要逐位翻转时钟和数据线在树莓派的CPU频率下虽然也能跑到几兆但占用的CPU时间非常多而且时钟抖动较大。SD卡这类设备对时序要求不算苛刻但数据量大时性能差距会很明显。更关键的是树莓派自带的硬件SPI外设配置起来并不复杂寄存器就那么几个前一篇已经准备好了。用硬件SPI还有一堆额外好处可以配置DMA自动搬运数据可以调整时钟极性相位可以设置片选极性。这些在后续做高速读取时都不用改上层代码只需要替换最底层的传输函数就行。4. FAT解析核心代码从扇区到文件的完整链路4.1 第一步识别MBR分区还是整体FAT进入FAT解析层第一件事是搞清楚手上的卡是什么布局。市面上有两种情况一种是大容量TF卡出厂带了MBR分区表FAT32分区从偏移2048扇区开始另一种是小容量卡或某些设备格式化出来的超级软盘整个卡就是一套FAT文件系统没有分区表。区分方法很简单读扇区0如果第511和512字节是0x55 0xAA再看偏移0x00到0x02是不是跳转指令头。如果是0xEB 0x?? 0x90或者0xE9那扇区0就是FAT引导扇区属于第二种如果不是跳转指令而是分区代码字节那就是MBR需要从偏移0x01BE开始读4个16字节的分区表项找到类型为0x0B或0x0C的条目FAT32对应类型用它的起始LBA作为FAT分区的起点。int detect_partition(uint32_t *part_lba) { uint8_t mbr[512]; if (sd_read_block(0, mbr) ! 0) return -1; // 直接就是FAT引导扇区跳转指令头 结束标志 if ((mbr[0] 0xEB mbr[2] 0x90) || mbr[0] 0xE9) return 0; // 否则按MBR解析找FAT32分区 for (int i 0; i 4; i) { uint8_t *pe mbr 0x1BE i * 16; if (pe[4] 0x0B || pe[4] 0x0C) { *part_lba rd_u32(pe 8); return 1; } } return -1; }这里必须强调MBR里的起始LBA是四字节小端而且单位是扇区不是字节偏移。很多新手直接把分区表里的数字当字节地址用结果读出来的全是空白。正确的做法是扇区号乘以512或者直接把扇区号传给接下来的读取函数。4.2 第二步BPB解析和小端读取确认分区起点后从起点读取引导扇区并解析BPB。我强烈建议用函数按字节拼接字段而不是把结构体指针强转成一个uint8_t*缓冲区。原因有两个一是ARM上未对齐的4字节读取会产生总线异常或者拿到错位值二是编译器结构体对齐规则可能导致从偏移0x20开始字段错位这种bug极难排查。手工拼字段哪怕多写两行换来的是稳定和可读。static uint16_t rd_u16(const uint8_t *p) { return (uint16_t)(p[0] | (p[1] 8)); } static uint32_t rd_u32(const uint8_t *p) { return (uint32_t)p[0] | ((uint32_t)p[1] 8) | ((uint32_t)p[2] 16) | ((uint32_t)p[3] 24); } typedef struct { uint16_t bytes_per_sector; uint8_t sectors_per_cluster; uint16_t reserved_sectors; uint8_t num_fats; uint32_t total_sectors; uint32_t sectors_per_fat; uint32_t root_cluster; uint32_t fat_start; uint32_t data_start; } fat32_t; int fs_init(fat32_t *fs, const uint8_t *bpb) { fs-bytes_per_sector rd_u16(bpb 0x0B); fs-sectors_per_cluster bpb[0x0D]; fs-reserved_sectors rd_u16(bpb 0x0E); fs-num_fats bpb[0x10]; fs-total_sectors rd_u32(bpb 0x20); fs-sectors_per_fat rd_u32(bpb 0x24); fs-root_cluster rd_u32(bpb 0x2C); if (fs-bytes_per_sector ! 512) return -1; fs-fat_start fs-reserved_sectors; fs-data_start fs-fat_start fs-num_fats * fs-sectors_per_fat; return 0; }注意FAT规范里几乎所有多字节字段都是小端序rd_u16和rd_u32直接按小端拼字节是对的。这个结构体把后续所有计算需要的参数都装好了fat_start和data_start都是相对分区起点的偏移后面所有读操作都要再加上分区起点重新定位。每簇扇区数决定了文件读取的批处理粒度FAT32大分区普遍是32个扇区一簇也就是16KB一簇读取大文件时以簇为单位连续读会比较高效。4.3 第三步FAT表项与簇链前进接下来是FAT表项读取也就是沿着簇链往下走的寻路函数。输入当前簇号输出下一个簇号。如果返回的值落在0x0FFFFFF8到0x0FFFFFFF之间说明链结束了。static const uint8_t *sd_get_sector(uint32_t sector) { static uint8_t cache[4][512]; static uint32_t tag[4]; static int way; for (int i 0; i 4; i) { if (tag[i] sector) return cache[i]; } if (sd_read_block(sector, cache[way]) ! 0) return NULL; tag[way] sector; const uint8_t *p cache[way]; way (way 1) 3; return p; } uint32_t fat_next_cluster(const fat32_t *fs, uint32_t part_base, uint32_t cluster) { uint32_t off cluster * 4; // FAT32表项4字节 uint32_t sec fs-fat_start part_base off / 512; const uint8_t *p sd_get_sector(sec); if (!p) return 0xFFFFFFFF; return rd_u32(p (off 511)) 0x0FFFFFFF; }这段代码里有几个关键点。第一FAT32表项虽然是4字节但一个扇区有512字节是128个表项的整数倍所以表项不会跨扇区边界off 511可以直接定位扇区内的字节偏移。第二 0x0FFFFFFF把高4位屏蔽掉因为FAT32规定只使用低28位。有些卡在高4位写了脏数据不屏蔽的话会把正常值污染成巨大数字。第三sd_get_sector做成返回缓存指针而不是拷贝数据可以减少一次内存复制但调用方要注意在再次调用sd_get_sector之前用完数据否则缓存可能被覆盖。4.4 第四步目录遍历与文件读取目录遍历本质上和读文件一样只是把目录当作数据内容来解析。先定位根目录簇uint32_t cluster fs-root_cluster;然后在一个循环里做三件事读取当前簇的全部扇区逐条扫描32字节目录项如果碰到0x00就返回目录结束遇到0xE5或0x0F就跳过遇到匹配的短文件名条目就取出起始簇号和文件大小。扫完整个簇还没有匹配项就沿FAT链取下一个簇继续直到链走到终点。typedef struct { uint32_t cluster; uint32_t size; } dir_entry_t; static int name8_match(const uint8_t *e, const char *name8, const char *ext3) { for (int i 0; i 8; i) { uint8_t c e[i]; if (c ) c 0; if (c ! (uint8_t)name8[i]) return 0; } for (int i 0; i 3; i) { uint8_t c e[8 i]; if (c ) c 0; if (c ! (uint8_t)ext3[i]) return 0; } return 1; } int fs_dir_find(const fat32_t *fs, uint32_t part_base, uint32_t dir_cluster, const char *name8, const char *ext3, dir_entry_t *out) { uint32_t cluster dir_cluster; while (cluster 0x0FFFFFF8) { uint32_t sec fs-data_start part_base (cluster - 2) * fs-sectors_per_cluster; for (uint32_t i 0; i fs-sectors_per_cluster; i) { const uint8_t *p sd_get_sector(sec i); if (!p) return -1; for (int off 0; off 512; off 32) { const uint8_t *e p off; if (e[0] 0x00) return 0; // 目录结束 if (e[0] 0xE5) continue; // 已删除条目 if (e[0x0B] 0x0F) continue; // 长文件名条目跳过 if (name8_match(e, name8, ext3)) { out-cluster (rd_u16(e 0x14) 16) | rd_u16(e 0x1A); out-size rd_u32(e 0x1C); return 1; } } } cluster fat_next_cluster(fs, part_base, cluster); if (cluster 0xFFFFFFFF || cluster 0) return -1; } return 0; }这个函数有几个细节值得琢磨。第一目录项第一字节是0x00代表整个目录结束注意返回0而不是返回-1表示目录正常但没有找到调用方可以把这两种情况区分开。第二文件名匹配把空格当结束符查询名在调用前需要拆好并转成大写因为卡上存的就是大写。第三起始簇号由高16位和低16位拼起来这在FAT32里才是正确的32位值只看低16位是最常见的错误。找到目录项后文件内容就是一条簇链。读取文件的方法也是一层循环先在内存里准备好目标缓冲然后从起始簇开始逐簇读取int file_to_buffer(const fat32_t *fs, uint32_t part_base, uint32_t cluster, uint32_t size, uint8_t *dst) { uint32_t remain size; while (remain 0) { uint32_t sec fs-data_start part_base (cluster - 2) * fs-sectors_per_cluster; uint32_t n remain; if (n fs-sectors_per_cluster * 512) n fs-sectors_per_cluster * 512; for (uint32_t i 0; i n; i 512) { const uint8_t *p sd_get_sector(sec i / 512); if (!p) return -1; memcpy(dst, p, 512); dst 512; } remain - n; if (remain 0) break; cluster fat_next_cluster(fs, part_base, cluster); if (cluster 0xFFFFFFFF || cluster 0x0FFFFFF8) return -1; } return 0; }这个函数的健壮性体现在两个边界一是文件大小按簇对齐最后一簇可能不满整簇长度但读取时按扇区整读拷贝到目标缓冲区时靠n控制数量避免越界写二是FAT链提前断了或者簇号异常必须给出明确错误返回而不是默默读完一串垃圾。路径解析建议做成最简单的逐级查找单级路径直接匹配根目录多级路径就先在根目录找到子目录项再以子目录的起始簇作为下一级目录的起点继续扫描。树莓派裸机场景通常只需要单级文件但保留逐级扩展对后续加载配置模块很有帮助。4.5 缓存层把读扇区次数降下来前面代码里反复用了sd_get_sector这里再单独讲一下缓存的设计。我的实现只有四路、每路512字节命中时直接返回缓存指针未命中才真正发起SPI读。为什么四路就够因为FAT解析的访存模式非常局部同一时刻你只会在若干个位置之间跳来跳去——当前数据扇区、当前FAT扇区、当前目录扇区。四路缓存能覆盖绝大多数场景。实际测试中读取一个分布在几百个簇的文件FAT扇区的读取次数从几百次降到了十几次提升非常明显。但要注意这个缓存没有处理脏数据的概念纯只读场景完全没问题一旦要写文件缓存就需要加入写回或失效机制否则会出现读到旧数据的诡异问题。写实现之前一定要先把这层想清楚。5. 踩坑记录问题速查与调试三板斧5.1 最常见的六个问题实操过程中遇到的问题我整理成一张速查表你遇到类似现象可以直接对照现象直接原因解决思路初始化卡在ACMD41重试超时上电时序不够或供电不稳增加74时钟脉冲检查3.3V供电电容降低初始化时钟读扇区返回数据全部错位没跳过0xFF填充字节读0xFE令牌时用超时循环逐字节处理文件匹配失败8.3名字的空格补齐没处理查询名拆成83空格视为结尾读出的内容缺少后半段FAT链断在0x0FFFFFFF之前打印每次fat_next_cluster返回值对照卡上实际FAT表读到全是0xFFCS引脚时序或SPI模式错误确认SPI Mode 0检查CS是否在命令期间保持低电平大容量卡解析不正确按FAT16偏移读了FAT32字段总扇区数必须从0x20读32位从0x13只适合FAT16这里面最隐蔽的是第一个问题。卡的初始化失败不一定是你代码错多半是上电时序不满足要求或者SPI时钟在初始化阶段就拉得太高。有一张老卡25MHz下ACMD41永远超时改成400kHz初始化后一次通过之后再提频到25MHz做数据传输完全正常。所以慢初始化、快传输不是一句空话。5.2 调试三板斧对拍、日志、最小测试卡遇到解析问题我最常用的手段不是单步调试而是三方对拍。所谓三方就是裸机端的十六进制输出、主机端挂载后读出的同一扇区、以及代码里实际的解析结果。具体操作分三步先在裸机端把怀疑出错的扇区内容通过UART打出来然后在主机上把这张卡挂载后用十六进制工具直接查看同一个物理扇区的原始字节最后比对两份数据。哪边不一样问题就锁定在哪一侧。这个方法在定位FAT表项计算和目录项偏移问题时效率极高基本上一次对拍就能确认是读错了扇区还是算错了偏移。第二个技巧是给每一步关键计算结果加断言式日志。解析BPB后把fat_start、data_start、root_cluster全部打印出来和主机上看到的数值比对一遍。很多看起来玄妙的找不到文件问题最后都是data_start算错了一位导致所有簇地址整体偏移。日志打印会占用不少UART带宽但对调试的回报远超这点开销。第三个技巧是准备一张最小测试卡。我专门准备了一张200MB左右的小卡格式化后只在根目录放一个文件名极短、内容极简单的测试文件。小卡结构简单没有长文件名干扰簇数量也少非常适合作为初始验证环境。等裸机代码在这张卡上跑通了再换真实场景的大卡和复杂目录结构。如果你直接拿一张128GB的卡上来就调LFN条目和巨大FAT表会让每个问题都叠加在一起根本没法定位。5.3 性能优化方向和写入扩展最后聊一点性能。SPI模式下单扇区读取本身已经很快瓶颈主要在逐字节的状态轮询上。如果对速度有更高要求可以把底层的sd_read_block换成DMA驱动的多块读取一次读多个扇区FAT解析逻辑完全不用动。树莓派硬件SPI支持DMA请求配置好后CPU几乎不参与数据搬运大文件读取性能能翻好几倍。后续如果要做文件写入需要补三块内容空闲簇扫描、FAT表项回写、目录项追加。空闲簇扫描就是遍历FAT表找到值为0的表项回写FAT表要注意规范里的先写第一份再写第二份备份的顺序目录项追加则要处理目录已满就扩展新簇的逻辑。这三块全部建立在本文的只读解析之上先把读取链路理解透彻写操作只是在骨架上添肉。我个人在这套代码实现完后最大的体会是文件系统真不神秘剥开层层封装后就是一张表加一堆编号。裸机环境下没有现成库可用反而逼着你把FAT的每一个字节、每一次偏移都抠清楚这个过程虽然痛苦但对底层理解的好处是长期的。以后不管是给软核CPU写启动加载器还是做裸机数据采集存储这套读扇区、查FAT、取文件的思路都能直接复用。如果还想继续往下玩建议试试给代码加上递归目录遍历实现一个基础的ls命令或者更进一步把FAT写入实现出来让裸机程序拥有在SD卡上记录运行日志的能力。那样的话这个裸机系列才真正算是在存储方向上开出花来了。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
