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