【ググっても無駄！】WindowsのRS-232Cシリアル通信で受信データに欠落が発生する

ちょっと、ちょっと、

アンタが持ってる悩みは、コレでっか～～～～！？

もしそうであれば、この記事がお役に立つかも知れまへんでぇ～！

と言うか、、、、

最初に言い切ってしまいましょう！！！

この記事を読んで解決せぇへん場合、

これ以上ググっても無駄でっせぇ～！！！

なんでそんな事が言い切れるのかって？

ワイも超ググりまくったからじゃーーーーっっっっっっっっっ！

ヤフりまくりも、
ビングりまくりも、
ライコまくりも、

やったけど・・・・

でも、答えは見つからんかった・・・

なんとか一応解決したけど、超大変やった！！

ワイと同じような悲しい思いをする人を一人でも減らしたいから、この記事を書いたんやでぇ～～～～！！

もしかしたら、この記事で解決できるかも知れない内容

こんにちは。kei（@boot_kt）です。

冒頭にも書いたけど、この記事が役に立つとしたら、以下の悩みを持ってる人になります。

先に対応案一覧を書いとくでぇ～！

シリアル通信の受信でデータの欠損と言うか、取りこぼしが発生する場合、対応方法は以下しかないねん。（おそらく・・・）
ここに書いてある事を全て実行してもデータ漏れがなくならへん場合、、、、

 
もうできることはありまへぇ～ん
あきらめておくんなはれぇ～！！！！
 

もしくは、欠損発生頻度が許容できる程度に低いんやったら、それは仕方がないとして諦めておくんなはれぇ～。

対応案をやる前に、調べておいて欲しいこと

以下の二点を調べておいてやぁ～

1. シリアルのデータは確実にマシンのCOMポートまで届いていること
   
   Analyze232C や LINE EYE 等のアナライザで実際にCOMポートまでデータが届いていることを確認しましょう。

   アナライザで見てもデータが欠落しているなら、以下を確認してや。

   • シリアルケーブルに断線は無いか？（テスターを使えば導通確認できます）
   • シリアルケーブルが長すぎないか？
   • フロー制御を使っている場合、途中で分配器等を使っていて、それらがフロー制御用の制御線に対応しているのか？
   • シリアルケーブルの通り道に、電波や電器で干渉するものがないか？
2. 自分が作った受信プログラムに不具合はないこと
   
   シリアル通信できるソフトは沢山あるから、それらを使っても受信データの欠落が発生することを確認する。

   • COMポートまでデータは正常に届いている
   • 他のソフトで正常に受信できる
     Vectorにもあるでしょうし、SocketDebuggerシリーズとかでもいいと思います。

   他のソフトでは正常に受信できる！！

   という状態であれば、アンタが作った受信プログラムに不具合がありまっせ！！！
   

対応案の説明

１．シリアル通信の速度を落とす！

これが一番効果があるはずやねん！

可能であれば、まずはこれをやってくだっさい！

とは言え・・・・・・・

実際の業務においては、先に動いているサーバーやマシンがあって、それと通信する事があるよね。
そのサーバーが既に 115,200 bps とかの高速で動いていることがあるよね。

さすがに現在動いているサーバーの設定を変更することはでけへんやろし、他のマシンやサーバーにも影響を与えるよね。

なので、現実問題としては通信速度を変更することなんて出来へんという状況が多いよね。
変更することが出来へんのであれば、この手段は ボツ ですわ。

ですが、ニッチもサッチもいかへんのであれば、既存アプリの再テストを含めてでも通信速度を落とすことを話し合われる方が良いかも知れまへんで。
新規のプログラムやマシンだけでなんとかしようとしてもなかなか大変ですし。

通信速度を落とすのが最終的な工数は安く済む場合もありまっせ。

２．フロー制御を使う

可能であればやけど、フロー制御を使いましょう。

フロー制御の詳しい説明はせぇへんけど、簡単に言うと、、、
（と言うか、ワイもよう知らんねんｗｗｗｗ）

っていう感じのもんですわ。

ただ、使わへんことが多いようですね。

また、制御線をショートさせて、常に『送信してきてオッケー！』となるシリアルケーブルがあるらしいので注意しましょう。
そういうケーブルを使うとフロー制御が役に立ちまへん。

３．FIFOバッファを変更する

受信バッファを小さくしたり大きくしたりして確認してみてね。

多分やけど、受信バッファを小さくすれば、割り込みが増えるんじゃないかな？

シリアル通信のチップ内のバッファが枯渇する前に、頻繁にメインメモリへ受信データを移動しよっちゅう考えやと思いますわ。
こまめに割り込み発生（メインメモリに移動）させてバッファを空けてオーバーしないようにしているんでしょうね。

でも、割り込みが頻繁に発生するのは、それはそれで処理に時間取られて別の影響が出そうやけど。

４．レジストリを触って割り込み優先度を上げる

ワイがやって効果出たのはコレやねん！！！

シリアルデータ受信時の動き

シリアル通信の事はようワカランけど、おそらく上記のような動きをしてるんとちゃうかな、って思っとります。
 

