since 2007.8 by K-ichi


ループバックテスト
先日入手した、USB-シリアル変換ケーブル(HL-340)の動作について調べてみた。

導入時は、簡単なループバック回路によって動作を確認した。設定はほとんどデフォルトのまま、9600bpsにて。
コピペ時に独特の振る舞いはあるが、送信も受信もできていることは確認できた。

今回は、速度を上げたり設定を変えたりしつつ、波形も見てみることとする。
波形の確認は、RIGOLオシロによる。シングルトリガの結果を、Ultra Sigmaで取り込んだ。


とりあえずスピードを上げてみる。


シリアルポート設定ら
デバイスマネージャから当該COMポートの[プロパティ]を開く。[ポートの設定]タブの中に、ビットレートなどを設定する箇所がある……が、ここではない。
通信はTeraTermで行うが、COMポートの速度設定などはこちらで行う。[設定]-[シリアルポート]で、設定画面にいける。

速度の選択肢は画像のとおり。TeraTermには921600bpsなんて速度もある。ちなみにこれは、2DDフロッピーの4倍近く、Blu-rayの1/40に相当する。
文字列に起こしておくと、デバイスマネージャでは、128000、115200、57600、38400、19200、14400、9600、7200、4800、2400、1800、1200、600、300、150、134、110、75、の18種が選択できる。
TeraTermは、921600、460800、230400、115200、57600、38400、19200、14400、9600、4800、2400、1200、600、300、110、の15種類。
その他の設定は、データ幅は8bit、パリティは無し、ストップビットは1bit、フロー制御は無し、とした。送信遅延は、ともに0msとする。

ループバックを構成して各種速度で試すと、TeraTermで設定できるすべての速度で問題なく動作した。


まとまった量の文字列をコピペしてみる。


16kBをコピペ
ループバックテストでは、キー入力文字がすぐに返ってくる。
ローカルエコーを有効にした状態で「ABC」と打てば、「AABBCC」という表示になる。ところが「ABC」とコピペすると「ABCABC」になってしまう。

RS-232Cなどと呼ばれるシリアル接続は、全二重通信のはず。上記現象は、間断なくデータを送り続けると半二重になることを意味する。
生のシリアルポートが無いので確認のしようが無いが、半二重であるUSBを経由しているための制限・仕様ではないか、と想像する。
この変換を担保するには、間にバッファが必要になるので、どの程度まで耐えられるか試してみた。

細かいところからいくつか試したが、最終的には、1000文字+CR+LFを16行のコピペ、で行った。
結果、データ落ち無し。ROMカートリッジぐらいの16KBやそこらでは、限界を見ることはできなかった。
すべてエコー表示された後、すべてループバックで返る。半二重にはなるけど、最終的に漏れなく応答はされる。


送信途中でイリーガルなことをしてみる。


途中からループバック開始
9600bpsだと1000文字送信に約1秒。そこそこ時間がかかる。
タイミングを計って、送信終了とともにループバック開始する、送信終了とともにループバックを解除する、などしてみた。画像は前者。

ローカルエコーで16kB出力完了した直後にループバック開始すると、データのなかほど過ぎあたりから戻ってくる。
この例では、本来は「00000……」のところが文字化けして「&bbbb……」になっている。

逆に、ループバックした状態でコピペし、ローカルエコーで16kB出力完了した直後にループバック解除すると、8kB強あたりまでは何事も無くデータが戻ってくる。

どうやら、だいぶ遅延があるらしい。9600bpsにおいて、16kB出たはずの時点で、実際のコネクタにはまだ半分強程度しか出ていない。


送信にウェイトをかけてみる。


行間遅延をかけてみる
上記実験の通り、HL-340は間断なくデータを送ると半二重になる。少しスキを見せたらどうか、ということで、送信遅延を入れてみた。

ポート設定のところに、それっぽい入力窓があるがそれではない。
[設定]-[その他設定]-[コピーと貼り付け]タブ内の、[貼り付けの行間遅延]。ここを、1msとか10msとか、適当な値に設定する。

9600bpsと921600bpsで確認した。画像は、921600bpsでの結果例。
ローカルエコーとループバックとが、適当に入り組んでいる感じ。

9600bpsで試すと、必ず次のようになる。
先頭1000文字2行をエコー、先頭23文字ループバック、次の1000文字1行エコー、次の23文字ループバック、1000文字、23文字……送信分がなくなったら残り全てをループバック。
遅延設定は1msでも100msでも、結果は変わらない。足すと1023というところが何か臭ったが、意味は解らず。

