デバイスドライバーが必要になるのはいつですか、いつポートに直接読み書きしても問題ありませんか？

デバイスドライバーが必要な場合や、OSが提供するシリアル/パラレル/ USBなどを介してポートコントローラーと直接通信するだけで問題ない場合は、理解に苦労しています。運転者。

たとえば、例1：OpenBCIを見てみましょう。これは、EEG + EKG（ "brainwave"）の読み取り値を読み取ることができるオープンソースのハードウェアBCIです。OpenBCIヘッドセットは、マシンに接続されたUSBドライブにRF信号を送信し、独自のソフトウェアを記述して、そのポートに着信するデータを読み取ることができます。したがって、自分の脳波を読み取って、アプリ層で脳波データを解釈することができます。かなりクール。「ストリーミング」脳波データを読み取るには、シリアルポートから読み取るだけでなく（OSが提供するシリアルドライバーを使用）、OpenBCI仕様に従ってデータを解釈する必要があります。したがって、スタックは次のようになります。

しかし、ここには、OpenBCIヘッドセットに固有の「デバイスドライバー」はありません。データのバイトを読み取るために必要なシリアルドライバーだけで、アプリ内からこれらのバイトの意味を解釈する必要があります。したがって、たとえば、Javaアプリで脳波データを解釈したい場合は、JSerialCommを使用してローカルCOMポート（またはローカルシステム上のUSBが何であれ）からデータを読み取ることができます。その後、上記の仕様に従ってデータを調査するのは私のアプリ次第です。

さて、例2：このような Logitech USBウェブカメラ。ここでは、Webカメラのデバイスドライバーをマシンにインストールして使用できるようにする必要があります。なぜだろう。このWebカメラのピン配置が愚かで単純だったとしましょう（ちょっと " 信じます！ "ボタンを押します）。

PIN #       Meaning
===================
1           Power
2           Ground
3           Send data (if 1 then the camera will start "streaming" its video data over data pins)
4           Data pin 1
5           Data pin 2

これはOpenBCIと同様にUSBデバイスです。では、なぜUSB /シリアルポートに直接読み書きする（これもおそらくJSerialCommなどを使用する）だけのアプリ（どの言語でも）を作成できないのでしょうか。私はアプリがウェブカメラの映像データの取得を開始したい場合は、私はシリアルポートにバイトを送信する（再び JSerialCommなどを経由して）回しピン＃3高/後ピン4と5からのビデオデータを読み始める上、およびこと。

OpenBCIがデバイスドライバーを持たない、または必要としないのに対し、Webカメラ（またはプリンター、マウス、キーボードなどの他の標準USBデバイス）が備えている理由が理解できないと思います。前もって感謝します！

デバイスドライバーを作成する必要がある、または必要がある理由はいくつかあります。

1. あなたは、一般的なカテゴリに適合するデバイスを作成しています。プリンター、スキャナー、Webカメラ、ストレージコントローラーなど。一般的なアプリケーションがアプリケーションを変更せずにデバイスと通信できるように、デバイスドライバーを作成したいとします。

2. 同時に実行されている複数のアプリケーションでデバイスを使用できるようにしたい。デバイスドライバーは、アプリケーション間でのデバイスの使用を調停する必要があります。これは通常、「バイトのストリーム」よりもデバイスの理解度が高いことを意味します。

3. ハードウェアまたはオペレーティングシステム、あるいはその両方の設計により、強制される場合があります。Windowsが動作するには、USBデバイスにバインドされたある種のドライバーが必要です。ハードウェアがHIDデバイスであると主張するように設定されている場合にのみ、hidドライバーを悪用することができます。既存のUSB toシリアルデバイスドライバーを使用できるのは、デバイスが存在し、シリアルポートのように見えるインターフェイスの場合のみです。デバイスがダイレクトDMAを備えたメモリマップバス上にある場合、DMAトランザクションを正しく設定するには、ドライバーがカーネル内にある必要があります。

同様に、デバイスドライバー、特にカーネルモードのデバイスドライバーの作成を避けたい理由があります。

1. カーネルモードのコードを書くのは注意が必要です/専門的であり、それを台無しにすると、プログラムだけでなくシステム全体がダウンします。OSがユーザーモードでドライバーを作成する機能を提供していても、慣れていない言語と環境でプログラミングすることを意味する場合があります。

2. 展開ははるかに困難です。Windows側では、MSは最近、ドライバー署名要件を段階的に引き上げています。Linux側では、ユーザーランドインターフェイスはカーネル側のインターフェイスよりもはるかに安定しており、新しいカーネルバージョンごとにカーネルモジュールをほとんど再構築する必要があります。

