7

背景情報：

私は現在、USBポートに接続するハードウェアデバイスを持っています。ハードウェアデバイスは、さまざまなネットワークに正確な定期的なメッセージを送信し、ネットワークも接続します。ハードウェアデバイスの中には、MicrochipdsPICがいくつかあります。動作には2つのモードがあります。

1つのシナリオは、単純な「ジョブ」をdsPICに送信し、それが.001msの精度で正確なメッセージを送信できる場合です。このアーキテクチャは、PCアプリケーション内で発生するイベントに基づいて変化する定期的なパケットを送信する必要がある、より複雑なメッセージングには理想的ではありません。したがって、PCアプリケーションが定期的なメッセージを送信し、dsPICがそれに応じて変換して送信するという2番目の操作モードがあります。ちなみに、これはすべて、当社のソフトウェアのエンドユーザーに対して透過的です。当社のハードウェアデバイスは、自動車分野で使用されるテストツールです。

現在、ハードウェアをPCソフトウェアに接続するために、FTDIおよびFTDIWindowsドライバーからのシリアルチップへのUSBを使用しています。

問題は、PCからメッセージを送信するモード2では、平均的なハードウェア範囲で約1ミリ秒を達成できることです。Windowsカーネルのプリエンプションの対象となります。私は次のようなことを改善するためにいくつかの「トリック」を試しました。

  1. 可能な場合は、リーダースレッドとライタースレッドが別々のCPUアフィニティで動作することを確認してください。
  2. リーダーのスレッド優先度を下げながら、ライターのスレッド優先度を上げます。
  3. 当社のソフトウェアを使用する際にスクリーンセーバーやその他のアプリケーションをオフにするようにユーザーに通知します。
  4. createthread呼び出しをCreateTimerQueueTimer呼び出しに置き換えます。

私たちのソフトウェアはすべてC/C++で書かれています。私は高度なWindowsプログラミングに非常に精通していて快適です。IO完了、重複I / O、ロックレススレッドキュー（実際には設計戦略）、ソケット、スレッド、セマフォなど...

しかし、私はWindowsドライバーの開発については何も知りません。KMDFとUDMFとWDMに関するいくつかの論文を読みました。

ベテランのWindowsカーネルモードドライバー開発者がここで応答することを期待しています...

次の回転。私たちのハードウェアの一部には、FTDIチップを交換して、dsPICのUSBインターフェイスを使用するか、場合によっては、オープンソースのLinux FTDIをWindowsに移植して、カスタムドライバー内でFTDIチップを引き続き使用するオプションがあります。PC側のカーネルモードドライバーに行くことで、プリエンプションやDMAを利用することなく、より正確な間隔で定期的なメッセージを送信できるカーネルドライバーを確立できると思います。

私たちのビジネスには、彼らのツールとまったく同じようなことをしていると思う競合他社がいます。私の知る限り、ユーザースペースアプリケーションは1msを超えるスレッドをスケジュールすることはできません。現在、スレッドでtimeGetTimeを使用しています。私は（CreateTimerQueueTimerを介して）タイマーキューを試しましたが、実際の改善はありませんでした。

WDMは、より正確なタイミングを実現するための正しいアプローチですか？

競合他社は、Windows駆動の信号からハードウェアへの非常に正確なタイミングをどのように達成しており、カーネルドライバー（.sys）をロードし、デバイスは私たちと同じようにUSB2.0上で実行されます。

WDMが進むべき道である場合、タイミングを設定するためにどのカーネル機能を研究する必要があるかについてアドバイスを得ることができますか？読んでくれてありがとう

4

3 に答える 3

5

カーネルモードでは、割り込みを処理せずに、100ナノ秒間隔の倍数でDPCをトリガーすることができます。スレッドスケジューラもDPCであるため、DPCをプリエンプトすることはできません（スレッドスケジューラによって中断されることもあります）。ただし、割り込みによってDPCがプリエンプトされる可能性があります。したがって、10の間隔値は、最高の精度でコールバックを行うためのトリックを実行する必要があります。

ただし、ページングメモリや、DPCレベルの特定のスレッドのメモリ空間など、多くの機能にアクセスすることはできません。これらの機能は任意のコンテキストで実行されるためです。より多くの機能にアクセスできるAPCを使用して、処理を独自のユーザーモードプロセスのコンテキストに延期すると便利な場合があります。

