[ttssh2-dev 576] Re: ticket #45271 / Serial Hard Flow

Zurück zum Archiv-Index
matsuo zmats****@gmail*****
2023年 2月 4日 (土) 02:17:09 JST


松尾です。

 > テストしました。結果はこちらに。
 > https://osdn.net/users/nmaya/pf/Tera_Term_test/wiki/serial#h2-rev10562
ありがとうございます。
安定してきました。


通常は
 > send 32, sent 0 byte pending
 > send size 1 (finish)
このペアがでます。松尾環境も同じです。
main.cpp からみると、write() (送信リクエスト)した結果、
まだ完了していない(pending)
その後完了(finish)というイメージです。

 > send 34, sent 1 byte
は、main.cpp からみると、
write() したら、write()内で送信完了した時です。

device_com.cpp の write() 内では、
1) WriteFile() でそのまま完了したか
2) WriteFile() がPENDINGを返してきて、
    0msイベントのシグナルを待った結果、シグナル状態になって
    GetOverlappedResult() で1バイト送信が確認できた
のどちらかになります。

送信リクエストした前後でOSで何かが起こって
(よくあるのはウィルスチェックが動作するとかでしょうか)
ttcomtester.exeに時間が回ってこなくなって、
そのすきにリクエストした送信がシリアルに送られ完了状態になって
main.cppからみるとリクエストがすぐに完了したように見える
という感じでしょうか。

 > 確認ですが、send mode で 受信側が 0 の間に送信側で押したキーは
 > 受信側を 1 にしても出てきません。
 > ttssh2-dev 553 では
 >>> - 対向側の RTS を 0 にして、send mode で送信し、その後対向側の RTS を 1
 >>> にすると?
 >> 1にしたところで受信する(送信される)
 > とありましたが

この時は、HHD SOFTWARE の Virtual Serail Ports
だけでテストしていて、実機(FT232RL)がない頃でした。
CTS=0となっていても
OS側はいくらでも送信リクエストを受け付けて、
CTS=1になったらすべて送り出してくれる、
シリアルはOSがうまくやってくれて、このように動作すると思っていました。
でも、この動作は上記のドライバだからのようです。

 >ttssh2-dev 572 の
 >> RTS(CTS)=0→1で送信側が送信できるようになった時、
 >> 送信されるかどうかは送信バッファ(OS,チップ,両方?)に
 >> どんなふうに溜まっているかで変化すると思います。
 >これが最新の理解ということでしょうか?

そのような理解です。


1byteの送信完了したところで、
アプリ(ttcomtester)から1byte送信リクエストしていると
とても送信が遅くなります。

そこで、ある程度チップ内には送信バッファがあって
そこから送信するれば効率よく送信できます。
FT232BM,FT232RLとも128byteの送信バッファがあるようです。

多分チップのバッファとは別にOS(チップのドライバ)の送信バッファもあって、
チップの送信バッファが空になる前に、
OSの送信バッファからデータをつめていくはずです。
(または、Overlaped I/O時は、アプリ(ttcomtester)のメモリそのままかも)

送信している途中に CTS=1→0 となったときチップが送信を止めます。
CTS=0→1 となったとき、アプリが送信しなくても
チップ,OSのバッファが残っていればそこから送信されるはずです。

CTS=0 の間にもアプリ(ttcomteser)から送信リクエストを出して
チップ,OSのバッファをつめることができれば、
次のCTS=0→1になったときに最適に送信できるはずと考えていました。

でも場合によって(手もとではFT232RLのドライバで)は
CTS=0のときバッファを詰めようとリクエストを出していると
ある程度から動作がおかしくなってしまいます。
(他のドライバでも起こるのでは?と思います。)
そこで、アプリからCTS=0を検知したら
OSにリクエストを出さないようにしました。


 > 話を大元に戻すと、ticket は「Hardware Flow Control が動作しない」つまり
 > Tera Term と 
何か(ハードウェア制御に対応してる)をシリアルケーブルで繋ぎ、
 > フロー制御を RTS/CTS に設定して、シリアル接続で開いて通信したとき、
 > 「RTS/CTS シグナルが無視されている」ということでした。

手もとで動作を見たところ無視していました(ttssh2-dev 571)。
これからソースも追いかけていきます。

 > これは
 > 「Tera Term は何か 側の CTS=OFF 
を無視して送信する」ということでしょうか?
 > また、Tera Term 
が受信するときには、ハードウェア制御は関係ないのでしょうか?

ハードウェアに関係しているはずですよね。
ttcomtesterでフロー制御できているので
Tear Termでもできるはずです。
何かの拍子にCTSを無視して動作するよう設定しているとか
ちょっとした間違いではないかな?と予想しています。



ttssh2-dev メーリングリストの案内
Zurück zum Archiv-Index