ワンボードマイコンをつくろう!(パソコンの原点はここから始まった)
TK80ソフトコンパチブル!8080、Z80マシン語からBASICまでこれ1台でこなせます
当記事は2009年11月から「TTLでCPUをつくろう!」というタイトルの もとにほとんど毎日連載をしてきたものを再編集したものです。 2011.7.4
前へ
次へ
目次へ戻る
ホームページトップへ戻る
☆RS232C
ND80ZVはパソコンとUSB接続してデータやプログラムをパソコンとの間で送信、受信することができます。
ND80ZVはUSB通信とは別にRS232C通信の機能ももっています。
ところがそのRS232C通信の動作テストでエラーがおきてしまいました。

[第90回]

●受信バッファオーバーフロー

前回は、PIC18F14K50がRS232C受信をするときに発生するエラーとして、フレーミングエラーとオーバーランエラーがあります、という説明をいたしました。
どちらのエラーがおきたのかをZ80CPU側でもわかるようにするために、エラー信号出力(PIC18F14K50のRC4)をONにするとともに、エラーコードをデータとして出力するようにしました。
オーバーランエラーのときは、データとして02(00000010)を出力し、
フレーミングエラーのときは、データとして04(00000100)を出力します。

ところで実はPIC18F14K50がRS232C受信をするときに発生するエラーにはもう1つあります。
それは受信バッファオーバーフローです。
PIC18F14K50はRS232C受信を割り込みプログラムで処理しています。
RS232Cでデータを受信すると、受信割り込みが発生し、割り込みプログラムが実行されます。
割り込みプログラムは受信したデータをPIC18F14K50の汎用メモリに割り付けた256バイトの受信バッファに格納します。

Z80CPU側のプログラムからPIC18F14K50に受信データを渡すように要求があると、受信バッファにあるデータは順次Z80CPU側に渡されます。
通常考えられる処理の手順では、まずZ80CPU側の受信プログラムが先にスタートしてから、送信側がRS232C送信を開始することになりますから、受信割り込みプログラムによって受信バッファにデータが入れられるとすぐに、Z80CPU側がそれを引き取ってしまいますから、受信バッファが一杯になるということは、まず考えられません。

しかしもしなんらかの理由で、ND80ZVのRS232C受信プログラムが実行されていないのに、送信側がRS232C送信を開始してしまった場合とか、ND80ZV側のプログラムがRS232C受信以外の処理も実行していて、その処理に時間がかかるために、PIC18F14K50から受信データの引き取りを十分に行うことができなかったというような場合には、受信バッファに受信データがどんどん溜まっていって、ついには256バイトのバッファにフルに受信データが溜まってしまう、ということも考えられます。

このときもPIC18F14K50は受信エラー信号をONにして、エラーコードをZ80CPU側に渡すようにしました。
すでにエラーコードとして02、04を使っていますから、受信バッファオーバーフローのエラーコードは01(00000001)にしました。

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

受信バッファエンプティをZ80CPUに知らせるために、STB信号を15μsecの間だけアクティブにしていたのですが、7セグメントLED表示のためのDMAアクセスが発生すると、Z80CPUがその信号を見落としてしまい、そこでハングアップしてしまうことがわかりました。
その方法では駄目なことがわかりましたから、何か別の方法を探さなくてはいけません。
というところから、いきなり受信エラー信号の説明になってしまいました。
いったい何をやっているのだ、と言うようなものですが、しかし、すでにお気づきの方もみえると思います。

そうです。
受信エラーが発生したときに受信エラー信号をONにするとともに、データとしてはエラーコードをZ80CPUに渡す、という方法に、受信バッファエンプティも加えてしまおう、と考えたのです。

Z80CPU側が受信データを渡すように要求してきたときに、受信バッファにデータがあれば、そのデータをZ80CPU側に渡します。
もしも、受信バッファが空だったら、受信エラー信号をONにします。
そしてデータとしては、FF(11111111)を渡すことにしました。
このようにしたことで、DMAアクセスによって、ハングアップしてしまうようなことは発生しないで、正しくRS232C受信が行われるようになりました。

めでたしめでたし、と言いたいところなのですが、なかなかにそうは簡単にことは運ばないのです。
受信バッファエンプティのためのプログラム変更作業に着手したところ、Z80CPUとPIC18F14K50との間でのデータの受け渡しの方法にまで影響してしまいました。
いままでの方法は、Z80側がPIC18F14K50にRS232C受信データを要求するときに、232Cセレクト信号をアクティブにすることで、それをPIC18F14K50に知らせていたのですが、これは実に気持ちが悪い方法であることに気がついてしまったのです。

そのようにしたのにはそれなりの理由があったのですが、だんだんとシステムが整理されてくると、これはまことにみっともないことをやっているように思えてきました。
PIC18F14K50がWindowsパソコンから受信するHIDデータにせよ、RS232C受信データにせよ、そのデータをPIC18F14K50の方からZ80CPUにいきなり送ることはありません。
必ずZ80CPUの側からデータ要求があったときに、それに応える形でデータを送ります。

確かにRS232C受信データを要求するときには、232Cセレクト信号が先にアクティブになってから、PIC18F14K50が受信データをセットします。
しかしHID受信データの場合には、先にZ80CPU側から、Windowsパソコンにデータを要求する合図を送ってから、受信スタンバイするという流れになっているために、そこのところがちょいといいかげんに処理されていました。

●Z80BUSYをZ80READに変更

で、これはかなり大掛かりなシステムの変更になってしまって、結局また2日ほどを費やしてしまいました。
Z80CPU側がデータを要求して、それにPIC18F14K50が応える形でデータが出てくるのですから、Z80CPUの側の信号がREADY/BUSYというのは、おかしいのです。
READまたはREQUESTにすべきなのでした。

ああ。
タイミングチャートで説明するよりも、カメレオンUSB+ロジアナで説明したほうが簡単ですので、そうすることにいたします。

これはRS232C受信データの読み取りと、続いて受信バッファオーバーフローが発生したところです。

プローブの接続がちょっと逆になってしまいましたから、PICSTBがZ80READの上になっています。
またロジアナのクロックが100KHzと低速なので、信号が同時発生しているように見えますが、先にZ80READがアクティブになってから、PICデータD0〜D3セット、PICSTBアクティブの順です。
今までと違って一番上の232Cセレクト信号はトリガとして使わないことになりましたから、ずっとアクティブ(L)になっています。
データは最初に下位4ビットが渡され、続いて上位4ビットが渡されます。
948500μSのところで渡されているのは
00111000ですから16進数の38です。

そのあと、948700μSで受信バッファオーバーフローが出力されています。
データD0〜D3の下のERROR出力がLになっています。
そして、データとして00000001(16進数の01)が出力されています。

こちらは受信バッファエンプティが繰り返し出力されているところです。

ERROR出力はLになっていますが、データD0〜D3はHのままです。
つまりデータとしては、11111111(FF)が出力されていることになります。
CPUをつくろう!第592回(2010.8.25upload)を再編集

ワンボードマイコンをつくろう![第90回]
2011.7.4upload

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