標準TTLだけ(!)でCPUをつくろう!(組立てキットです!)
(ホントは74HC、CMOSなんだけど…)
[第610回]

●BASICでRS232C受信ができません

今回は、ディップスイッチがSTEP側になっている状態で、リモート接続を終了すると、ND80ZVの7セグメントLEDに05C0xxxxと表示されてしまうことについて、その解決編を書くつもりだったのですが、急遽予定変更です。

説明書の作業もいよいよ仕上げ段階に近付いてきています。
BASICの操作説明書の作業で、ちょいと説明が面倒になりそうなので後回しにしておりました、RS232Cの送信、受信の説明に取りかかりましたところ、どういうわけか、全く受信できません。
送信は大丈夫です。
受信だけができなくなってしまいました。

そんなはずは…。
で、ノートを見てみたのですけれど、これがもう、あきれてしまうくらい、いい加減で、肝心の作業記録がほとんど書いてありません。
なにしろ、毎日のように、突発的に問題が発生しては、その対策に没頭する、ということを繰り返してきておりまして、そのために行った対策のあれこれを、きちんとノートにまとめておかなくては、と思ってはいるのですが、なかなかにノートにまとめるという作業は面倒なものなのですよね。

はるか昔、学生時代から、ノートを取らないことが唯一の自慢だったくらいの出来が悪い学生だったものですから、今になってまともにノートが取れるわけがない。
って居直ってみたって仕方がないのですけれど。

そういえば、ホームページの、この連載記事。確かどこかで、RS232Cについてのあれこれを書いたような…。
で、過去記事を読み直してみましたら。
おお。あった。ありました。
ちゃんと、しっかり書いているではありませんか。

これこそ、まさに、ブログそのものでありまして、ほとんど毎日取り留めの無いことばかり書いておりますけれど、このところ、過去記事が結構役に立っておるのであります。
そうなりますと、読者の皆様がたのご迷惑とか困惑とかは、ちょいとご容赦いただきまして、一方的に備忘録をつけさせていただくことに相成ります。
そういう次第で、今回もまた突然の予定変更ですけれど、なにとぞお許しあれ。

で。
その過去記事なのですが。
BASICでのRS232Cについて、最初に書いておりますのが[第561回]のようです。7月23日ですから2ヶ月近くも前になります。どうやらこのあたりからBASICでの232Cプログラムの作業にとりかかったようです。

[第567回](7月29日)では、まだ大いに悩んでいるようです。BASICでのRS232C受信に問題があって、PIC18F14K50のRS232C受信を割込みを使ったプログラムに変更しなければならない、と書いております。
このあと、ずっとBASICでの232C受信の作業が続くのですけれど、途中からコマンドプロンプト画面への表示速度が遅い、遅すぎると思ったことから、C++での画面表示プログラムの変更だとか、WindowsXPでのコマンドプロンプトの画面設定、などというとんでもない横道にそれていってしまいました。

やっとRS232Cに戻るのは[第579回](8月10日)です。
BASICでのRS232C受信でときどきデータが欠落する、と書いています。
そうだったとしても、このあたりではちゃんとBASICで232C受信ができていたのですよねえ。
それが、今はまったく受信できません。
その後の1ヶ月ほどの間に行った作業が関係しているはずなのですが…。

[第580回]ではPIC18F14K50のプログラムのフローチャートをお見せしています。
突然に思い出したのですが、そういえば、その後、このフローを一部変更した、と思います。それについても書いておかなければいけませぬ(でも、それについては、また後日)。

[第582回](8月13日)に、BASICのRS232C受信プログラムのリストがあります。非常に簡単なプログラムです。
この時点では、このプログラムでちゃんと受信できていました。
今は、これと全く同じプログラムで、全然受信できません。
[第583回]で、やっと232C受信時のデータ欠落の原因がはっきりして、そのためのプログラム修正をしています。
そうすると、ここからさらに後で、まだ何か変更作業をしている、はずなのですが…。
おお。そういえば、何かやったような。

どうやらこれが原因らしいです。
[第588回](8月21日)で、ND80ZVをリモート接続しないで、単独でRS232C受信をすると、ハングアップしてしまう、と書いています。
それまではBASICでの232C受信が問題だったので、そのために苦労してプログラムを修正してきたのでしたが、今度はND80ZVのモニタプログラムでの232C受信でこけてしまいました。
そこで、その原因の追求が始まります。
そして、おお、[第592回]で、それまでの232C受信のときのPIC18F14K50とZ80CPUの間でのデータの受け渡しの方法を完全に変更してしまっています。

やっと、みつけました。
そうだったのでした。
ND80ZV単独でのRS232C受信が、7セグメントLED表示のためのDMAによって、ハングアップしてしまったことから、それまでのPIC18F14K50とZ80CPUとの間のデータの受け渡しの方法を変更してしまったのでした。
そういえば、その後に、キー入力データの受け渡しなどについては、新しいやりかたに合わせるために、プログラムを変更したのでしたが…。
BASICのRS232C受信については、[第583回]で行った修正作業が最後になっておりました。
むむ。これじゃあ、受信できるわけがありません。
さっそくプログラムの修正作業にかかりました。

