USB-RS485シリアルインターフェースを介したセンサーポーリングが16msでスタックする

私は、接続、設定しているカミソリIMUと、センサーボードをRS485ブレークアウトに、ボードUSB-RS485シリアルインタフェース私のラップトップにUSBケーブルを経由して。ラップトップ（Max / MSP）でソフトウェアを実行して、センサーにポーリングメッセージを送信し、応答データを待機します。応答を受信すると、新しいポーリングメッセージが自動的にトリガーされます。それは定数ループです：

1. ポーリングメッセージを送信する
2. 返事を待つ
3. 応答時に1に進みます。

これらのセンサーのうち21個を同じRS485バスに接続する必要があるため、このポーリングをできるだけ高速にしたいと考えています。RazorのファームウェアはArduino IDEでプログラムされており、コードによれば、ポーリングメッセージと応答の書き込みの間にわずか2msの遅延があるはずです。ファームウェアは、センサーの割り当てと計算に20ミリ秒ごとに12ミリ秒も費やします。この計算により、ポーリングへの応答が遅れることがあります。私はそれを認識しており、すべての結果はそれに応じています。

私の現在の問題は、センサーのポーリングが平均15ミリ秒の更新レートでスタックしていることです。小さなusb-oscillosopeでデータを見て、図（> PDF）を作成しました。

私のオシロスコープは、USB-RS485インターフェースに直接座って、ポーリングが消え、応答メッセージが届くのを確認します。これら2つの間の遅延は、2〜13 msです。この違いは、かみそりがセンサーの計算に忙しいことがあるという事実で説明できます。奇妙な事実は、応答が異なる遅延を伴って到着しても、ポーリングは常に約15msの同じ間隔で送信されるように見えることです。

同じセットアップを実装しました

• Cでファームウェアをコーディングし、avr-dudeでRazorをプログラミングする
• Pythonコードでソフトウェアポーリングを行う
• Mac OSXおよびPC Windows 7

すべての可能な組み合わせは、同じ15msの間隔になります。したがって、問題はArduinoコードにも、Max / MSPにもありません。USB-RS485シリアルインターフェースや必要なFTDIドライバーが原因で問題が発生しているのではないかと疑っています。

この問題はだれにもおなじみのように聞こえますか？

これは、FTDIドライバーの16ミリ秒のレイテンシータイマーと、ポーリングの応答が64バイトのバッファーをいっぱいにしてバッファーの空化を自動的にトリガーするほど長くなかったことが原因です。興味がある場合はAN232B-04_DataLatencyFlow.pdfを読むか、または単にデバイスマネージャーに移動して、USBシリアルポートプロパティの設定を変更してください。

多くの詳細（本当に知りたくない）がわからなければ、USBからRS-485へのアダプターのせいにしてしまいます。これらのアダプターの1つを搭載したLinuxを実行するIntel Q7プロセッサーでも同様の問題がありました。

カスタムハードウェアの準備ができるまで、アダプターを一時的に使用していました。当社のカスタムハードウェアは、PCIeリンクとFPGAを使用して、同じRS-485インターフェイス（およびその他）を実行します。ソフトウェアは、アダプターとカスタムハードウェアで同じままでした。カスタムハードウェアに切り替えると、問題はなくなりました。