(ホントは７４ＨＣ、ＣＭＯＳなんだけど…）
［第５７０回］
●ＳＴＲＯＢＥ信号を拡大してみました
前回はＺ８０ＢＡＳＩＣのＰＲＩＮＴ文の実行に時間がかかっているようなので、Ｚ８０ＣＰＵからＰＩＣ１８Ｆ１４Ｋ５０にデータを送るときのＺ８０ＣＰＵ側からのＳＴＲＯＢＥ信号出力と、それを受けるＰＩＣ１８Ｆ１４Ｋ５０のＲＥＡＤＹ／ＢＵＳＹ信号の状態をオシロスコープで見てみました。
するとなんと９００ｍｓｅｃ近くもＳＴＲＯＢＥ信号が出力されたままになっていることがわかりました。
ＳＴＲＯＢＥ信号がＨになっている期間はほんのわずかしかありません。
そのＳＴＲＯＢＥ信号がわずかの間だけＨになっているところを、時間軸を拡大してみました。
ＳＴＲＯＢＥ信号もＲＥＡＤＹ／ＢＵＳＹ信号も短い時間に繰り返し出力されています。
このわずかな期間だけＣＰＵからＰＩＣへデータの送出が行われ、そのほかの大部分の時間はＳＴＲＯＢＥ信号がアクティブになったままになっています。
Ｚ８０ＣＰＵがＰＩＣ１８Ｆ１４Ｋ５０にＰＲＩＮＴ文の出力データを送るためにＳＴＲＯＢＥ信号をアクティブにしているのですが、ＰＩＣ１８Ｆ１４Ｋ５０がそれに応答していない、という状態のようです。
しかし、ＰＩＣ１８Ｆ１４Ｋ５０はＣＰＵクロックが４８ＭＨｚと非常に高速ですし、プログラムの流れを確認してみても、そのように長い時間Ｚ８０ＣＰＵに応答しないなどということは考えられません。
ああ、いや、１つだけ、そのような状態が起こる可能性がありました。
それはＰＩＣ１８Ｆ１４Ｋ５０からＷｉｎｄｏｗｓパソコンにデータを送信するためのバッファがバッファフルの状態になっているときです。
しかし、そのようなことがあるでしょうか？
●ＵＳＢ（ＨＩＤ）ＩＮトランザクション
ＵＳＢ（ＨＩＤ）でＰＩＣ１８Ｆ１４Ｋ５０からＷｉｎｄｏｗｓパソコンへのデータ送信は、ＷｉｎｄｏｗｓパソコンからＰＩＣ１８Ｆ１４Ｋ５０へＩＮトランザクションを要求して、ＰＩＣ１８Ｆ１４Ｋ５０がそれに答えて、データを送出することによって行われます。
前に少し書いたことがあったと思いますが、ホストからのＩＮトランザクションの要求は１ｍｓｅｃ毎に、機械的に行われます。
この要求にはＰＩＣ１８Ｆ１４Ｋ５０は、機械的にでも応答しなければなりません。
答えないでおくとホスト（Ｗｉｎｄｏｗｓ）側のプログラムがハングアップしてしまいます。
でもそれならば、ＩＮトランザクションに答えるための、ＰＩＣ１８Ｆ１４Ｋ５０からの送信バッファがフルになってしまう、ということはありえないのではないか、という気がしますが、実は、そのように簡単ではないのです。
実は、ＷｉｎｄｏｗｓパソコンからのＩＮトランザクションは、アプリケーションの実行とは全く無関係に（！！！）行われるのです。
ＨＩＤというのは、とんでもない仕組みなのですよお。
たとえば、ＲＳ２３２Ｃ受信ならば、ファイルをＯＰＥＮしたときから、受信スタンバイになりますが、もちろんホストが勝手にＲＥＡＤするなどということはありえないので、送信側から送信されてきたときにその送信データを受信バッファに読み込みます。
この読み込みはアプリケーションの実行とは非同期に行われますが、しかし、ＲＳ２３２Ｃ受信では、データの受信後にＲｅａｄＦｉｌｅ（）を実行すれば、その受信バッファに読み込まれているデータを取り出すことができます。
しかしＨＩＤの場合は、送信側から送信されてくるのを待つのではなくて、ホストの側から勝手に１ｍｓｅｃに１回、データを送るように要求し、いわば強制的に、といいますか、無理やりにといいますか、データを送出させてしまうのですが、その後１ｍｓｅｃ以内にアプリケーションがＲｅａｄＦｉｌｅ（）を実行しないときは、その受信データは捨てられてしまうのです。
一方ＰＩＣ１８Ｆ１４Ｋ５０の側からは、そのように無理やり送出させられたデータがアプリケーションプログラムに吸い上げられたのか、それとも使われないで捨てられてしまったのかを知ることはできません。
でも、それって、そういうことだと、そのままでは使い物にならないのではありません？
もしも、ＰＲＩＮＴ文のデータをどんどん送って、でも、それがＷｉｎｄｏｗｓパソコンの側で画面に表示されなくて捨てられてしまったら？
ねえ。使い物になりませんでしょう。
●Ｚ８０ＢＡＳＩＣでのＨＩＤ受信の工夫
そこで、Ｚ８０ＢＡＳＩＣではなかなかに面倒なことをやっているのです。
ＰＩＣ１８Ｆ１４Ｋ５０は、ＵＳＢ（ＨＩＤ）の６４バイトの送信データの先頭に、シリアルナンバーを１バイトつけるようにしています。
と同時にもう１バイト、送信データのバイト数もつけます。
６４バイトの送信データのうち、先頭の２バイトはシリアルナンバーとデータバイト数になりますから、正味のデータ数は最大で６２バイトになります。
そしてホストからＩＮトランザクションの要求にそなえて、もし送信データがある場合には、データをセットするとともにシリアルナンバーとデータバイト数も先頭に置きます。
ＰＩＣ１８Ｆ１４Ｋ５０では、そのように送信データエリアにデータをセットしたあと、送信レディの状態にしておくと、内蔵のＨＩＤコントローラがホストからＩＮトランザクションを受け取ると、自動的に送信データエリアのデータを送出してくれます。
送信すべきデータがないときは、データ数のところに０をセットしておきます。
さてホスト側なのですが、バックグランドでＩＮトランザクションが１ｍｓｅｃごとにオートマチックに実行されているために、アプリケーションプログラムがＲｅａｄＦｉｌｅ（）を実行したときに、２つの異なる結果になることが考えられます。
その１つはＲｅａｄＦｉｌｅ（）が１ｍｓｅｃの間に複数回実行されてしまうことで起きます。
その場合、読み込まれるデータは同じデータになります。
こういうことは、ＲＳ２３２Ｃ受信ではありえないのですけれど、ＨＩＤ受信では当然のように起こり得ます。
その対策としてシリアルナンバーが生きてきます。
毎回ＲｅａｄＦｉｌｅ（）を実行するたびに、シリアルナンバーをまず確認し、前回実行したときのシリアルナンバーと比較するようにプログラムします。
もしシリアルナンバーが同じならば、受信データは更新されていない、と判断して、その受信データは捨てるようにします。
また、受信データのデータバイト数情報が０ならば、ＰＩＣ１８Ｆ１４Ｋ５０にはホストに送信すべきデータがない、という判断ができます。
さてもう１つの別の結果についてです。
今度は上とは逆に、ＲｅａｄＦｉｌｅ（）が２ｍｓｅｃ以上の間隔を空けて実行された場合の結果です。
この場合には、ＩＮトランザクションの実行によって受信したデータが、その間で落とされてしまうことになります。
これを防ぐには、ＩＮトランザクションの要求によってＰＩＣ１８Ｆ１４Ｋ５０がホストに送信したデータが、アプリケーションソフトウェアに受け取られたのか、それとも間に合わなくて捨てられてしまったのかを、、何らかの方法で、ＰＩＣ１８Ｆ１４Ｋ５０に知らせてやることが必要になります。
そこでもシリアルナンバーが生きてきます。
アプリケーションソフトの側は、ＲｅａｄＦｉｌｅ（）の実行によって、ＰＩＣ１８Ｆ１４Ｋ５０からのＵＳＢ（ＨＩＤ）送信データを受け取ると、すぐに、そのシリアルナンバーを、ＵＳＢ（ＨＩＤ）を通じてＰＩＣ１８Ｆ１４Ｋ５０に送信するのです。
このときは通常のデータとは区別するために、先頭にそのための識別マークをつけて、シリアルナンバーを送り返します。
ホストからの送信データも６４バイトですが、先頭に識別マークの１バイトと、通常の送信データの場合には、送信データのバイト数情報が必要です。
しかし、ＩＮトランザクションと違って、ホストが送信する、ＯＵＴトランザクションは、アプリケーションプログラムがＷｒｉｔｅＦｉｌｅ（）を実行しない限り、勝手に空のデータを送信してしまう、などということはありません。
すると、通常の送信データをＷｒｉｔｅＦｉｌｅ（）で送信するときは、必ず送信バイト数は１以上になるはずです。
送信バイト数が０ということはありえません。
ですから、さきほどの、受信したシリアルナンバーを返送するための特別の送信データのときは、普通の送信データと区別するために、そのバイト数情報のところを０にして送ります。
つまり通常のデータを送信するときの最大の送信バイト数は１度に６３バイト、ということになります。
一方ＰＩＣ１８Ｆ１４Ｋ５０は、ホストから返送されてくるシリアルナンバーをチェックします。
ＩＮトランザクションの要求によってホストに送信したデータのシリアルナンバーと同じシリアルナンバーが返送されてくるまで、送出するデータは更新しないで、毎回同じデータ、同じシリアルナンバーをホストに送出し続けるのです。
この間はホストへの送信データは更新されませんから、Ｚ８０ＣＰＵからＰＩＣ１８Ｆ１４Ｋ５０へのデータの送出も、「送信バッファフル」で待たされることになります。
●なぜ画面表示が遅いのか？
そこで、やっとオシロスコープで観測したＳＴＲＯＢＥ信号の状態についてのお話に戻ります。
ここまでかかってやっと説明しました、ＰＩＣ１８Ｆ１４Ｋ５０からの受信データの処理の仕組みによって、アプリケーションプログラムがＲｅａｄＦｉｌｅ（）を実行するのが遅れると、その間、ＰＩＣ１８Ｆ１４Ｋ５０の送信バッファがバッファフルになってしまい、そのためにＺ８０ＣＰＵからのＳＴＲＯＢＥ信号出力がアクティブになったままになる、ということがおわかりいただけたと思います。
それじゃあ、Ｚ８０ＢＡＳＩＣのＰＲＩＮＴ文の実行によって、ＰＩＣ１８Ｆ１４Ｋ５０からＵＳＢ（ＨＩＤ）を通じて送られてきたデータをＤＯＳプロンプト画面に表示するのに、そんなに時間がかかるのか？
と言いますと、ええ、確かにそんなに時間がかかっているのですよねえ。
そりゃあ、普通の画面表示とは違って、スクロールのための処理とか、ページモードのためのデータの処理や、ログファイルの作成などということまでやっているのでありますから、そうとう時間がかかるかもしれない、ということは考えてみました。
そこで、念の為に、スクロールとか、ページモードとかの処理をとりあえず外して試してみたのですが…。
それほど、画面表示は、速くはならなかったのです。
むむ。
いったいぜんたい、どういうことなのでしょう？
２０１０．８．１ｕｐｌｏａｄ
前へ
次へ
ホームページトップへ戻る