■■■20レス以内で済むF-BASICの質問はこちらへ■■■

637：598：2015/10/31(土) 03:56:11: >>636
>つまり、この計測器は簡略化された半二重通信でPCと通信をする仕様になっているので

　はい、そのいう状態だと判断しました。
通信用LSIチップとしては同時に送・受信バッファの処理はできるのでしょうけれど。

>このプログラムを実行すると、fRtsControl書換 3 (RTS フロー制御:0..3)

　はい、fRtsControlという項目を RTS_CONTROL_TOGGLE(値は3)に書き換えて
Windows API のSetCommState (kernel32.DLL内)を実行してWindows経由でシリアルドライバを
設定します。

　「RTS_CONTROL_TOGGLE(トグル)モード」については、わたしもまったく知りませんでした。

で、このモード、
Windows“では”サポートされているらしく、 >624 のテスト結果ご報告にあるように
GW-BASICでは、RTS_CONTROL_DISABLE(値はゼロ)つまり、RTSは常時OFFに設定しています。
GW-BASICやQBASICでも、トグルモードは持っていないと思われ、
RTS_CONTROL_DISABLEにしています。昔はOUT命令でＩ／Ｏポートをじかに叩く制御方法が
とられたこともあるようです。

　常時OFFでいいのなら、F-BASICで問題が起こらなくてもと思うのですが、実態は
計測器側が受け取ったRTSの状態を見て、通信を保留していると推察されます。
常時ONのときだめになるので、おそらくは測定データ送信時。
PCからコマンド送信は制御線無視してのいきなり送りつけOKだが
測定データ送信は制御線を(ちゃんと？)見てから送り返していると。

　ならば常時OFFで実用上問題ないと。通信規約上はおかしいけど。
　そのいう状態だと判断しました。

>トグルの場合、受信バッファにデータがなければ RTS がOFFになり、

　それは参照先記載の誤りで「送信バッファ」だと解釈しました。
たぶん「ハンドシェイク」の説明文につられて書き間違えていると。
　( >621 の参照Webページ参照)

　原文はつぎのとおりです。
RTS_CONTROL_TOGGLE (0x03): トグルモード
Specifies that the RTS line will be high if bytes are available for transmission.
After all buffered bytes have been sent, the RTS line will be low.

テストプログラム >633 (+ >635 訂正)では、設定にさらにfNullの項をONにするよう
追加します。ただ、設定前に受信したNULL(00h)はそのままでしょうから、
「!!受信バッファが・・」への対処は必要なままでしょう。

※「fn」で始まる変数名はF-BASICの言語仕様上、使用できません。この追加部分にある
fnULLは(変数でもFN関数(＊に見えるが)でもない)、#define 文によって
プリプロセッサで処理されているため、成立しています。

※書き込む際の注意事項はこちら

※画像アップローダーはこちら

（画像を表示できるのは「画像リンクのサムネイル表示」がオンの掲示板に限ります）