1

CMX-RTX RTOS と Elm Chan FatFS を使用しています。タスクが整列してファイル システムにヒットするまでは、うまく機能します。

Chan FatFS に精通している方のために、ENTER_FS マクロと LEAVE_FS マクロを変更して、リソースを取得および解放しました。タスクが FS に入ろうとし、リソースが所有されている場合、リソースが解放されるまで待機状態になります。

これが複数のタスクから FS へのアクセスを処理する最良の方法であることに疑問を持ち始めています。FS がエラーを生成し、SD への単純なコマンドでさえ正しくない応答を取得するインスタンスが複数ありました。FS へのアクセスに 1 つのタスクのみを制限すると、これらのエラーは発生しません。

主な質問に移りますが、マルチタスク FS アクセスに対する皆さんの考え/推奨事項は何ですか? たとえば、私が最初に使用したより洗練された方法はありますか? それとも、FS にアクセスするためにさまざまなタスクによってフラグが立てられる単一のタスクでしょうか?

4

2 に答える 2

0

ほとんどのアクセスは読み取りであるため、明らかで単純な改善点はマルチリーダー、シングルライターです。さらに改善するには、ルート FAT ディレクトリを特別に扱い、バイパスを作成して、他の場所への書き込みがルート ディレクトリの読み取りをブロックしないようにします。(これには、ルート ディレクトリの R/W キャッシュも含まれる場合があります)

于 2014-10-30T14:29:31.317 に答える
0

私は 1 つのスレッドを使用して、FatFS で SD カードにアクセスしています。おっしゃるとおり、よく効きます。ファイル システムのスタックが最大であるため、メイン スレッドを使用してファイル システムを実行します (crt、C++ 静的 ctors などを実行する必要があるため)。main() はスレッドになり、アプリを実行する他のすべてのスレッドを開始してから、プロデューサー/コンシューマー キューからの要求を処理するファイル システム ループを実行します。

ファイル操作を必要とするスレッドは、FS スレッドに対して「FSrequest」オブジェクトをキューに入れる必要があります。FS スレッドは、要求がキューに表示されると、それらの要求を順次処理します。FS を必要とするすべてのスレッドは、FSrequest から派生したクラスである FSnotifiable から派生します。これは、FSrequest をパラメーターとして受け取る FSnotify メソッドを持つ FSrequest から派生したクラスです。FS スレッドはキューから FSrequest をポップし、'command' 列挙型メンバーの要求に従ってそれらを処理し、'error' メンバーを null またはエラー文字列ポインターと共にロードし、完了した FSrequest をパラメーターとして FSnotify メソッドを呼び出します。

通常、FSnotify() は、元のスレッドが待機しているセマフォを通知します。

編集:それはACの質問なので、それはすべてゴミです:((

もう一度やり直します:

OK、クラスはありません:( FS要求/応答を表す「FSrequest」構造体を宣言します。目的の操作を表す列挙型と、元のスレッドに入力される「完了」コールバック関数が必要です。また、おそらくバッファー ポインター (読み取り/書き込みにバッファーが必要な操作、またはエラー メッセージを保持する操作が失敗した場合) と、成功/失敗のブール値も持っています。

ファイル システムを処理するために、プロデューサー/コンシューマー キュー構造体/コードからポップする 1 つのスレッドを使用します。スレッドが FS 操作を必要とする場合、FS 要求を宣言し、詳細を入力して FS スレッドのキューに入れる必要があります。セマフォを通知する関数への完了コールバックをポイントする必要があります。要求スレッドは、FS スレッドからの完了通知をセマフォで待機します。FS スレッドは、要求された操作を実行し、成功/失敗/エラーを入力してから、完了コールバックを呼び出します。

于 2014-10-30T14:31:24.620 に答える