921600psで試すと、結果は不定。
9600bpsと同じこともあれば、1000文字1行ごとにエコーとループバックを繰り返してみたり、ここの画像のようになったり。ただし遅延を20msあたりまで増やすと、必ず1000文字1行ごとにループバックされるようになる。

921600bpsでの20msは1676バイト相当(ストップビット=2)。このぐらいの十分な余裕があれば、きれいに返ってくる。15ms(1257バイト相当)では不定だったので、それなりのオーバーヘッドはありそう。
一方で、9600bpsでは1ms(0.96バイト相当)設定でも23文字返る。余裕のない場合の挙動は、やはりよくわからない。


大容量ファイルを送信してみる。


ファイルコンペアの結果
16kB程度のコピペのループバックテストでは、破綻は見られなかった。もっと大きなデータではどうか。
TeraTermにはファイルの送信機能があるので、これを使って1MBのテキストファイルを送信してみた。ちょうど1M個の「U」と、最後にCR、LFを付加した、1048578バイトのファイルを使う。
「U」のアスキーコードは55h。

[設定]-[端末]で、[ローカルエコー]のチェックを外し、[編集]-[バッファのクリア]で、掃除をしておく。
[ファイル]-[ログ]で、ログファイルを指定(teraterm.log)する。[バイナリ]にはチェック、[追記]のチェックは外しておく。
[ファイル]-[送信]で、[バイナリ]にチェックを入れた上でテスト用ファイル(test.txt)を送信する。
送信が終わったらTeraTermを終了し、ログファイルを確認する。

結果、先頭150KB余までは正常。その後は10CD8h(68824バイト)ごとに、定期的にCR+LFに化けている。ファイルサイズは変わらないので、挿入ではなく化け。
ついに破綻した。一気に大量データをやり取りする場合は、注意したほうがいいかもしれない。


実際の波形を見てみる。


9600bps

921600bps
端末の結果だけでは見えないこともあるので、生の波形も眺めてみる。画像は、デフォルトの9600bps、および最高速921600bpsでの波形。
下部には、シリアル信号の読み方を追記してある。Sがスタートビット、sがストップビット、iはアイドル(無信号)。
信号が来る前のずっと0Vのところは、書いてないがこれもiになる。データはLSBから送られる。

シリアルポートは本来、±3Vが不感帯で、±25Vに収まる規格。プラス電圧側が'0'(スペースと呼ぶ)で、マイナス側が'1'(マーク)、となる。
実際のポートでは、TTLに近いスレッショルド電圧を持っている。±12V程度出ていたDELL機でも、保護抵抗を咬ますだけでPICを接続できた。
HL-340では信号レベルまでTTLレベルになっている。CH340モジュールなど、TTLレベルを謳っているものと同等と思われる。

通信設定はともに、データ8bit、ストップビット1bit、パリティ無し、とした。
ストップビットは、1/1.5/2bitの設定ができ、基本的には1bit設定のときに1bit幅、1.5/2bit設定では2bit幅で出力される。例外的に、921600bpsのときは常に2bit出力される。
もっとも、ストップビットなのかアイドルなのかは、波形を見ても判別できない。画像にはアイドルとして記入している。

出力データは、"ABC"+CR+LF+CR+LF、をコピペした。
なぜかCRが連続している。TeraTermの[設定]-[端末]-[改行コード]カコミ-[送信]設定はCRにしてあり、これはコード変換無しの意、とのこと。コピペではLFは出力されないのかもしれない。


ストップビットの受信余裕を調べる。


シリアルポートにPICを接続

短いストップビット長のテスト
HL-340の921600bpsでは、ストップビット1bitでは出力できないことが判った。
逆に、この速度での受信は可能なのか、ストップビット幅がブレても構わないのか、を確認してみた。

PIC12F675で、ソフトウェアでシリアル信号を生成し、受信させてみる。PICは20MHzセラロック駆動しているので、1命令(1ステート)0.2μsで処理できる。
921600bpsの1bitは1.085069444……μs。5ステートで1μsのPICでは微妙に誤差が出る。1bitごとにステート数を調整し、各ビットでも10bit終了時でも、誤差1/2ステート以下に収めた。実際には、bit4時の0.09μs遅れが最大。これで数10文字連続で送信する。