14バイト毎にメインメモリへ移動する事によって、チップ内のFIFOバッファが満杯になるのを防ごうとしてるんやろな、きっと。
でも、割り込みが認められる時間が長いと、チップ内のFIFOバッファにはデータが溜まる一方なのでそのうち満杯になってしまいますわな。

オーバーランエラー発生のメカニズム

で・・・・満杯を迎えた時に・・・・

チャラリーーーーーン！
鼻から牛乳！！！

めでたくオーバーランエラー発生ですわ（笑）

オーバーランエラー発生後に割り込みが認められれば14バイトをメインメモリに移動して、チップ内のバッファに空きが出来て、また正常に受信できるけど、満杯の間に来たデータは消滅ですわ。

オーバーランエラーが発生するポイント

んで、何が一番の問題かと言うと・・・・

割り込みが認められるのを待つ
　　　　＆
認められるのが遅い

ってとこじゃないかなと思うねん。
大事な事なので

Windowsが何かの作業で忙しい時に、シリアル通信のチップが割り込みをかけてもすぐに処理できず待たされるのが問題。

アホ、ボケ、ワレッ！

ワシを待たせるっちゅうのはどゆことやねんっ！！！
ワシやのうて、他のヤツを待たせんかいっ！！

ちゃっちゃっとワシの割り込みを処理したらんかいっ！　しかしっ！

ワシの優先度を上げんかーーーーーーいっ！！！！！

しかしっ！

ってなりますよね。

で、、、、、優先度を上げましょう って話になりますわな。

優先度を上げる方法

シリアル通信のチップの割り込みの優先度を上げるには、レジストリを変更しまっせぇ～
 

手順１：COMポートの割り込み番号を確認しましょう

1. コントロールパネル
2. 管理ツール
3. コンピューターの管理
4. デバイスマネージャー
5. 表示(V) － リソース(種類別)(Y)
   
6. 目的とするCOMポートのIRQ番号を覚えておく
   
   

手順２：レジストリを変更しましょう

1. HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ PriorityControl
2. 右側の画面で、右クリック → 新規 → DWORD(32ビット)値
   
3. 値の名前： IRQ4Priority とする。
   4 の部分は手順１で見たIRQ番号です。
   
4. 値のデータ： 1
   1～38まで設定するらしいですが、通常は1か2を入れるみたいです。
   3以上入れても良いのかどうかは知りません。
   1以上の値を入れておけば、割り込みの優先度が上がります。

   

優先度低 1 ← → 38 優先度高

５．フロー制御に使う制御線の使えない分配器を使わない

一つの送信データを複数マシンで受信したい場合、シリアル信号を分配する分配器を使っている場合があるでしょう。
フロー制御を使うにはシリアルケーブルの制御用のピンという線を使うねん。
でも、分配器が制御線に対応していない事があって、フロー制御が効かない事がありまんねん。

ってことで、分配器を止めるか、フロー制御無しでも正常受信できるようにする必要がありまっせぇ！

>> シリアル信号分配器（AT-NDB310）

６．シリアルデータを受信するEXEのセッションがConsoleじゃない！

コマンドプロンプトを起動して、以下のコマンドを打ってみてぇ～や。

tasklist

シリアルデータを受信しているEXEのセッションは何になってまっか？
Console であればええけど、RDP-Tcp#0 とかになってまへんか？

WindowsのVerにもよるけど、Console も RDP-Tcp#0 も同じはずやねんけど、経験則としては動きが微妙に違うねん！！！

いや、EXEの動きは同じやけど、深い部分でEXE権限が違う気がするねん。

なので、理屈の説明はようせんけど、シリアルデータを受信するEXEはConsoleセッションの方が良さそうやねん。

リモートデスクトップでログインしてEXEを起動すると、そのEXEは RDP-Tcp#0 とか RDP-Tcp#1 とかになるねん。
マシンの前で直接ログインすれば Console セッションになりまっせ。
リモートデスクトップでログインすると、どうやっても Console セッションにはなりまへん。
tscon コマンド使っても無駄でっせ。

７．SetupComm関数を使ってみろ！

これも効果があってん！

理由はワカランけど・・・

SetupComm関数は送信バッファと受信バッファの確保なんやけど・・・・・・

SetupComm関数を使わんでも送受信バッファは確保されてて、それも無限に使えるはず。
なので、わざわざSetupComm関数を使う必要が無いと思うねんけどなぁ・・・

でも・・・・

SetupComm( hFile, 1024 * 1024, 1024 * 1024 );

と書いたらうまく動くようになってん。

なんでやねーーーーーんっ！！！！！

SetupComm関数でバッファを明示的に確保してる方が、何かと処理が速いんやろか？
ごめんなさい、理由は分かりません。

シリアル通信の仕組み

ワイはシリアル通信について詳しくないけど、CE_OVERRUNのメカニズムはこういう感じなのかなぁ？というイメージを持ってるねん。
正しいかどうかワカランけど、辻褄合ってるので、おそらく正しいんじゃないかな・・・

★ の部分で待たされるとまずいわけですよ、きっと。
割り込みが入ってすぐに許可されるわけでもないし。

参考品

Wi-FiやBluetoothの変換アダプタがあるだなんて、、、、知らなかった。

参考動画