3. コードがアプリケーションとドライバーに分割されている場合、アプリケーション/ドライバーのバージョンが混在している状況を心配する必要があります。

次に、特定のデバイスにとってより説得力のある理由のバランスをとる行為に行き着きます。

デバイスドライバーは抽象化レイヤーです。 これにより、低レベルのオペレーティングシステムの仕組みやデバイス固有の特異性を知らなくても、デバイスと通信できます。また、オペレーティングシステムへのよく知られた高レベルのインターフェイスも提供します。これは、類似のデバイスでもまったく同じインターフェイスです。

デバイスドライバーがなければ、基本的に自分で作成する必要があり、そのデバイスドライバーはデバイスモデルごとに完全に異なります。代わりに、製造元は通常、その特定のデバイスのハードウェア固有のインターフェイスから、オペレーティングシステムの既知の高レベルのインターフェイスに変換するデバイスドライバーを提供します。

この配置には、いくつかの利点があります。

1. これらのデバイス用に作成されたソフトウェアは、同じ共通の高レベルインターフェイスに対して作成された場合、すべてデバイスクラスのデバイス（Webカメラなど）で動作します。

2. タイミング、信号処理、データプロトコルなどのデバイス固有の特性は、ユーザーから抽象化されています。

3. デバイスドライバーは、安全のレイヤーを提供します。デバイスドライバーは通常カーネルで動作しますが（問題がOSをクラッシュさせる可能性があります）、ユーザーアプリケーションは通常、問題がアプリケーションをクラッシュさせるだけのユーザースペースでデバイスドライバーと通信します。

4. デバイスドライバーは、コントロールパネルなどの管理ツールにアクセスできます。

場合によっては、デバイスをHID（Human Interface Device）仕様のようなAPIに合わせることができ、別のデバイスドライバーをインストールする必要さえありません。

私はOpenBCIソフトウェアを詳細には調べていませんが、実際にはそれがデバイスドライバであるか、デバイスドライバを持っているのではないかと思います。 最近のほとんどのオペレーティングシステムでは、ポートと直接通信することもできません。オペレーティングシステムを経由する必要があります。

Webカメラのドライバーをインストールする必要がある理由は、WebカメラがOSよりも新しいか、またはそのドライバーがOSに含まれていない可能性があるためです。多くのウェブカメラはドライバーをインストールする必要がありません。多くのウェブカメラは古くからあるプラットフォームを使用しており、それらのドライバーはOSに付属しているためです。15年前のLogicoolウェブカメラを見つけて接続すれば、何もインストールしなくても使用できることがわかる可能性があります*

シリアルポートのハードウェアは基本的に20年間同じものであるため、シリアルポートにはほとんどの場合、OSにドライバーが含まれています。

ただし、2つのタイプのドライバーは、異なるハードウェアの異なる抽象化へのプログラムによるアクセスを提供します。そのため、ユーザー空間では、バイトのストリームを介してWebcamとやり取りすることはできません。代わりに、ウェブカメラは、DirectShow、Video4Linux、またはOSが使用しているあらゆるビデオ抽象化を「発声」します*

逆もまた真です。シリアルポートはバイトストリームのみを「話す」ため、ビデオフレームを要求してドライバーから取得することはできません。

*一部のドライバは、デバイスを完全に使用するために、年齢に関係なく特別なドライバをインストールする必要があります。デバイスには、パン、チルト、ズーム、または顔認識を行うWebカメラなど、DirectShowなどでサポートされていない機能がある場合があるためです。または他のもの。しかし、これらは特別なケースなので、あまり気にしないでください。

他の回答のいくつかは、アプリケーションをデバイスインターフェイスから分離することの利点と抽象化の利点に関して非常に優れた点を持っていますが、パフォーマンスとアクセス権限については言及されていない2つの点があります。

パフォーマンス

デバイスドライバーは、入力または割り込みを待って入力を読み取るように指示することがよくあります。そのため、独自のコードを記述する場合は、次のいずれかを実行する必要があります。

• デバイスをポーリングし、残りのコードはこれが十分に頻繁に発生することを確認する必要があります
• 割り込み処理はこれが専門的なスキルであり、複数のデバイスと通信する必要がある場合はどうなりますか
• マルチスレッディングまたはマルチプロセッシングのスペシャリストスキル、すべての言語が十分なサポートを提供しているわけではありません。デバイスハンドラーを別のスレッドに分割する場合は、デバイスドライバーのほとんどの方法です

