(ホントは７４ＨＣ、ＣＭＯＳなんだけど…）
［第５８０回］
●ＰＩＣ１８Ｆ１４Ｋ５０のプログラムの概要
前回、ＰＩＣ１８Ｆ１４Ｋ５０とＺ８０ＣＰＵとの間でのデータのやりとりについて簡単に説明をいたしましたが、その仕組みからもおそらく想像できますように、ＮＤ８０ＺⅢのＰＩＣ１８Ｆ１４Ｋ５０はかなりキツい作業をこなしているのです。
そのあたりの事情につきましては［第５６７回］でも説明をいたしました。
ＰＩＣ１８Ｆ１４Ｋ５０の一番の役目はもちろんＷｉｎｄｏｗｓパソコンとの間でＵＳＢ（ＨＩＤ）を介してデータの送受信を行うことです。
しかし単にＨＩＤ送受信を行うのではなくて、ＷｉｎｄｏｗｓパソコンからＵＳＢ（ＨＩＤ）で受信したデータをそのままＺ８０ＣＰＵに伝える、あるいはＺ８０ＣＰＵからのデータをＵＳＢ（ＨＩＤ）でＷｉｎｄｏｗｓパソコンに送らなくてはいけません。
つまりＰＩＣ１８Ｆ１４Ｋ５０は片方でＵＳＢの送受信を行いつつ、もう一方では、Ｚ８０ＣＰＵとの間でのデータの受け渡しもしなければならないのです。
さらにもうひとつ、その間にＰＩＣ１８Ｆ１４Ｋ５０はＲＳ２３２Ｃでの送受信と、そのデータもＺ８０ＣＰＵとの間でやり取りする、という作業もこなさなければなりません。
まさに八面六臂（はちめんろっぴ）の大活躍です。
その作業のうちのＺ８０ＣＰＵとの間でのデータのやりとりについては、前回、回路図とタイミングチャートで簡単に説明をしました。
ＵＳＢ（ＨＩＤ）での送受信については、送信、または受信バッファを設定しておくとともに、送信あるいは受信可能な状態をプログラムで設定しておくことによって、実際のＵＳＢ（ＨＩＤ）送信、受信はＰＩＣ１８Ｆ１４Ｋ５０内蔵のＵＳＢコントローラが、ＰＩＣ１８Ｆ１４Ｋ５０のプログラムとは非同期にこなしてくれます。
その設定作業はなかなかに理解しがたいところがありまして、それを理解するまでに、なんと数ヶ月もかかってしまいました。
その詳細はまだ説明しておりませんが、いずれゆっくり説明をさせていただくつもりでおります。
ＲＳ２３２Ｃの受信については、普通のプログラムでは受信データの処理が追いつかなくて、オーバーフローしてしまうことがわかりましたので、ＲＳ２３２Ｃ用の受信バッファを設けて、割り込みプログラムで処理することにしました（［第５６８回］）。
割り込みプログラムとその仕組みについてはそれほど難しいものではありませんが、そこのところが詳しく知りたいなあ、とお思いの方もいらっしゃると思います。
それにつきましては、もう少し先のところで、説明をさせていただくつもりでおります。
ともあれ、ＲＳ２３２Ｃの受信につきましても、そのように割り込みプログラムで処理しますから、ＰＩＣ１８Ｆ１４Ｋ５０のメインプログラムとしては、
１）ＵＳＢ受信については、ＵＳＢコントローラの状態をセンスして、ＵＳＢデータが受信済みになっていたら、受信バッファからデータを読み出してから、ふたたび受信可の状態にセットする
２）ＵＳＢ送信については、ＵＳＢコントローラの状態をセンスして、ＵＳＢデータが送信済みになっていて、そのとき送信するデータがあったら、送信バッファに新しいデータを書き込んでから、ふたたび送信可の状態にセットする
３）ＲＳ２３２Ｃ受信については、ＲＳ２３２Ｃ受信バッファに受信データがあったら、それを読み出す
という作業をそれぞれ行うことで、実際のデータの送受信のタイミングとは切り離して、ＰＩＣ１８Ｆ１４Ｋ５０のメインプログラムのフローを滞らせることなく、データを処理することができます。
なぜ、そこで「滞ることなく」処理する必要があるかといいますと、あくまでデータ処理の主導権はＺ８０ＣＰＵの側の、ＮＤ８０ＺⅢモニタプログラムあるいはＺ８０ＢＡＳＩＣプログラムが握っているからです。
Ｚ８０ＣＰＵがマスターですから、ＰＩＣ１８Ｆ１４Ｋ５０はスレーブに徹しなければならないのです。
Ｚ８０ＣＰＵからの要求にはできるだけ速く応答しなければなりません。
もっとも、ＵＳＢ通信やＲＳ２３２Ｃ受信にも一定の時間内に処理しなければならない制約はありますから、Ｚ８０ＣＰＵとの間のデータの受け渡しについても、そこで余り長い時間待ちが発生してしまうような処理の仕方は避けなければなりません。
それに加えて、ＵＳＢでは最初にＷｉｎｄｏｗｓパソコンと接続したときのセットアップの過程であのややこしいＥｎｕｍｅｒａｔｉｏｎの手続きもこなさなければなりません。
その手続きも含めたＰＩＣ１８Ｆ１４Ｋ５０のプログラムはなかなかに複雑なものになっています。
しかし、そのプログラムについての説明を始めてしまいますと、またまた藪の奥深く入り込んでしまって、出てこられなくなってしまいますから、それにつきましては、いずれ後日、ということにさせていただきたいと思います。
ここでは、ＲＳ２３２Ｃでの受信データにときどき欠落がおきる、ということの説明をすることがそもそもの目的ですから、そのことをご理解いただくための予備知識として、ＰＩＣ１８Ｆ１４Ｋ５０のプログラム全体の流れについてだけ、簡単に説明することにいたします。
●ＰＩＣ１８Ｆ１４Ｋ５０のプロク゜ラムのフローチャート
ＰＩＣ１８Ｆ１４Ｋ５０のプログラムの概略フローチャートです。
このフローチャートでは、ＬＯＯＰＴＯＰから始まるようになっていますが、勿論これより前の部分にはいろいろな初期設定の処理があります。
しかし初期設定を終わったら、このＬＯＯＰＴＯＰ以下のルーチンを、その名前の通りループして処理を続けます。
ループのトップにはＵＳＢホスト（Ｗｉｎｄｏｗｓパソコン）から送られてくるｓｅｔｕｐコマンドを検出する部分が置かれています。
通常は、一度セットアップの処理を完了してＷｉｎｄｏｗｓパソコンにＨＩＤデバイスとして認識されてしまえば、セットアップ作業は必要ないのですが、実はセットアップの処理は、ここだけではなくて、その次のＥＰ０［ｉｎ］の処理も含めておこないますから、このような流れにしてあります。
ＥｎｕｍｅｒａｔｉｏｎはＥＰ０［ｏｕｔ］にＷｉｎｄｏｗｓパソコンがセットアップコマンドを送ってくることから開始されます。
［ｉｎ］、［ｏｕｔ］はＰＩＣ１８Ｆ１４Ｋ５０から見た向きとは逆になっています。
［ｉｎ］はホスト、つまりＷｉｎｄｏｗｓパソコンから見て「入力」になるパイプで、［ｏｕｔ］はＷｉｎｄｏｗｓパソコンから見て「出力」になるパイプです。
フローチャートにはＥＰ０［ｏｕｔ］の処理が書かれていませんが、その処理は［ｓｅｔｕｐ］の中で行われます。
ところで、フローチャートでは、セットアップコマンドの検出がずっとループの中で繰り返されるようになっています。
一見すると、この流れは無駄なようです。
セットアップの処理は一度完了して、ＷｉｎｄｏｗｓパソコンにＨＩＤデバイスとして認識されてしまえば、ＵＳＢケーブルでの接続が保たれていて、ＷｉｎｄｏｗｓパソコンもＮＤ８０ＺⅢも電源が入っていて正常に動作している限り、再び行われることはありません。
途中でＵＳＢケーブルの抜き差しをしてしまったときなどは、またセットアップから始めることになりますが、しかし、そのような場合にはＺ８０ＣＰＵの側のプログラムもＷｉｎｄｏｗｓパソコンの側も途中でハングアップしてしまっているはずですから、どのみちリセットして最初からやりなおさなければならないはずです。
してみると、このセットアップの処理は、ＬＯＯＰＴＯＰより前の初期設定のところに含めてしまって、ループからは外してしまったほうがよいように思えます。
ところがそのようにはできない事情があるのです。
セットアップの完了後は、ホストであるＷｉｎｄｏｗｓパソコンの側ではＮＤ８０ＺⅢがＨＩＤデバイスとして認識できれば、それ以後は再びセットアップの処理が繰り返されることはありません。
しかし、ＰＩＣ１８Ｆ１４Ｋ５０の側では、セットアップの手続きが完了したかどうかは単純には判断することはできません。
まあ、要するに、ＰＩＣ１８Ｆ１４Ｋ５０としては、ホストから送られてくるデータ要求に従って、順番にデスクリプタを送るだけで、その結果がどうなったのかは、わからないのですよねえ。
確かに、緻密にプログラムを組めば、セットアップが完了して通常のデータ処理が開始されたことを認識して、その時点でセットアップ処理をループから外すようにすることもできるとは思いますが。
しかしそうまでしなくても、ＰＩＣ１８Ｆ１４Ｋ５０の処理速度はなにしろ４８ＭＨｚのクロックで動作するので非常に高速ですから、それを考えれば、セットアップコマンドの検出部分をループに残したままでも、特に支障はありません。
で、そのままにしてあるのです。
こうしておくほうが、プログラムとしては簡単になりますから。
実は、今回のそもそもの問題であります、２３２Ｃ受信データの欠落という現象も、このループの処理そのものがセットアップコマンドの検出部分を含めて実行されていながら、想定していたよりもずっと速く行われてしまうことが原因だった、というほど速く処理されているのです。
したがってセットアップが完了してからの通常のデータ処理サイクルでは、最初のｓｅｔｕｐ、及びＥＰ０［ｉｎ］の処理は常にスルーされる、と考えてもよいことになりますから、すると、ループのトップで最初にチェックされるのは、Ｚ８０ＣＰＵからのＳＴＢがアクティブになっているかどうか、ということです。
Ｚ８０ＳＴＢがアクティブならば、Ｚ８０からのデータがセットされていることになりますから、そこでそのデータを受け取る処理を行います。
このとき同時に、２３２Ｃセレクト信号の状態をチェックして、それがアクティブならばそのデータを２３２Ｃで送信します（ｓｏｕｔｓ）。
２３２Ｃセレクト信号がアクティブでなければ、ＵＳＢ（ＨＩＤ）でＷｉｎｄｏｗｓパソコンに送るデータですから、ＨＩＤ送出用のバッファにそのデータを書き込みます。
どちらの処理も完了後は、次のＥＰ１［ｏｕｔ］のチェックに行きます。
ＥＰ１［ｏｕｔ］は、ＷｉｎｄｏｗｓパソコンからＵＳＢ（ＨＩＤ）でデータを送るときに使われるエンドポイントです。
そこに送られてきたデータがあるかどうかをチェックします。
一方、最初のＺ８０ＳＴＢのチェックのところで、Ｚ８０ＳＴＢがアクティブでない場合には、次にＲＳ２３２Ｃセレクト信号がアクティブであるかどうかをチェックします。
２３２Ｃセレクト信号がアクティブのときは、Ｚ８０側が、２３２Ｃ受信データを要求していますから、２３２Ｃ受信バッファを確認して、受信データがあれば、それをＺ８０に渡す処理を行います。
２３２Ｃ受信バッファが空であれば、バッファエンプティを知らせる処理を行います。
いずれの場合も、その次にはＥＰ１［ｏｕｔ］のチェックへ行きます。
ＥＰ１［ｏｕｔ］でＷｉｎｄｏｗｓパソコンからＵＳＢ（ＨＩＤ）を通じて受け取ったデータがあるときには、そのデータをＺ８０側に送ります（ｄｔｏｕｔ）。
ＥＰ１［ｏｕｔ］でのデータが無い場合には、つぎにＥＰ１［ｉｎ］のバッファの状態をチェックします。
ＰＩＣ１８Ｆ１４Ｋ５０内蔵のＵＳＢコントローラの状態をセンスして、ＥＰ１［ｉｎ］バッファのデータがＷｉｎｄｏｗｓパソコンに送出されていたら、次に送るデータがあるかどうかを確認して、データがあれば、そのデータをＥＰ１［ｉｎ］送出用バッファに書き込んだあと、ＵＳＢコントローラを、ＥＰ１［ｉｎ］バッファデータの送出可の状態にセットします。
これでループを一巡したことになりますから、ＬＯＯＰＴＯＰに戻ります。
●フリーソフトＤｉａｇｒａｍＤｅｓｉｇｎｅｒ
フローチャートなど滅多に描くことはありませんし、もしその必要があったとしても、エンピツでメモ書き程度にサッサと描いてしまいます。
今回お見せしたフローチャートも、もとはエンピツで描いたものです。
しかしいくらなんでもこんなものを皆様にお見せして、これで説明するというのもなんだかなあ、という感じですので、もうちょっと見やすいように描き直そうと思いまして。
最初は簡単にｍｓｐａｉｎｔで、とも思ったのですけれど、意外と簡単ではないのですよねえ。
それならということで、回路図の作成に使いましたｂｓｃｈ３ｖで描き始めたのですけれど、これもなかなかにフローチャートには不向きなところがあります。
フローチャートには文字が欠かせないのですが、ｂｓｃｈ３ｖでは文字も図形（線画）も目の粗いセクション位置にしか置けないために、図形を小さくまとめようとすると、文字をその中にうまく納めることができません。
まあ、でも、文字の配置に目をつぶれば、ｂｓｃｈ３ｖでフローチャートを描くこともできないことはありません。
ｂｓｃｈ３ｖにつきましては［第２７３回］でご紹介いたしました。
しかしせっかく皆様に見ていただくわけですから、どうせ手間をかけるのでしたら、すこしでも見栄えのするものの方がよいと思いまして、ネットでフリーなソフトをサーチしてみました。
いくつかみつかったのですけれど、私としては今回使わせていただきました、ＤｉａｇｒａｍＤｅｓｉｇｎｅｒが好みにピッタリという感じです。
フリーのフローチャート作成ソフトＤｉａｇｒａｍＤｅｓｉｇｎｅｒは、こちらのサイトへ行っていただいて、下の画面コピーにも見えております、Ｄｏｗｎｌｏａｄ Ｎｏｗをクリックしていただきますと、ＤｉａｇｒａｍＤｅｓｉｇｎｅｒＳｅｔｕｐ．ｅｘｅがダウンロードされますから、それを実行することで簡単にセットアップできます（下の画面はただのコピーですから、クリックできません）。
さっそくｄｏｗｎｌｏａｄいたしましたところ、Ｗｉｎｄｏｗｓ９８（ＳＥ）では、ｓｅｔｕｐの途中で、ｇｄｉｐｌｕｓ．ｄｌｌがない、ということでｓｅｔｕｐできません。
それじゃあ、ということで、またネットをサーチしまして、見つけたｇｄｉｐｌｕｓ．ｄｌｌをｄｏｗｎｌｏａｄして、再度ｓｅｔｕｐしてみたのですけれど。
今度は。
ということで、結局ｓｅｔｕｐできませんでした。
仕方がありませんから、Ｗｉｎｄｏｗｓ９８にインストールするのはあきらめて、ＷｉｎｄｏｗｓＸＰでｓｅｔｕｐすることにいたしました。
ＷｉｎｄｏｗｓＸＰでは、特に問題になることもなく、あっさりとセットアップできてしまいました。
うむむ。
だんだんＷｉｎｄｏｗｓ９８では使えないものが増えてきてしまいますねえ。
悲しいことです。
ＤｉａｇｒａｍＤｅｓｉｇｎｅｒの実行画面です。
右のシンボルを中央の作画エリアにドラッグするだけで簡単に配置できます。
初めて使ってみたのですがＨｅｌｐを全く見ることなく作画することができました。
何回か試行錯誤を繰り返すうちに、ごく自然に、こうすればいいんだな、ということがわかってきます。
こういうソフトは好きですねえ。
フォントも選ぶことができるのですけれど、かな、漢字がどういうわけか横向きになって寝てしまいます。
まあ、大体において、プログラム自体が英字で書くわけですから、日本語の表示に難があったとしても、それほど支障があるとは思えません。
おお。今回も道草をしてしまいました。
次回こそは、２３２Ｃ受信時のデータ欠落について、の核心にせまりたいと思います。
２０１０．８．１１ｕｐｌｏａｄ
前へ
次へ
ホームページトップへ戻る