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

●受信バッファエンプティ

ＲＳ２３２Ｃの受信データはＰＩＣ１８Ｆ１４Ｋ５０の割り込みプログラムによって、ＰＩＣ１８Ｆ１４Ｋ５０内部メモリに設けた２５６バイトの受信バッファに書き込まれます。
ＮＤ８０Ｚ�VのＮＤ８０Ｚモニタの機能を使って２３２Ｃ受信データを読み込む場合には、［＊（Ｉ／Ｏ］キーと［ＳＩ］（１６進キーの３）を使って、先にＮＤ８０Ｚ�Vを受信スタンバイにしておいてから、送信側の送信をスタートさせる、という使い方になると思いますから、そういう使い方ならば、受信バッファは必要ありません。

事実、最初にＰＩＣ１８Ｆ１４Ｋ５０のＲＳ２３２Ｃ受信プログラムを書いた時点では、受信割り込みプログラムではなくて、普通に受信データを待っていて、受信したらそのデータをすぐにＺ８０ＣＰＵ側に渡す、というプログラムでした。
ところがだんだん欲がでてきて、ＷｉｎｄｏｗｓパソコンとＵＳＢで接続して、Ｗｉｎｄｏｗｓパソコンのキーボードからキーデータを入力する、リモートプログラムが使えるようにしました。
そしたら、またまたさらに欲がでてきてしまって、ついにＺ８０ＢＡＳＩＣを走らせるところまできてしまいました。
ＢＡＳＩＣでプログラムを書く、ということになりますと、当然、ＲＳ２３２Ｃ受信をしながら、その受信データを画面に表示するとか、あるいはなにかほかの作業をしながら同時に２３２Ｃの受信もする、というようなプログラムも書く場合がでてきます。

そうなりますと、最初ＮＤ８０Ｚ�Vのモニタプログラムでの２３２Ｃ受信で考えていたような、ひたすら受信データを待っている、という硬直した機能では使い物になりません。
そこで、ＰＩＣ１８Ｆ１４Ｋ５０の２３２Ｃ受信は割り込みによって処理することにして、Ｚ８０ＣＰＵ側から受信データを渡すように要求されるまでは、受信したデータは受信バッファに書き込むようにしたのです。

それにともなって、ＰＩＣ１８Ｆ１４Ｋ５０とＺ８０ＣＰＵ側のプログラムとの間での受信データの受け渡しの方法も変わってきます。
Ｚ８０ＣＰＵ側の２３２Ｃ受信プログラムがスタートして、ＰＩＣ１８Ｆ１４Ｋ５０に、２３２Ｃ受信データを渡すように要求したとしても、そのときに受信データがあるとは限りません。
ＮＤ８０Ｚ�VでのＲＳ２３２Ｃ通信のボーレートは最高９６００ボーで、これはかなり速い転送速度なのですが、それでも９６０バイト／秒の速度ですから、１バイトのデータを受信してから、次の１バイトのデータを受信するまでに、約１ｍｓｅｃの空きができてしまいます。
ＮＤ８０Ｚ�VのＺ８０ＣＰＵのクロックは６ＭＨｚですから、１ｍｓｅｃもあればかなりのことが実行できてしまいます。
ほかのことを何もしないで、ただ受信データを待つ、というだけのプログラムでしたら、ＰＩＣ１８Ｆ１４Ｋ５０から受け取った受信データをＲＡＭに書き込む作業はあっという間に済んでしまいますから、受信バッファにデータが溜まる余地はまずありません。

するとＺ８０ＣＰＵがＰＩＣ１８Ｆ１４Ｋ５０に受信データを渡すように要求したときに、Ｚ８０ＣＰＵ側に渡す受信データがありませんから、そういうときにはデータを渡す代わりに「受信データがありません」ということをＺ８０ＣＰＵ側に知らせることになります。
それが受信バッファエンプティです。

ほんとうは、そういうときに、どこかの信号線をＨかＬかにすることで、受信バッファエンプティの合図にする、という方法が一番簡単なのですが、前回も書きましたように、ＰＩＣ１８Ｆ１４Ｋ５０のＩ／Ｏ端子は全てすでに使い切ってしまっていますから、受信バッファエンプティに割り当てる信号がありません。
そこで、苦肉の策として、ＰＩＣ１８Ｆ１４Ｋ５０からのデータ出力の際のＳＴＲＯＢＥ信号を利用して、１５μｓｅｃの間だけアクティブにすることで、受信バッファエンプティ信号の代用としたのです。

この方法は当初はうまくいっているように思えましたが、先回書きましたように、７セグメントＬＥＤ表示のためのＤＭＡによって、その受信バッファエンプティ信号をＺ８０ＣＰＵが読み落としてしまい、そのために受信できなくてハングアップしてしまう、という信じられないことが確認されたことで、なにか他の方法を考えなくてはならなくなってしまいました。

というところまでが、前回の内容だったのですが、今回も時間が無くなってしまい、先に進めませんでした。
詳細は次回に説明することにいたします。
２０１０．８．２３ｕｐｌｏａｄ

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