自家製のUSBデバイス用のドライバーの作成

この記事の目的は、USBを介した自家製デバイスとコンピューターとの通信を整理するために必要なソフトウェアセット全体の開発プロセスを段階的に示すことです。



現時点では、ほとんどのハムはRS232のUSBアダプターチップを使用してこのタイプの接続を実装しているため、アダプターチップに付属の仮想COMポートドライバーを介してデバイスとの通信を整理しています。 このアプローチの欠点は理解できると思います。 これは、少なくともボード上の余分なチップであり、このチップとそのドライバーによって課される制限です。

しかし、このようなやり取りを整理するプロセス全体を、それが行われるべきであるように、すべての深刻なデバイスでどのように行われるかを強調したいと思います。

結局、今は21世紀であり、ほとんどすべてのマイクロコントローラーにUSBモジュールがあります。 これは、このモジュールを迅速に使用する方法に関するものであり、この記事で説明します。



USBデバイスドライバーを作成するプロセスを示すためにデバイス自体が必要なので、ロシアで利用可能な一般的なデバッグボードの1つを選択します。 このボードは、OLIMEXモデルLPC-P2148で製造されています。 ボードのベースは、ARM7TDMIアーキテクチャのNXPマイクロコントローラーLPC2​​148アーキテクチャです。 ボード上のすべての情報は、次のリンクの製造元のWebサイトで入手できます。 これは彼女がどのように見えるかです。







コントローラーとデバッグボードの選択は絶対に重要ではありません。 パソコンのOSとボード自体の相互作用を開発するプロセスはこれに依存しません。 マイクロコントローラのファームウェア開発環境は、KEILバージョン4.23を使用しますが、これも重要ではありません。 そのため、バルク転送タイプのみを実装する予定です。 デバイスからコンピューターにデータ配列を読み取り、LEDのステータスをデバイスに転送して、ボードがコマンドに応答していることを明確にします。



わかりやすくするために、この段階でさらにアクションを分割し、順番に実行します。



1.ボードが機能し、USBチャネルも機能することを確認するために、完成したUSBデバイスの例をボードに適合させます。 それが出発点のようになります。

2.ボードのファームウェアを変更して、製造元のドライバーを必要とするWindows用の不明なデバイスになるようにします。

3. Windowsがデバイスをサービスするために正しくインストールできるように、基本テンプレートである空のドライバーを調整します。

4.ユーザーアプリケーションとドライバーの対話の実装。

5.ドライバー、つまり接続されたUSBデバイスで動作するWindowsコンソールアプリケーションを作成します。

6.システム全体を必要な機能で満たす。



この記事にはありません。 適切なドライバーを見つけてインストールできるOSの動作メカニズムについては説明しません。 KEIL環境でファームウェアを構築する方法については説明しません。 USB記述子のパラメーターの説明はなく、一般にファームウェアの動作については何も言われません。 最後に、すべての情報源、ソースコード、収集したバイナリへのリンクを提供します。 したがって、この記事でカバーされていない瞬間の説明は、示されたソースで簡単に見つけることができます。 正しく理解し、これらすべてのトピックに関する詳細情報を1つの記事に入れるのは非現実的です。 さらに、より有能な情報源があります。

1. RTX_MemoryサンプルをOLIMEX LPC-P2148ボードに適合させる

プロジェクトのファームウェアの基礎として、KEILで提供されるRTX_Memoryの例を取り上げます。 この例が正常に機能すると、ボードをコンピューターに接続でき、通常のUSBフラッシュドライブのように表示されます。 したがって、ファームウェアを取得します。これにより、明らかにUSBモジュールと、プロセッサに必要なすべての周辺機器が正しく構成されます。



このプロジェクトは、ARM \ Boards \ Keil \ MCB2140 \ RL \ USB \フォルダにあります。 以下のパスは、KEIL環境がインストールされているメインフォルダーに対する相対パスです。



