●受信バッファオーバーフロー
前回は、ＰＩＣ１８Ｆ１４Ｋ５０がＲＳ２３２Ｃ受信をするときに発生するエラーとして、フレーミングエラーとオーバーランエラーがあります、という説明をいたしました。
どちらのエラーがおきたのかをＺ８０ＣＰＵ側でもわかるようにするために、エラー信号出力（ＰＩＣ１８Ｆ１４Ｋ５０のＲＣ４）をＯＮにするとともに、エラーコードをデータとして出力するようにしました。
オーバーランエラーのときは、データとして０２（００００００１０）を出力し、
フレーミングエラーのときは、データとして０４（０００００１００）を出力します。
ところで実はＰＩＣ１８Ｆ１４Ｋ５０がＲＳ２３２Ｃ受信をするときに発生するエラーにはもう１つあります。
それは受信バッファオーバーフローです。
ＰＩＣ１８Ｆ１４Ｋ５０はＲＳ２３２Ｃ受信を割り込みプログラムで処理しています。
ＲＳ２３２Ｃでデータを受信すると、受信割り込みが発生し、割り込みプログラムが実行されます。
割り込みプログラムは受信したデータをＰＩＣ１８Ｆ１４Ｋ５０の汎用メモリに割り付けた２５６バイトの受信バッファに格納します。
Ｚ８０ＣＰＵ側のプログラムからＰＩＣ１８Ｆ１４Ｋ５０に受信データを渡すように要求があると、受信バッファにあるデータは順次Ｚ８０ＣＰＵ側に渡されます。
通常考えられる処理の手順では、まずＺ８０ＣＰＵ側の受信プログラムが先にスタートしてから、送信側がＲＳ２３２Ｃ送信を開始することになりますから、受信割り込みプログラムによって受信バッファにデータが入れられるとすぐに、Ｚ８０ＣＰＵ側がそれを引き取ってしまいますから、受信バッファが一杯になるということは、まず考えられません。
しかしもしなんらかの理由で、ＮＤ８０ＺⅢのＲＳ２３２Ｃ受信プログラムが実行されていないのに、送信側がＲＳ２３２Ｃ送信を開始してしまった場合とか、ＮＤ８０ＺⅢ側のプログラムがＲＳ２３２Ｃ受信以外の処理も実行していて、その処理に時間がかかるために、ＰＩＣ１８Ｆ１４Ｋ５０から受信データの引き取りを十分に行うことができなかったというような場合には、受信バッファに受信データがどんどん溜まっていって、ついには２５６バイトのバッファにフルに受信データが溜まってしまう、ということも考えられます。
このときもＰＩＣ１８Ｆ１４Ｋ５０は受信エラー信号をＯＮにして、エラーコードをＺ８０ＣＰＵ側に渡すようにしました。
すでにエラーコードとして０２、０４を使っていますから、受信バッファオーバーフローのエラーコードは０１（０００００００１）にしました。
●受信バッファエンプティ
受信バッファエンプティをＺ８０ＣＰＵに知らせるために、ＳＴＢ信号を１５μｓｅｃの間だけアクティブにしていたのですが、７セグメントＬＥＤ表示のためのＤＭＡアクセスが発生すると、Ｚ８０ＣＰＵがその信号を見落としてしまい、そこでハングアップしてしまうことがわかりました。
その方法では駄目なことがわかりましたから、何か別の方法を探さなくてはいけません。
というところから、いきなり受信エラー信号の説明になってしまいました。
いったい何をやっているのだ、と言うようなものですが、しかし、すでにお気づきの方もみえると思います。
そうです。
受信エラーが発生したときに受信エラー信号をＯＮにするとともに、データとしてはエラーコードをＺ８０ＣＰＵに渡す、という方法に、受信バッファエンプティも加えてしまおう、と考えたのです。
Ｚ８０ＣＰＵ側が受信データを渡すように要求してきたときに、受信バッファにデータがあれば、そのデータをＺ８０ＣＰＵ側に渡します。
もしも、受信バッファが空だったら、受信エラー信号をＯＮにします。
そしてデータとしては、ＦＦ（１１１１１１１１）を渡すことにしました。
このようにしたことで、ＤＭＡアクセスによって、ハングアップしてしまうようなことは発生しないで、正しくＲＳ２３２Ｃ受信が行われるようになりました。
めでたしめでたし、と言いたいところなのですが、なかなかにそうは簡単にことは運ばないのです。
受信バッファエンプティのためのプログラム変更作業に着手したところ、Ｚ８０ＣＰＵとＰＩＣ１８Ｆ１４Ｋ５０との間でのデータの受け渡しの方法にまで影響してしまいました。
いままでの方法は、Ｚ８０側がＰＩＣ１８Ｆ１４Ｋ５０にＲＳ２３２Ｃ受信データを要求するときに、２３２Ｃセレクト信号をアクティブにすることで、それをＰＩＣ１８Ｆ１４Ｋ５０に知らせていたのですが、これは実に気持ちが悪い方法であることに気がついてしまったのです。
そのようにしたのにはそれなりの理由があったのですが、だんだんとシステムが整理されてくると、これはまことにみっともないことをやっているように思えてきました。
ＰＩＣ１８Ｆ１４Ｋ５０がＷｉｎｄｏｗｓパソコンから受信するＨＩＤデータにせよ、ＲＳ２３２Ｃ受信データにせよ、そのデータをＰＩＣ１８Ｆ１４Ｋ５０の方からＺ８０ＣＰＵにいきなり送ることはありません。
必ずＺ８０ＣＰＵの側からデータ要求があったときに、それに応える形でデータを送ります。
確かにＲＳ２３２Ｃ受信データを要求するときには、２３２Ｃセレクト信号が先にアクティブになってから、ＰＩＣ１８Ｆ１４Ｋ５０が受信データをセットします。
しかしＨＩＤ受信データの場合には、先にＺ８０ＣＰＵ側から、Ｗｉｎｄｏｗｓパソコンにデータを要求する合図を送ってから、受信スタンバイするという流れになっているために、そこのところがちょいといいかげんに処理されていました。
●Ｚ８０ＢＵＳＹをＺ８０ＲＥＡＤに変更
で、これはかなり大掛かりなシステムの変更になってしまって、結局また２日ほどを費やしてしまいました。
Ｚ８０ＣＰＵ側がデータを要求して、それにＰＩＣ１８Ｆ１４Ｋ５０が応える形でデータが出てくるのですから、Ｚ８０ＣＰＵの側の信号がＲＥＡＤＹ／ＢＵＳＹというのは、おかしいのです。
ＲＥＡＤまたはＲＥＱＵＥＳＴにすべきなのでした。
ああ。
タイミングチャートで説明するよりも、カメレオンＵＳＢ＋ロジアナで説明したほうが簡単ですので、そうすることにいたします。
これはＲＳ２３２Ｃ受信データの読み取りと、続いて受信バッファオーバーフローが発生したところです。
プローブの接続がちょっと逆になってしまいましたから、ＰＩＣＳＴＢがＺ８０ＲＥＡＤの上になっています。
またロジアナのクロックが１００ＫＨｚと低速なので、信号が同時発生しているように見えますが、先にＺ８０ＲＥＡＤがアクティブになってから、ＰＩＣデータＤ０～Ｄ３セット、ＰＩＣＳＴＢアクティブの順です。
今までと違って一番上の２３２Ｃセレクト信号はトリガとして使わないことになりましたから、ずっとアクティブ（Ｌ）になっています。
データは最初に下位４ビットが渡され、続いて上位４ビットが渡されます。
９４８５００μＳのところで渡されているのは
００１１１０００ですから１６進数の３８です。
そのあと、９４８７００μＳで受信バッファオーバーフローが出力されています。
データＤ０～Ｄ３の下のＥＲＲＯＲ出力がＬになっています。
そして、データとして０００００００１（１６進数の０１）が出力されています。
こちらは受信バッファエンプティが繰り返し出力されているところです。
ＥＲＲＯＲ出力はＬになっていますが、データＤ０～Ｄ３はＨのままです。
つまりデータとしては、１１１１１１１１（ＦＦ）が出力されていることになります。
ＣＰＵをつくろう！第５９２回（２０１０．８．２５ｕｐｌｏａｄ）を再編集
ワンボードマイコンをつくろう！［第９０回］
２０１１．７．４ｕｐｌｏａｄ
前へ
次へ
目次へ戻る
ホームページトップへ戻る