当前位置：首页 > news >正文

从SD协议到FatFs：深入解析Block与Sector的映射关系及disk_ioctl实战指南

news 2026/5/10 14:53:46

1. 理解SD协议中的Block与Sector

第一次接触SD卡底层协议时，我被Block和Sector这两个概念搞得晕头转向。记得当时在调试一个基于STM32的日志存储系统，FatFs总是报"磁盘错误"，折腾了一周才发现是disk_ioctl函数里的GET_BLOCK_SIZE返回值设置错了。这段经历让我深刻认识到：理解SD协议中存储单元的定义，是嵌入式文件系统开发的第一道门槛。

SD2.0协议文档（可从GitHub获取）明确区分了不同容量卡的存储单元规格。对于SDHC/SDXC这类高容量卡，最小的数据操作单位是512字节的Block。有趣的是，协议中Sector的概念在Version 2.0中已经被弱化——CSD寄存器中的Sector Size字段固定为0x7F，实际意义由AU（Allocation Unit）取代。这就好比一栋公寓楼：Block是每个房间（最小可操作单元），而AU是整个楼层（物理擦除单元）。

通过分析协议4.10.2节的表格，我们会发现SDHC卡的Maximum AU Size恒定为4MB（即8192个512B的Block）。这个数字很关键，因为它决定了后续FatFs中Block Size的上限值。我在实际测试中发现，某些工业级SD卡的实际AU可能小于4MB，但协议规定驱动只需考虑最大值即可。

2. FatFs文件系统的存储单元模型

当我们将目光转向FatFs时，会发现一个有趣的现象：它的Block和Sector定义与SD协议正好相反。在FatFs的架构中，Sector（通常512B）是文件系统的最小访问单元，而Block由多个Sector组成，主要用作擦除单位。这种定义反转就像镜子里的世界——SD协议的Block对应FatFs的Sector，而SD的AU则对应FatFs的Block。

这种映射关系可以通过一个实际案例来理解：假设我们需要读取SD卡中2KB的数据。在底层驱动层面，SD协议要求我们操作4个连续的512B Block；而在FatFs层面，这相当于读取4个Sector。我曾经在论坛看到有开发者争论"为什么FatFs的ffconf.h里Sector Size要设成512"，其实这正是为了匹配SD卡的物理Block大小。

更关键的是擦除操作的处理。当FatFs执行格式化或TRIM时，会通过GET_BLOCK_SIZE获取擦除单位。根据我们的映射关系，对于SDHC卡应该返回8192（即4MB/512B）。但实测发现，有些优化过的驱动会返回实际AU包含的Block数，这可能导致兼容性问题。我的建议是：除非有特殊需求，否则按协议最大值配置最稳妥。

3. disk_ioctl的关键命令实现

disk_ioctl就像FatFs与硬件之间的翻译官，需要准确转换两种存储模型的概念。其中最关键的三个命令是：

GET_SECTOR_SIZE：必须返回512，对应SD卡的Block大小
GET_BLOCK_SIZE：返回每个擦除单位包含的Sector数（SD卡的AU换算值）
GET_SECTOR_COUNT：总Sector数等于SD卡容量除以512B

这里有个容易踩坑的地方：GET_BLOCK_SIZE的返回值单位是Sector而不是字节。我曾见过一个经典错误案例：

// 错误实现：直接返回SD卡的AU大小（字节单位） *(DWORD*)buff = 4096 * 1024; // 4MB // 正确实现：返回Sector数量 *(DWORD*)buff = 8192; // 4MB/512B

对于多存储设备支持的情况，建议采用如下结构：

typedef struct { uint32_t sector_size; uint32_t sectors_per_block; uint64_t total_sectors; } device_geo_t; // 初始化时从CSD寄存器读取参数 device_geo_t sd_geo = { .sector_size = 512, .sectors_per_block = 8192, .total_sectors = ... // 根据卡容量计算 }; DRESULT disk_ioctl(BYTE pdrv, BYTE cmd, void *buff) { switch(cmd) { case GET_SECTOR_SIZE: *(DWORD*)buff = sd_geo.sector_size; break; case GET_BLOCK_SIZE: *(DWORD*)buff = sd_geo.sectors_per_block; break; ... } }

4. 实战中的异常处理与优化

在实际项目中，单纯实现协议要求的功能往往不够。根据我的踩坑经验，有以下几个需要特别注意的要点：

SD卡识别阶段的参数校验：有些山寨卡会错误报告CSD寄存器值。建议在初始化时增加校验逻辑：

// 校验Sector Size是否为512B if(sd_geo.sector_size != 512) { log_error("Invalid sector size"); return RES_ERROR; } // 校验Block Size是否为2的幂次方 if((sd_geo.sectors_per_block & (sd_geo.sectors_per_block - 1)) != 0) { log_error("Block size not power of 2"); return RES_ERROR; }

擦除边界对齐问题：虽然协议规定擦除操作可以按AU边界执行，但某些卡片在非对齐擦除时会出现异常。安全做法是在disk_write中维护写缓存，确保每次擦除都从AU起始地址开始。这里分享一个经过验证的写缓冲方案：

#define AU_SIZE 8192 // sectors static uint8_t write_buf[AU_SIZE * 512]; static uint32_t buf_start_sector = 0; static bool buf_dirty = false; DRESULT disk_write(...) { if(sector >= buf_start_sector && sector < buf_start_sector + AU_SIZE) { // 写入缓冲区内 memcpy(&write_buf[(sector - buf_start_sector)*512], buff, count*512); buf_dirty = true; } else { // 缓冲区越界，先提交已有数据 if(buf_dirty) { sd_write_blocks(buf_start_sector, write_buf, AU_SIZE); buf_dirty = false; } // 处理新数据... } }

性能优化技巧：对于高频小数据写入场景，可以适当减小报告的Block Size（如改为4096 Sector）。但需要确保该值是AU的整数约数，并在每次磁盘挂载时执行完整擦除。这个技巧在我参与的IoT设备项目中，将写操作吞吐量提升了约30%。

查看全文

http://www.jsqmd.com/news/790048/