filesystems - 如何使用 SD 卡以 48 ksamples/s 的速度记录 16 位数据？

Question

背景

我的主板包含一个 STM32带有 SD/MMC card 的微 Controller 在 SPI并以 48 ksamples/s 的速度采样模拟数据。我使用的是 Keil 实时库 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(或 FAT32 为 4)边界处编码。

问题

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

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

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

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

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

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

Answer 1

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

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

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

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

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