久方ぶりに投稿させていただきます。ぱんぷきんと申します。
プログラム、というより半分デバイス関係のことですので、もしこちらの掲示板
の趣旨に合わないということでしたら、お詫び申し上げます。
現在、PCに、外部装置から送られるNTSC信号とRS-232C情報の２つを同期しながら
処理を行っていくシステムの調整を行っています。
このRS-232C信号は装置から一定間隔で送信されているものとします。
(NTSCの垂直同期と必ずしも同時ではありません）
その際、受信時にRS-232Cの入力が±15msecくらい間隔のばらつきがあり、
なかなかNTSC信号との同期を取らせるのが難しいのが現状です。
（RS-232Cでミリ秒オーダーの調整を行うこと自体、問題なのかもしれませんが。。）
問題解決のため、現在いろいろな情報を集めております。
お聞きしたいこととして、PCにRS-232Cの信号が到着してから、ReadFileなどでアクセス
できるメモリ領域にデータが書き込まれるまでの時間、というものは
何かしら決まっているものでしょうか？
それとも、マシンの状態などでこのあたりは結構ばらつきがあり、時間についての保証
というものはあまりないのでしょうか？
どなたかご存知でしたら、ご教授いただけましたら幸いです。
よろしくお願い申し上げます。
開発環境
Visual Studio .NET 2005 Professional
マシン：Pentium 4 3GHz
RS-232C : 19200bps、パリティなし、ストップビット=1 , データビット長=8、フローコ
ントロール=なし
受信方法：スレッド内でのReadFile呼び出し（ポーリング）
Windowsでms単位のリアルタイム性を求めちゃいかんのじゃないかなぁ...
> 現在、PCに、外部装置から送られるNTSC信号とRS-232C情報の２つを同期しながら
> 処理を行っていくシステムの調整を行っています。
同期方法は？
>その際、受信時にRS-232Cの入力が±15msecくらい間隔のばらつきがあり、
>なかなかNTSC信号との同期を取らせるのが難しいのが現状です。
バイト数にもよりますが、あってもおかしくないですね。
>（RS-232Cでミリ秒オーダーの調整を行うこと自体、問題なのかもしれませんが。。）
そのとおりだと思います。
> お聞きしたいこととして、PCにRS-232Cの信号が到着してから、ReadFile
> などでアクセ>スできるメモリ領域にデータが書き込まれるまでの時間、
> というものは何かしら決まっているものでしょうか？
> それとも、マシンの状態などでこのあたりは結構ばらつきがあり、
> 時間についての保証というものはあまりないのでしょうか？
WINDOWS環境ですから時間についての保証はありません。
マウスを激しく動かしただけでも変わる場合があります。
> Visual Studio .NET 2005 Professionalは
> マシン：Pentium 4 3GHz
> RS-232C : 19200bps、パリティなし、ストップビット=1 , データビット長=8、
> フローコントロール=なし
> 受信方法：スレッド内でのReadFile呼び出し（ポーリング）
OSは?
ポーリングでなく割込みで考えないとだめかもしれませんね。
19200ボーだと、30バイトで15msかかりますね。
まあそもそも USB-COM 変換器とか使っていると COM 側の速度とは無関係に
USB 側の出来次第で通信が遅れるとかもありうるわけだし
内蔵 COM であっても 19200bps で 1byte 単独データを受信する場合に
10/19200sec = 0.52msec でデータが得られると思ったら大間違いだしな
# 16550A+FIFO 構成だと 2msec 経過しないとハードウェアから信号がこない
ハードウェアから信号が来て
デバイスドライバが受け取って、までに数msecが経過するわけだし
アプリケーションタスクが切り替わって ReadFile が結果を得る
までということなら 15msec 程度のずれならごく普通に発生しうるだろうな
これを「アプリケーションソフトウェア」のレベルで吸収することはきわめて困難
原理的に無理
質問者のぱんぷきんです。
皆様、いろいろな情報をいただき、ありがとうございます。
>> 現在、PCに、外部装置から送られるNTSC信号とRS-232C情報の２つを同期しながら
>> 処理を行っていくシステムの調整を行っています。
> 同期方法は？
ご質問内容とは意味が異なるかもしれませんが。。内容としては以下のようになりま
す。
1.装置内の画像が一定間隔で更新されます（ただし1,2ミリ秒程度の誤差があります）
2.更新後のNTSC垂直同期信号送出時に合わせ、RS-232C信号が更新信号として装置から送
信されます（画像内容に変化がない場合、232C信号は送信されず、NTSCのみが送信され
ることになります）。
3.受信PCでは、RS-232C信号受信後、信号をトリガと考え、NTSC->画像取得ボードから画
像を取得することで、更新信号に合わせた画像をボードから１枚取得する
装置側からは232CとNTSC信号は数μ秒単位でのずれしかないということが波形モニターで
分かっていますので、同期がとれていないのはPC側の問題ということになります。
> OSは?
失礼しました。
Windows XP Service Pack 2です。
> ポーリングでなく割込みで考えないとだめかもしれませんね。
割り込み形式はまだ試していませんので、今後試してみます。
> まあそもそも USB-COM 変換器とか使っていると COM 側の速度とは無関係に
> USB 側の出来次第で通信が遅れるとかもありうるわけだし
さすがに怖いので、USB<->COM変換ケーブルは使っておりません。
Windowsでミリ秒オーダーのコントロールは難しいということが
確認できて助かりました。
もっと別の方法で同期ずれを回避する方法も考えてみます。
232Cで同期を行うのなら、
１．データ取得後、処理後に、PCから相手にACKを送る。
２．データがうまく取得できなかった場合は、NAKを送信する。
３．相手はACK/NAK信号を確認して232C信号を送信する。
４．ACK信号の場合は、次のデータを送信する。
５．NAK信号の場合は、前のデータを再送信する。
ですね。
これは、基本的な通信方法です。
これは、ほんの１例です。
参考にどうぞ
投稿者のぱんぷきんです。
皆様、ご意見をいただきまして、ありがとうございました。
Windowsでこういった制御が難しいということが今回の件で勉強になりました。
その後、マシンをグレードアップしたり、送信側のプログラムを見直すことで、なんと
か今回の装置を目的に沿って動作させることができるようになりました。
(主に、送信側の時間のばらつきと、マシンスペックの低さによる処理落ちが原因だった
ようです）
画像がどんどん送られてくるタイプの装置ですのでハンドシェイク的なことは難しいか
もしれませんが、今後は同期の方法をよく考えながら装置側との仕様を詰めていくこと
にいたします。
ひとまず、この件はクローズさせていただきたく思います。
ありがとうございました。
返信する
最新の投稿: お久しぶりです、いかがお過ごしでしょうか。 最新のメンバー: gantez 最近の投稿 未読の投稿
