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

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

●ロジアナで確認、でもその前に

その前に、もう少し補足して説明をさせていただきます。

前回からの続きです。
Ｚ８０ＢＡＳＩＣで簡単なＲＳ２３２Ｃの受信プログラムを書いて試してみたところ、受信データがときどき欠落してしまいます。
その欠落したデータをよく見てみますと、見事に規則性があることがわかりました。
Ｚ８０ＢＡＳＩＣのＲＳ２３２Ｃ受信命令はＲＥＡＤ　＃１，Ａ＄，Ａ％という形をしています。
受信したデータは文字変数Ａ＄に格納されます。
Ｚ８０ＢＡＳＩＣの文字変数は３９バイトの固定長です。
受信データがＡ＄に３９バイト格納されるか、または０Ｄ０Ａコードを受信すると、ＲＥＡＤ　＃１命令が完成します。
どうやら、そのときに、データの欠落がおきるようです。

前回の最後にお見せした、テストプログラムの実行結果の一部ですが、確かに文字変数に３９バイトのデータが格納されたあとに、データの欠落がおきています。

12345678901234567890ABCDE0,1,2,3,4,5,6,
12345678901234567890ABCDE7,8,9,10,11,12
12345678901234567890ABCDE13,14,15,16,17
12345678901234567890ABCDE18,19,20,21,22
12345678901234567890ABCDE,23,24,25,26,2

１２３４５～ＡＢＣＤＥはダミーです。
データの欠落の原因を探るために、こんなややこしいことをさせています。
ここでは、１２と１３の間、それと１７と１８との間の　，　が欠落しています。

最初に考えられることは、文字変数に３９バイトのデータが格納されてＲＥＡＤ　＃１命令が完了してリターンしてきたあと、次にふたたびＲＥＡＤ　＃１命令が実行されるまでの間の時間がかかりすぎて、それでデータが欠落してしまうのではないか、ということです。
しかし、それはちょっと変なのですよねえ。

確かに前回の最初のプログラム（下記）では、ＲＥＡＤ　＃１命令が完了するごとに、ＰＲＩＮＴ文が実行されています。

    10 A%=0
    20 READ #1,A$,A%
    30 IF A%<1 GOTO 20
    40 PRINT A$
    50 GOTO 10

ＲＥＡＤ　＃１命令は受信データが無い場合、そこでデータが来るまで待っているのではなくて、すぐにリターンしてきます。
そのときは、受信の状態を示す整数型変数Ａ％に－１が入れられます。
受信データがある場合でも、データの終わりを示す０Ｄ０Ａコードが来るまでは、－１が示されます。
Ａ＄には、そのときまでに格納されたデータが入れられています（このデータはつねに参照可能です）。

０Ｄ０Ａコードが受信されたときは、Ａ％には受信してＡ＄に入れられた文字数が入ります。
このときは、Ａ％の値＝Ａ＄の文字バイト数になります。
Ａ＄には受信途中のデータが格納されている状態でも参照できますから、そのままではデータの終わりが確認できません。

ＲＳ２３２Ｃ通信では一般にデータの終わりには０Ｄ０Ａコードを送ります。
もし、ＲＥＡＤ　＃１，Ａ＄，Ａ％の実行後に、ＰＲＩＮＴ　Ａ＃を実行したところ、
ＡＢＣ
と表示された場合、
それだけでは、
［４１］［４２］［４３］［０Ｄ］［０Ａ］
と送信されてきたのか、それとも
［４１］［４２］［４３］［４４］…
と続くデータの途中までを受信しただけなのかがわかりません。ですから後者の場合にはＡ％＝－１にしてリターンするのです。
前者ではＡ％＝３になります。

［注記］４１、４２、４３はそれぞれ文字Ａ、Ｂ、ＣのＡＳＣＩＩコードです。一般にＲＳ２３２Ｃでは、データをバイナリコードのままで送らずに、ＡＳＣＩＩコードで送ります。

もし０Ｄ０Ａコードがまだ受信されていないならば、その続きのデータがあるはずですから、続きのデータを受信しなければなりません。

３９バイトよりも大きいデータを受信した場合には、０Ｄ０Ａコードが来る前に、文字変数Ａ＄が一杯になってしまいます。
この場合にはＡ＄のデータを一旦引き取って画面に表示するとか、別の文字変数に移し換えるとかしなければなりません。
ですからこの場合にはＡ％＝４０でリターンします。
そのようにしたあとで、Ａ％＝０にしてから再びＲＥＡＤ　＃１の実行に戻ります。

