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

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

●ＲＳ２３２Ｃ受信プログラムの説明です（７）

前回の説明で、ＲＳ２３２Ｃ受信プログラムｒ２３２．ｃｐｐの説明は一応は終わったのですが、１つだけ、受信バッファのサイズについては、「あとで説明します」と書きました。

ｒ２３２．ｃｐｐの中では、ＲｅａｄＦｉｌｅ（）のパラメータとして、読み取ったデータを格納する場所として、ｉｎｂｆという４０９６バイトの文字変数エリアを確保し、かつ読み取りデータの最大値としても４０９６バイトを指定しています。


char inbf[4096]="\0";

// rs232c read
if(!ReadFile(hcom,&inbf,4096,&rdbytes,NULL))printf("%s READ ERROR\n",comname);

しかし、そもそもは、どこかに本当の「ＲＳ２３２Ｃ受信バッファ」があるはずです。
そのバッファサイズは指定しなくてもよいのでしょうか？
これもまた気になるところです。

そこで、受信バッファについても調べてみました。

●ＣＯＭＭＰＲＯＰ構造体とＧｅｔＣｏｍｍＰｒｏｐｅｒｔｉｅｓ（）

ＲＳ２３２Ｃの受信バッファサイズ（および送信バッファサイズ）は、ＣＯＭＭＰＲＯＰ構造体にあることがわかりました。
そしてＣＯＭＭＰＲＯＰ構造体にアクセスして、その情報を読み出すのに使うのが、やはりＷｉｎｄｏｗｓＡＰＩのＧｅｔＣｏｍｍＰｒｏｐｅｒｔｉｅｓ（）です。
もう、構造体だらけです。ホント、いいかげんうんざりしてしまいます。
でも、これしか方法がありませんから仕方がありません。

ｒ２３２．ｃｐｐを少し変形して、受信バッファサイズ（ついでに送信バッファサイズ）も求めてみました。
ｒ２３２ｃｋ．ｃｐｐのプログラムリストです。


/// r232ck.cpp
// 09/6/4
// buffer size check
#include <windows.h>
#include <stdio.h>
//
        char comname[5]="\0";
        int tsize;
        int rsize;
        HANDLE hcom;
///
void main()
{
// com open
        sprintf(comname,"COM3");
        hcom=CreateFile(comname,GENERIC_READ|GENERIC_WRITE,0,NULL,
        OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL);
        if(hcom==INVALID_HANDLE_VALUE)printf("can't open %s\n",comname);// pass to end
else
        {
        COMMPROP commprop;
        if(!GetCommProperties(hcom,&commprop))printf("getcommerr");
        else
        {
        tsize=commprop.dwMaxTxQueue;
        rsize=commprop.dwMaxRxQueue;
        printf("tx=%d,rx=%d",tsize,rsize);
        printf("\n");
        }
// com close    
        CloseHandle(hcom);
}
}

ｒ２３２ｃｋ．ｃｐｐをコンパイルして、できたｒ２３２ｃｋ．ｅｘｅを実行してみました。
．ｃｐｐというのはＣ＋＋のソースプログラムファイルにつける拡張子です。
．ｃｐｐファイルをＣ＋＋コンパイラにかけると、実行形式のファイル　．ｅｘｅができます。

ｒ２３２ｃｋ．ｅｘｅを実行してみた結果、送信バッファも受信バッファもデフォルトでは４０９６バイトであるらしいことがわかりました。
今回の使用目的である、「つくるＣＰＵ（ＭＹＣＰＵ８０）」との間でのデータの送受信のため、という用途に限定するならば、送信バッファも受信バッファも、４０９６バイト（４Ｋバイト）もあれば十分ですから、既定値のまま使うことにしました。

以上で、長々と続いた、ＲＳ２３２Ｃ受信プログラムの説明も、やっと終了いたしました。

●ＵＳＢインターフェース基板ができてきました

［第２７０回］で説明しました、「つくるＣＰＵ（ＭＹＣＰＵ８０）」本体基板から分離させてしまった、「ＵＳＢインターフェース基板」が本体基板よりも一足先にできてきました。
さっそくＩＣやそのほかのパーツを組みつけて、動作テストをしました。
ＵＳＢケーブルで、Ｗｉｎｄｏｗｓパソコンに接続したところ、無事「USB<->Serial」デバイスとして認識されました。

こちらが部品面です。

こちらがハンダ面です。

この基板は１０ｐｉｎの基板接続用コネクタで「つくるＣＰＵ（ＭＹＣＰＵ８０）」本体基板に接続します。
電源は１０ｐｉｎコネクタを介して「つくるＣＰＵ（ＭＹＣＰＵ８０）」本体基板から供給しますから、ＵＳＢコネクタの＋５Ｖは配線してありませんが、今回はＷｉｎｄｏｗｓパソコンへの接続テストですから、ＵＳＢコネクタから＋５Ｖをもらうため、写真の赤ケーブルのように追加配線をしています。

ＵＳＢ＜＞２３２Ｃ変換ＩＣのＦＴ２３２ＲＬは２８ｐｉｎのフラットパッケージＩＣなので、写真のように面実装しなければなりません。
ハンダ付けに余り慣れていない方にはちょいと難しい作業ですから、この基板は完成品動作テスト済みとして供給することにしました。
ですから、シルク印刷もグリーンレジストもありません。
なるべく原価を安くしたい、という理由からです。

それでも本当のことをいいますと、当初の案のように、「秋月」の「ＵＳＢ２３２Ｃ変換ケーブル」をそのまま使った方が安くあがります。
苦労して作って、原価も高くなってしまうなんて馬鹿みたいな話です。
もともと別基板にしないで、「つくるＣＰＵ」本体の基板上にのせてしまうならば、こちらの方がすこしは安くあがる計算だったのですけれど、別基板の、プリント基板の分だけ原価アップしてしまいました。

いささか愚かかも知れませんが、前にも書きましたように、ＵＳＢ→ＲＳ２３２Ｃ変換（ＴＴＬ）→ＲＳ２３２Ｃレベルにと変換したものをまたＲＳ２３２Ｃレベル→ＴＴＬレベルへ変換するというのは、いかにも冗長なので、その回路上のムダを省くためにこうしたのです。

それと、もうひとつ、ＵＳＢ・ＲＳ２３２Ｃ変換ケーブルという製品になってしまうと、中がどうなっているのか見えません。ブラックボックスです（すこしは透けてみえるようですけれど）。
それをこういう基板で見ると、本当にＩＣ１個だけで、そういうこと（ＵＳＢ・２３２Ｃ変換）ができてしまう、ということを目で見て実感することができる、というメリットもあると思います。
２００９．７．２０ｕｐｌｏａｄ

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