GD32F103实现SD卡USB大容量存储设备(MSC)与FATFS文件系统完整指南

1. 项目缘起：为什么是GD32F103+SD卡+USB+文件系统？

几年前，我在一个工业数据采集器的项目上遇到了一个经典难题：设备需要在野外长时间运行，采集到的数据量不小，需要可靠地存储下来，并且能方便地让现场工程师通过最通用的方式（比如U盘）把数据拷走。当时市面上主流的方案要么成本太高，要么灵活性不足。直到我把目光投向了GD32F103这颗国产的ARM Cortex-M3内核MCU，以及SD卡和USB Device这个组合，才发现这是一个性价比和实用性都极高的“黄金搭档”。

你可能要问，为什么是GD32F103？它不就是STM32F103的“平替”吗？没错，从引脚和基本外设兼容性上看，确实如此。但正是这种兼容性，带来了巨大的生态红利：海量的教程、成熟的驱动、丰富的工具链。更重要的是，它的性能（108MHz主频）和内存（64KB SRAM, 256KB Flash）对于实现SD卡文件系统读写和USB大容量存储设备（MSC）功能来说，是绰绰有余的。成本却只有同类进口芯片的一半甚至更低，这对于需要控制BOM成本的产品来说，吸引力巨大。

而这个组合的核心价值在于，它实现了一个“可移动海量存储”的嵌入式子系统。SD卡负责提供GB级别的、非易失的、成本低廉的存储空间；USB MSC（大容量存储设备）协议则让我们的设备在连接到电脑时，能像普通U盘一样被识别和访问，无需安装任何专用驱动；而文件系统（通常是FAT32）则是连接两者的桥梁，它定义了数据在SD卡上的组织格式，使得无论是MCU写入的数据，还是电脑拷贝的文件，都能被对方正确读写。

所以，这个标题背后的项目，绝不仅仅是把几个模块拼起来。它涉及到存储介质的底层驱动、文件系统的移植与集成、USB设备协议栈的适配，以及这三者之间高效、稳定的协同工作。接下来，我就结合自己的实战经验，把这套方案的选型、实现细节、踩过的坑以及优化心得，毫无保留地分享出来。

2. 硬件选型与核心电路设计要点

工欲善其事，必先利其器。硬件是稳定性的基石，这一步如果没走好，后面软件调试会异常痛苦。

2.1 MCU选型：GD32F103系列细分

GD32F103系列有很多型号，后缀不同，资源差异很大。对于我们这个项目，需要重点关注以下几点：

1. SRAM大小：这是最重要的指标。文件系统（如FATFS）需要缓冲区，USB协议栈也需要缓冲区。64KB的SRAM是舒适线，48KB是及格线。如果还要运行其他复杂任务，建议选择SRAM更大的型号，如GD32F103VCT6（48KB）或RET6（64KB）。
2. Flash大小：256KB足够容纳整个工程（含USB和文件系统库），但如果你计划加入OTA升级等功能，512KB会更游刃有余。
3. USB接口：确保型号支持USB 2.0全速设备（USB Device）。GD32F103全系基本都支持。
4. SDIO接口：这是高速读写SD卡（SDHC，容量>2GB）的关键。GD32F103的SDIO接口性能远高于用SPI模拟。因此，务必选择带有SDIO接口的型号，如GD32F103V系列或C系列。
5. 封装与引脚：考虑你的板子空间和布线难度。LQFP封装是比较通用的选择。

基于以上，我常用的型号是GD32F103VCT6（LQFP100脚，256KB Flash，48KB SRAM，带SDIO和USB）或GD32F103RET6（LQFP64脚，512KB Flash，64KB SRAM，带SDIO和USB）。它们性价比极高，资源完全够用。

2.2 SD卡电路与PCB布局“玄学”

SD卡电路看似简单，但布线不好极易导致数据错误甚至无法识别。

核心电路设计：

