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

Back to archive index
matsuo zmats****@gmail*****
2023年 2月 11日 (土) 01:03:34 JST


松尾です。

 > 受信時に RTS を 1 にするのは Tera Term 側の役目だと思いますが、
 > どこで上げるんでしょうか?

Tera Termの動作しているOS(ドライバ)が、
OS&チップ内の受信バッファのたまり具合から
(実際は多分、チップ内受信FIFOがある閾値になったら自動で)
RTS=0/1の制御をしていると思います。
Tera TermはOSのAPIを通して、OS(ドライバ,チップ)に
RTSを制御するようお願いしていると。


 > 
https://learn.microsoft.com/ja-jp/windows/win32/api/winbase/ns-winbase-dcb
 > - dcb.fOutxCtsFlow = TRUE;
 >    CTS が off だと CTS が on になるまで送信が一時停止される
 >    これが送信の設定?
これだと思います。

 > - dcb.fRtsControl = RTS_CONTROL_HANDSHAKE;
 >    RTS を上げるが、バッファが少なくなると RTS を下げる
 >    入力バッファとあるので、これが受信の設定?
これだと思います。


 >> ttssh2-dev 557
 >> 送信する側はOSによるフロー制御(HandShake=HS)しないといけないので
 >> フロー制御テストする時の送信側は--rts hs で起動、
 >> 受信側は--rts on で起動しないといけないです。
 > この説明と合わない気がするのですが、私が勘違いしているでしょうか?

送信側はOSに送信フロー制御(CTSの0/1を見て送信を実行/停止する)を
してもらうために--rts hsで起動

ちょっとややこしいのですが、
https://osdn.net/projects/ttssh2/svn/view/branches/ttcomtester/tools/ttcomtester/main.cpp?view=markup&revision=10588&root=ttssh2#l227
		} else if (wcscmp(arg_rts, L"hs") == 0) {
			dcb.fRtsControl = RTS_CONTROL_HANDSHAKE;
			dcb.fOutxCtsFlow = TRUE;
   RTS/CTSフロー制御 = RTSとCTSの両方のフロー制御ですね。
   このAPIではRTSフローなし、CTSフローありの設定などもできますね。

ttcomtesterの設定コードが最初間違っていて
dcb.fOutxCtsFlow を設定していなかった気がします。

受信側は'r'キーでRTS=0/1の出力
を切り替えたいので --rts on で起動
(クロス接続なので受信側RTS(出力)は
  送信側のCTS(入力)につながっている)

ttcomtester でRTS/CTSフロー制御でテストするための
クロス接続はこんな感じですね。

受信            送信
RTS ----------> CTS
RxD <---------- TxD
CTS <---------- RTS
TxD ----------> RxD


 > ticket の波形は、同期を取るため?に1文字ごとに、CTS(PCから見て)が
 > 上がっているように見えます。

1文字ごとのCTSのパルスを見て、下の図の古い(1の)フロー制御を使って
送ってきているような気がしました。
- 一番最初はRTS=1状態で、送信開始、そのあとRTSをみていない?
- 1byte送信直前にCTSを↑↓してから、1byte送信
なのかなと思いました。
または
- RTSは使っていない,CTSは1byte送信直前に↑↓する
かもしれません。
(RTS,CTSが普通のシリアルの仕様とは異なっている仮説です)

古いフロー制御のとき
RTS,CTSがどんなふうな波形になるのが正しいのか
資料を探し出せませんでした。
ただCTSに1byte毎にパルスが出ているのはかなり怪しいと思います。

 > この記事の波形(PCが送信側)は、RTS(上のオレンジ色)が上がりっぱなし
 > に見えます。MS の説明も、バッファがすべて送信されると RTS が下がる
 > と言っているので、ずっと上がっているのだと思います。
 > この記事のフロー制御と ticket のフロー制御?とは違うと思います。
うーん、そうですね。

 > USB だと OK になることも、ハイパーターミナルだと OK になることも
 > 不思議ですね。

不思議です。多分、
- PC(Tera Term)側の受信フロー制御が効いていない
   (送信側がフロー制御を見ていない)
という前提があって、
- HyperTerminalよりTera TermがOSからの取り込みが少し遅い
- HyperTerminalのほうがOS内の受信バッファサイズが大きい
のどちらか、または両方があって
- OS(チップ)内の受信バッファがあふれてdropする
となっているのかなと思います。
USBだとdropしないのはチップ内の受信バッファが
大きくて何とかなっているからではないかと思います。

というので SetupComm()で指定してる受信バッファサイズを大きくしてみると
解決するかも、と予想しました。

 > 返信を書き途中ですが、こちらの考えているフロー制御の部分は
 > こんな説明であっているでしょうか?
 > 
https://osdn.net/users/nmaya/pf/Tera_Term_test/wiki/serial#h1-Hardware.20flow.20control
↑見るの明日以降になるかも。すみません。

英語Wikipediaを元に図を作ったところでした。
良かったら使ってください。
1の古いフロー制御は今は使われていない方法ですね。
2が現在サポートしているフロー制御です。
リポーターの方に送信側のフロー制御を確かめてもらえたらな
と思っていました。

------------------------------

Now we are considering flow control of 2.

---------
ref
https://en.m.wikipedia.org/wiki/RS-232#RTS,_CTS,_and_RTR


1. Original define (half duplex,asymnetric)

DCE             DTE
RTS <---------- RTS (1)
CTS ----------> CTS (2)
TxD <---------- TxD (3)

   (1) DTE asserts RTS
   (2) DCE asserts CTS
   (3) DTE transmit


2. Mordan define (full duplex,symmetric)

DCE             DTE
CTS ----------> CTS (1)
TxD <---------- TxD (2)
RTS <---------- RTS (1')
RxD ----------> RxD (2')

   (1&2)   DTE transmit when DCE assert CTS
   (1'&2') DCE transmit when DTE assert RTS
--------------------

DTE is PC runing Tera Term.



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