バックナンバーはこちら。
https://www.simulationroom999.com/blog/In-vehicle-external-storage-backnumber/
はじめに
FatFs WinシミュレーションでSDカードに直接制御する話。
今回は「FatFs改造」の話の詳細続き。
登場人物
博識フクロウのフクさん
イラストACにて公開の「kino_k」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=iKciwKA9&area=1
エンジニア歴8年の太郎くん
イラストACにて公開の「しのみ」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=uCKphAW2&area=1
実験手順
想定実験手順は以下。
「FatFs改造」の話の詳細の続きになる。
- FatFs改造方針を考える
- FatFs改造 ← これの3回目/全3回
- FatFsでSDカードのFAT認識
- FatFsでファイル書き込みとWindowsでの認識
- FatFsでFAT32フォーマットしてWindowsで認識
そして、全体構成
ソースコードの修正差分で気になった部分は以下で、
前回、dismount_volume関数についてやったところだね。
- dismount_volume関数
- main.cのVolToPart配列
VolToPart配列について説明しよう。
VolToPart配列
まず、この配列自体はFatFsとしては以下の状況を想定したものとなる。
- マルチボリューム
- マルチパーティション
今さらだけどボリュームとパーティションの関係性がイマイチわかってないんだけど・・・。
そうだねー。
ボリュームは論理ドライブの連番。
パーティションは一つの物理ドライブを複数の論理ドライブに分割。
ってイメージかな？
今回のVolToPart配列は以下だよね？
PARTITION VolToPart[FF_VOLUMES] = {
{0, 1}, /* "0:" ==> 1st partition on PD#0 */
{1, 0}, /* "1:" ==> PD#1 */
{2, 0}, /* "2:" ==> PD#2 */
{3, 0}, /* "3:" ==> PD#3 */この場合だとどうなるのかなって。
最初の「{0, 1},」FatFsに最初から実装されてるRAMディスクで、
その後の{1, 0}～{3, 0},を示している状態。
これは先にPARTITION構造体を説明した方が良いな。
PARTITION構造体
PARTITION構造体の定義を見ると、以下。
typedef struct {
BYTE pd; /* Physical drive number */
BYTE pt; /* Partition: 0:Auto detect, 1-4:Forced partition) */
} PARTITION;コメントを読むと分かるんだけど、
pdが物理ドライブ番号で、ptがパーティション番号。
そしてPARTITION構造体配列の先頭からボリューム番号。
って関係性だ。
この構造体配列をちゃんと宣言してあげれば、
それに合わせてボリュームが定義されるってことか！
そうなるね。
複数の物理ドライブ、最大4つまでのパーティションの管理が可能だ。
フリーなFileSystemだけど結構しっかりしてるんだねー。
確かにすごいことだね。
使わなきゃ勿体ない。
次は？
じゃー、そろそろ実際に動かしてみるってところかな？
そうだね。
主だった修正箇所は説明し終えたんで、
あとは動かして、ダメだったらまた調べてみるってところか。
まぁ事前実験では動いたんで大丈夫なはずだけど。
(ここまで説明しておいて、「動きません！」って結果じゃーさすがにカッコ付かないよねー。)
まとめ
まとめだよ。
- FatFs内のVolToPart配列について説明。
- マルチボリューム、マルチパーティション想定したパラメータ。
- PARTITION構造体について説明。
- 物理ドライバ番号とパーティション番号が格納される。
- これにより、論理ドライブ番号、物理ドライブ番号、パーティション番号が紐づけられる。
バックナンバーはこちら。
コメント