試すと、ストップビット1.0μs(≒1bit)でも問題なかった。それ以上、0.2μs刻みで2bit相当まで増やしても正常。さらに長い、数μsスケール、数msスケールでも問題は起きなかった。単にアイドル状態が長いだけなので、当然といえば当然ではある。
逆に短くしたときの結果がこの画像。0.8μsでは問題なかったが、0.6μsまで短くすると、実用にならないレベルに不安定化した。

921600bps、ストップビット1bit、最高速設定での受信マージンは十分あると思われる。


さらにPICから送信してみる。


PICからの送信波形

PICからの送信波形(拡大)

PICからの送信波形(拡大)のつづき
PICから、"HL340"+CR+LF+"UUUU……"+CR+LF、と出力、TeraTermで受信する。

ストップビット幅は、以下の通り微妙に変えてあり、画像からも読み取れる。通信速度は、もちろん921600bps。
'H'=1.0μs、'L'=1.4μs、'3'=1.8μs、'4'=2.2μs、'0'=2.6μs、CR=1.0μs、LF=2.2μs、'U'=1.2μs(ときどき1.6μsまたは2.0μs)

こんなまちまち幅のストップビットでも、すべて正常に読み込める。


"UUUU……"は、'U'がちょうど1M個並んでいる。ここはログを取って確認してみる。

上で行ったループバックテストでは、16k文字程度なら問題ないが、大容量ファイルでは150K文字越え付近から一部「改行」に化けていた。
しかしこのテストでは、文字化けは発生しなかった。複数回試したが、きれいに1M個の'U'が揃い、一文字の欠けも置き換えも発生していない。

最高速で大量のデータ(とりあえずは1MBほど)であっても、受信は問題ないらしい。
となると、鬼門は送信側か……?


TeraTermからの送信データを確認する。


PICから返った結果(1MB版)

PICから返った結果(32KB版)

「ファイル送信(バイナリ)」時の波形

「コピペ」時の波形
TeraTermから、1M個の'U'とCR+LFが入ったファイルをバイナリ送信。PICはそれを受信し、結果を返信する。引き続き921600bpsで行う。

1bitあたりに使える命令数は5強。PIC側は結構カツカツ。受信データのうち、'U'だけをカウントすることとした。
読み込みは、BTFSC+GOTOを256個並べてポーリング、この150μs余の間に信号が来なかったら返信、とした。ただし、カウント値がゼロのときは返さない。返信、ループ処理中に信号先頭がぶつかると読み落とすが、そこは「考慮」して実験する。
返信データは、カウント値と最後に受信した文字コード。理想的な返信結果は、「10 00 00:0A」になる。

結果は画像の通り。
どうやら、先頭から8KBで切り分け、バースト転送されているらしい。バーストとバーストの間は、2ms弱~8ms強が多いようだが、100μsとか400μsとかいう場合もある。100μsではプログラムの構造上、連続データとみなされる。8KB×128回=1MBなので、データの欠落などはない。
32KBほどのファイル(32K個の'U'と改行)での実験では、1度だけ「00 80 00:0A」と返ったことがあった。

別の送信方法でも試してみる。
ファイル送信ではなく、コピペで試すと、こちらは16KBでブロック分割されていた。LFは送信されなかった。64回に分けられるので、こちらも計算は合う。
ウィンドウへファイルをD&Dすると、ファイル送信のダイアログが表示される。この送信方法は、ファイル送信で[バイナリ]にチェックを入れなかった場合と同様で、100バイト(64h)ごとに分割される。こちらもLFは送信されない。

どうやらLFを含めて送信されるのは、[ファイル]-[ファイル送信]で[バイナリ]にチェックしたときのみ、のよう。

オシロ波形を見ると、送信と短い休憩が繰り返されているのがわかる。
休憩時間は、確認した範囲では100μs強から8ms超えまでまちまち。規則性も見えない。そのときどきの、PCやUSBあたりの忙しさ具合によるのかもしれない。

癖はあるものの、送信データにも致命的な問題は無さそう。


結局、ループバックによる「定期的な改行化け」の原因はつかめず。平行して大量の送受信があると、ダメなことがあるのかもしれない。
とりあえず、大量の送信、受信には問題ない。921600bpsとけっこうな速度での通信もできる。なにより、ワンコインで2本も買える。HL-340は、お買い得と言ってよい。

0 件のコメント:

コメントを投稿

.

関連記事


この記事へのリンク by 関連記事、被リンク記事をリストアップする」記事

ブログ アーカイブ