(ホントは７４ＨＣ、ＣＭＯＳなんだけど…）
［第４８１回］
●ＷｒｉｔｅＦｉｌｅ（）関数の続きです（ＨＩＤの怪を追求）
正直なところ、こんなことにこだわっている暇はないはずなのですけれど…。
若いころならば、「あー、無視。無視。次行きましょー」だったのですが、それがトシをとってきますと、「お若いの。そんなに急いでどこへ行きなさる？ほれ。野辺は花盛りというに。しばし花などを愛でてみてはいかがかな？」という気分になってまいります。
君子忙中有閑。
で。なんとなく気になるＨＩＤの「６５バイトルール」について、貴重な１日を割くことにしまして、いま少し追求を試みることといたしました。
まずは前回（［第４８０回］）のテスト結果を読み直してみて、気が付いた点について確認をしてみました。
前回、ＰＩＣ１８Ｆ４５５０のＨＩＤレポートディスクリプタの設定を、４０（＝６４）バイトから２０（＝３２）バイトに変更してのテストで、ＨＩＤ送信プログラムの送信バッファの第１バイトｗｂｆ［０］の値が００ではなくてＦＦにしたままであったところを、念の為に００に直して、再度テストしてみました。
しかし、結果は前回の結果と何も変わりませんでした。
もうひとつ。ひょっとしたら、ＨＩＤレポートディスクリプタの設定を、４０（＝６４）バイトから２０（＝３２）バイトに変更したのですから、ＷｒｉｔｅＦｉｌｅ（）関数の第３パラメータ（ｎｗｒｉｔｅ）の値を２１（＝３３）にしても、今回はエラーにはならないのではないか、と考えました。
で、そのようにＨＩＤ送信プログラムを書き換えてテストしてみたのですが…。
結果はやっぱりエラーになってしまい、送信できませんでした。
やはりＨＩＤレポートディスクリプタの設定とは関係なく、ＨＩＤでのＷｒｉｔｅＦｉｌｅ（）関数の第３パラメータはつねに４１（＝６５）を指定しなければならない、ようです。
次にもうひとつ。
受信側（当社ＺＢ２５Ｋ）なのですが、簡易的なプログラムでテストをしたものですから、事実を誤認しているところがあるかもしれません。
ＺＢ２５Ｋ側の受信プログラムを変更して、再度テストをしてみました。
すると、意外な事実が判明したのであります。
前回、「…／ｍｏｇａｍまでの３２バイトが送信された」と書きました。
受信側の表示では、確かに／ｍｏｇａｍの後ろは意味不明の文字列になっています。
私はこれを見て単純に「送信されたデータは３２バイト」だと早合点してしまったのです。
事実はそうではありませんでした。
受信側（ＺＢ２５Ｋ）のプログラムを変更して、再度テストしてみた結果です。
前回のテストでは見えていなかった、終わりの部分「ｇａｗａ」が現れました。
でも中間にゴミが挟まっています。
そして１文字「ｉ」が落ちています。
むむ。
なんだか推理小説の謎解きめいてきましたよ。
おおお。
これは？
ひょっとしたら…！
こちらは同時にチェックしたオシロスコープの波形です。
下側（ＣＨ２）がＲＳ２３２Ｃ（ＲＳ４８５）の送信データ（ＰＩＣ１８Ｆ４５５０のＴＸ出力）です。
上側は（ＣＨ１）ＭＡＸ４８５の送信／受信を切り換えるための信号です。
送信開始でＨ、送信終了でＬになります。
●ＰＩＣ１８Ｆ４５５０回路図
参考までに、ＰＩＣ１８Ｆ４５５０ＨＩＤテスト基板の回路図をお見せします。
さきほどのオシロスコープのＣＨ１は、ＰＩＣ１８Ｆ４５５０の２ｐｉｎの出力波形で、ＣＨ２は２５ｐｉｎの出力波形です。
ＣＨ１の波形をよく見ると、途中約４０ｍｓｅｃのあたりにＬ信号が確認できます。
これは、ＲＳ２３２Ｃの送信が２回行われたことを示しているのです。
でも最初の送信は約４０ｍｓｅｃなのに、次の送信は約７０ｍｓｅｃほどもあります。
これは？
ボーレートは９６００ボーです。１バイトの送信ごとにスタートビットとストップビットが付加されますから、転送速度は９６０バイト／秒になります。
ということは、約４０ｍｓｅｃの間に送信された文字数は、９６０×０．０４≒３８文字です。
これは、Ｗｉｎｄｏｗｓマシンから送信されたはずの文字列「ｓａｍｉｄａｒｅ…ｍｏｇａｍｉｇａｗａ（および０Ｄ０Ａ）」の文字数３８バイト（２６Ｈ）にぴったり一致します。
ＰＩＣ１８Ｆ４５５０はどこからこの送信文字数を得たのでしょうか？
そうです。
Ｗｉｎｄｏｗｓマシンからは、送信する文字列の先頭に、文字列の総バイト数を挿入して送る、というのが今回のＨＩＤ送信のルールでした（［第４７９回］）。
このページのトップでお見せした送信テストの実行結果の画面では、右のＤＯＳ窓（ＨＩＤ送信プログラムを実行）で、データの先頭に［２６］が表示されていることがわかります。
ＰＩＣ１８Ｆ４５５０は、Ｗｉｎｄｏｗｓマシンから送られたデータの先頭につけられた、送信データ数情報の２６（＝３８）にしたがって、ＲＳ２３２Ｃで３８バイトの文字列を送出したのです。
もう一度、このページのトップでお見せした送信テストの実行結果の画面で、今度は左側のＤＯＳ窓、ＺＢ２５Ｋの受信データを見てみましょう。
ｓａｍｉｄａｒｅｏ／ａｔｓｕｍｅｔｅｈａｙａｓｈｉ／ｍｏｇａｍォSツｊ［ｐ６
ここまでで３８文字です。
ここで一旦送信が切れて、そのあと
ｇａｗａ
が送信されたことが、さきほどのオシロスコープの波形から推測されます。
画面からはわからないのですが、実はｇａｗａのあとに改行コード０Ｄ・０Ａがあって、そのあとに００が続いていることがわかっています。
ああ。
それもお見せすることにいたしましょう。
ＺＢ２５ＫがＰＩＣ１８Ｆ４５５０から受信したデータはＺＢ２５Ｋの配列ＤＤ＄に格納されます。
ＤＤ＄の領域はダイレクトにはちょっとアクセスしにくいので、固定領域のＡ＄〜Ｄ＄に移してから、メモリダンプしてみました。
ＺＢＫ・ＢＡＳＩＣの文字変数のサイズは４０バイトの固定サイズです。
先頭に１バイトの文字数情報が入りますから、文字型の１変数に格納できる文字数は最大で３９文字です。
いま、受信データはＦ３００〜Ｆ３２７、Ｆ３２８〜Ｆ３４Ｆ、Ｆ３５０〜Ｆ３７７、Ｆ３７８〜Ｆ３９Ｆの順に４つの変数エリア（Ａ＄、Ｂ＄、Ｃ＄、Ｄ＄）に納められています。
ここからがＺＢＫの側の仕様でちょっとややこしくなるのですが、水色で囲んだ４つの数値は各変数エリアの先頭にあって、そこに格納されている文字数を示しています。
最初のブロックを見ますと、格納文字数は２７（＝３９）です。
そのうち３８文字をピンクで囲いました。
この３８文字がＰＩＣ１８Ｆ４５５０から最初に送信されたグループなのです。
ＺＢＫＢＡＳＩＣは改行コード０Ｄ０Ａを見つけるまでは、連続したデータ列とみなすので、途中で送信が途切れてもそのまま待ち続けます。
そのために、受信した結果からは送信の切れ目はわかりませんが、先に推論した結果から、ここに送信の切れ目があったと考えられます。
ああ。そうでした。
これも確認できることに気が付きました。
さきほどのオシロスコープの波形を拡大してみました。
最初の送信データの最後のところです。
００１１０１１００と読めます。最初の０はスタートビットです。ＲＳ２３２Ｃのデータはビット０からビット７の順に送られます。
これを普通のバイナリ（２進数）の表記に直すと、００１１０１１０ですから、１６進数の３６です。これは文字”６”のＡＳＣＩＩコードです。
こちらは次の送信ブロックの最初のデータです。
０１１１００１１０と読めます。
さきほどと同様に、普通のバイナリ（２進数）の表記に直すと、０１１００１１１ですから、１６進数の６７です。これは文字”ｇ”のＡＳＣＩＩコードです。
これで文字コード３６（文字”６”）が最初の送信ブロックの最後で、文字コード６７（文字”ｇ”）が次の送信ブロックの最初のデータであることが確認されました。
一体それがどういうことを意味しているのか、まだおわかりいただけないかもしれません。
私としても、うまく説明できないもどかしさを感じています。
ええ。
私は、何が起きたのか、今ははっきりわかっていると思います。
こういうことなのです。
ＰＩＣ１８Ｆ４５５０は、ホストからの着信があると（その受信データはオートマチックに受信バッファに格納されます）、その受信したデータを最初の１バイトの値（ホストからの送信バイト数を示す）に従ってＲＳ２３２Ｃで送出するようにプログラムされています。
［２０１０．４．２０注記］
ＰＩＣ１８Ｆ４５５０に、そのような機能がある、ということではありません。
もちろん、「そのようにプログラムした」のは、この私です。
ＰＩＣ１８Ｆ４５５０の機能としては、ＵＳＢとＲＳ２３２Ｃの機能は完全に独立して存在していますし、それらを連動させるような、都合のよい仕組みは用意されていません。
いずれそのプログラムの内容についても説明をする時があると思います。
独立して存在しているＵＳＢ（ここではＨＩＤ）の受信データを、ＲＳ２３２Ｃで送信するように「私がＰＩＣアセンブラでプログラムしました」という意味です。
また下の文で、「受信バッファは６４バイト」としているところも、「私がそのようにプログラムしたから」です。
ＰＩＣ１８Ｆ４５５０ではＵＳＢのバッファは任意のバイト数で任意の個数を用意することができますが、そのようにプログラムしなければ、ＰＩＣ１８Ｆ４５５０は何もしてくれません。
もちろん「最初の１バイトが送信文字数を示している」ことも、「私がそのようにプログラムしたから」です。
それからずっと下の方で出てきますが、「ＲＳ２３２Ｃの送信カウンタに値をセットして」というところも、ＰＩＣ１８Ｆ４５５０に「送信カウンタ」や「バッファのデータをＲＳ２３２Ｃで送信してくれる」機能がもとから備わっている、という意味ではありません。
それも「そのようにアセンブラでプログラムしたから」です。
［注記ここまで］
ＰＩＣ１８Ｆ４５５０の受信バッファは６４バイトで、実際に何バイトがホストから送られたのかを知ることはできませんが、最初の１バイトが送信データ数を示しているとの約束に従って、受信バッファの２番目以下の文字列をＲＳ２３２Ｃで送出します。
ホストから送られた最初のデータはおそらく２６（＝３８）のはずなので、ＰＩＣ１８Ｆ４５５０からはＲＳ２３２Ｃ経由でＺＢ２５Ｋに３８文字のデータが送られた、と考えられます。
それではなぜ、ＺＢ２５Ｋが受信した３８文字のデータのうち、本来含まれているはずのｍｏｇａｍより後ろの７文字がでたらめな文字列に置き換わってしまっていたのでしょうか？
ううう。実にミステリーです。
合理的な答えはただひとつです。
それは、Ｗｉｎｄｏｗｓマシンからは３２文字しか送られてこなかったから、なのです（その３２バイトという数値は、ＨＩＤレポートディスクリプタで指定した値です）。
そうとしか考えられません。
最初の１バイトは文字数情報ですから、データの本体は３１文字です。
だから、ＰＩＣ１８Ｆ４５５０の受信バッファには、３１文字のデータｓａｍｉｄａｒｅ〜ｍｏｇａｍまでしか入っていなかったのです。
しかしＰＩＣ１８Ｆ４５５０は第１バイトの示す文字データ数情報に従って受信バッファから（３１文字ではなくて）３８文字を取り出して、それをＺＢ２５Ｋに送信してしまった、というのがことの真相です（と思います）。
では、その次のデータブロックの「ｇ」＋「ａｗａ」は何を意味しているのでしょうか。
さきほども説明しました通り、「ｇ」はＲＳ２３２ＣでＰＩＣ１８Ｆ４５５０からＺＢ２５Ｋに送信された、２番目のデータブロックの最初の文字です。
その後に続く文字列は、ＺＢ２５Ｋの次の文字変数Ｂ＄に格納されています。
アドレスはＦ３２８〜Ｆ３４Ｆです。
さきほどお見せしたＺＢ２５Ｋの変数エリアデータの表示画面を見てください。
Ｆ３２８には、変数Ｂ＄に格納されている文字数が入っています。
０３が入っていますから、ここに格納されているデータは３文字、つまり「ａｗａ」であることを示しています。
オシロスコープの波形では、第２ブロックの送信データは約７０ｍｓｅｃですから、９６０×０．０７≒６７バイトていどはあるはずなのに、ここが３文字であることには理由があります。
上の方でも書いたと思いますが、ＺＢＫＢＡＳＩＣでは改行コード０Ｄ０Ａを受信するとそこが文字列の区切りだと判断して、そこで格納する文字変数を次の変数に切り換える仕組みになっています。
このとき、０Ｄ０Ａコードそのものは、文字変数に格納されません。
つまり、ＺＢ２５Ｋのメモリダンプ結果からは、ａｗａの後ろに０Ｄ０Ａコードがあったことがわかります。
以上のことをまとめてみると、どうなるでしょうか。
こういうことがおきた、と考えられます。
ＨＩＤにおけるＷｒｉｔｅＦｉｌｅ（）関数の制約から（と思われます）、送信バイト数は４１（＝６５）を指定することしか許されませんが、それにもかかわらずＨＩＤレポートディスクリプタが指定した２０（＝３２）バイトに従って、実際には、先頭の文字列データ数情報の１バイトと、それに続く３１文字のデータ（合計３２バイト）がＰＩＣ１８Ｆ４５５０に送られた、と考えられます。
これは推測するしかないのですが、おそらくＷｒｉｔｅＦｉｌｅ（）関数はＨＩＤデバイスに対するハンドルを使った場合、第３パラメータ（送信バイト数）は４１（＝６５）しか受け付けないようにガードがかかっているのではないでしょうか。
しかしその下層にＨＩＤ送信ルーチンがあって、そこではレポートディスクリプタで指定されたバイト数だけを送信する、のだと考えられます。
するとここで、上層のＷｒｉｔｅＦｉｌｅ（）関数が定義している４０（＝６４）バイトの送信データと、下層のＨＩＤ送信ルーチンが従っている２０（＝３２）バイトの間でずれが生じます。
下層のＨＩＤ送信ルーチンは、まだ後半の２０（＝３２）バイトを送信していませんから、そのために、１回の送信では完了せずに、続いて２回目の送信が行われた、のではないでしょうか。
当然、２回目に送信されたデータは、１回目に送信されたデータの続き、のはずです。
１回目は、…ｓａｇａｍで終わっていましたから、２回目は、その続きのｉｇａｗａ＋０Ｄ＋０Ａになるはずです。
しかし、実際にＰＩＣ１８Ｆ４５５０からＺＢ２５Ｋに送信されたのは、ｇａｗａ＋０Ｄ＋０Ａでした。
いったい「ｉ」はどこに行ってしまったのでしょうか？
また、２回目にＰＩＣ１８Ｆ４５５０からＺＢ２５Ｋにどうして約６７バイトものデータが送られたのでしょうか。
そこからも、興味深い意外な事実が浮かび上がってきます。
実は、２回目に送信されたデータバイト数は、およそではなくて、正確に求めることができます。
もう一度、さきほどのＺＢ２５Ｋの変数エリアデータの表示画面を見てください。
さきほどまでの説明で、ＺＢ２５Ｋのメモリダンプの結果から、２回目の受信データは、「ｇ」＋「ａｗａ」＋０Ｄ＋０Ａである、というところまでは明らかになりました。
では、そのあと、どれだけのデータがＰＩＣ１８Ｆ４５５０から送られたのでしょうか。
それは、その次の変数Ｃ＄とＤ＄の格納データ数情報を見ることでわかります。
Ｃ＄の格納データ数情報はアドレスＦ３５０にあります。水色で囲った２７（＝３９）バイトです。
Ｄ＄の格納データ数情報はアドレスＦ３７８にあります。水色で囲った１２（＝１８）バイトです。
以上の情報から、２回目にＰＩＣ１８Ｆ４５５０からＺＢ２５Ｋに送信されたデータは、
１＋３＋１＋１＋３９＋１８＝６３バイトであることが確認できます。
その数字の意味についてはちょっと置くことにしまして、まずは、２回目に送信されたデータの中身について確認してみたいと思います。
送信されたデータの改行コード０Ｄ０Ａの後ろのデータは変数Ｃ＄に格納されています。
アドレスＦ３５１から後ろです。
このデータを見ますと、００が２５個あります。その後ろはその前の変数にも見える「ゴミデータ」と同じです。
００が２５個、ということに何か意味があるのでしょうか？
大有りなのです。
ＨＩＤ送信テストプログラムでは送信バッファとしてｗｂｆ［］を用意しました。６５バイトのバッファです。
ｗｂｆ［］を定義するときに、同時に値として”￥０”を定義しました。
つまり、初期値はオール００です。
そこに、ｗｂｆ［１］から（ｗｂｆ［０］からではありません）、先頭の文字数情報１バイト＋「ｓａｍｉｄａｒｅ…ｍｏｇａｍｉｇａｗａ」３６バイトおよび０Ｄ、０Ａコードの合わせて３９バイトの文字列が代入されます。
６４−３９＝２５ですから、０Ｄ０Ａの後ろには２５個の００データがあるはずです。
ああ。そうでした。
そんな計算をしなくても、最初にお見せした、送信テストの実行結果の画面を見れば、右のＤＯＳ窓の送信データの表示で、［００］が２５個表示されていることがわかります。
ということは、さきほどの推論に従えば、この００データの終わりが、ホストからＰＩＣ１８Ｆ２５５０に２回目に送信されたデータの終わりである、と考えられます。
仮に２回目に送信されたデータの先頭が、「ｇ」＋「ａｗａ」＋０Ｄ＋０Ａである、と考えて、送信データ数を計算してみると、
１＋３＋１＋１＋２５＝３１バイトになります。
６４バイトの送信バッファｗｂｆ［］から、３２バイトずつちょうど２回に分けて送信された、と考えられるのですが…。
うむむ。
なんとなく合いそうで、どこかがずれているようです。
何なのでしょうか？
さきほども書きましたように、最終的にＺＢ２５Ｋに送信されたデータをつなぎ合わせてみると、確かに６４バイトのデータがホストからＰＩＣ１８Ｆ４５５０に３２バイトずつ２回に分けて送信された、ように見えるのですが、しかし、後半が１バイト足りません。
どうも「ｉ」の文字が１文字落ちてしまっているようです。
そしてまた、ＺＢ２５ＫがＰＩＣ１８Ｆ４５５０から受信したデータは１回目が３８バイトで、２回目はなんと６３バイトである、という事実は何を物語っているのでしょうか？
実は皆様にお知らせしていない事実がひとつありました。
それは、ＰＩＣ１８Ｆ４５５０がＺＢ２５Ｋに受信バッファのデータを送信するとき、そのバッファの先頭のデータを送信バイト数としてカウンタにセットするのですが、例外が２つあるのです。
その第１は、送信データ数として受信した値が００であったときは、ＲＳ２３２Ｃ送信を行わない、ということです。
その第２は、もしも送信データとして受信した値が、受信バッファの最大データ容量（６３バイト）を超える場合には、６３バイトを送出して、そこでＲＳ２３２Ｃの送信を打ち切る、というルールです。
以上で、謎を解く鍵は、包み隠すことなく全て読者の皆様に公開いたしました。
おそらく、聡明なる読者の皆様におかれましては、すでにことの真相を突き止められたことでありましょう。
以下は私が推理して到達した、ことの真相です（と思います）。
すでに説明いたしましたとおり、おそらくＷｉｎｄｏｗｓマシンからは６４バイトのデータが３２バイトずつ２回に分けて送信されたのだ、と思います。
ではなぜ、２回目の送信データの先頭にあったはずの「ｉ」の文字が、ＰＩＣ１８Ｆ４５５０からＺＢ２５Ｋに送信されたデータからは消えてしまい、またなぜＰＩＣ１８Ｆ４５５０からＺＢ２５Ｋへの２回目の送信データ数が６３バイトだったのでしょうか。
ここで皆様方にぜひとも思い出していただきたいのは、ＰＩＣ１８Ｆ４５５０がホストから受信した第１番目のデータをどう扱うか、ということです。
ホストから１回目に送信されたデータの第１番目には送信文字数情報の２６（＝３８）が入っていました。
ですからＰＩＣ１８Ｆ４５５０は、実際に受信した文字データの３１文字に、その後ろのバッファにもとからあった無意味なデータを含めた３８文字を、ＲＳ２３２Ｃで送出してしまったのです。
ではホストから２回目に送られたはずのデータの、第１番目は何だったのでしょうか？
そうです。
おそらく、１回目に送信された、…ｍｏｇａｍに続く文字「ｉ」だったはずです。
２回目には、ホストからは、「ｉｇａｗａ０Ｄ０Ａ…」という文字列が送信されてきたはずです。
しかしＰＩＣ１８Ｆ４５５０は、ルールに従ってその先頭の文字「ｉ」を文字としてではなく、「送信文字数」として、そのコードである６９（＝１０５）を送信カウンタに入れてしまったのです。
そして、その次の文字から後ろの「ｇａｗａ０Ｄ０Ａ…」をＲＳ２３２Ｃで送出したのです。
しかし、６９（＝１０５）はＰＩＣ１８Ｆ４５５０の受信バッファの最大容量（６３バイト）を超える値です。
そのためＰＩＣ１８Ｆ４５５０はバッファの最初のデータである「ｇ」からバッファの最後までの６３バイトを送出したところで、送信を打ち切ってしまったのだと考えられます。
２０１０．４．１９ｕｐｌｏａｄ
２０１０．４．２０注記
前へ
次へ
ホームページトップへ戻る