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

Back to archive index
matsuo zmats****@gmail*****
2023年 2月 2日 (木) 22:48:45 JST


松尾です。

チェックいただきありがとうございます。

シリアルに書き込みをリクエスト(Win32の WriteFile())しますが
すぐに送信は完了しません。(すぐ完了する時もあるかも)。
アプリ側の送信バッファのデータは保持しておく必要はなさそうですが、
(32KB送信時、WriteFile()完了(送信は未完)ですぐfree()してます)
送信が完了するまで次のWriteFile()を行わないようにしています。

WriteFile()でブロックしないのは、別の処理を行うためです。
WindowsではOverlaped I/Oと呼ぶそうです。

実際は送受の2スレッドで処理すれば
ブロックしてもいいのでは?となると思うのですが
こういうAPIの使い方が効率が良いそうです。

 > ※1 基本的に大丈夫だ("send size 1 (finish)" と表示される)が、連続
 > して打っていると "writing.." と表示されるときがある。その時のキーは
 > 受信側に表示されない。

送信リクエストが完了するまでに、
次の送信しようとすると"writing.."と表示してそのキーは送信しません。
"writing.."は、書き込み中,完了してないので.. という気持ちでした。
Tera Termをビルドしながらテストするなど
CPUを忙しい状態にすると出やすいかも。

 > ※2 0 にした1文字目は送信側に何も表示されない。2文字目から送信側に
 > "writing.." と表示される。

送信完了とならないので、アプリ(ttcomtester)から文字が送れない状態です。
1文字目はOSがリクエストを受け付けた状態になっているんだと思います。

 > ※3 r で 1 にしても 0 の間のデータは表示されない。その後(1の状態で)
 > 送信しても送信側 "writing.." となり受信側に表示されない(l で見ると
 > CTS は ON になっているのに)。送信側の close / open で復旧する。

RTS(CTS)=0→1で送信側が送信できるようになった時、
送信されるかどうかは送信バッファ(OS,チップ,両方?)に
どんなふうに溜まっているかで変化すると思います。

そのあと送信完了が発生せず送信できなくなるのはr10562で対応しました

 > ※4 最初は大丈夫だが、しばらく打っていると "write() error
 > 4317,0x10dd 識別操作子が無効です。" と表示され、その後キーを受け付け
 > なくなる。アプリを落とすしかない。PC6 固有の問題?

フラグの設定を間違っていました。r10561で修正しました。

 > ※5 0 にした3文字目まで送信側に "send size 1 (finish)" と表示される。
 > 4文字目は送信側に何も表示されない。5文字目から送信側に "writing.."
 > と表示される。

送信リクエストしたデータが受け付けられて
未送信状態の時 pending と出るようにしました

 > ※6 r で 1 にすると 3 文字だけ表示される。その後(1の状態で)送信し
 > ても送信側 "writing.." となり受信側に表示されない(l で見ると CTS は
 > ON になっているのに)。送信側の close / open で復旧する。

症状は ※3 と同じように見えます。
直っていると思います。


フロー制御で送信が止まっている(RTS(CTS)=0)間でも、
ある程度はWriteFile()が完了します。
FTDIのドライバだとある程度(67byteぐらい)から挙動がおかしくなります。
HHD SoftwareのVirtual Serial Port,Local Bridgesだと
いくらでも(32KBを数回は試してokでした)送信リクエストできます。
(本当は送信完了まで送信バッファを保持しておかないといけないかもしれないですね)

プログラムでCTSをチェックして0なら
WriteFile()しないようにしました。(r10562)
手もとでは安定しているように思えます。

本当は、フロー制御中でもある程度送信バッファに積んでおきたいんですけど
どれぐらい積んでokなのか判断できないようです。



ttssh2-dev メーリングリストの案内
Back to archive index