Ａ％＝０で　ＲＥＡＤ　＃１，Ａ＄，Ａ％　にエントリしたときはＡ＄をクリアしてから受信データを格納します。
Ａ％＝－１で　ＲＥＡＤ　＃１，Ａ＄，Ａ％　にエントリしたときは現在Ａ＄に格納されているデータの後ろに受信データを追記します。
Ａ％がそれ以外の値で　ＲＥＡＤ　＃１，Ａ＄，Ａ％　にエントリしたときは、何もしないですぐに戻ってきます。

なんだかめちゃめちゃ面倒なようですが、こうすることで、プログラムが受信待ちでハングアップすることが避けられます。
ＢＡＳＩＣのプログラムは受信データが無い場合には、受信データがくるのを待っていないで、ＲＥＡＤ　＃１文をすぐに抜け出しますから、受信データが無いときには、そのほかの処理をすることができます。

ＲＳ２３２Ｃの受信は、ＰＩＣ１８Ｆ１４Ｋ５０が割り込み処理によって行いますから、せっかくそのような処理をしているのに、もしもＢＡＳＩＣプログラムがひたすら受信データを待っていて、その間何もできない、というのではそれこそ、「宝の持ち腐れ」になってしまいます。
ですから受信データが無い場合にはすぐにＲＥＡＤ　＃１を終了するようにしてあるのです。

ちょっと余談になってしまいますが、せっかくＲＥＡＤ　＃１の動作の説明をいたしましたので、その実際の動きを見ていただくことにいたしましょう。

    10 PRINT "start"
    20 A%=0
    30 READ #1,A$,A%
    40 PRINT A$,A%
    50 IF A%<1 GOTO 30 ELSE GOTO 20
>r.
start
             -1
             -1
             -1

今回のはじめのところでお見せしたプログラムとは少し、ＰＲＩＮＴ文の位置が異なっています。
そのプログラムですと、Ａ＄に受信データが３９バイト格納されるか、または０Ｄ０Ａコードを受信したときしかＰＲＩＮＴ文は実行されません。
その実行結果は前回、［第５８１回］でお見せしました。
それに対して上のプログラムでは、受信データの有無に関係無くＰＲＩＮＴ文が実行されますから、受信の状態をモニタすることができます。

プログラムの実行を開始した直後は、まだ受信データが来ていませんから、Ａ＄の値としては何も表示されません。
Ａ％は受信が継続中であることを示す－１になっています。

受信データが入ってきました。

             -1
             -1
 0           -1
 0,          -1
 0,1         -1
 0,1,2       -1
 0,1,2,      -1
 0,1,2,3     -1
 0,1,2,3,    -1
 0,1,2,3,4   -1
 0,1,2,3,4,  -1
 0,1,2,3,4,5,-1
 0,1,2,3,4,5,6            -1
 0,1,2,3,4,5,6,           -1
 0,1,2,3,4,5,6,7,         -1
 0,1,2,3,4,5,6,7,8        -1
 0,1,2,3,4,5,6,7,8,9      -1
 0,1,2,3,4,5,6,7,8,9,     -1
 0,1,2,3,4,5,6,7,8,9,10   -1
 0,1,2,3,4,5,6,7,8,9,10,  -1
 0,1,2,3,4,5,6,7,8,9,10,11-1
 0,1,2,3,4,5,6,7,8,9,10,11,            -1
 0,1,2,3,4,5,6,7,8,9,10,11,12          -1
 0,1,2,3,4,5,6,7,8,9,10,11,12,1        -1
 0,1,2,3,4,5,6,7,8,9,10,11,12,13       -1
 0,1,2,3,4,5,6,7,8,9,10,11,12,13,1     -1
 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,   -1
 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 -1
 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,40
16,          -1
16,1         -1
16,17        -1
16,17,       -1
16,17,1      -1
16,17,18,    -1
16,17,18,1   -1
16,17,18,19  -1
16,17,18,19, -1
16,17,18,19,2-1
16,17,18,19,20            -1
16,17,18,19,20,2          -1
16,17,18,19,20,21         -1

