ＦａｔＦｓを使ってみる
ＲＸ６２ＮでＳＤカードのファットファイルシステム（ＦａｔＦｓ）を操作する記事がインターフェイス２０１１年６月号にありましたが、このＦａｔＦｓを使ってみます。ＦａｔＦｓは３年ほど前（v 0.06 ）からテスト的に動作させていましたが、ＦＡＴ３２且つ、ロングファイルネームが扱えると知って、これはよさそうだと思いました。ＦＡＴ（１６）については、１５年以上も前に自作で作成したことがあり、その頃、組み込み外部ストレージは、ＳＣＳＩの２４０ＭＢ程度のＨＤＤを使っていました。ＣＰＵは、ＳＣＳＩインターフェイス付きの、モトローラのＶＭＥバスマスター基板で、マシンは、ＭＣ６８０４０でした。ＳＣＳＩはＵＳＢに置き換わって、今ではほとんど使われなくなりました。自作ＦＡＴ１６は、ほぼ問題なく動作しましたが、何分時代遅れって感じで、ＳＤカードに移植する気が起こらず、そのままになっていました。
最近のＦａｔＦｓを見ると、ＳＤカード、しかもＳＰＩモードで使うのを前提で作成されているようです。サンプルソフトもＳＰＩでＳＤカードを操作する例になっています。それ以外の場合は、いくつか変更する必要があります。v 0.06 の場合は、ＳＰＩ接続のＳＤカードに限定していなかったので、ストレージならなんでも簡単に移植できましたが、最近のはすんなりいきません。
ここでの解説は、
ＲＸ６２ＮのＳＰＩでＳＤカードを操作
した場合を元にしていますが、ＳＰＩのポートなどは変更しています。変更、追加の回路、プログラムソースは、
こちら。
ＦａｔＦｓを使う場合の注意点。突然の電源断でも安全に使うには？
結論から言うと、１秒ぐらい持つＵＰＳ（無停電電源装置）の機能を基板に付けるしかありません。
無論、電源断をマイコンが検出できるという条件付きです。
ＦａｔＦｓの移植に関しては、今更ここで解説する必要はないと思いますが、組み込み工業用のスタンドアローンマイコンのストレージとして使うには、いくつか注意が必要です。それは、ＦＡＴファイルシステムの構造によるものです。ＦＡＴファイルシステムでなくても、書き込み中に電源が切れると、脆弱なファイルシステムでは、復旧が困難になることがあります。
ＳＤカードをＦＡＴファイルシステムで使うには、以下の不具合が起こらないようにしなければなりませんが、小さなシステムでは簡単に対応できそうにありません。特にＲＡＭ容量が少ないと、#define _FS_TINY 0 にしずらいので、アクセス回数が増え、それだけ電源断の耐性が低くなります。
操作中に電源が切れると、最後のファイルを書いても、ディレクトリが更新されずに、いくつかデータ部分が抜けます。
操作中に電源が切れると、ファイルシステムが壊れて、パソコンから「フォーマット」を要求されることがあります。これはごくごくまれです。
操作中に電源が切れると、パソコンがＳＤカードを認識できなくなります。これは更にごくごくまれです。意図的に起こせるＳＤカードのメーカーがありますが、ＳＰＩモードではまだ未確認です。ＳＤモードで操作する装置で、ＢＩＯＳもそれなりに改造したものでこの現象の発生を確認できました。ただこうなっても、その装置で該当ＳＤの終わり近くに何かを書くと、復帰でき、パソコンからもアクセスできるようになりました。無論、ファイルは一部こわれていました。
対策としては、
電源ＯＦＦの信号をマイコンのＮＭＩに入れ、直ちにファイルをクローズします。
ファイルのデータを書き足したとき、そのファイルをクローズします。頻繁にこれを実行すると書き込み回数が増えるので、１秒単位以上でクローズするようにします。
電源ＯＦＦの信号をマイコンのＮＭＩで受け取ったあと、ＳＤカードと操作ＣＰＵを１秒ほど動かせるように電源を設計します。これは、ファイルクローズに伴う最終のデータの書き込み完了が、長くても１秒以内に終わると思われるからです。（ＳＤカードのメーカーによってこの時間は異なります）
さてここで、ファイルに５１２バイト追加してクローズするまで、どれだけ時間がかかるのか、時間を測定しながら何回もトライすると、たいていは２０ｍｓ程度で終わりますが、数十回に一度ぐらいで、４００ｍｓもかかってしまうことがあります。ファイルのデータを書き足したとき、そのファイルをクローズしてる最中に電源ＯＦＦ信号が来ると、最大４００ｍｓは動作させないと、正しくＦＡＴファイルシステムの更新が終わりませんので、たまたま時間がかかっている場合に電源断になると、ファイルに書けていない状態になります。
では、通常は、２０ｍｓほどで終了するのに、ファイルに追加してクローズするのになぜ４００ｍｓもかかる場合があるのか、詳しく調査してみます。ＦａｔＦｓでの操作が増えてアクセス回数が多くなり、４００ｍｓもかかるとは思えません。
ＦａｔＦｓでのＳＤカードアクセスをロギングして、アクセス回数を調査
ＦａｔＦｓの動作を観察すると、次のような処理になっています。( _FS_TINY = 1, _USE_LFN = 0 の場合 )０ｘ２００バイトのデータを書き足した後、ファイルをクローズする操作をします。
対象ファイルのディレクトリを読みます。このとき、対象ファイルのディレクトリがルートディレクトリの先頭付近にあれば、１回で済みます。フォルダのネスティングが１段深くなると、最低１回のリードアクセスが追加されます。
ディレクトリの情報から、書き足す位置を計算して、ファイルの最終位置のＳＤカードのセクタを読みます。
ディレクトリの情報から、書き足す位置を計算して、５１２バイト境界で終了していれば、上記の読み出しは発生しません。
最終位置のセクタデータに、書き足すデータを追加します。この場合、読み出しサイズ＋書き足しサイズが５１２バイトを超えると２セクタ分書くことになりますが、５１２バイト境界から５１２バイトしか追加しないので、２セクタ分書く操作は理論上必要がないと思われます。
ファイルが大きくなったので、その旨サイズ情報を書き換えるため、ディレクトリを書換えます。
以上のような過程でファイルと管理部分の更新が行われ、最短で１回の読み出し、２回のライトで、ファイルデータの追加が終わります。
では、最悪どれだけのアクセスがあるのか、考察してみます。ただし、対象ファイルのディレクトリが、ルートの先頭付近にあるものとします。（ロングファイル名でなければ、ファイルディレクトリのサイズは３２バイトですから、ルートの最初のディレクトリの場所には、１６個のファイル情報を格納できます）
ファイルの追加で再オープン時、ファイルのサイズが大きいと、ＦＡＴテーブルの読み出しが行われ、ＦＡＴ３２の場合、ファイルサイズがクラスタ容量の１２８倍を超えるたびに、１回のリードが追加されます。ＦＡＴ１６の場合は、クラスタ容量の２５６倍単位。
データの追加で、５１２バイトの境界を越えた場合、１回のライトが追加されます。
データの追加で、クラスタ境界を超えたばあい、ＦＡＴテーブルの読み出しが最低１回追加され、ライトも２回追加されます。
上記の条件の場合で、ＦＡＴテーブルが、５１２バイト境界にまたがって更新される場合、さらに、２回の読み出し、２回のライトが追加されます。
とまあこんな具合ですが、いわゆる
細かく断片化したフラグメンテーション
だと、どんどんアクセス回数が増加していきます。上記の予想は、断片化が無いものとしての、理論的に予想される回数ですが、実際に、ＦａｔＦｓでアクセス回数のカウントをしてみると、さらに１回多い結果になりました。ちなみに、０ｘ２００バイトのデータを、ファイルに追加する場合、元のファイルが、０ｘ２００の整数倍のサイズだったとし、約１ＭＢあったとして、０ｘ２００単位で追加のためのファイルオープン、追加、クローズを１０２４回ほど繰り返すと、最大リード回数７回、ライト回数７回という結果になりました。
たった０ｘ２００バイトのデータをファイルに追加するだけで、７回もライトされることがある
ということです。
しかし、たとえ７回リード、７回ライトであっても、リードで通常２〜３ｍｓ、ライトで５〜１０ｍｓほどなので、合計で約７０ｍｓ程度です。そこで、ファイルに 0x200 バイトのデータを追加する操作で、どれだけ時間がかかるのか、テストするプログラムを作ってみました。ライトするデータは、0x200 バイト固定で、0x200 バイトの先頭に、時間データを埋め込んで、後で詳しく経過を見られるようにしました。時間データは、RX62N のリアルタイムクロックのレジスタを読み出して文字コードに変換して書きます。時間の分解能は、1/128 秒になりますが、RX62N の、RTC レジスタから読み出す途中で変化が起こると困るので、1/128 秒のカウンタポート( 0x8C400 番地の byte ポート ) が、127 の時は、１秒が繰り上がるのを待ってから、全体を読み出して時間データとします。
また、0x200 バイトを追加する処理を６４回繰り返した後で、途中経過として、セクタリード最大回数、セクタライト最大回数、最大処理時間、平均処理時間、平均セクタライト回数を、コンソールターミナルに報告するようにします。
以下は、スクリーンショットです。
１、パワーＯＮの後、ＲＡＭ用プログラムをロードして、0x400 番地から実行
２、date コマンドで日付を確認。その後、mount コマンドで FatFs を使えるようにしています。
３、dir コマンドで、ディレクトリの表示。すでに、TEST という１ＭＢのファイルがあります。
４、F10000,200 test で、0x200 バイト追加を、0x200 回行います。
この例でも判る通り、０ｘ２００バイトの追加で、最大 ０．４３７ 秒かかっています。
このテストを行う回路は、
ＲＸ６２ＮのＳＰＩでＳＤカードを操作
で紹介している回路から、以下のように追加、変更しています。
ＳＰＩポートとして、ポート０を選択できるようにしています。これは、ＪＴＡＧを使えるようにするためです。
ＵＡＲＴポートとして、ポート１、ポート２を選択できるようにしています。これは、ＳＩＯでブートできるように、ＳＩＯ１を選択できるようにするためと、ＳＩＯ２を追加で使えるようにするためです。
ポート選択を可能にした、ＳＤカード操作のモニタ（ FatFs 機能付き ) の
cygwin ソースファイル一式です。
rxsdfs2t.lzh
ＳＰＩポートの選択追加。ＳＰＩのポート０を使えるように改造。
ＵＡＲＴポートの追加、選択。コンソール用簡易ＲＳ２３２Ｃは、ＳＩＯポート０を使います。
工事中
ＳＤカードへのライトで、コマンド、レスポンス、ライト完了までの時間を個別に測定してみる
このような測定をするのにＦａｔＦｓで行おうとすると、時間を測定する位置をきっちりと指定しにくいので、
ＲＸ６２ＮのＳＰＩでＳＤカードを操作
での操作で測定します。というのは、ＦａｔＦｓの send_cmd 関数が、コマンドを出す前に、ＳＤカードのＢＵＳＹを確認しているので、「ちょうどこのライトのときの時間」をすんなり測定できないからです。ライトコマンドの後、データを送ってＳＤカードからレスポンスがあり、その後ＳＤカードのＢＵＳＹが解除されるまで待つという１連の処理の、始めと終わり、さらに途中も含めた時間計測をするには、ＦａｔＦｓで用意された、ＲＸ６２Ｎ用の、mmc_rspi.c のＢＩＯＳインターフェイスを改造するには、ff.c 本体に立ち入った変更箇所が多くなって、ＳＤカードの正常な制御ができなくなる恐れがあるので、あきらめました。
ＦａｔＦｓでは、ＳＤカードへのライト処理は、ＳＤカードにデータを送ってしまうと、f_write() 関数からすぐに戻ってきます。そして次にコマンドを出す前に、ＢＵＳＹを見ているのです。無論、こうすると、ＳＤカード側での処理を待つことなく、ＣＰＵは別の処理ができるので、全体のパーフォーマンスを上げることができるので、このような操作になっているものと思われます。
工事中
ホーム に戻る
SEO
