15

背景

我的开发板在SPI上集成了一个带有SD/MMC 卡的STM32微控制器，并以 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（或 4 对于 FAT32）边界处消耗了时间。

问题

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

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

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

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

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

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

4

2 回答 2

5

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

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

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

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

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

于 2010-07-22T10:35:52.973 回答
1

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

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

于 2013-12-29T17:52:06.023 回答