STM32H7虚拟U盘系统设计

基于 STM32H7 的虚拟U盘系统设计：从硬件驱动到多任务协同

在工业现场，工程师最头疼的问题之一就是“怎么把设备里的数据拿出来”。传统做法是写专用上位机、用串口慢慢传，或者拆卡去读——效率低还容易出错。有没有一种方式，能让嵌入式设备像普通U盘一样插上电脑就能拷文件？答案是肯定的。

STM32H7 系列凭借其强大的性能和丰富的外设资源，正成为实现这一目标的理想平台。结合 SDMMC 接口、FATFS 文件系统、USB MSC 协议以及 FreeRTOS 实时调度机制，我们可以构建一个真正意义上的“智能U盘”：既能高速存储大量数据，又能即插即用被 PC 识别，还能在后台持续运行其他任务而不影响用户体验。

这不仅是一个技术整合问题，更是一场关于 可靠性、实时性与用户体验平衡 的设计挑战。

---

设想这样一个场景：一台部署在现场的振动监测仪，每秒钟采集数百个数据点并写入SD卡。运维人员只需插入一根USB线，设备立刻变成一个可读写的U盘，所有历史记录一览无余；拔掉后自动恢复采样，整个过程无需断电、不丢数据。这种无缝切换的背后，隐藏着多个关键技术模块的精密协作。

首先， SDMMC控制器 必须稳定地驱动SD卡。STM32H7 支持 UHS-I 模式下的4-bit SDIO接口，理论带宽可达50MB/s以上。实际项目中我们通常将时钟配置为48MHz（通过APB2分频），配合DMA双缓冲机制，确保大块数据传输时不占用CPU资源。关键在于硬件布局——CLK、CMD 和 DAT 信号线必须严格等长，否则在高速下极易引发CRC错误或初始化失败。

HAL_StatusTypeDef MX_SDMMC1_SD_Init(void)
{
    hsd1.Instance = SDMMC1;
    hsd1.Init.ClockEdge           = SDMMC_CLOCK_EDGE_RISING;
    hsd1.Init.ClockPowerSave      = SDMMC_CLOCK_POWER_SAVE_DISABLE;
    hsd1.Init.BusWide             = SDMMC_BUS_WIDE_4B;
    hsd1.Init.HardwareFlowControl = SDMMC_HARDWARE_FLOW_CONTROL_DISABLE;
    hsd1.Init.ClockDiv            = 2; // 240MHz / (2+2) = 60MHz
    return HAL_SD_Init(&hsd1);
}

这段初始化代码看似简单，但每个参数都有深意。比如关闭 ClockPowerSave 是为了避免时钟停振导致响应延迟；而 ClockDiv=2 则需根据实际主频调整，过高会导致信号完整性下降，过低又浪费性能。实践中建议先以默认速度完成枚举后再切换至高速模式，提升兼容性。

有了物理层支持，下一步是让主机能“看懂”里面的文件结构——这就轮到 FATFS 登场了。作为ChaN开发的经典嵌入式文件系统模块，FATFS 的优势在于轻量、可裁剪且高度抽象。它通过 diskio.c 提供一组接口函数，将底层硬件差异完全隔离。无论你用的是SD卡、SPI Flash还是eMMC，上层应用都可以用标准的 f_open() 、 f_read() 进行操作。

但要注意，FATFS 并非天生线程安全。在多任务环境下，多个任务同时访问文件可能导致缓存不一致甚至文件系统损坏。例如，日志任务正在追加写入LOG.TXT，而USB任务恰好要读取该文件供PC浏览，若没有同步机制，结果可能是乱码甚至死锁。

解决方案是在 ffconf.h 中启用 _FS_REENTRANT ，并通过FreeRTOS的互斥量进行保护：

SemaphoreHandle_t sdMutex;

DRESULT USER_disk_read(BYTE pdrv, BYTE *buff, LBA_t sector, UINT count)
{
    if (xSemaphoreTake(sdMutex, pdMS_TO_TICKS(100)) != pdTRUE)
        return RES_WRPRT;

    if (HAL_SD_ReadBlocks_DMA(&hsd1, (uint32_t*)buff, sector, count) != HAL_OK) {
        xSemaphoreGive(sdMutex);
        return RES_ERROR;
    }

    while(HAL_SD_GetCardState(&hsd1) == HAL_SD_CARD_TRANSFER);
    xSemaphoreGive(sdMutex);
    return RES_OK;
}

这里我们使用了一个全局互斥量 sdMutex 来保护所有对SD卡的访问。虽然会引入一定延迟，但在大多数应用场景下是可以接受的。更重要的是避免了灾难性的文件系统崩溃。

当文件系统准备好之后，真正的魔法开始了：如何让PC一接上就认出这是一个U盘？

USB MSC（Mass Storage Class） 正是用来解决这个问题的标准协议。它的核心思想很简单：设备向主机声明自己是一个块设备，提供“总扇区数”和“扇区大小”，然后响应一系列SCSI命令（如READ_10、WRITE_10）。整个过程由USB OTG控制器配合USBD_MSC中间件完成。

关键在于 usbd_storage_if.c 中的三个回调函数：

int8_t STORAGE_GetCapacity(uint8_t lun, uint32_t *block_num, uint16_t *block_size)
{
    HAL_SD_CardInfoTypeDef cardinfo;
    HAL_SD_GetCardInfo(&hsd1, &cardinfo);

    *block_num = cardinfo.LogBlockNbr;
    *block_size = cardinfo.LogBlockSize;
    return 0;
}