あ。説明するのを忘れていました。
このプログラムのように２３２Ｃ受信と同時にＰＲＩＮＴ文を実行するときの問題点として、画面表示が異常に遅いために、受信バッファがオーバーフローしてしまう、ということにつきましては、［第５７１回］でｃｐｒｉｎｔｆ（）をｐｕｔｃ（）に変更することでクリアできましたが、それでもさすがに９６００ボーでこのプログラムを実行することはできません。
３９バイト受信ごとに表示するようにした、はじめのところでお見せしたプログラムでも、やっぱり受信バッファがオーバーフローしてしまいます。

ですから、そのどちらのプログラムでも、実はボーレートを２４００ボーにして実行いたしました。

さてそこで、本題に戻ります。
さきほど、文字変数Ａ＄に受信データが３９バイト入れられてリターンしてくるときに時間がかかりすぎる、と考えるのはちょっとおかしい、と書きました。

確かに前回、［第５８１回］でお見せしました最初のプログラムでは、３９文字受信するごとにＰＲＩＮＴ文が実行されています。
しかし同じく前回、［第５８１回］の終わりのところでお見せしたプログラムは、そのあたりのところを考慮して、受信中は別の配列変数にデータを移すだけで、ＰＲＩＮＴ文は実行しないようにしているのです。

受信を終了してから、プログラムを強制的に終了して、そのあとで、goto１１０をダイレクトに実行して、データの表示を行っています。
もちろん、Ａ＄から配列変数にデータを移すのにも多少の時間はかかりますが、それが問題になるほどかかるとは思えません。

実は結論から先に書きますと、確かにＡ＄に３９バイトの受信データが入れられて戻るときのみ、問題が発生する条件が成立していたのです。
しかしそれは、処理に時間がかかりすぎていたためではありませんでした。

●ロジアナで観測してみました

そこで、やっと、ロジアナの登場です。
［第３７４回］でご紹介いたしました、カメレオンＵＳＢ＋ロジアナです。

ＤＡＴＡ０～ＤＡＴＡ３をＰＲＯＢＥの若い番号から割り当てるつもりがうっかりして逆にしてしまいました。
でもまあどちらでも結果に変わりはありません。
この波形は、今回の説明の始めのところでお見せした受信データの出力表示が行われるのと同時に、つまりその受信データが作成されるのと同時に、ロジアナで記録されたものです。

もういちどその受信データをお見せします。

12345678901234567890ABCDE0,1,2,3,4,5,6,
12345678901234567890ABCDE7,8,9,10,11,12
12345678901234567890ABCDE13,14,15,16,17
12345678901234567890ABCDE18,19,20,21,22
12345678901234567890ABCDE,23,24,25,26,2

１２３４５～ＡＢＣＤＥはダミーです。
その後ろに受信データがあります。
データの欠落は１２と１３の間と、１７と１８との間で発生しています。
どちらも　，　が落ちています。
上のロジアナの波形は、その前後の波形の解析から、１６，１７と続くデータの、　，１の部分をＰＩＣ１８Ｆ１４Ｋ５０がＺ８０ＣＰＵに渡しているところだということがわかっています。

［２Ｃ］は　，　の、［３１］は　１　のＡＳＣＩＩコードです。
最初に下位４ビットを、次に上位４ビットを渡しています。
実は、ここで、
あれえ？
というおかしなところがあることに気がつきました。
そこが、やっぱりおかしかったのですが、それについてはまたあとで説明いたします。

そして、これが問題のデータ欠落部分です。

［３７］は　７　のＡＳＣＩＩコードです。
１６，１７，１８
と続く部分の、７，　のところです。
上でも説明しましたが、［２Ｃ］は、　，　のＡＳＣＩＩコードです。

コード［２Ｃ］はちゃんとＰＩＣ１８Ｆ１４Ｋ５０からＺ８０ＣＰＵ側に渡されています。
Ｚ８０ＢＵＳＹ信号も２回出ていますから、Ｚ８０側も確かに、［２Ｃ］を受け取っているはずなのですが…。
実はここで、とんでもないことがおきていたのです。

上から続く、［２Ｃ］、［３１］、［３７］の受け渡しの波形と、最後の［２Ｃ］の波形とをよーく見ていただきますと、そのとんでもないことが、見えてくるのでありますが…。
おわかりいただけますでしょうか？

というところで、本日も時間がなくなってしまいました。
この続きは、次回にさせていただくことにいたします。
２０１０．８．１３ｕｐｌｏａｄ

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