アクセス権

多くのオペレーティングシステムでは、さらにいくつかのアセンブリレベルのベアメタルターゲットにハードウェアと絶対メモリロケーションへのアクセスは特権を必要スーパーユーザー、ルート、管理者権限それはあなたのための良い練習ではありません- アプリケーション、およびその利用者、そのよう要求します権利が独自のデバイスインターフェイスを実装している場合は、それらが必要です。

ソフトウェアが特定のハードウェアでのみ機能することを目的としている場合は、追加のデバイスドライバーは必要ありません。ただし、サポートしたいインターフェイスが異なる他の脳波リーダーハードウェアがある場合は、追加のデバイスドライバーが役立ちます。それはすべて、プロジェクトの範囲によって異なります。趣味で使用する場合、追加のデバイスドライバーを作成する必要はありません。

基本的には答えは、デバイスドライバーと通信していない場合、プログラムはデバイスドライバーです。

デバイスドライバーを使用すると、ハードウェアとの通信が容易になりますが、制限もあります。デバイスドライバーが提供する機能しか実行できません。

しかし、一般的には、完全な自由が必要な場合は、直接港と話します。これにより、ソフトウェアが次のようにハードウェアと絡み合うことがよくあります。作成した特定のデバイスでのみ機能します。

利用可能なデバイスドライバーがない場合は、ハードウェアと直接通信する必要があります。

利用可能なデバイスドライバーが十分でない場合は、ハードウェアに直接話しかけます。

基本的に他のすべてのケースでは、デバイスドライバーを使用します。（ただし、デバイスドライバーを使用しなくても、それを使用しても、自分で作成したことを忘れないでください）

実際、図には重要なブロックがいくつかありません。「RFレシーバー（USBスティック）」は「シリアル/ USBポート」にデータを送信しません。まず、「USBポート」がありません。RFドングルは、ホストの要求に応じてUSBデータを「USBパイプ」に送信します。ホストは、ホストコントローラーのUSBドライバー、ehci.sysなどを介して要求を生成します。ホストドライバーはUSBパケットを形成し、USBプロトコルに従います。

ただし、ホストコントローラーのパケットコンテンツは、汎用COMクラスドライバー、別のソフトウェアレイヤー（これもOSの既定）によって開始されます。これは、標準のCOMポートをエミュレートし、ポートの読み取り/書き込みをクラス定義/フォーマットに従ってUSB要求にマップ/変換する「デバイスドライバー」です。Javaライブラリの一部であるJSerialCommは、このエミュレートされた仮想COMポートへの単なるストリームのような（バッファリングされた）インターフェースです。

ご覧のとおり、「ハードウェアと直接通信する」、「COMポートに直接書き込む」などの方法はありません。仮想ポートにはいくつかの層があります。メインメモリに巨大で非常に具体的で複雑なデータ構造（デバイス/スロットコンテキスト、転送リングバッファー、コマンドリング、イベントリングなど）を設定し、USBホストコントローラーをリンク用に構成せずに、USBバスで単一のトグルを生成することは不可能です。リスト処理を行った後、ドアベルレジスタを呼び出してUSBトランザクションを開始します。これはすべて、ドライバー、ホストコントローラー、およびデバイスの2層で実現され、何千行ものコードと、半ダース年の開発とデバッグが行われます。この隠れたサービス層の理解と評価を高めるために、、Microsoft確認してください。

カーネル空間からユーザー空間にデータをエクスポートするためのインターフェースは、あまり表現力がありません。特に、型なしです。バイトのシーケンスを取得し、ユーザー空間プログラムはそれらのバイトを意味論的な意味を持つ何かに変換する必要があります。したがって、デバイスドライバーは通常、ユーザー空間ライブラリとペアになります。

ジェネリックシリアルドライバーの上にカーネルスペースOpenBCIデバイスドライバーを追加した場合、基本的には、バイトをシーケンスする別の方法にバイトをシーケンスする1つの方法に変換する機能を提供します。これができるとしたら、どのシーケンスを選択しますか？別のシーケンスの方が良い場合は、なぜ最初からその優れたシーケンスをOpenBCIファームウェアに組み込んでいないのですか？

デバイス固有のカーネルモードドライバーを作成するパフォーマンス上の理由がある場合、または既存のインターフェイスに準拠するように変換する必要がある場合がありますが、それ以外の場合は、OpenBCI_Pythonのような表現力豊かなユーザースペースライブラリを作成することで、より多くの価値を得ることができます。非常に貧弱なカーネルモードドライバーに相当するものを作成するよりも。