int8_t STORAGE_Read(uint8_t lun, uint8_t *buf, uint32_t blk_addr, uint16_t blk_len)
{
    if (HAL_SD_ReadBlocks_DMA(&hsd1, (uint32_t*)buf, blk_addr, blk_len) != HAL_OK)
        return -1;

    while(HAL_SD_GetCardState(&hsd1) == HAL_SD_CARD_TRANSFER);
    return 0;
}

int8_t STORAGE_Write(uint8_t lun, uint8_t *buf, uint32_t blk_addr, uint16_t blk_len)
{
    if (HAL_SD_WriteBlocks_DMA(&hsd1, (uint32_t*)buf, blk_addr, blk_len) != HAL_OK)
        return -1;

    while(HAL_SD_GetCardState(&hsd1) == HAL_SD_CARD_TRANSFER);
    return 0;
}

这些函数本质上是把USB请求翻译成对SD卡的操作。特别注意 STORAGE_GetCapacity 必须返回准确值，否则Windows可能蓝屏或拒绝挂载。另外，如果希望支持只读模式（防止误删日志），可以通过 STORAGE_GetWriteProtect 返回状态。

到这里，单个功能模块已经跑通，但真实系统远比这复杂。想象一下：传感器任务正往SD卡写数据，用户突然插上USB线要求导出，两个任务争抢同一个资源怎么办？USB通信本身也有中断和服务轮询的需求，如何保证不超时？

这就是 FreeRTOS 发挥作用的地方。我们不再把系统当作顺序执行的程序，而是划分为多个独立运行的任务，各自承担职责：

• AppTaskStart ：最低优先级，负责初始化外设、创建互斥量、挂载文件系统。
• DataLoggerTask ：高优先级，周期性采集数据并写入日志文件。
• UsbDeviceTask ：中等优先级，定期调用 USBD_RunTestMode() 处理USB事件。
• LedCtrlTask ：最低优先级，闪烁LED指示当前工作状态。

void DataLoggerTask(void *pvParameters)
{
    while(1) {
        if (xSemaphoreTake(sdMutex, pdMS_TO_TICKS(1000)) == pdTRUE) {
            FIL file;
            f_open(&file, "LOG.TXT", FA_OPEN_APPEND | FA_WRITE);
            f_printf(&file, "Time:%lu Temp:%.2f\r\n", get_tick(), read_temp());
            f_close(&file);
            xSemaphoreGive(sdMutex);
        }
        vTaskDelay(pdMS_TO_TICKS(5000));
    }
}

这个简单的例子展示了多任务协同的核心逻辑： 谁要用SD卡，先拿锁；用完释放，别人再用 。USB任务同样需要获取同一把锁才能安全读取文件内容。这样既保证了并发性，又避免了竞争条件。

当然，细节决定成败。比如USB OTG中断的优先级一定要高于普通的GPIO中断，否则可能因响应延迟导致枚举失败；每个任务的堆栈大小也要合理分配，FATFS相关操作尤其耗栈，建议不少于512字节；此外，开启I-Cache和D-Cache可显著提升整体性能，尤其是在频繁调用文件API时。

还有一个常被忽视的问题是热插拔处理。用户可能随时插拔USB线，系统必须能够检测到VBUS的变化并做出反应。理想的做法是利用外部中断监控VBUS引脚，在上升沿启动USB设备模式，下降沿关闭并调用 f_sync() 确保所有未写入的数据落盘。

void VBUS_Detect_IRQHandler(void)
{
    if (__HAL_GPIO_EXTI_GET_IT(GPIO_PIN_9) != RESET) {
        if (HAL_GPIO_ReadPin(VBUS_GPIO_Port, VBUS_Pin) == GPIO_PIN_SET) {
            USBD_Start(&hUsbDeviceFS); // 插入，启动USB
        } else {
            USBD_Stop(&hUsbDeviceFS);  // 拔出，停止设备
            f_sync(&file);             // 强制刷新缓存
        }
        __HAL_GPIO_EXTI_CLEAR_IT(GPIO_PIN_9);
    }
}

这样的设计使得系统具备了真正的“即插即用”能力，用户体验接近消费级产品。

回到最初的问题：为什么选择这套组合而不是其他方案？

因为 STM32H7 + SDMMC + FATFS + USB MSC + FreeRTOS 构成了一种 黄金三角架构 ：高性能MCU提供了足够的算力和内存来支撑复杂的协议栈；标准化的文件系统确保跨平台兼容性；USB MSC实现了零依赖的数据导出；而RTOS则赋予系统应对多事件并发的能力。

这套方案已经在多个领域落地验证：
- 在医疗设备中用于导出病人检测报告；
- 在音频采集仪中实现WAV文件直录；
- 在教学平台上让学生自主拷贝实验结果；
- 在工业网关中作为应急数据备份通道。

未来还有更多优化空间。例如动态切换设备模式（U盘/读卡器/自定义HID）、引入LittleFS提升闪存寿命、增加网络接口实现ETH+USB双模导出等。但无论如何演进，其核心理念始终不变： 让嵌入式设备更好地融入人类的工作流程，而不是让人去适应机器的限制 。

这种高度集成的设计思路，正引领着智能边缘设备向更可靠、更高效的方向演进。