プロジェクトを別の場所にコピーし、KEILにアップロードして組み立てます。 エラーなしで集まる必要があります。 その結果、FlashMagicユーティリティを使用してフラッシュできるHEXファイルを取得しました。

確かに、ボード上では機能しないことは明らかなので、まだフラッシュすることはできません。

ボードと例が書かれたボードの回路を比較すると、これがKEILモデルMCB2140である場合、D +ラインサスペンダーの接続の違いを確認できます。

MCB2140では、常に3.3Vにプルアップされ、LPC-P2148では、このプルアップはトランジスタを介してマイクロコントローラーによって制御されます。



両方のボードの回路図は、それぞれwww.olimex.comおよびwww.keil.comで入手できます。



簡単にするために、初期化コードをわずかに変更して、ボードがオンになったときに常にD +ラインプルアップがオンになるようにします。これはUSB_LINK LEDで示されます。

USB_Init（）プロシージャで、CONNECT行をUSBモジュールから切断し、自分で管理します。 また、同じトランジスタにUSB_LINK LEDもあるため、オンにするとD +ラインリフトが自動的にオンになることがわかりました。



さらに、当社のボードには、MCB2140よりも少ないLEDがあります。 したがって、それらの目的も再定義する必要があります。 この時点で、読み取り/書き込みプロセスを示すためにそれらを再割り当てしました。

LED_CFGインジケーターとLED_SUSPインジケーターがないため、プロジェクトコードに従ってそれらの使用をコメントアウトしています。

これで、プロジェクトを組み立てて、コントローラーにフラッシュできます。 ボードをコンピューターに接続すると、ボードが外部ドライブとして認識され、システムに約25KBのサイズの別のディスクが表示され、readme.txtファイルが表示されます。



この時点で、最初の段階は完了したと見なすことができます。

2. USBドライブから一意のデバイスへの移行。

現時点では、どのOSを搭載したコンピューターでも、外部USBドライブとして認識されるデバイスがあります。 しかし、Windowsがデバイスの操作方法を知らず、ドライバーを必要とすることが必要です。 接続されたデバイスがドライブクラスに属しているという事実は、インターフェイス記述子にあるインターフェイスクラスパラメータによって示されます。



usbdesc.cファイルを開き、そこでこのパラメーターを見つけると、値がUSB_DEVICE_CLASS_STORAGEであることがわかります。



これをUSB_DEVICE_CLASS_VENDOR_SPECIFICに置き換え、それに続く2つのフィールドをゼロに置き換えます。

プロジェクトを再構築してボードをフラッシュすると、Windowsがデバイスがドライブであることを認識できなくなり、適切なドライバーの提供が必要になることがわかります。



問題がある可能性があります。 実際、外部記憶装置に関連するデバイスのVIDおよびPIDを以前に記憶していたWindowsは、デバイスクラスが変更されたという事実に注意を払うことなく、その上にドライバーを配置し続けることができます。 解決策は簡単です。 ボードがまだドライブとして定義されている場合は、デバイスマネージャーのUSBブランチで見つけて、ドライバーを手動で削除します。 その後、OSはドライバーを要求し始めます。

3.基本ドライバーを作成します。

そのため、ドライバを提供する必要がある機能するUSB​​デバイスがあります。

まず、デバイスがUSBバスに表示されたときにシステムを起動すること以外は、何も役に立たない最も単純なドライバーを作成します。 ドライバーには、正しく起動してシステムをアンロードするための最小限のコードしかありません。



最も最小限の方法でドライバーを作成します。 コード自体はメモ帳で編集され、コマンドラインで収集されます。



開始するには、Microsoft Webサイトからドライバー開発キットをダウンロードする必要があります。 Windows Driver Kitと呼ばれます。 WDKバージョン7600.16385.1を使用しています。



インストール後、多くの例、アセンブリの環境、およびドキュメントを取得します。 [スタート]メニューで、WDKセクションと[ビルド環境]を見つける必要があります。 これらは、いわゆるビルド環境です。 実際、これらは、目的のシステムのドライバーを収集するために既にセットアップされているコンソールを提供します。