• 上拉电阻：SDIO的CMD（命令线）和DAT0-DAT3（数据线）必须在靠近MCU一端加上拉电阻（通常10kΩ-100kΩ）。这是SD协议规定的，用于保证信号空闲时为高电平，提高抗干扰能力。很多初学者忽略这点，导致识别不稳定。
• 电源路径管理：SD卡供电最好由一颗独立的LDO（如AMS1117-3.3）提供，并与MCU的3.3V数字电源隔离（可用0Ω电阻或磁珠连接）。这样能避免MCU数字噪声干扰SD卡，同时在热插拔时提供缓冲。
• 电平匹配：GD32F103的I/O口是3.3V，与SD卡电平一致，无需转换。
• 检测引脚：建议使用一个GPIO连接SD卡的卡座检测脚（Card Detect, CD）。这样软件可以实时知道卡是否插入，而不是盲目操作。上拉或下拉根据卡座型号决定。

PCB布局经验：

注意：SDIO信号属于高速信号（理论上可达25MHz），必须当作敏感信号处理。

1. 等长与差分：对于SDHC高速模式，DAT0-DAT3最好能做到大致等长。虽然不要求像USB差分线那样严格，但长度差异控制在几百mil内有利于稳定性。CMD线可以单独处理。
2. 远离干扰源：SDIO走线应远离晶振、DC-DC电源电路、电机驱动等噪声源。
3. 完整地平面：信号线下层最好有完整的地平面作为参考，提供清晰的回流路径。
4. 电源滤波：在SD卡座的VCC引脚附近，放置一个10uF的钽电容和一个0.1uF的陶瓷电容，进行退耦滤波。

2.3 USB接口的“不起眼”关键点

USB接口电路更简单，但细节决定成败。

• ESD保护：USB端口是暴露在外的，必须加ESD保护二极管（如SRV05-4）。一个静电就可能打坏USB引脚，我因此烧过不止一个芯片。
• DM/DP走线：USB的D+和D-是一对差分信号线。布线时必须等长、等距、紧耦合。长度差要控制在5mil以内。走线阻抗最好控制在90欧姆（差分阻抗）。
• 1.5kΩ上拉电阻：USB全速设备需要在D+（对于全速）上通过一个1.5kΩ电阻上拉到3.3V。这个电阻必须放在靠近USB插座的一端，而不是MCU一端。这是为了在设备拔出时，能快速释放总线。

3. 软件架构与核心库的选型

软件部分是这个项目的灵魂，我们需要三个核心组件：SD卡驱动、文件系统、USB设备协议栈。我的策略是：站在巨人的肩膀上，优先选择成熟、开源、社区支持好的方案。

3.1 底层驱动：HAL库还是标准外设库？

GD32提供了类似STM32的多种库。我的选择是GD32的HAL库（虽然它可能叫标准库或Firmware Library，但其面向对象的设计思想更接近HAL）。原因如下：

1. 移植性更好：HAL库的API抽象程度更高，将SDIO、USB等复杂外设的操作封装成了统一的句柄和函数。当你未来换用其他GD32系列甚至其他品牌MCU时，底层驱动代码的修改量会小很多。
2. 兼容性与未来：新出的芯片和复杂外设（如USB OTG）更多以HAL库形式支持。早点熟悉这套框架，长远来看更省力。
3. 社区资源：STM32的HAL库生态极其庞大，很多问题和解决方案可以直接参考、类比到GD32上。

当然，标准外设库更直接、代码量小，如果你对寄存器非常熟悉且项目时间紧迫，也可以用。但对于我们这个整合性项目，HAL库的模块化特性更利于管理。

3.2 文件系统：FatFs是唯一答案

在嵌入式领域，FatFs几乎是FAT文件系统实现的事实标准。它由ChaN先生编写，纯C语言实现，与平台无关，代码结构清晰，文档齐全，最重要的是完全免费开源。

• 为什么是FAT32？因为它是Windows、macOS、Linux、相机、播放器等设备最广泛支持的通用文件系统格式，保证了我们设备里SD卡的数据能在任何电脑上被读取。
• FatFs的配置：FatFs的可配置性（ffconf.h）极强。你需要关注：
  • _FS_TINY：设置为1，使用极简模式，将文件对象中的缓冲区移到单独的FIL结构，能节省大量RAM，非常适合我们这种内存紧张的MCU。
  • _USE_LFN：长文件名支持。设置为1或2。这会消耗更多RAM和Flash，但用户体验好。如果存储的都是数据文件（如DATA_20231001.BIN），可以关闭以节省资源。
  • _CODE_PAGE：设置中文等语言支持，根据需求选择。