カーネルスレッドは、優先順位に関して特別な扱いを受けません。これらは、スケジューラーの観点からはユーザースレッドと同じです。カーネルスレッドが取得できる優先度の高いレベルがいくつかありますが、通常、カーネルスレッドはそれらのいずれも使用しません。あなたのボトルネックはスレッドの優先順位ではないと思います。優先順位の数がいくら大きくても、他の誰よりも1つ多いだけで、最優先の「神の糸」になることができます。優先度が最も高いからといって、継続的に注目されるわけではありません。OSはスレッドを一時停止して他のスレッドを実行するため、クォンタムの枯渇は発生しません。

Windowsプリエンプションの動作に関する別の注意：スレッドが非同期イベント（GUIクリック、タイマートリガー、I / O完了）によって通知されると、Balance Set Managerはスレッドの優先度を一時的に高め、完了コードがより少ないプリエンプションで処理を終了できるようにします。非同期タイマーハンドラーを使用すると、少なくともクォンタムのプリエンプションを防ぐのに十分なブーストが得られるはずです。なぜあなたのコードはそのウィンドウに入らないのだろうか。ただし、タイマーの精度に問題があるのはあなただけではないようです：http ://www.virtualdub.org/blog/pivot/entry.php?id=272

ドライバー開発の複雑さについてPaulに同意しますが、正当な理由がある限り、それはロケット科学ではなく、より多くの努力です。

于 2012-01-23T20:18:25.180 に答える
1

これは、Windowsカーネルの基本的な設計の側面の1つです。パッシブレベルで実行されるコード（=>すべてのユーザーモードコード）は、DPCと割り込みの影響を受け、時間がかかります。1usの精度が必要な場合は、おそらくそうではありません。 UMDFまたはユーザーモードドライバーのいずれかで取得します。

ただし、カーネルドライバーの作成は、簡単で安価な作業ではありません。作成することも、顧客のマシンで動作することを確認することも非常に困難です（多くのテストが必要です）。それを正しく行うには、かなりのエンジニアリングリソースが必要になります。

一時的なものとして、MMCSS for> = Vista（http://msdn.microsoft.com/en-us/library/windows/desktop/ms684247(v=vs.85).aspx）を調べます。あなたが満足できる十分な優先順位。

本当にうさぎの穴を下りたいのなら、KMDFを使うべきです。KMDFは、WDMに基づくフレームワークであり、ドライバー向けに体系化された多くのベストプラクティスを表しています。絶対に強制されない限り、KMDFは常にドライバーにとって最良の方法です。そして正直なところ、OSR（http://www.osr.com）と契約するか、Windowsドライバーの作成に経験のある人（何人か？）を雇いたいと思うでしょう。

于 2011-12-26T22:03:01.360 に答える
1

ドライバーとカーネルのパフォーマンスに焦点を合わせると、ツリーのフォレストが失われます。部屋の中の象は、フルスピードのUSB2バスフレームが1msの周期で発生するという事実です。高速USB2マイクロフレームは1/8msごとに発生します。

フルスピードUSB（ほとんどのFTDIチップのように）を介してデータを送信する場合、アプリケーションが期待できる最善の方法は、データが次のいずれかの時点でデバイスに到達することです。フレーム。USBバスがアンロードされている場合、転送はフレームの開始点の非常に近くで行われます。ランダムな偏差が小さい1msの粒度として観察されます。これはまさにあなたが見ているものであり、悪くはありません。たとえば、同じホストに接続されているすべてのUSBデバイスは同時にフレームを表示するため、マイクロ秒よりも優れた精度で複数のデバイスクロックを同期する簡単な方法です。アプリケーションでできることは、データだけでなく、近い将来に送信する必要があるメッセージを含むメッセージを送信することです。USBのもう1つの問題は、データ送信の要求がいつ処理されるかについての保証がないことです。結局のところ、あなたは他のデバイスとバスを共有しています。

PC側からのタイミングに依存せず、システムをリエンジニアリングする必要があると思います。PCで実行されるアプリケーションは、タイミング的には、それと対話する人間のパフォーマンスに制限されていると想定する必要があります。保証されたリアルタイムパフォーマンスを必要とするものはすべて、dsPICデバイス上にある必要があります。USBバスでさえ、リクエストがバス上でどれだけ早くスケジュールされるかについての保証がまったくないため、それをカットしません。

基本的に、Windowsでリアルタイムのパフォーマンスを保証したい場合は、ユーザーモードを使用しないでください。すべてカーネルモードで実行する必要があります。また、専用の通信チャネルを使用する必要があります（または、そのように動作させる必要があります）。方法、例えば、USBホストの真上でフィルタリングすることによって）。

于 2013-02-17T04:44:51.757 に答える