CheckedおよびFree環境がいくつかあるOSごとに個別のフォルダーがあることがわかります。 いわゆるCheckedシステムの最初のものは、デバッグに役立つ追加情報を含むドライバーを収集します。

2番目はドライバーリリースを収集し、それが使用されます。



Windows XPから引き続きx86 Checked Build Environmentを使用します。 これにより、Windows XP以降のシステムで正常に動作するユニバーサルドライバーが得られます。



次に、開始するのに最も便利なテンプレートを探しましょう。



最も適切な候補は、特定のOSR USB-FX2学習キットの例でした。 これはどのようなボードか、まったくわからないが、必要な例はWDKのパスsrc \ usb \ osrusbfx2 \に沿っている。 最も興味深いのは、これが単なる例ではなく、このボードのドライバーの作成方法に関する段階的なチュートリアルであることです。 まさに必要なもの。 kmdf \ sysディレクトリをさらに深く見て、すべてのステップがあり、パパにいることを確認しましょう。 これらの詳細については、osrusbfx2.htmファイルにあるサンプルの説明を参照してください。



ここでは、以下のアクションをもう少し明確にするために、少し余談します。

実際には、Windows NTの登場以来、ドライバーを作成する過程で何かが変更されています。 当時は、OSカーネルの機能を直接使用する必要があり、多くの場合、ダミーをロード、アンロード、PNPイベントなどに対応できるようにするだけでした。 基本的な機能、私は多くのことを学び、BSODに2回以上飛び出さなければなりませんでした。 その後、Microsoftは、Windowsドライバーモデルと呼ばれるモデルを作成しました。このモデルは、ドライバーがどのように見えるべきか、何らかの標準などを導入しました。 私はこれに特に安心していませんでした。 そして次のステップは、Windows Driver Frameworkと呼ばれるフレームワークでした。 このおかげで、人生はずっと楽になりました。 これで、フレームワークがメインイベントを処理するために必要なすべての基本アクションの実装を処理し、必要な機能を正しい方法で追加するだけで済みます。 使用するのはこの技術です。



最初のステップから始めます。 「x86 Checked Build Environment」を起動し、「cd」コマンドを使用してWinDDK \ 7600.16385.1 \ src \ usb \ osrusbfx2 \ kmdf \ sys \ step1 \フォルダーに移動します。



build -ceZコマンドを実行します。



ビルドプロセスが発生し、その結果、objchk_wxp_x86フォルダーが作成され（その名前は選択した環境によって異なります）、sys拡張子を持つファイルが見つかります。 これが私たちのドライバーです。 それをインストールするには、INFファイルが必要です。 同じプロジェクトの最後のフォルダーで見つけてください。 osrusbfx2.infと呼ばれます。 唯一の問題は、例のボード用に設計されていることです。 このファイルがボード用のドライバーをインストールできるようにするには、どこでもVIDとPIDの値をusbdesc.cファイルのUSBデバイス記述子に書き込まれている値に変更するだけです。 INFファイルを目で見てみると、ドライバーをインストールするためにWdfCoInstaller01009.dllファイルがまだ必要であることがわかります。 また、WDKの供給にも含まれています。



そのため、3つのファイルを別々のフォルダーにコピーします：組み立てられたSYS、INF、WdfCoInstaller01009.dll。



ボードをコンピューターに接続し、Windowsからドライバーへのパスについて尋ねられたら、このフォルダーを指定します。



ドライバーファイルをコピーする通常のプロセスを観察すると、デバイスマネージャーのサンプルデバイスクラスの下にデバイスが表示されます。 すべて、オペレーティングシステムは満足です！



ここで疑問が生じるかもしれませんが、コードが実行されていることをどのようにして知ることができますか。 言い換えれば、ドライバーから何らかのフィードバックをもらいたいのです。 そうです、何が起こっているのかを理解するために、ドライバーにデバッグ情報を追加する時が来ました。



