標準ＴＴＬだけ（！）でCPUをつくろう！（組立てキットです！）
(ホントは７４ＨＣ、ＣＭＯＳなんだけど…）
［第５６８回］
●Ｚ８０ＢＡＳＩＣのＲＳ２３２Ｃ受信プログラム
このところ、ＲＳ２３２Ｃの処理で悩んでおります、ということを、前回書きました。
ＲＳ２３２Ｃの送受信も、ＵＳＢの送受信も、それぞれの機能をマニュアル操作で使う分には、特にこれといった問題もなく使えるところまで、プログラムはできているのですが、ＲＳ２３２Ｃの受信と、その受信したデータを画面に表示する、といったごくごく簡単なプログラムをＢＡＳＩＣで書いて実行すると、受信エラーが発生してしまうのです。
下はＢＡＳＩＣのサンプルプログラムとその実行結果です。
>.
10 A%=0
20 READ #1,A$,A%
30 IF A%<1 GOTO 20
40 PRINT A$
50 GOTO 10
>R.
80008058CD47023CCA00803DCD0E80C30080F5E
5D5C5214180856F461E1A503EF7D3982A000021
000015C21F80503EE7D3982A000021000015C22
E801DC21A80C1D1E1F1C97F77716A5F59544F47
33F3B35322F2C25272A4B38642321
いまどきはＢＡＳＩＣなど時代遅れの一言で片付けられてしまいそうですが、簡単に記述できる、というのが最大の長所です。
これほど簡単に使える言語は他にはないのではありませんでしょうか？
ＲＥＡＤ ＃１がＲＳ２３２Ｃ受信命令です。
文字変数Ａ＄に受信データが入ります。
Ａ％は制御用の変数です。
Ａ＄、Ａ％は使用例です。Ａ＄の代わりに任意の文字変数、Ａ％の代わりに任意の整数型変数を使うことができます。
Ａ％＝０でＲＥＡＤ ＃１，Ａ＄，Ａ％を実行すると、Ａ＄をクリアして受信データが入力されます。
Ｚ８０ＢＡＳＩＣは、少ないＲＡＭ容量を有効に使うためと、マシン語サブルーチンとの併用が簡単にできるようすることなどの理由から、文字変数は固定長（３９バイト）です。
ＲＳ２３２Ｃ受信データは、０Ｄ０Ａコードまでを一区切りとして扱います。
０Ｄ０Ａコードを受信するまでＡ＄にデータが格納されていきます。
データが途切れるか、０Ｄ０Ａコードを受信するか、Ａ＄が一杯（３９バイト）になるか、のいずれかでＲＥＡＤ ＃１，Ａ＄，Ａ％は終了して次の行に移ります。
０Ｄ０Ａが受信されたときはＡ％にその受信した文字数（Ａ＄に格納されている文字数と同じ）が入ります。
０Ｄ０Ａが受信される前にＡ＄に３９バイトの受信文字データが入ると、Ａ％＝４０になります。
それ以外のときはＡ％＝－１になります。
このＡ％の値を見ることで受信の状況を判断することができます。
ここで受信されたデータはバイナリデータのように見えますが、ＡＳＣＩＩ文字データです。
ＲＳ２３２Ｃは通常は文字データ（キャラクタコード）を扱います。
送信側（Ｃ＋＋で作成したプログラム）で使ったファイルは、ＭＹＣＰＵ８０のときのｓｏｕｎｄ．ｈｔｘです。
バイナリデータを１６進数表現にして０～９、Ａ～ＦのＡＳＣＩＩ文字コードで表現したファイルです。
実は、やっと昨晩になって、ここまでできるところまできたのです。
ＲＥＡＤ ＃１命令でのＲＳ２３２Ｃ受信はＰＩＣ１８Ｆ１４Ｋ５０で受けたあと、Ｚ８０ＣＰＵに渡されたものですし、ＰＲＩＮＴ文で画面に表示されたデータ（上のリストは画面に表示されたものをそのまま記録したログファイルの一部です）は、Ｚ８０ＣＰＵからＰＩＣ１８Ｆ１４Ｋ５０に送られたあと、ＵＳＢ経由でＷｉｎｄｏｗｓパソコンに送られてきたものです。
ＰＩＣ１８Ｆ１４Ｋ５０のＲＳ２３２Ｃ受信は、当初普通のプログラムでしたが、そのままではどうしようもないことがわかりましたので、急遽割り込みプログラムに書き換えてしまいました。
受信バッファは２５６バイトです。
そのあたりのＰＩＣプログラムの実際についても説明させていただくつもりなのですが、本日はとても時間がありません。
いずれあらためて、ということになると思います。
ともあれ、ＲＳ２３２Ｃ受信は、ＰＲＩＮＴ文の実行によるＷｉｎｄｏｗｓパソコンへのＵＳＢ送信と、同時並行的に行われています。
このサンプルではうまくいったのでしたが、さらにテストを重ねていきますと、やっぱり問題が出て来てしまいました。
●不正な処理メッセージが…
以前にＲＳ２３２Ｃ送信（ＣＯＭ１）のためのテストプログラムを作ったものがありましたので、今回のテストにはそのプログラムｗ２３２ｃｏｍ１．ｅｘｅを使いました。
まあ、それが、ちょいといい加減なプログラムだったのですねえ。
上でお見せしたｓｏｕｎｄ．ｈｔｘ程度のデータファイルを送出したときは問題無く実行できたのですけれど、今度はちょいと大きいデータを送ってみようと思いまして、ｗ２３２送信プログラムのソースをそのまま送信してみましたところ、ご覧のように、あのどうしようもない「不正な処理」エラーが表示されてしまいました。
しかしこれはもう、多分データサイズだな、と思いましたので、一度に送る送信データを小さくしましたところ、エラーは表示されなくなりました。
まずは、めでたしめでたし、です。
そのように対策したプログラムｗ２３２ｃｏｍ１＿ｂ．ｃｐｐです。
毎々説明しておりますように、ＢｏｒｌａｎｄＣ＋＋コンパイラでコンパイルしております。
ＶＣ＋＋など他のコンパイラではエラーが出るかもしれません。
/// w232.cpp for mycpu 09/03/13 3/20
// 10/5/8 COM1
// 7/30
#include <windows.h>
#include <stdio.h>
//
FILE *rfp;
unsigned char outbf[1024]="\0";
char comname[5]="\0";
char *fname;
int dtbyte=0;
int e;
int i;
int j;
int inbfn;
int datan;
unsigned long int dwWrite;
HANDLE hcom;
int open();
int write();
int close();
///
void main(int argn,char *args[])
{
fname=args[1];
//file open
rfp=fopen(fname,"rb");
if(!rfp){printf("can't open %s\n",fname);return;}
sprintf(comname,"COM1");
e=open();
if(e==0){printf("can't open %s\n",comname);fclose(rfp);return;}// pass to end
//file read & send data
fseek(rfp,0,SEEK_END);
datan=ftell(rfp);
fseek(rfp,0,SEEK_SET);
printf("datan=%d\n",datan);//test
for(i=0,inbfn=0;i<=datan;i++)
{
outbf[inbfn]=fgetc(rfp);
if(inbfn==999||i==datan)
{inbfn++;
e=write();
if(e==0){close();fclose(rfp);return;}
printf("send data %d bytes\n",dwWrite);
inbfn=0;
}
else inbfn++;
}
close();
fclose(rfp);
printf("end\n");
}
///
/// com open
int open()
{
hcom=CreateFile(comname,GENERIC_READ|GENERIC_WRITE,0,NULL,
OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL);
if(hcom==INVALID_HANDLE_VALUE)return 0;
/// get DCB
DCB dcb;
GetCommState(hcom,&dcb);
dcb.BaudRate=9600;
dcb.ByteSize=8;
dcb.Parity=NOPARITY;
dcb.StopBits=ONESTOPBIT;
if(!SetCommState(hcom,&dcb))return 0;
return 1;
}
///
int write()
{
if(!WriteFile(hcom,outbf,inbfn,&dwWrite,NULL))
{printf("%s WRITE ERROR\n",comname);return 0;}
return 1;} /// end of elseif
//
int close()
{CloseHandle(hcom);return 1;}
それにしても、ＢＡＳＩＣと比較すると、なんと面倒なことでしょう。
おまけに、不正な処理ですものねえ。
もとのプログラムではｏｕｔｂｆ［］をうんと大きいサイズにしておいて、ファイルから全部読み込んでそのままＷｒｉｔｅｆｉｌｅ（）に突っ込んでいたのですけれど、そりゃあ少し乱暴でした。
上の実行例からすると、どうやら標準の出力バッファのサイズは１０２４バイトあたりのようです。
バッファサイズは指定することもできるようなのですが、どうせそうしたところで、どこかで区切らざるを得ないと思いますので、手ごろなところで、１０００バイトごとに送信するように書き改めました。
なお送信側はプログラムでボーレートを９６００ボーに設定していますが、Ｚ８０ＢＡＳＩＣの側はどこで設定しているのでしょう？
じつはＮＤ８０ＺⅢ基板のＤＩＰスイッチの余った部分を利用して、９６００、４８００、２４００ボーの３通りを選択するようにしてあるのです。
さて、上のような送信プログラムにすることで、不正な処理メッセージは出なくなったのですが、今度は受信側でエラーが出てしまいました。
というところで、本日もタイムアウトになってしまいました。
この続きはまた次回にすることに致します。
２０１０．７．３０ｕｐｌｏａｄ
前へ
次へ
ホームページトップへ戻る