3.3 USB协议栈：使用CubeMX生成的Middleware

这是最省心也是最推荐的做法。虽然我们可以手动移植一个轻量级的USB栈（如LUFA），但对于GD32，利用GigaDevice提供的USB Device Library（通常包含在HAL库包或类似STM32 CubeMX的工具中）是最佳路径。

这个库已经实现了USB核心驱动、标准请求处理以及各种设备类（Class）的框架，包括我们需要的MSC（大容量存储设备）类。我们的工作就是实现MSC类要求的几个回调函数（Storage_Inquiry,Storage_ReadCapacity,Storage_Read,Storage_Write），将这些操作映射到我们底层的SD卡和FatFs上。

软件架构图（逻辑层面）

[PC/手机] <---USB MSC协议---> [GD32F103 USB Device Core] | v [USB Mass Storage Class (MSC)] | v (SCSI命令转换) [BSP (板级支持包): 磁盘IO接口] | v [FatFs 文件系统] | v (扇区读写) [SDIO/SPI 底层驱动] | v [SD Card]

我们的编码工作，主要集中在下半部分：驱动FatFs，并实现BSP层的那几个磁盘读写函数，供USB MSC库调用。

4. 从零搭建：工程创建与底层驱动实现

这里我以Keil MDK和GD32的HAL库为例，手把手走一遍流程。

4.1 工程初始化与外设配置

1. 创建基础工程：从GD32官网下载对应型号的HAL库包，在Keil中基于模板创建工程，包含核心启动文件、HAL库的CMSIS和GD32F10x标准外设库文件。
2. 时钟树配置：这是第一步，也是容易出错的一步。GD32F103最高运行在108MHz。我们需要配置：
   • HXTAL（外部高速晶振）：8MHz。
   • PLL倍频：将8MHz倍频到108MHz。PLL倍频系数 = 108 / 8 = 13.5。但PLL的倍频系数必须是整数，所以需要分频再倍频。通常配置为：CK_HXTAL=8M->CK_PREDIV=8M/1=8M->CK_PLL = 8M * 13.5 = 108M。注意检查库函数中PLL倍频系数的宏定义，选择RCU_PLL_MUL13_5或类似值。
   • 系统时钟源：选择PLL作为SYSCLK。
   • 外设时钟：使能SDIO、USB、GPIO等所用外设的时钟（RCU_AHBx, RCU_APBx）。
3. GPIO初始化：根据原理图，初始化SDIO和USB对应的引脚。
   • SDIO:GPIOB的PIN8/9/10/11/12/13（CK, CMD, DAT0-3）需要设置为复用推挽输出（AF_PP），高速模式。
   • USB:GPIOA的PIN11/12（DM, DP）设置为复用推挽输出（AF_PP）。
   • SD卡检测引脚：设置为上拉输入模式。

4.2 SDIO驱动实现与FatFs的磁盘IO层

这是连接硬件和文件系统的桥梁。

1. SDIO初始化：调用HAL库的sdio_init函数，配置时钟分频（初期识别用低速400kHz，初始化后切换到高速，如24MHz）、总线宽度（1位模式开始，后切换到4位）、DMA等。DMA对于大数据量读写至关重要，能极大解放CPU。
2. 实现磁盘IO函数：FatFs要求我们提供一组底层磁盘访问接口，在diskio.c文件中。核心是这几个函数：
   • disk_status：返回磁盘状态（是否初始化、是否写保护等）。我们可以在这里检查SD卡检测引脚的电平。
   • disk_initialize：初始化磁盘（即SD卡）。这里调用SDIO的初始化序列，发送CMD0, CMD8, ACMD41等命令，识别卡的类型（V1, V2, SDHC等）。
   • disk_read：读取一个或多个扇区。参数是扇区号（LBA）和缓冲区指针。这里调用SDIO的块读取命令（CMD17/CMD18）。
   • disk_write：写入一个或多个扇区。调用SDIO的块写入命令（CMD24/CMD25）。
   • disk_ioctl：设备控制。用于获取扇区数量（GET_SECTOR_COUNT）、扇区大小（GET_SECTOR_SIZE）等信息，这些信息对FatFs和USB MSC都至关重要。

一个关键细节：SD卡地址模式。

