ＴＴＬでＣＰＵを作ろう！

~~標準ＴＴＬ~~だけ（！）でCPUをつくろう！（組立てキットです！）
(ホントは７４ＨＣ、ＣＭＯＳなんだけど…）
［第４８０回］

●ＷｒｉｔｅＦｉｌｅ（）関数

いつものことなのですが、前回は時間がなくなってしまいましたので、ＨＩＤ送信プログラムについて詳しく説明することができませんでした。
今回はＷｒｉｔｅＦｉｌｅ（）関数について、すこし詳しく説明をいたします。

ＷｒｉｔｅＦｉｌｅ（）関数はＷｉｎｄｏｗｓＡＰＩです。
ＭＳＤＮライブラリ（http://msdn.microsoft.com/ja-jp/library/cc429856.aspx）にその説明があります。
そのページでは下記のように説明されています。
同じページの下の方には、各パラメータについての詳しい説明もあるのですが、例によって業界用語の羅列で概ね意味不明です。
つまり、ドシロウトは立入禁止、ということのようです。

BOOL WriteFile(
  HANDLE hFile,                    // ファイルのハンドル
  LPCVOID lpBuffer,                // データバッファ
  DWORD nNumberOfBytesToWrite,     // 書き込み対象のバイト数
  LPDWORD lpNumberOfBytesWritten,  // 書き込んだバイト数
  LPOVERLAPPED lpOverlapped        // オーバーラップ構造体のバッファ
);

前回のＨＩＤ送信プログラムでは、

if(!WriteFile(handle,&wbf,nwrite,&nwritn,NULL))cout<<"write error"<<endl;

というように使いました。

ファイルのハンドル、データバッファ、書き込み対象のバイト数、書き込んだバイト数については説明がなくてもわかります。
最後のパラメータについてはよくわかりませんが、ここはＮＵＬＬにしておけばよいようです。
第２パラメータ（データバッファ）と第４パラメータ（書き込んだバイト数）はポインタを指定します。

ＨＩＤの場合、第３パラメータ（書き込み対象のバイト数）は要注意です。
前回のＨＩＤ送信プログラムでは、

DWORD nwrite=65;//not 64!

としました。

ＨＩＤでは送信および受信はフルスピードモードでは６４バイトということになっています（［第４２３回］）。
［第４２３回］で引用しました「ＵＳＢ２．０　Ｓｐｅｃｉｆｉｃａｔｉｏｎ」のＣｈａｐｔｅｒ　５には、下記のように書かれています。

６４ｂｙｔｅｓ　ｏｒ　ｌｅｓｓとあります。
それならＷｒｉｔｅＦｉｌｅ（）関数の第３パラメータには６４バイト以内なら何を指定してもいい、とつい誤解してしまいますが、そういう意味ではないようです。
たとえ１バイトしか送信するデータが無い場合でもダミーデータと一緒にして、常に６４バイトを送信しなければいけません。

念の為に、ＨＩＤ送信プログラムの送信バイト数を６０に直して実行してみました。

ご覧の通り、ｗｒｉｔｅ　ｅｒｒｏｒになってしまいました。
やっぱりＨＩＤではいつも６４バイトを送信しなければいけないようです。

ところで。
では、６４バイトではなくて、なぜ６５バイトなのか？
ということなのですが…。

確かにどこかのサイトにそのようなことが書いてあったと思ったのですが、でも今調べてみますと、どこだったのわかりません。
ＷｒｉｔｅＦｉｌｅ（）はＲＳ２３２Ｃでも使っていますから、そのような制約がＷｒｉｔｅＦｉｌｅ（）にある、ということではないはずです。
ＨＩＤの場合については、ＷｒｉｔｅＦｉｌｅ（）、ＲｅａｄＦｉｌｅ（）では、そうしなければならない、ということのようです。

念の為、ＤＷＯＲＤ　ｎｗｒｉｔｅを６４、６５、６６と変えて試してみましたが、ｎｗｒｉｔｅ＝６５以外はｗｒｉｔｅ　ｅｒｒｏｒになってしまいました。

なお実際に送信されるのはｗｂｆ［１］～ｗｂｆ［６４］の６４バイトで、ｗｂｆ［０］は送信されません。
ｗｂｆ［０］には０（ＮＵＬＬ）を指定する、ということのようだったと思うのですが、それも念の為、ｗｂｆ［０］＝０ｘｆｆとして試してみたところ、それについては特にエラーにもならず正しく送信できました。
しかしあえてそのようにする必要もありませんから、ここはおとなしく

unsigned char wbf[65]="\0";

としておくのがよいでしょう。

と、ここまで書いてきてから、はてね？
と思い当たるところがありました。
ｎｗｒｉｔｅ＝６５にしなければエラーになってしまう、ということは、ひょっとすると、ＵＳＢ接続時にＰＩＣからホストに送られるＨＩＤレポートディスクリプタの設定値がもとになっているのでは？

うむむ。そうなのかもしれません。
でも、まあ、学校の研究レポートではありませんから、その設定値を変えてまで試してみる必要は、私の場合には、ありません。
とにかく、送信も受信もＨＩＤの場合の最大値である６４バイトに設定して使いますから、その場合にはｎｗｒｉｔｅ＝６５にする、ということになります。
ここは、それでよい、ということにいたしましょお。
ではみなさま。おやすみなさい。

のつもりだったのですが、またまた、ひょっとしたら、と思いついて、［第４７７回］でご紹介させていただきました、ｅｍａ様のサイト（http://emaame.com/20061227.html）を再び訪問させていただきました。
おお。やっぱり。ここだったのですねえ。

ＨＩＤ送信テストプログラムの
//write file test
以下のところを、次のように書き変えてみました。

//
PHIDP_PREPARSED_DATA pp;
if ( !HidD_GetPreparsedData( handle, &pp ) )return;
//
HIDP_CAPS caps;
if ( HidP_GetCaps( pp, &caps ) != HIDP_STATUS_SUCCESS )return;
cout << "InputByteLength  : " << caps.InputReportByteLength   << endl;
cout  <<  "OutputByteLength : "  <<  caps.OutputReportByteLength    <<  endl;
        CloseHandle(handle);
}

