標準TTLだけ(!)でCPUをつくろう!(組立てキットです!)
(ホントは74HC、CMOSなんだけど…)
[第581回]
●データの欠落には規則性がありそうです
今回はやっと、[第571回]で書きました、RS232C受信データがときどき欠落してしまう、ことについての説明までたどりつきました。
例によってまた途中で道草をしてしまったものですから、ここまで来るのにたっぷりかかってしまいました。
ずいぶん時間が経ってしまいましたから、もう一度問題の現象について説明をいたします。
下記はRS232Cデータを受信して、それをそのままPRINT文で画面に表示させるという、実に簡単なプログラムと、その実行結果です。
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
READ #1,A$,A% というのが、RS232Cの受信命令です。
受信したデータは文字変数A$に読み込まれます。
Z80BASICの文字変数は39バイトの固定長です。
0D0Aコードか、39バイト受信するごとに、READ #1命令は、その受信データをA$に入れてリターンしてきます。
リターンしてくる都度、PRINT文でA$の値を表示しますから、上のような結果になります。
ところが表示された結果をよく見てみますと、ところどころ、1バイトですけれど、データが欠落しています。
4(0)、68(,)、(9)5、(1)16、135(,)、15(5)、1(7)5、(1)95、214(,)、23(4)、2(5)4
以上の( )内の文字が欠落しています。
さらに、文字が欠落している位置を見てみますと、その全てが、行の最後(あるいは最初)の1文字であることがわかります。
こうなってくると、どうも232Cの受信そのものに原因があるというよりも、もう少し別のところに原因がありそうな気がします。
しかしどうにもその原因らしきものに思い当たりません。
苦し紛れに、こうなったら、下手な鉄砲も数撃てば当る、とばかりにいろいろ思いつくままにプログラムを書き換えてテストしてみました。
ちょっと見ただけでは何をやっているのか意味不明のプログラムですが。
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
いろいろ考えているのです。
上は実行結果の一部だけですが、やっぱり行の終わりだけがときどき欠落しています。
12と13の間、それと17と18の間の , が落ちています。
規則性があることは間違いなさそうですが、これにはまいりました。
さっぱり原因がつかめません。
はっきり言って、お手上げです。
しかし手を上げてみたところで物事が解決するわけではありませんから、やっぱりなんとかするしかありません。
とりあえず出来ることからやってみましょう、ということで、PIC18F14K50とZ80の間でデータがきちんと渡されているのか、それとも渡っていないのか、まずはそこのところを確認してみることにしました。
データの受け渡しとなりますと、少なくとも、232Cセレクト、STB、BUSYとデータライン4本、の合計7本のラインを見なければなりません。
これはオシロスコープではとても無理です。
いや、規則性があるとは言うものの、受信データは9600ボーですから、960バイト/秒、約1msecに1回の割りでしか、データの受け渡しは行われません。
しかもPIC18F14K50からZ80に1バイトのデータが渡されるときの速さは遅くても数十μsec程度です。
しかもしかも毎回データが欠落するのではなくて、何回かあるいは何十回かに1回、欠落するのですから、こりゃあとてもオシロスコープでは歯が立ちません。
すると。
やっぱり、あれです。
ロジアナの出番でしょう。
カメレオンUSB+ロジアナです。
うう。
時間が無くなってしまいました。この続きはまた次回にいたします。
2010.8.12upload
前へ
次へ
ホームページトップへ戻る