• 标准容量SD卡（SDSC, <=2GB）：使用字节地址。CMD17/24的参数是字节地址。
• 高容量SD卡（SDHC, 2GB-32GB）和扩展容量卡（SDXC, >32GB）：使用扇区地址（LBA）。CMD17/24的参数是512字节的扇区号。 我们的驱动必须在初始化时判断卡类型，并在disk_read/write中做相应转换。HAL库的SDIO驱动通常已经处理好了这一点，但我们需要确保传递给FatFs的GET_SECTOR_COUNT是正确的。

4.3 FatFs的集成与文件操作封装

1. 将FatFs源码加入工程：下载FatFs，将source文件夹下的ff.c,ff.h,diskio.c,diskio.h以及可选的字库文件加入工程。
2. 修改ffconf.h：根据前面所述，配置好功能开关和代码页。
3. 编写应用层文件操作API：为了使用方便，我通常会封装几个最常用的函数：

   // 初始化文件系统 uint8_t FS_Init(void); // 打开/创建文件 FRESULT FS_OpenFile(const char* path, FIL* file, uint8_t mode); // 读取文件 uint32_t FS_ReadFile(FIL* file, void* buffer, uint32_t len); // 写入文件 uint32_t FS_WriteFile(FIL* file, const void* buffer, uint32_t len); // 列出目录 FRESULT FS_ScanDir(const char* path); // 获取剩余空间 uint64_t FS_GetFreeSize(void);

   在FS_Init里，我们会依次调用disk_initialize、f_mount来挂载SD卡。挂载成功后，就可以用f_open,f_write,f_read,f_close,f_lseek等FatFs原生API进行文件操作了。

实测心得：文件操作一定要检查返回值！每一个FatFs函数调用（f_open,f_write,f_close）都必须检查其返回的FRESULT。常见的错误有：

• FR_DISK_ERR：底层磁盘IO错误，可能是SD卡接触不良或驱动问题。
• FR_NO_FILE：文件不存在。
• FR_EXIST：文件已存在（当你以创建新文件模式打开时）。
• FR_INT_ERR：FatFs内部错误，断言失败。 完善的错误处理是产品稳定性的保证。

5. USB大容量存储设备（MSC）的集成与实现

这是让电脑识别我们设备为U盘的关键。

5.1 USB Device库的配置与初始化

1. 添加USB库文件：将GD32 HAL库中USB相关的驱动文件（usbd_core.c,usbd_ctlreq.c等）和MSC类文件（usbd_msc.c,usbd_msc_bot.c,usbd_msc_scsi.c）加入工程。
2. 实现设备描述符：在usbd_desc.c中，定义你的设备的USB描述符，包括设备描述符、配置描述符、接口描述符、端点描述符和字符串描述符。重点：
   • idVendor,idProduct：可以自定义，但不要与已知厂商冲突。
   • bDeviceClass/bDeviceSubClass/bDeviceProtocol：对于MSC设备，通常在设备描述符中设为0，而在接口描述符中具体定义。
   • 接口描述符中：bInterfaceClass = 0x08（Mass Storage），bInterfaceSubClass = 0x06（SCSI Transparent Command Set），bInterfaceProtocol = 0x50（Bulk-Only Transport）。
   • 端点描述符：需要定义两个Bulk端点，一个IN（设备到主机），一个OUT（主机到设备），最大包长度一般为64字节（全速USB）。
3. USB核心初始化：在主函数中，初始化USB硬件，然后调用usbd_init，注册MSC类回调函数。

5.2 实现MSC的SCSI命令回调函数

USB MSC类实际上是通过封装SCSI命令集来与主机通信的。我们需要在usbd_msc_scsi.c或自己实现的文件中，完成以下几个关键回调函数：

