我最近使用 GHI Electronics 的 uALFAT microSD 板进行数据记录，但我一直遇到其可靠性问题；有时，它的某些函数调用所花费的时间远远超出了我的处理能力。我目前正在使用 MSP430 微控制器与 uALFAT 进行通信。
我可以使用哪些类似的板来代替 uALFAT，这样会更可靠？
或者，
如果我需要设计自己的接口板以与 MSP430 配合使用，最有利的 OEM 解决方案是什么？
I have recently been using a uALFAT microSD board by GHI Electronics for data logging, but I have been having problems with its reliability; some of its function calls, at times, take far longer than I can handle. I am currently using an MSP430 microcontroller to talk to the uALFAT.
What similar boards are out there that I could possibly use instead of the uALFAT that would hopefully be more reliable?
OR
What would be the most favorable OEM solution if I needed to design my own interface board to work with an MSP430?
发布评论
评论（3）
我会对这个问题有一些不同的看法。任何基于闪存的存储设备都可能具有可变的写入时序。尤其是具有文件系统和磨损均衡等功能的系统。这往往是闪存的本质，因为你必须擦除整个块并移动东西。如果您无法忍受可变的时序，我过去所做的就是将这一部分移出代码的时间关键部分。
通常，我会添加一个队列，将时间关键的代码写入其中，然后在后台从队列中拉出并写入 SD 卡。在 RTOS 中，这将是优先级较低的任务。在轮询循环中，它将是系统空闲时调用的函数。
这将约束从函数调用的最坏情况时序更改为仅仅能够满足日志记录的平均吞吐量要求。最坏情况下的延迟和吞吐量决定了队列必须有多大；通常这可能很小。
I would think about this a bit differently. Any flash based storage device is likely to have variable timing on writes. Especially one with a file system and wear leveling and features like that. It tends to be the nature of flash since you have to erase whole blocks and move things around. If you can't live with the variable timing, what I've done in the past is to move this piece out of the time critical portion of the code.
Typically I add a queue which the time critical code writes to, and then in the background pull from the queue and write to the SD card. In a RTOS, this would be a lower priority task. In a polling loop, it would be a function called when the system is Idle.
This changes the constraint from being the worst case timing for a function call to simply being able to meet the average throughput requirements for logging. The worst case latency and throughput determine how big the queue must be; typically this can be small.
它可能比这更复杂，最好的解决方案是@sbass建议的，即使您确实选择更改文件系统。在指责 uALFAT 之前，您需要准确确定延迟发生的位置和原因。
然而，郑重声明，我已成功使用 ELM FatFs 及其削减ELM Petit FatFs，以及EFSL。
关于延迟，例如，使用 ELM，我使用 SPI 实现了高达 300 kbit/s 的写入速度（速度很大程度上取决于卡，速度范围从 30 kbit/s 到 1 Mbit） /s），即使使用优化的缓冲区大小（多个扇区大小），以及 512 字节扇区的 50 kbit 队列。这与库无关，而是 SD 卡的性质，显然在 1 Mbit 边界上，它会停滞长达 128 毫秒，这足以耗尽队列提供的缓冲。解决方案当然是像 @sbas 所说的那样增加缓冲，但在这种情况下，总系统 RAM 只有 64 kbit，因此这是不可能的。
如果您可以使用内存和 RTOS 任务（在您的情况下可能是 TI 自己的 SYS/BIOS）来解决问题，您应该能够使其与您拥有的库一起工作。所需的 RAM 量取决于数据速率以及数据是突发的还是连续的。
It is probably more complex than that and the best solution is as @sbass has advised, even if you do choose to change the file-system. You need to determine exactly where and why the latency is occurring before you blame uALFAT.
However for the record, I have successfully used ELM FatFs, and its cut-down ELM Petit FatFs, and also EFSL.
With respect to latency, while for example with ELM I have achieved write speeds of up-to 300 kbit per second using SPI (the speed is largely dependent on the card, and speeds can range from 30 kbit/s to 1 Mbit/s), I could not successfully use it to log a data stream of 96 kbit/s for any sustained length of time, even with optimised buffer sizes (multiples of a sector size), and a 50 kbit queue of 512 byte sectors. This was not down to the library, but rather the nature of the SD card, which apparently on 1 Mbit boundaries, would stall for up to 128 milliseconds, which was enough to exhaust the buffering provided by the queue. The solution is of course to increase the buffering as @sbas has said, but in this case the total system RAM was only 64 kbit so that was not possible.
If you can throw memory and an RTOS task (probably TI's own SYS/BIOS in your case) at the problem you should be able to get it working with the library you have. The amount of RAM necessary depends on the data rate and whether it bursts or is continuous.
谢谢大家，我最终实现了一个带有额外内存的循环缓冲区，这似乎已经成功了。感谢您的良好投入！
Thanks guys, I ended up implementing a circular buffer of sorts with additional memory and that seems to have done the trick. Thanks for the good input!