カーネルモードでは、KdPrint（）関数はデバッグ情報を出力します。 その使用法は、よく知られているprintf（）と同じです。 出力を表示するには、プログラムDbgViewをインストールする必要があります。 MicrosoftのWebサイトhttp://technet.microsoft.com/en-us/sysinternals/bb896647で入手できます。 実行し続けると、OSのカーネルモードからのすべてのデバッグ情報の出力が表示されます。 通常、必要なモジュールのメッセージのみが表示されるようにフィルターを構成します。 Step_1の私のバージョンでは、DeviceEntry（）およびDeviceAdd（）プロシージャに出力を追加して、どの関数が呼び出されたかを単純に書き込みました。 ボードを接続および切断することにより、DbgViewウィンドウで、これが発生する順序を明確に確認できます。

4.カーネルモードとユーザーモードの相互作用。

ご存じのように、デバイスドライバーはカーネルモード（一部の例外を除く）で動作し、アプリケーションはユーザーモードで動作します。 対話には、ファイルの操作と同じメカニズムが使用されます。 つまり、システムに接続されている各デバイスには、通常のファイルのように開くことができるシンボル名があります。 それでは、ReadFile（）やWriteFile（）などのファイルを操作するための通常の手順を使用してください。 この部分では、ドライバーにデータを開いたり、閉じたり、書き込んだり、読み取ったりすることができる機能をドライバーに追加します。



記録されたデータを保存して、後で読み取り操作中にそれらを返すことができるようにします。



最初に行うことは、EvtDevicePrepareHardwareイベントのコールバック関数を登録することです。これは、デバイスがD0の初期化されていない状態に入った後、ドライバーで使用できるようになる前にPnPマネージャーが呼び出します。 実際、これは非常に単純なことを意味します。デバイスをスタックし、ドライバーを起動しましたが、使用するにはデバイスの設定が必要になる場合があります。 この種のチューニングはこのイベントで行います。 USBに適用する場合、少なくとも目的の構成を選択する必要があります。 したがって、関数を登録します。 これを行うには、次のコードをDriverEntryに追加します。



WDF_PNPPOWER_EVENT_CALLBACKS_INIT(&pnpPowerCallbacks);

pnpPowerCallbacks.EvtDevicePrepareHardware = EvtDevicePrepareHardware;

WdfDeviceInitSetPnpPowerEventCallbacks(DeviceInit, &pnpPowerCallbacks);









二番目。 前の段落のドライバーコードからのWdfDeviceCreateプロシージャコールに注意を払うと、このプロシージャの2番目のパラメーターに定数WDF_NO_OBJECT_ATTRIBUTESが渡されることに気付くでしょう。 つまり、デバイスオブジェクトには属性がありません。 しかし、実際には、少なくとも1つの属性が必要です。 これは、いわゆるデバイスコンテキストです。 簡単に言えば、これは、ドライバーによってサポートされるデバイスの特定のインスタンスに関連する何らかの種類の構造であり、ドライバーのほぼどこでも利用可能になります。 たとえば、何らかの種類のバッファが含まれている場合があります。 そして、ドライバーではなくデバイスオブジェクトに添付されます。 複数の同一のデバイスをコンピューターに接続することができ、それらは同じドライバーによって提供されますが、それらはすべて独自のデバイスオブジェクトを持ちます。



そのため、コンテキスト構造体を作成し、属性パラメーターで初期化して、さらにWdfDeviceCreateに渡します。



typedef struct _DEVICE_CONTEXT {

WDFUSBDEVICE UsbDevice;

WDFUSBINTERFACE UsbInterface;

WDFUSBPIPE BulkReadPipe;

WDFUSBPIPE BulkWritePipe;

} DEVICE_CONTEXT, *PDEVICE_CONTEXT;

WDF_DECLARE_CONTEXT_TYPE_WITH_NAME(DEVICE_CONTEXT, GetDeviceContext)



WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&attributes, DEVICE_CONTEXT);