1. SCSI_Inquiry_Cmd：响应主机的查询请求，返回设备信息，如厂商名、产品名、版本号。这里返回的信息会在电脑的“磁盘管理”中显示。
2. SCSI_ReadCapacity10_Cmd：这是最关键的函数之一。主机通过它获取存储设备的容量信息。我们必须返回正确的总扇区数和扇区大小（固定为512字节）。这两个值需要从SD卡驱动中动态获取（通过disk_ioctl(GET_SECTOR_COUNT)和GET_SECTOR_SIZE）。如果这里返回错误，电脑会认为磁盘容量为0或无法识别。
3. SCSI_Read10_Cmd：处理主机发来的读请求。参数是起始扇区号（LBA）和要读取的扇区数。我们需要调用之前为FatFs实现的disk_read函数，将数据写入USB IN端点缓冲区。
4. SCSI_Write10_Cmd：处理主机发来的写请求。参数同样是LBA和扇区数。数据会通过USB OUT端点发送过来，我们需要调用disk_write函数将其写入SD卡。
5. SCSI_TestUnitReady_Cmd：报告设备是否就绪。通常直接返回成功，除非SD卡被拔出或发生错误。
6. SCSI_RequestSense_Cmd：当命令执行出错时，主机通过此命令获取详细的错误信息。

实现的核心逻辑是：USB MSC库接收到的SCSI命令中的LBA地址，直接对应SD卡的物理扇区号。这意味着，当电脑向我们的“U盘”写入一个文件时，它实际上是通过SCSI_Write10_Cmd向我们发送了一系列扇区数据，我们直接将其写入SD卡的对应物理扇区。FatFs文件系统层在此时是“透明”的。也就是说，USB MSC访问的是SD卡的物理磁盘镜像，而MCU自身的程序通过FatFs访问的是磁盘上的逻辑文件系统。这两者必须协同工作，不能互相破坏。

5.3 处理“安全弹出”与缓存同步

这是一个高级但至关重要的主题。当你从电脑上点击“弹出设备”时，Windows会做什么？它会发送一个SCSI_START_STOP_UNIT命令（启动/停止单元），其中的Start位为0，表示停止（弹出）。我们的设备应该在这个命令中做什么？

正确的做法是：

1. 刷新FatFs和SD卡驱动的所有缓存。对于FatFs，如果之前以写方式打开过文件，必须确保所有f_write的数据都通过f_sync或f_close真正写入磁盘。
2. 将SD卡置于空闲状态（发送CMD0）。
3. 告诉主机操作成功。

如果不处理这个命令，或者处理不当，直接拔掉USB线，极有可能导致文件系统损坏，因为电脑可能还有数据在缓存中没有下发给设备，或者设备收到了数据但还没写入SD卡。我曾在早期版本中忽略这一点，导致十次里有两三次文件系统会挂掉，需要重新格式化。后来完善了SCSI_START_STOP_UNIT命令的处理，并确保所有文件写操作后都及时同步，问题才彻底解决。

提示：在disk_ioctl函数中实现CTRL_SYNC命令，它会被FatFs的f_sync调用，用于确保物理写入完成。在USB MSC的写命令完成后，也可以调用这个同步操作。

6. 系统整合、调试与稳定性实战

当三个模块都准备好后，整合起来并稳定运行才是真正的挑战。

6.1 内存规划与堆栈管理

这是嵌入式开发永恒的课题。我们的系统消耗大量内存：

• USB缓冲区：IN/OUT端点缓冲区，通常各需要64字节x N（双缓冲）。
• FatFs缓冲区：如果使能_FS_TINY，每个打开的文件对象（FIL）需要约12字节，但读写缓冲区是公用的，需要_MAX_SS字节（通常512）。如果使能长文件名，还需要额外缓冲区。
• SDIO DMA缓冲区：用于SD卡读写的数据传输。
• 栈空间：USB中断、SDIO中断、文件系统操作都需要栈空间。

我的经验配置（针对GD32F103VCT6，48KB SRAM）：

• 堆（Heap）：设置8KB - 12KB，用于动态内存分配（FatFs和USB库内部可能会用到malloc）。
• 栈（Stack）：设置4KB - 6KB。在启动文件（startup_gd32f10x.s）中修改。
• 绝对不要开启C标准库的malloc，使用编译器自带的或自己实现的内存管理，避免碎片化。
• 使用__attribute__((section(".ram_data")))将大的全局数组（如文件读写缓冲区）定位到特定的RAM段，方便管理。

经常使用Keil的Map文件（.map）查看内存使用情况，确保没有溢出。

6.2 中断优先级与冲突处理

系统中有多个可能产生中断的外设：

• USB中断：处理USB总线事件、端点传输完成。优先级应设为较高。
• SDIO中断：处理数据传输完成、命令响应。优先级应设为较高。
• DMA中断：服务于SDIO或USB的数据搬运。优先级与SDIO/USB中断协调。
• SysTick中断：系统心跳，用于延时和任务调度。优先级最低。