しかし。
これほど、過去記事が役に立つとは思ってもみませんでした。
ほとんど毎日UPしているのですけれど、正直言って、毎日書くのはなかなかにしんどい作業です。
しんどい作業ではありますけれど、こうして、後々役に立つ、ということになりますと、がんばって、書かなくちゃあ、であります。

[第583回]に、BASICのRS232C受信命令READ#のマシン語のプログラムリストがあります。
参考までに、そのときのリストと、今回それを修正したあとのリストをお見せすることにいたします。
こちらが修正前のリストです。

39B4 08       RDSB:EX AF,AF'
39B5 C5       RDSB2:PUSH BC
39B6 06EB     LD B,EB
39B8 78       LD A,B
39B9 D398     OUT (98),A
39BB DB94     RDSB3:IN A,(94)
39BD E620     AND 20
39BF C2BB39   JP NZ,RDSB3
39C2 3E0A     LD A,0A;WAIT ABOUT 20MICROS
39C4 3D       RDSB32:DEC A;(4)
39C5 C2C439   JP NZ,RDSB32;(10)
39C8 DB94     IN A,(94)
39CA E620     AND 20
39CC C2F739   JP NZ,RDSB4
39CF DB94     IN A,(94)
39D1 E610     AND 10
39D3 F5       PUSH AF
39D4 CDA706   CALL RSIN
39D7 3EEF     LD A,EF
39D9 D398     OUT (98),A
39DB F1       POP AF
39DC CAFD39   JP Z,SINER;=73
39DF 79       LD A,C
39E0 C1       POP BC
39E1 FE0A     CP 0A
39E3 C8       RET Z
39E4 FE0D     CP 0D
39E6 CAB539   JP Z,RDSB2
39E9 77       LD (HL),A
39EA 23       INC HL
39EB 04       INC B
39EC 08       EX AF,AF'
39ED 3D       DEC A
39EE CAF539   JP Z,RDSB33
39F1 08       EX AF,AF'
39F2 C3B539   JP RDSB2
39F5 3C       RDSB33:INC A;reset zf
39F6 C9       RET
39F7 3EEF     RDSB4:LD A,EF
39F9 D398     OUT (98),A
39FB C1       POP BC
39FC C9       RET
              ;
39FD F1       SINER:POP AF;DUMMY
39FE F1       POP AF;DUMMY
39FF D1       POP DE
3A00 E1       POP HL
3A01 71       LD (HL),C
3A02 23       INC HL
3A03 3600     LD (HL),00
3A05 3EEF     LD A,EF
3A07 D398     OUT (98),A
3A09 3E49     ER49:LD A,49
3A0B C33D31   JP ERRDP

こちらが今回修正したあとのリストです。
39AC 08       RDSB:EX AF,AF'
39AD C5       RDSB2:PUSH BC
39AE 06EB     LD B,EB
39B0 78       LD A,B
39B1 D398     OUT (98),A
39B3 CD8D07   CALL SINSB
39B6 79       LD A,C
39B7 C2C539   JP NZ,RDSB3
39BA FEFF     CP FF
39BC CADE39   JP Z,RDSB4;NO DATA
39BF 32B8FF   LD (SINERMK),A
39C2 C3E539   JP SINER
39C5 C1       RDSB3:POP BC
39C6 FE0A     CP 0A
39C8 CAE039   JP Z,RDSB5
39CB FE0D     CP 0D
39CD CAAD39   JP Z,RDSB2
39D0 77       LD (HL),A
39D1 23       INC HL
39D2 04       INC B
39D3 08       EX AF,AF'
39D4 3D       DEC A
39D5 CADC39   JP Z,RDSB33
39D8 08       EX AF,AF'
39D9 C3AD39   JP RDSB2
39DC 3C       RDSB33:INC A;reset zf
39DD C9       RET
39DE B7       RDSB4:OR A;RESET ZF
39DF C1       POP BC
39E0 3EEF     RDSB5:LD A,EF
39E2 D398     OUT (98),A
39E4 C9       RET
              ;
39E5 F1       SINER:POP AF;DUMMY =PC
39E6 F1       POP AF;DUMMY =BC
39E7 D1       POP DE
39E8 E1       POP HL
39E9 77       LD (HL),A
39EA 23       INC HL
39EB 3600     LD (HL),00
39ED 3EEF     LD A,EF
39EF D398     OUT (98),A
39F1 3E49     ER49:LD A,49
39F3 C33631   JP ERRDP

修正前はバッファエンプティを知るために時間待ちループがあったのですが、修正後は、そこの部分が無くなって、データ無し、受信エラー、を受ける部分が完全に変わっています。

●受信できました

プログラムを修正して再度テストしましたところ、正しく受信できるようになりました。
やれやれ、です。

>list
    10 PRINT "START"
    20 KETA%=0
    30 READ #1,RDATA$,KETA%
    40 IF KETA%<=0 GOTO 30
    50 PRINT RDATA$;
    60 IF RDATA$="END"THEN STOP 
    70 IF KETA%=40 GOTO 20 ELSE PRINT :GOTO 20
>run
START
abcxyz
ABCXYZ
123
abcdefg
/end
END
break in 60

2010.9.14upload

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