三番目。 次に、ドライバーをユーザーモードプログラムで使用できるようにするインターフェイスを作成する必要があります。 以前は、プログラマは、CreateFileプロシージャを介してデバイスにアクセスできる名前をハードコードする必要がありました。 これですべてが簡単になりました。 1つのプロシージャを呼び出すだけでインターフェイスを作成する必要があり、生成されたGUIDを使用してそれを識別します。 さらにユーザーモードでは、同じGUIDを使用してデバイスファイル名を取得します。 したがって、GUIDとそれをインターフェイスにリンクするコードは次のとおりです。



DEFINE_GUID(GUID_DEVINTERFACE_OSRUSBFX2, // Generated using guidgen.exe

0x573e8c73, 0xcb4, 0x4471, 0xa1, 0xbf, 0xfa, 0xb2, 0x6c, 0x31, 0xd3, 0x84);

// {573E8C73-0CB4-4471-A1BF-FAB26C31D384}



status = WdfDeviceCreateDeviceInterface(device,

(LPGUID) &GUID_DEVINTERFACE_OSRUSBFX2,

NULL);// Reference String









最後の1つ。 最初の段落では、EvtDevicePrepareHardwareイベントを処理するプロシージャを登録しました。 今、あなたはそれを書く必要があります。 私は記事のテキストを書き換えません。ソースコードを見る方が簡単だと思います。 この手順では、接続されたデバイスを使用したドライバーのその後の操作に必要なすべてのものを準備していると言えます。 具体的には、USBデバイスオブジェクトを作成し、目的の構成を選択し、デバイスコンテキストのデバイスに実装されているインターフェイスのBULKエンドポイントに関連するチャネル識別子を保存します。 データ転送を実装するには、これらの識別子が後で必要になります。 明確にするために、チャネルパラメーターの出力をDbgViewに追加しました。 これらのパラメーターは、ファームウェアのusbdesc.hファイルのエンドポイント記述子で指定した値と同じであることに気付くかもしれません。

そのため、ドライバーを再度再構築し、システムで更新できます。 現時点では、ドライバーは起動するだけではありません。 彼は既に接続されたデバイスを構成する方法を知っており、最も重要なことは、ユーザーモードからのプログラムで利用可能になっています。





5.ユーザーモードからドライバーを操作します。



次に、ドライバーへのアクセスのみを試みる簡単なコンソールプログラムを作成します。 ご存知のように、現時点では、ドライバーは自分自身にアクセスする機会を与えることを除いて、他に何かを行う方法を知りません。



デバイスでの作業は、通常のファイルとしてデバイスを開き、通常のWriteFileおよびReadFileプロシージャを使用してデータの書き込みと読み取りを行うことになります。 また、ドライバーとの相互作用を整理するための非常に便利なDeviceIoControlプロシージャがあります。これは、ファイルを操作する形式を超えていますが、使用しません。 ファイルはCreateFileの通常の呼び出しによって開かれますが、ファイル名のみが必要です。 そして、ここでGUIDが必要になります。これはドライバーインターフェイスに結び付けられています。 GUIDを使用して名前を取得する手順全体については説明しませんが、WDKの例から完全に取ったことを正直に認めます。 GetDevicePathプロシージャはGUIDを受け取り、それに対応するフルパスを返します。



ファイルが開いています。 ファイルから10バイトを記録して読み取る呼び出しをいくつか追加します。



しかし、ドライバーに戻りましょう。 ユーザープログラムでは、すでにドライバーに書き込み、ドライバーから読み取りますが、ドライバーコード自体はそれについて何も知りません。 状況を修正してください。



ここでのロジックは、EvtDevicePrepareHardwareと同じです。 ドライバーからの読み取りまたはドライバーへの書き込みの手順が発生したときに呼び出されるコールバック関数を登録する必要があります。 これはEvtDeviceAddで行われます。 I / Oキューを初期化し、フィールドにコールバック関数へのポインターを入力し、デバイスオブジェクトにアタッチして作成する必要があります。 行こう：



WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&ioQueueConfig,

WdfIoQueueDispatchParallel);



ioQueueConfig.EvtIoRead = EvtIoRead;

ioQueueConfig.EvtIoWrite = EvtIoWrite;



status = WdfIoQueueCreate(device,

&ioQueueConfig,

WDF_NO_OBJECT_ATTRIBUTES,

WDF_NO_HANDLE);









読み取りおよび書き込みプロシージャを宣言することに加えて、それらを実装することを忘れないでください。 この段階では、転送されたデータをDbgViewに出力するスタブを配置し、読み取り時に10バイトの配列を渡します。 ソースコードでそれらのコードを見ることができます。 おもしろいことは何もありません。メモリを操作することに注意を払うことをお勧めします。 特定のルールに従って、バッファを受信する必要があります。 データはカーネルモードとユーザーモードの間を移動します。 スクリーンショットは、ドライバーにデータを送信する方法を明確に示しており、DbgViewウィンドウに表示されます。 次に、ドライバーからパッケージを読み取り、コンソールアプリケーションの出力で取得します。





6.ドライバーを便利にします。



それで、ドライバーを便利にする時が来ました。 現時点では、彼はユーザーモードで通信していますが、実際のデバイスでは動作しません。 あとは、記録手順でデバイスにデータを送信するコードと、読み取り手順でデバイスからデータを受信するコードを追加するだけです。 ソースでは、ドライバーで入力/出力を処理する手順がわずかに変更されていることがわかります。 バッファをUSBカーネルサブシステムにさらに転送するだけで、必要に応じてすべてが実行されます。

PCとデバイス間の実際のデータ転送を開始する前に、デバイスのファームウェアを変更して、何らかの方法でデータに応答する必要があります。



データ受信イベントの処理でコードを変更して、受信した最初のバイトが0x01の場合はLED_1をオンにし、0x02の場合はLED_2をオンにします。 そして以来 デバイスへの書き込み後、すぐに10バイトを読み取り、このコードも追加します。 着信パケットの処理イベントで送信するためにパケットを送信することに注意してください。 これは、USBモジュールのこのような機能です。 INトランザクションを実行できるように、送信するデータを事前に提供する必要があります。 また、明確にするために、2つの異なる配列を渡します。 MSC_BulkOut（）の内容を次のように変更します。



void MSC_BulkOut (void) {



BulkLen = USB_ReadEP(MSC_EP_OUT, BulkBuf);



LED_Off( LED_RD | LED_WR );

if( BulkBuf[ 0 ] == 0x01 )

{

USB_WriteEP( MSC_EP_IN, (unsigned char*)aBuff_1, sizeof( aBuff_1 ) );

LED_On( LED_RD );

}

else

if( BulkBuf[ 0 ] == 0x02 )

{

USB_WriteEP( MSC_EP_IN, (unsigned char*)aBuff_2, sizeof( aBuff_1 ) );

LED_On( LED_WR );

}

}









また、プロシージャMSC_BulkIn（）では、すべてのコードをコメント化し、完全に空のままにします。



スクリーンショットに表示される全体の束の結果。

同時に、ボード自体が2つのLEDで点滅します。





それだけです。 独自のUSBデバイス用のファームウェアと完全なドライバーを作成しました。 4kのブロックで転送を開始すると、800 Kb / sの速度を達成できます。

ご覧のとおり、ドライバーテキストは非常にシンプルで、約250行しか含まれていません。



この記事では、機能するドライバーを取得するために必要な基本的な手順のみを説明しました。 使用される手順の詳細については、WDKで読む必要があります。 さらに、今ではこのドキュメントを読むのがとても楽しくなり、例がたくさんあります。



ソースコードを含む完全なアーカイブはここからダウンロードできます。

アーカイブには、ポイントで名前が付けられたフォルダーが含まれ、各フォルダーには、対応する段落で達成した最終結果が含まれています。



この記事がガイド「フクロウの描き方」とは違っていて、誰かが役に立つと思うことを願っています。