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

●データの欠落には規則性がありそうです

今回はやっと、［第５７１回］で書きました、ＲＳ２３２Ｃ受信データがときどき欠落してしまう、ことについての説明までたどりつきました。
例によってまた途中で道草をしてしまったものですから、ここまで来るのにたっぷりかかってしまいました。
ずいぶん時間が経ってしまいましたから、もう一度問題の現象について説明をいたします。

下記はＲＳ２３２Ｃデータを受信して、それをそのままＰＲＩＮＴ文で画面に表示させるという、実に簡単なプログラムと、その実行結果です。

    10 A%=0
    20 READ #1,A$,A%
    30 IF A%<1 GOTO 20
    40 PRINT A$
    50 GOTO 10
>r.
0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,1
6,17,18,19,20,21,22,23,24,25,26,27,28,2
9,30,31,32,33,34,35,36,37,38,39,40,41,4
,43,44,45,46,47,48,49,50,51,52,53,54,55
,56,57,58,59,60,61,62,63,64,65,66,67,68
69,70,71,72,73,74,75,76,77,78,79,80,81,
82,83,84,85,86,87,88,89,90,91,92,93,94,
5,96,97,98,99,100,101,102,103,104,105,1
06,107,108,109,110,111,112,113,114,115,
16,117,118,119,120,121,122,123,124,125,
126,127,128,129,130,131,132,133,134,135
136,137,138,139,140,141,142,143,144,145
,146,147,148,149,150,151,152,153,154,15
,156,157,158,159,160,161,162,163,164,16
5,166,167,168,169,170,171,172,173,174,1
5,176,177,178,179,180,181,182,183,184,1
85,186,187,188,189,190,191,192,193,194,
95,196,197,198,199,200,201,202,203,204,
205,206,207,208,209,210,211,212,213,214
215,216,217,218,219,220,221,222,223,224
,225,226,227,228,229,230,231,232,233,23
,235,236,237,238,239,240,241,242,243,24
4,245,246,247,248,249,250,251,252,253,2
4,255,end

ＲＥＡＤ　＃１，Ａ＄，Ａ％　というのが、ＲＳ２３２Ｃの受信命令です。
受信したデータは文字変数Ａ＄に読み込まれます。
Ｚ８０ＢＡＳＩＣの文字変数は３９バイトの固定長です。
０Ｄ０Ａコードか、３９バイト受信するごとに、ＲＥＡＤ　＃１命令は、その受信データをＡ＄に入れてリターンしてきます。
リターンしてくる都度、ＰＲＩＮＴ文でＡ＄の値を表示しますから、上のような結果になります。

ところが表示された結果をよく見てみますと、ところどころ、１バイトですけれど、データが欠落しています。

４（０）、６８（，）、（９）５、（１）１６、１３５（，）、１５（５）、１（７）５、（１）９５、２１４（，）、２３（４）、２（５）４

以上の（　）内の文字が欠落しています。
さらに、文字が欠落している位置を見てみますと、その全てが、行の最後（あるいは最初）の１文字であることがわかります。

こうなってくると、どうも２３２Ｃの受信そのものに原因があるというよりも、もう少し別のところに原因がありそうな気がします。
しかしどうにもその原因らしきものに思い当たりません。

苦し紛れに、こうなったら、下手な鉄砲も数撃てば当る、とばかりにいろいろ思いつくままにプログラムを書き換えてテストしてみました。

ちょっと見ただけでは何をやっているのか意味不明のプログラムですが。

    10 DIM T$(500)
    20 T%=0
    30 A%=-1
    35 A$="12345678901234567890ABCDE"
    40 READ #1,A$,A%
    50 IF A%<1 GOTO 40
    60 T$(T%)=A$
    70 T%=T%+1
    80 'IF T%<10 GOTO 30
    90 'PRINT A$
   100 GOTO 30
   110 FOR B%=0 TO T%-1:PRINT T$(B%):NEXT B%
>p.t%
62

>g.110
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

いろいろ考えているのです。
上は実行結果の一部だけですが、やっぱり行の終わりだけがときどき欠落しています。
１２と１３の間、それと１７と１８の間の　，　が落ちています。

規則性があることは間違いなさそうですが、これにはまいりました。
さっぱり原因がつかめません。
はっきり言って、お手上げです。

しかし手を上げてみたところで物事が解決するわけではありませんから、やっぱりなんとかするしかありません。
とりあえず出来ることからやってみましょう、ということで、ＰＩＣ１８Ｆ１４Ｋ５０とＺ８０の間でデータがきちんと渡されているのか、それとも渡っていないのか、まずはそこのところを確認してみることにしました。

データの受け渡しとなりますと、少なくとも、２３２Ｃセレクト、ＳＴＢ、ＢＵＳＹとデータライン４本、の合計７本のラインを見なければなりません。
これはオシロスコープではとても無理です。
いや、規則性があるとは言うものの、受信データは９６００ボーですから、９６０バイト／秒、約１ｍｓｅｃに１回の割りでしか、データの受け渡しは行われません。
しかもＰＩＣ１８Ｆ１４Ｋ５０からＺ８０に１バイトのデータが渡されるときの速さは遅くても数十μｓｅｃ程度です。
しかもしかも毎回データが欠落するのではなくて、何回かあるいは何十回かに１回、欠落するのですから、こりゃあとてもオシロスコープでは歯が立ちません。

すると。
やっぱり、あれです。
ロジアナの出番でしょう。
カメレオンＵＳＢ＋ロジアナです。

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

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