最近、GHI Electronics の uALFAT microSD ボードをデータ ロギングに使用していますが、信頼性に問題がありました。その関数呼び出しのいくつかは、私が処理できるよりもはるかに長くかかることがあります。現在、MSP430マイクロコントローラを使用して uALFAT と通信しています。
uALFAT の代わりに使用でき、より信頼性が高いと思われる同様のボードには、どのようなものがありますか?
また
MSP430 で動作する独自のインターフェイス ボードを設計する必要がある場合、最も有利な OEM ソリューションはどれですか?
私はこれについて少し違った考え方をします。フラッシュ ベースのストレージ デバイスでは、書き込みのタイミングが変動する可能性があります。特に、ファイルシステムとウェアレベリングなどの機能を備えたもの. ブロック全体を消去して物を移動する必要があるため、これはフラッシュの性質である傾向があります。可変タイミングに耐えられない場合は、私が過去に行ったことは、コードのタイム クリティカルな部分からこの部分を移動することです。
通常、タイム クリティカルなコードが書き込まれるキューを追加し、バックグラウンドでキューからプルして SD カードに書き込みます。RTOS では、これは優先度の低いタスクになります。ポーリング ループでは、システムがアイドル状態のときに呼び出される関数になります。
これにより、制約が、関数呼び出しの最悪の場合のタイミングから、単にログ記録の平均スループット要件を満たすことができるものに変わります。最悪の場合のレイテンシとスループットによって、必要なキューの大きさが決まります。通常、これは小さい場合があります。
おそらくそれよりも複雑であり、ファイルシステムを変更することを選択した場合でも、@sbass がアドバイスしたように最善の解決策があります。uALFAT のせいにする前に、遅延が発生している場所と理由を正確に特定する必要があります。
ただし、記録のために、私はELM FatFsとそのカットダウンELM Petit FatFs、およびEFSLを正常に使用しました。
レイテンシに関しては、たとえば ELM を使用して、SPI を使用して最大 300 kbit/秒の書き込み速度を達成しました (速度はカードに大きく依存し、速度は 30 kbit/s から 1 Mbit/s の範囲になります)。最適化されたバッファ サイズ (セクタ サイズの倍数) と 512 バイト セクタの 50 kbit キューを使用しても、96 kbit/s のデータ ストリームを持続的に記録するためにそれを使用できませんでした。これはライブラリに起因するものではなく、明らかに 1 Mbit 境界で最大 128 ミリ秒停止する SD カードの性質によるもので、これはキューによって提供されるバッファリングを使い果たすのに十分でした。解決策はもちろん@sbasが言ったようにバッファリングを増やすことですが、この場合、システムRAMの合計は64kbitしかないので、それは不可能でした.
問題にメモリと RTOS タスク (おそらく TI 独自の SYS/BIOS) を投入できれば、お持ちのライブラリで動作させることができるはずです。必要な RAM の量は、データ レートと、バーストか連続かによって異なります。
みんなありがとう、私は追加のメモリを備えた種類の循環バッファを実装することになりました、そしてそれはトリックをしたようです。良い入力をありがとう！