如何使用 SD 卡以 48 ksamples/s 记录 16 位数据？

Posted 2023-02-19

【中文标题】如何使用 SD 卡以 48 ksamples/s 记录 16 位数据？

【英文标题】：How can I use an SD card for logging 16-bit data at 48 ksamples/s?

【发布时间】：2011-03-19 10:58:11

【问题描述】：

背景

我的电路板在SPI 上集成了一个STM32 微控制器和一个SD/MMC card，并以48 ksamples/s 的速度对模拟数据进行采样。我正在使用 Keil Real-time Library RTX 内核和ELM FatFs。

我有一个高优先级任务，通过 DMA 以 40 个样本块（40 x 16 位）的形式捕获模拟数据；数据通过长度为 128 的队列（构成大约 107 毫秒的样本缓冲）传递到第二个低优先级任务，该任务将样本块整理到 2560 字节缓冲区（这是 512 字节 SD 扇区大小和40 个样本块大小）。当此缓冲区已满（32 个块或大约 27 毫秒）时，数据将写入文件系统。

观察

通过检测代码，我可以看到每 32 个块写入数据，并且写入大约需要 6 毫秒。这一直持续到（在 FAT16 上）文件大小达到 1 MB，此时写入操作需要 440 毫秒，此时队列已填满并且日志记录被中止。如果我将卡格式化为FAT32，则“长写入”事件之前的文件大小为 4 MB。

发生这种情况的文件大小在 FAT16 和 FAT32 之间发生变化的事实向我表明，这不是卡的限制，而是文件系统在 1 MB 或 4 MB 边界上执行的操作需要额外的时间.

我的任务似乎也被及时安排了，并且时间消耗在 ELM FatFs 代码中仅在 1 MB（或 4 对于 FAT32）边界处。

问题

有解释或解决方案吗？是 FAT 问题，还是特定于 ELM 的 FatFs 代码？

我考虑过使用多个文件，但根据我的经验，FAT 不能很好地处理单个目录中的大量文件，这也会失败。完全不使用文件系统并写入原始卡是可能的，但理想情况下，我希望在具有标准驱动程序且无需特殊软件的 PC 上读取数据。

我想到尝试编译器优化来缩短写入时间；这似乎有效果，但写入时间似乎更加多变。在 -O2 时，我确实得到了一个 8 MB 的文件，但结果不一致。我现在不确定文件大小与失败点之间是否存在直接关联；我已经看到它在没有特定边界的各种文件长度上以这种方式失败。可能是显卡性能问题。

我进一步检测了代码并应用了分而治之的方法。这种观察可能会使这个问题过时，并且之前的所有观察都是错误的或红鲱鱼。

我最终将其缩小到一个多扇区写入 (CMD25) 的实例，其中卡的“等待就绪”轮询偶尔需要 174 毫秒，用于 5 个块中的前三个扇区。等待就绪的超时设置为 500 毫秒，因此它会很高兴地忙——等待那么长时间。在一般情况下，迭代地使用 CMD24（单扇区写入）要慢得多 - 每个扇区 140 毫秒 - 而不是偶尔。

所以这毕竟是卡的行为。我将努力尝试各种卡 SD 和 MMC。

【问题讨论】：

+1。我对这个话题一无所知，呵呵，但是一个有趣且写得很好的问题:-)

对于任何仍然感兴趣的人，我最终找到了一个 Transcend 2GB SD 卡，它具有足够低的延迟，可以让数据成功流式传输。所以答案是获得正确的卡片——它们并非生而平等。

【参考方案1】：

尝试的第一件事可能很简单：将队列深度增加到 640。这将为您提供 535 毫秒的缓冲时间，并且至少应该在这个特定的文件系统事件中存活下来。

要查看的第二件事是 ELM FatFs 的配置。默认情况下，许多嵌入式文件系统对缓冲区的使用非常吝啬。我见过一个为所有操作使用单个 512 字节块缓冲区的一个，它为某些文件系统事务爬网。我们给了它几 KB，它变得更快了几个数量级。

当然，以上两者都取决于您是否有更多可用 RAM。

第三种选择是预先分配一个大文件，然后在数据收集期间覆盖数据。这将消除大量昂贵的簇分配和 FAT 操作操作。

由于编译器优化对此有影响，因此您还必须考虑它是多线程问题的可能性。是否有其他正在运行的线程可能会干扰较低优先级的读取器线程？您还应该尝试将那里的缓冲更改为样本大小和闪存块大小的倍数以外的值，以防遇到某种系统共振。

【讨论】：

是的，增加队列深度将是一个解决方案——只要我有足够的 RAM 允许这样做！该部件有 64Kb RAM，因为 640x40x16bit 队列将是 51Kb，而且它不是唯一运行的东西。对于这个问题，我已经将它增加到 128，我真的需要它更低；在发生此扩展写入之前，8 个队列就足够了。已经尝试过选项 3 - 没有效果。将查看选项 2 并报告。谢谢。

您确定 #3 是以不需要集群重新分配的方式完成的吗？换句话说，您打开文件是为了“修改”而不是“写入”吗？打开“写入”会将其归零并重新开始集群分配。

w.r.t.选项 2 选项是使用每个文件的扇区缓冲区或共享扇区缓冲区。我使用的是前者，但无论如何只打开一个文件。

在这种情况下，我会研究另一种 FAT 文件系统实现。那将是一个真正的系统瓶颈。

对于#3，是的，文件总是打开以进行更新（这就是为什么我错误地认为它是 always 1Mb - 那只是“高潮”标记. 我已经进行了进一步的测试，可能会使以前的所有观察结果都过时，我已将它们添加到原始问题中。

【参考方案2】：

您（或阅读此问题的任何其他人）可以试试这个 FAT 库：https://github.com/fernando-rodriguez/fat32lib。

在具有 10 Mbit/s SPI 总线的 40 MIPS Microchip dsPIC33 上，它可以在我尝试过的任何卡上以 230 Ksps（16 位）的速度进行采样。

【讨论】：

正如问题的第二次更新中指出的那样，我认为这不是软件问题 - 卡有时会在很长一段时间内进入繁忙状态，尽管有平均传输速率通常维持在 300 kbyte/s 以上。如评论中所述，找到了一张有效的 Transcend 卡。但是，我必须仅限于 SD（不是 SDHC）和 SPI 接口；此代码支持更大的卡，因此在任何情况下都可能有用，并且更大的 SDHC 卡可能不会出现此问题。但是，我无法将 GPL3 代码放入我的项目中。

这通常是因为闪存页擦除。如果文件系统与 SD 卡页面大小对齐可能会有所帮助。我知道 Windows 7 上的格式化实用程序会对不确定标准 SD 卡的 SDHC 卡执行此操作。在 SD 卡上，页面大小可以从 CSD 寄存器的 SECTOR_SIZE 字段中获得。如果您有办法确保在 Flash 页面的开头分配文件，它也可能会有所帮助。如果写入未正确对齐，则较大的卡可能会随着页面大小变大而变得最糟糕。

在 SDHC 和 SDXC 页面大小是 AU_SIZE 字段 SD 状态寄存器，它们进一步分为记录单元 (RU)，根据卡容量和速度等级 (SD 状态寄存器上的 SPEED_CLASS) 计算) 并且您需要写入 RU 大小的块以避免页面擦除。