ｅｍａ様のサイト（http://emaame.com/20061227.html）から、そのままいただいてしまいました。

そして、これが実行結果です。

ＨＩＤレポートディスクリプタでは４０（＝６４）と指定しているのですが、HidP_GetCaps関数で得られるＯｕｔｐｕｔＲｅｐｏｒｔＢｙｔｅＬｅｎｇｔｈおよびＩｎｐｕｔＲｅｐｏｒｔＢｙｔｅＬｅｎｇｔｈは、それよりも１バイト大きい４１（＝６５）バイトになっています。
むむむ。
そういうことだったのですねえ。
やっと、これで、送信バイト数を６５バイトにする根拠が得られました。

うむむ。
そういうことならば…。
さきほどは、学校の研究レポートではありませんから、などと書きましたけれど。
それほど手間のかかることでもありませんから。

ＰＩＣ１８Ｆ４５５０のレポートディスクリプタの、Ｏｕｔｐｕｔ、Ｉｎｐｕｔのバイト数を書き直して、その結果がどうなるかを試してみることにいたしました。

そうしましたら。
なんとも、よくわからない結果となりました。

画面に見えているＰＩＣアセンブラのリストの最下行の
movlw 20;max packet size(Low)
は、もとは４０（＝６４）にしていたところです。
それを半分の２０（＝３２）にしてみました。

ところが、右のＤＯＳ窓の上の方に見えるように、さきほど書き直したＨＩＤテストプログラムを実行してみると、ＰＩＣの値を直したはずなのに、表示された値はやっぱり４１（＝６５）でした。
しかし、この状態で実際にＷｒｉｔｅＦｉｌｅ（）つきのテストプログラムを実行してみますと、画面左のＤＯＳ窓に表示されているように、正しく送信されたのは３２バイトでした。
…／ｍｏｇａｍまでで３１バイトしかありませんが、実は送信データの先頭には１バイトの送信バイト数データがついていますから、それを合わせるとちょうど３２バイトになります。

そうすると、ｃａｐｓ．ＩｎｐｕｔＲｅｐｏｒｔＢｙｔｅＬｅｎｇｔｈとｃａｐｓ．ＯｕｔｐｕｔＲｅｐｏｒｔＢｙｔｅＬｅｎｇｔｈの値が変わらないのがおかしいのですけれど…。
念の為にＷｉｎｄｏｗｓ９８マシンをリセットして再起動させてから、もう一度テストしてみたのですけれど、結果は全く同じでした。
どこかがおかしいようです。

しかし、それはそれとして、仮に送信バイト数を６４バイトよりも小さい値に設定してみたとしても、それでスループットが向上するわけではありませんから、ここはやっぱり６４バイトの固定長として扱うべきなのでしょう。
２０１０．４．１８ｕｐｌｏａｄ

前へ
 次へ
 ホームページトップへ戻る