配置原则：

• USB和SDIO的中断优先级不能低于SysTick，否则在中断服务程序中调用FatFs或USB库函数（可能耗时）时，会被SysTick中断打断，导致系统不稳定。
• SDIO和USB的中断之间，如果它们没有共享资源（如缓冲区），优先级可以相同。但如果它们会访问同一个SD卡或文件系统，则需要考虑互斥，通常我会将SDIO的优先级设得比USB稍高一点，因为存储介质的操作更需要原子性。
• 在SD卡操作（读/写/初始化）的关键段，可以考虑暂时关闭USB中断，防止USB MSC的读写请求打断正在进行的SD卡操作，造成状态混乱。当然，这需要精细设计，否则会影响USB响应速度。

6.3 稳定性调优与压力测试

模块单独测试可能都正常，但整合后长时间运行就可能出问题。以下是我的压力测试方法和调优点：

1. 大文件连续读写测试：

   • 从PC拷贝大文件（如1GB的电影）到设备：考验USB写入和SD卡写入的稳定性、DMA效率、缓冲区管理。观察是否中途断开、速度是否稳定、文件校验是否一致。
   • 从设备拷贝大文件到PC：考验SD卡读取和USB读取的稳定性。
   • 调优点：调整SDIO时钟频率（24MHz, 36MHz, 48MHz），找到速度和稳定性的平衡点。优化disk_read/write函数中的超时等待逻辑，避免死等。

2. 小文件随机读写测试：

   • 在设备上创建数百个小文件（几KB到几十KB），然后通过USB在电脑上反复删除、创建、修改。这考验文件系统的健壮性和两个系统（MCU FatFs vs PC文件系统）对磁盘结构的并发修改容忍度。
   • 调优点：确保FatFs的_FS_REENTRANT（可重入）选项根据你的RTOS情况正确配置。如果是在中断和主循环中都可能调用文件操作，必须使用信号量进行保护。

3. 异常处理测试：

   • 热插拔SD卡：在设备运行中，突然拔出SD卡。程序应能通过检测引脚或disk_initialize失败检测到，并安全地卸载文件系统（f_mount(NULL, ...)），USB MSC应返回NOT READY状态。重新插入后能自动识别并挂载。
   • USB意外断开：在数据传输中直接拔掉USB线。USB硬件会检测到断开，驱动应能正确清理状态，避免残留状态影响下一次连接。
   • 突然断电：测试写入过程中断电，文件系统是否容易损坏。可以考虑启用FatFs的_FS_NOFSINFO选项，或者定期调用f_sync来减少数据丢失范围。

4. 性能监控：

   • 使用GPIO引脚翻转来测量关键函数的执行时间（如disk_read一次扇区的时间）。
   • 计算实际的文件传输速率，与理论值（USB全速约1MB/s，SD卡Class10约10MB/s）对比，定位瓶颈。

7. 进阶优化与功能扩展

当基础功能稳定后，可以考虑以下优化和扩展，让项目更上一层楼。

7.1 实现读写缓存（Cache）提升性能

直接读写SD卡扇区效率较低，尤其是对于小文件和非对齐访问。可以在diskio.c层之上，FatFs层之下，实现一个简单的读写缓存。

基本思路：

• 在RAM中开辟一个或多个缓存块（例如，每个块包含8个扇区，4KB）。
• 当FatFs请求读某个扇区时，先检查是否在缓存中。如果在（缓存命中），则直接返回缓存数据；如果不在（缓存未命中），则从SD卡读取一个块（包含该扇区）到缓存，再返回数据。
• 当FatFs请求写扇区时，先写入缓存，并标记该缓存块为“脏”。当缓存块需要被替换，或者收到同步命令（CTRL_SYNC）时，再将“脏”块写回SD卡。
• 替换策略：常用的是LRU（最近最少使用）。

收益与代价：

• 收益：对于重复读取或局部性访问，速度可提升数倍甚至数十倍。大大减少SD卡的实际读写次数，延长其寿命。
• 代价：消耗额外的RAM（每个缓存块需要4KB+管理开销）。增加了代码复杂性，需要处理缓存一致性（特别是与USB MSC直接写物理扇区的冲突）。

