ＴＴＬでＣＰＵを作ろう！

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

●なぜか受信バッファがオーバーフローしてしまいます

ＮＤ８０ＺⅢのＺ８０ＢＡＳＩＣで簡単なＲＳ２３２Ｃ受信プログラムを実行して、そこに短いテキストファイルのデータを送信したところ、無事うまく受信して、そのデータをＰＲＩＮＴ文で、ＷｉｎｄｏｗｓのＤＯＳプロンプト画面に表示させるところまではなんとかできました。
ＰＲＩＮＴ文はデータをＵＳＢ経由でＷｉｎｄｏｗｓパソコンに送って、そこでＤＯＳプロンプトの画面に表示させます。

ところがもう少し大きいサイズのデータを、Ｂｏｒｌａｎｄ　Ｃ＋＋で作ったＲＳ２３２Ｃ送信プログラムで、ＮＤ８０ＺⅢに送信しようとしましたら、「不正な処理」メッセージが出されてしまいました。
これはＲＳ２３２Ｃ送信プログラムでデータを送信するときに、標準の送信バッファの容量を越えるサイズのデータをＷｒｉｔｅＦｉｌｅ（）関数に与えてしまったためでした（多分）。
そこで送信データを１０００バイトずつに区切ってＷｒｉｔｅＦｉｌｅ（）関数に渡すようにしたところ、「不正な処理」メッセージは出なくなりました。

というところが、前回までに説明しました内容です。
これで全てうまくいってくれれば、めでたしめでたし、なのですけれど、世の中というものは、そこまで甘くはないのですよねえ。

送信側は「不正な処理」メッセージも出なくなって、エラーなく送信を完了してくれるようになったのですけれど。
今度は受信側でエラーが発生してしまいました。

logfile nd80zlog\07300945.txt open

ＮＤ８０ＺⅢに接続しました
0001 0000 - z
1000 00C3 - 
*** nd80z3 basic ****
>h.
TEXT 8004-8073
ﾍﾝｽｳ DE47-DFFF
>.
    10 A%=0
    20 READ #1,A$,A%
    30 IF A%<1 GOTO 20
    40 PRINT A$,"a%=";A%
    50 GOTO 10
>r.
/// w232.cpp for mycpu  09/03/13 3/20  a%=37
#include <windows.h>      a%=20
#include <stdio.h>        a%=18
//           a%=2
        FILE *rfp;   a%=11
        char outbf[300]="\0";     a%=22
        char comname[5]="\0";     a%=22
        char *fname; a%=13
        int dtbyte=0;a%=14
        int e;       a%=7
        unsigned long int dwWrite;a%=27
        HANDLE hcom; a%=13
int open();  a%=11
int write(); a%=12
int close(); a%=12
//           a%=2
oid main(int argn,char *args[])        a%=31
name=args[1];a%=13
/file open   a%=10
f(!(rfp=fopen(fname,"r")))a%=26
{printf("can't open %s\n",fname);}// paa%=40
s to end     a%=8

ERR:73 
    20 READ #1,A$,A%

>/exit
0000 00C3 - 
ndremote.exeを終了しました
logfile closed at Fri Jul 30 09:47:05 2010

ＥＲＲ：７３が表示されています。
２３２Ｃ受信エラーです。

でもこれだけでは何がおきたのかわかりませんから、ＰＩＣ１８Ｆ１４Ｋ５０のプログラムを少し直して、エラーの種類もわかるようにして、確認をしてみました。

その結果、受信バッファのオーバーフローであることがわかりました。
ＰＩＣ１８Ｆ１４Ｋ５０はＲＳ２３２Ｃ受信を割り込み処理で行っています。
受信したデータは割り込みプログラムによって、ＰＩＣの内蔵メモリ上に設けた２５６バイトの受信バッファに書き込まれます。

Ｚ８０ＢＡＳＩＣの側は、ＲＥＡＤ　＃１命令を実行したときに、ＰＩＣ１８Ｆ１４Ｋ５０に対して、受信バッファのデータを渡すように要求します。
ＲＳ２３２Ｃのボーレートは９６００ボーなので、これはスタートビットとストップビットを計算に入れると、９６０バイト／秒の速度です。
約１バイト／１ｍｓｅｃの速度ですから、バッファがオーバーフローするまでに２６０ｍｓｅｃほども時間があります。
いくらなんでもＰＩＣ１８Ｆ１４Ｋ５０とＺ８０ＣＰＵの間のデータの受け渡しに１バイト１ｍｓｅｃもの時間がかかるなどということはありえません。

ええ。
大体のところはつかんでいるのです。
もしＰＲＩＮＴ文を実行しないで、たとえば受信したデータを配列に格納してしまって、全部受信し終わってから、それをＰＲＩＮＴ文で表示させるようにすれば、ＥＲＲ：７３は発生しないのです。

問題はＰＲＩＮＴ文にあるようです。
しかし、しかし、ＰＲＩＮＴ文はＵＳＢ（ＨＩＤ）経由でＷｉｎｄｏｗｓパソコンにデータを送りますが、その速度は１回の送信あたり、１ｍｓｅｃです。
それじゃＲＳ２３２Ｃと同じじゃないの？
いや、それは違います。
ＲＳ２３２Ｃは９６００ボーのとき、１バイトの受信に約１ｍｓｅｃかかりますが、ＵＳＢ（ＨＩＤ）の送信は１回あたり６４バイトのデータを送ることができますから、速度が違います。
もっとも、つねに６４バイトフルに送っているか、というと当然ロスはあるわけなのですが…。

そういえば、画面の表示が異常に遅いのですよねえ。
確かにそこのところが気にかかります。

一体何がおきているのかもう少し詳しくしらべてみよう、ということで、Ｚ８０ＣＰＵとＰＩＣ１８Ｆ１４Ｋ５０の間のデータのやり取りの状況をオシロで確認してみることにしました。
そうしましたら…。
な、なんと、とんでもないことがわかってしまいました。

上側（ＣＨ１）は、ＰＲＩＮＴ文の実行時にＺ８０ＣＰＵ側から、ＰＩＣ１８Ｆ１４Ｋ５０にデータを送出するときのＳＴＲＯＢＥ信号です。
下側（ＣＨ２）は、ＰＩＣ１８Ｆ１４Ｋ５０がそれに応答するＲＥＡＤＹ／ＢＵＳＹ信号です。

ＳＴＲＯＢＥ信号がほとんど下がりっぱなしじゃありませんか。
この間は、ＰＩＣ１８Ｆ１４Ｋ５０の応答を待っているのです。
ＰＩＣ１８Ｆ１４Ｋ５０が応答するのに１秒もかかっています！？

ああ。
時間がなくなってしまいました。
この続きはまた次回にいたします。
２０１０．７．３１ｕｐｌｏａｄ

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