与USB MSC的协同：这是缓存设计最棘手的地方。因为USB MSC是直接读写物理扇区的，它会绕过FatFs和我们的缓存。解决方案有两种：

1. 写通（Write-Through）缓存：USB MSC的写操作，在写入SD卡的同时，也检查并更新缓存中对应的数据（如果存在）。这保证了缓存一致性，但每次USB写都会实际写卡，性能提升有限。
2. 禁用缓存对USB MSC路径：USB MSC的读写直接调用底层的disk_read/write，不经过缓存层。但需要在USB MSC写操作后，失效（Invalidate）缓存中对应的块，因为缓存中的数据已经过时。下次FatFs读取时，会从SD卡重新加载。这种方法更简单，但USB写入后，MCU程序紧接着读取同一数据，会遭遇一次缓存未命中。

7.2 支持多分区与虚拟磁盘

默认情况下，USB MSC将整个SD卡作为一个磁盘（LUN 0）呈现。我们可以扩展，支持多个分区或多个逻辑磁盘。

1. 多分区：在SCSI_ReadCapacity10_Cmd等函数中，不再返回整个SD卡的容量，而是返回某个分区的容量和起始扇区。这需要解析SD卡的MBR（主引导记录）或GPT分区表。USB MSC的读写命令中的LBA将是分区内的相对地址，我们需要将其转换为SD卡的绝对物理地址（LBA + 分区起始扇区）。
2. 多LUN（逻辑单元号）：USB MSC协议支持一个设备报告多个LUN。我们可以将SD卡上的不同分区映射为不同的LUN，这样在电脑上会显示为多个可移动磁盘。甚至可以将一部分内部Flash或外部SPI Flash也虚拟成一个LUN。这需要修改USB描述符（报告多个LUN），并为每个LUN实现独立的SCSI_Inquiry_Cmd、SCSI_ReadCapacity10_Cmd等回调函数。

7.3 集成RTOS实现并发操作

在基础项目中，主循环可能是while(1)中轮询处理文件日志和USB事件。但如果你想同时做更多事，比如通过网络传输数据、运行用户界面等，集成一个RTOS（如FreeRTOS, RT-Thread）是必要的。

任务划分建议：

• USB任务：优先级较高，负责处理USB中断事件和MSC命令解析。这个任务大部分时间在等待信号量，由USB中断唤醒。
• 文件管理任务：优先级中，负责执行具体的文件操作（创建、读写、删除）。它接收来自其他任务（如数据采集任务）的消息队列请求。
• 数据采集任务：优先级低或中，周期性采集传感器数据，然后将数据通过消息队列发送给文件管理任务进行存储。
• 设备状态监控任务：优先级低，周期性检查SD卡是否存在、USB连接状态、电池电量等。

关键同步机制：

• 互斥锁（Mutex）：保护共享资源——SD卡驱动和FatFs。任何任务在调用f_open,f_write,disk_read等函数前，必须先获取这个互斥锁。特别注意：在中断服务程序（如USB中断）中，不能等待互斥锁，因为可能导致死锁。中断中的处理应尽量简短，将耗时操作通过队列或信号量交给任务处理。
• 消息队列（Queue）：用于任务间通信，例如数据采集任务将“存储一包数据”的请求发给文件管理任务。

集成RTOS后，系统的结构更清晰，响应更及时，但调试复杂度也会增加，需要仔细处理任务优先级和资源共享问题。

从选型到硬件设计，从驱动实现到系统整合，再到最后的优化扩展，完成一个稳定的“GD32F103+SD卡+USB+文件系统”项目，就像完成一次精密的嵌入式系统工程。它考验的不仅是编码能力，更是对硬件特性、协议栈原理和系统稳定性的综合理解。每一次调试，每一次压力测试，都是对设计是否鲁棒的检验。当你的设备被电脑顺利识别为一个U盘，并能稳定高速地传输文件时，那种成就感是无可替代的。希望这篇基于实战经验的长文，能为你扫清障碍，助你成功实现这个极具实用价值的嵌入式经典方案。如果在实现过程中遇到具体问题，不妨从时钟配置、内存分配和中断优先级这三个最常出问题的地方入手排查，往往能事半功倍。