😂 🎛️ 🎠 レジスタ上のUSB：STM32L1 / STM32F1 🆕 🐇 🍧

さらに低いレベル（AVR-VUSB）

レジスタのUSB：マスストレージの例使用してバルクエンドポイント

割り込みエンドポイントをHID用の例使用：レジスタのUSBを

レジスタにUSBを：オーディオ装置の例を使用してアイソクロナスエンドポイントを

我々はすでに使用してソフトウェアUSBを満たしていますAVRの例では、より重い石（stm32）に時間がかかります。私たちの実験対象は、古典的なSTM32F103C8T6と、低電力STM32L151RCT6シリーズの代表です。以前と同様に、購入したデバッグボードとHALは使用せず、自転車を優先します。

タイトルには2つのコントローラーがあるので、主な違いについて説明する価値があります。まず第一に、これは何かがそれにスタックしていることをUSBホストに伝えるプルアップ抵抗です。 L151では組み込みでSYSCFG_PMC_USB_PUビットによって制御されますが、F103ではそうではありません。外部からボードにはんだ付けし、VCCまたはコントローラーレッグに接続する必要があります。私の場合、PA10の脚が私の腕の下に来ました。 UART1がぶら下がっているところ...そしてUART1のもう一方のピンがボタンと衝突しています...私は素晴らしいボードを投げましたね。 2つ目の違いは、フラッシュメモリの量です。F103では64 kB、L151では256 kBであり、バルクエンドポイントを調査するときにいつか使用します。また、クロッキング設定がわずかに異なり、ボタン付きの電球でさまざまな脚に掛けることができますが、これらはすでに非常に些細なことです。 F103の例はリポジトリで利用できるため、残りの実験をL151に適合させることは難しくありません。ソースコードはこちらから入手できます： github.com/COKPOWEHEU/usb

USBでの作業の一般原則

このコントローラーでのUSBでの操作は、ハードウェアモジュールを使用して想定されています。つまり、私たちは彼に何をすべきかを伝え、彼はそうし、最後に「私は準備ができています！」割り込みを引き出します。したがって、メインメインからほとんど何も呼び出す必要はありません（念のためにusb_class_poll関数を提供しましたが）。通常の作業サイクルは、データの交換という1つのイベントに限定されます。残り（リセット、スリープなど）は、例外的な1回限りのイベントです。

今回は、交換の低レベルの詳細については説明しません。興味のある人は誰でもvusbについて読むことができます。ただし、通常のデータの交換は1バイトではなくパケットで行われ、送信方向はホストによって設定されます。また、これらの方向の名前も指示します。IN送信は、ホストがデータを受信する（そしてデバイスが送信する）ことを意味し、OUTは、ホストがデータを送信する（そして私たちが受信する）ことを意味します。さらに、各パケットには独自のアドレス（ホストが通信するエンドポイントの番号）があります。今のところ、デバイス全体を担当する単一のエンドポイント0があります（簡潔にするために、ep0とも呼びます）。残りは何のためにあるのか、私は他の記事であなたに話します。標準によると、ep0のサイズは低速デバイス（同じvusbが属する）の場合は厳密に8バイトであり、8、16、32、私たちのようなフルスピードの64バイト。

データが小さすぎてバッファが完全にいっぱいにならない場合はどうなりますか？ここではすべてが単純です。パケット内のデータに加えて、それらのサイズも送信されます（これは、送信の終了を示すwLengthフィールドまたはSE0信号の低レベルの組み合わせである可能性があります）。したがって、転送する必要がある場合でも64バイトのep0までの3バイトの場合、正確に3バイトが転送されます...その結果、不要なゼロを駆動することによって帯域幅を浪費することはありません。したがって、小さすぎないでください。64バイトを費やす余裕があれば、ためらうことなく費やします。特に、これによりバスの負荷がいくらか軽減されます。これは、64バイト（およびすべてのヘッダーとテール）をそれぞれ8バイト（それぞれにヘッダーとテール）の8倍よりも一度に転送する方が簡単だからです。）。

それどころか、データが多すぎる場合はどうでしょうか。ここではもっと複雑です。データはエンドポイントのサイズで分割し、チャンクで転送する必要があります。 ep0のサイズが8バイトで、ホストが20バイトを送信しようとしているとします。最初の割り込みで、バイト0〜7が、2番目の8〜15で、3番目の16〜20で私たちに届きます。つまり、パッケージ全体を収集するには、最大3つの割り込みを受け取る必要があります。このために、同じHALでトリッキーなバッファーが発明され、それを理解しようとしましたが、関数間で同じものを転送する第4レベルの後、私は唾を吐きました。その結果、私の実装では、バッファリングはプログラマーの肩にかかっています。

ただし、ホストは少なくとも常に、転送しようとしているデータの量を示します。データを転送するときは、データが終了したことを明確にするために、何らかの方法でレッグの低レベルの状態をだます必要があります。より正確には、データが終了していることと、脚を引っ張る必要があることをUSBモジュールに明確にするためです。これは明らかな方法で行われます-バッファの一部のみを書き込むことによって。たとえば、バッファに8バイトがあり、4を書き込んだ場合、明らかに4バイトのデータしかありません。その後、モジュールは魔法の組み合わせSE0を送信し、誰もが満足します。そして、8バイトを書き込んだ場合、それは8バイトしかないことを意味しますか、それともこれはバッファーに収まるデータの一部にすぎないことを意味しますか？ USBモジュールはそれを考えています。したがって、転送を停止したい場合は、8バイトのバッファを書き込んだ後、次の0バイトのバッファを書き込む必要があります。これは、ZLP、ゼロ長パケットと呼ばれます。コードでどのように見えるか、少し後でお話しします。

記憶の構成

標準によれば、エンドポイント0のサイズは最大64バイトです。その他のサイズ-最大1024バイト。ポイントの数もデバイスごとに異なる場合があります。同じSTM32L1は、入力で最大7ポイント、出力で最大7ポイント（ep0をカウントしない）、つまり最大14kBのバッファーのみをサポートします。そのようなボリュームでは、誰もが必要になることはほとんどないでしょう。許容できないメモリの消費！代わりに、usbモジュールは共有カーネルメモリのチャンクを切り落とし、それを使用します。この領域はPMA（パケットメモリ領域）と呼ばれ、USB_PMAADDRで始まります。また、各エンドポイントのバッファーがその内部のどこにあるかを示すために、それぞれ次の構造を持つ8つの要素の配列が最初に割り当てられ、次にデータの実際の領域が割り当てられます。

typedef struct{
    volatile uint32_t usb_tx_addr;
    volatile uint32_t usb_tx_count;
    volatile uint32_t usb_rx_addr;
    volatile union{
      uint32_t usb_rx_count;
      struct{
        uint32_t rx_count:10;
        uint32_t rx_num_blocks:5;
        uint32_t rx_blocksize:1;
      };
    };
}usb_epdata_t;

ここでは、送信バッファの先頭とそのサイズを設定し、次に受信バッファの先頭とそのサイズを設定します。まず、usb_tx_countは実際のバッファサイズではなく、転送するデータの量を設定することに注意してください。つまり、コードはアドレスusb_tx_addrにデータを書き込み、次にそのサイズをusb_tx_countに書き込み、データが書き込まれたUSBモジュールレジスタをプルして転送する必要があります。受信バッファサイズの奇妙な形式にさらに注意を払ってください。これは、10 rx_countビットが実際に読み取られるデータ量を担当し、残りは実際にはバッファサイズを担当する構造です。あなたが書くことができる場所、そして他の人のデータがどこから始まるのかを知る必要があります。この設定の形式も非常に興味深いものです。rx_block_sizeフラグは、サイズが設定されている単位を示します。 0にリセットされた場合、次に、2バイトワードでは、バッファサイズは2 * rx_num_blocks、つまり0から62です。1に設定すると、それぞれ32バイトブロックで、バッファサイズは32 * rx_num_blocksになります。そして、32から512の範囲にあります（はい、1024までではありません。これがコントローラーの制限です）。

この領域にバッファを配置するには、セミダイナミックアプローチを使用します。つまり、メモリをオンデマンドで割り当てますが、それを解放しません（malloc / freeはまだ発明するのに十分ではありませんでした！）。割り当てられていないスペースの先頭は、変数lastaddrによって示されます。この変数は、最初はPMAの先頭から、上記で説明した構造のテーブルを引いたものを指します。次のエンドポイントusb_ep_init（）を構成する関数が呼び出されるたびに、そこで指定されたバッファーサイズだけシフトされます。もちろん、必要な値はテーブルの対応するセルに入力されます。この変数の値は、リセットイベントの後にリセットされ、続いてusb_class_init（）が呼び出されます。この呼び出しでは、ユーザーのタスクに従ってポイントが再構成されます。

送受信レジスタの操作

さっき言ったように、受信時に実際に受信したデータの量（usb_rx_countフィールド）を読み取り、次にデータ自体を読み取り、次にusbモジュールをプルしてバッファーを解放し、次のパケットを受信できるようにします。送信の場合は、その逆です。データをバッファーに書き込み、次にusb_tx_countに書き込まれた量を設定し、最後にモジュールをプルしてバッファーがいっぱいになるようにします。これを転送できます。

最初の熊手バッファー自体を操作するときに開始します。バッファーは、コントローラーの他の部分のように32ビットで構成されておらず、予想どおり8ビットで構成されていません。そしてそれぞれ16ビット！その結果、4バイトに合わせて2バイトで読み書きされます。そのような倒錯をしてくれてありがとうST！それがなければ、なんてつまらない人生でしょう！今では普通のmemcpyが不可欠なので、特別な機能をフェンスする必要があります。ちなみに、DMAが好きな人なら、テストはしていませんが、それだけでそのような変換ができるようです。

そして 2番目の熊手モジュールのレジスタに書き込みます。実際のところ、各エンドポイントの構成（タイプ（制御、バルクなど）と状態）については、1つのレジスタUSB_EPnRが責任を負います。つまり、少し変更することはできず、注意する必要があります。残りを台無しにしないように。そして第二に、このレジスタにはすでに4種類のビットがあります！一部は読み取り専用（これは素晴らしい）、その他は読み取りと書き込み（これも通常）、その他はレコード0を無視しますが、1を書き込むと、状態が反対に変更され（楽しみが始まります）、4番目は逆に、レコード1を無視しますが、レコード0はそれらを0にリセットします。いいえ、コードとハードウェアの両方からアクセスされるときに、レジスタの整合性を維持するためにこれが行われたと想定する準備ができています。しかし、あなたは何が欲しいですか、1を書き込むことによってビットがリセットされるようにインバーターを配置するのは面倒でしたか？または、0を書き込むことによって他のビットが反転されるようにインバーターを使用しますか？その結果、2つのレジスタビットを設定すると、次のようになります（このような倒錯についてはSTに再度感謝します）。

#define ENDP_STAT_RX(num, stat) do{USB_EPx(num) = ((USB_EPx(num) & ~(USB_EP_DTOG_RX | USB_EP_DTOG_TX | USB_EPTX_STAT)) | USB_EP_CTR_RX | USB_EP_CTR_TX) ^ stat; }while(0)

そうそう、私はほとんど忘れていました。彼らは番号でレジスターにアクセスすることもできません。つまり、マクロUSB_EP0R、USB_EP1Rなどです。彼らは持っていますが、数が変数に入った場合、悲しいかな。私は自分のUSB_EPx（）を発明しなければなりませんでした-そして何をすべきか。

さて、手続きに準拠するために、準備フラグ（つまり、前のデータをすでに読み取ったこと）がUSB_EP_RX_VALIDビットマスクによって設定され、書き込み用（つまり、データを書き込みました）であることを指摘します。フルで転送可能）-USB_EP_TX_VALIDマスクによる。

INおよびOUTリクエストの処理

USB割り込みの発生はさまざまなことを示す可能性がありますが、ここでは通信要求に焦点を当てます。このようなイベントのフラグは、USB_ISTR_CTRビットになります。それを見れば、ホストがどのポイントと通信したいかを理解できます。ポイント番号はUSB_ISTR_EP_IDビットマスクの下に隠されており、INまたはOUT方向はそれぞれUSB_EP_CTR_TXビットとUSB_EP_CTR_RXビットの下に隠されています。

多くのポイントを持つことができ、それぞれに独自の処理アルゴリズムがあるため、対応するイベントで呼び出される、それらすべてのコールバック関数を作成します。たとえば、ホストがエンドポイント3にデータを送信し、USB-> ISTRを読み取り、そこから要求がOUTであり、ポイント番号が3であることを引き出します。したがって、epfunc_out [3]（3）を呼び出します。括弧内のポイント番号は、ユーザーコードが突然複数のポイントで1つのハンドラーをハングさせたい場合に送信されます。そうそう、USB規格でも、IN入力ポイントをコック付きの7番目のビットでマークするのが通例です。つまり、出力のendpoint3の番号は0x03になり、入力のエンドポイント3は-0x83になります。また、これらは異なる点であり、同時に使用することができ、互いに干渉しません。まあ、ほとんど：stm32では、受信と送信の両方のタイプ（バルク、割り込みなど）の設定があります。したがって、同じ0x83番目のINポイントがコールバックに一致します 'epfunc_in [3]（3 | 0x80）で。

同じ原則がep0にも当てはまります。唯一の違いは、その処理がユーザーコード内ではなく、ライブラリ内で行われることです。しかし、HIDのような特定のリクエストを処理する必要がある場合はどうなりますか？ライブラリコードをわざわざ選択しないでください。このために、特別なコールバックusb_class_ep0_outとusb_class_ep0_inがあります。これらは特別な場所で呼び出され、特別な形式を持っています。これについては、最後に詳しく説明します。

パケット処理割り込みの発生に関連するもう1つのあまり明白ではない点について言及する価値があります。 OUTリクエストを使用すると、すべてが簡単になります。データが届きました。ただし、IN割り込みは、ホストがIN要求を送信したときではなく、送信バッファが空のときに生成されます。つまり、原則として、この割り込みはUARTバッファアンダーラン割り込みに似ています。したがって、何かをホストに転送する場合は、データを転送バッファーに書き込み、IN割り込みを待って、適合しないものを追加するだけです（ZLPを忘れないでください）。そして、「通常の」エンドポイントであっても、プログラマーによって制御されます。今のところ無視してかまいません。しかし、ep0を通じて、交換は常に行われています。したがって、それを使用する作業はライブラリに組み込まれている必要があります。

結果として、転送の開始はep0_send関数によって実行されます。この関数は、バッファーの開始のアドレスと転送するデータの量をグローバル変数に書き込みます。その後、それ自体がINイベントをプルします。初めてハンドラー。将来的には、このハンドラーはハードウェアイベントで呼び出されますが、それでもプッシュする必要があります。

ハンドラー自体は非常に単純です。次のデータを転送バッファーに書き込み、バッファーの先頭のアドレスをシフトして、転送用に残っているバイト数を減らします。別の松葉杖が同じZLPに関連付けられており、空のパケットで一部の要求に応答する必要があります。この場合、転送の終了は、データアドレスがNULLになったという事実によって示されます。そして、空のパケット-それはZLPP定数に等しいこと。サイズがゼロに等しいときに両方が発生するため、実際の記録は発生しません。

他のエンドポイントを操作する場合は、同様のアルゴリズムを実装する必要があります。しかし、これはユーザーの関心事です。また、作業のロジックはep0での作業とは異なることが多いため、ライブラリレベルでバッファリングするよりもこのオプションの方が便利な場合があります。

USB通信ロジック

ホストは、データラインと電源の間にプルアップ抵抗が存在することにより、接続の事実そのものを判断します。彼はデバイスをリセットし、バス上のアドレスを割り当てて、何がデバイスにスタックしているかを正確に判別しようとします。これを行うために、デバイスと構成記述子（および必要に応じて特定の記述子）を読み取ります。また、文字列記述子を読み取って、デバイスがそれ自体を呼び出すものを理解することもできます（ただし、VID：PIDのペアに精通している場合は、データベースから行を取得することをお勧めします）。その後、ホストは適切なドライバーをロードし、理解できる言語でデバイスを操作できます。理解できる言語には、特定のインターフェースとエンドポイントへの特定の要求と呼び出しが含まれます。それについても説明しますが、最初に、少なくともシステムにデバイスを表示する必要があります。

SETUPリクエストの処理：DeviceDescriptor

USBを少しでもいじったことがある人は、長い間警戒していたはずです。COKPOWEHEU、INとOUTの要求について話しているのですが、SETUPも標準で詳しく説明されています。はい、そうですが、それは一種のOUTリクエストであり、特別に構造化され、エンドポイント0専用に意図されています。その構造と作業の機能について説明しましょう。

構造自体は次のようになります。

typedef struct{
  uint8_t bmRequestType;
  uint8_t bRequest;
  uint16_t wValue;
  uint16_t wIndex;
  uint16_t wLength;
}config_pack_t;

この構造の分野は多くの情報源で検討されていますが、それでも思い出させていただきます。

bmRequestTypeはビットマスクであり、そのビットは次のことを意味します

。7：送信方向。 0-ホストからデバイスへ、1-デバイスからホストへ。実際、それは次の送信のタイプ、OUTまたはINです。

6-5：リクエストクラス

0x00（USB_REQ_STANDARD）-標準（今のところのみ処理します）

0x20（USB_REQ_CLASS）-クラス固有（次の記事で説明します）

0x40（USB_REQ_VENDOR）-メーカー固有（それらに触れる必要がないことを願っています）

4-0：対話者

0x00（USB_REQ_DEVICE）-デバイス全体

0x01（USB_REQ_INTERFACE）-個別のインターフェイス

0x02（USB_REQ_ENDPOINT）

-bRequestエンドポイント

-wValueリクエスト自体-小さな16ビットデータフィールド。単純なリクエストの場合は、本格的な転送を行わないようにします。

wIndexは受信者の番号です。たとえば、ホストが通信したいインターフェース。

wLength-16ビットのwValueでは不十分な場合の追加データのサイズ。

まず、デバイスを接続するときに、ホストはデバイスに何が詰まっているのかを正確に見つけようとします。これを行うために、次のデータを含む要求を送信します：

bmRequestType = 0x80（読み取り要求）+ USB_REQ_STANDARD（標準）+ USB_REQ_DEVICE（デバイス全体に）

bRequest = 0x06（GET_DESCRIPTOR）-記述子要求

wValue = 0x0100（DEVICE_DESCRIPTOR）-デバイス記述子全体

wIndex = 0-未使用

wLength = 0-追加データなし

次に、デバイスが回答を送信するIN要求を送信します。覚えているように、ホストからのIN要求とコントローラー割り込みは疎結合であるため、応答をep0トランスミッターバッファーにすぐに書き込みます。理論的には、この記述子および他のすべての記述子からのデータは特定のデバイスに関連付けられているため、ライブラリのコアに配置することは意味がありません。対応するリクエストはusb_class_get_std_descr関数に渡されます。この関数は、データの先頭とそのサイズへのポインターをカーネルに返します。重要なのは、一部の記述子は可変サイズである可能性があるということです。しかし、DEVICE_DESCRIPTORはそれらの1つではありません。そのサイズと構造は標準化されており、次のようになります。

uint8_t bLength; // 
uint8_t bDescriptorType; // .    USB_DESCR_DEVICE (0x01)
uint16_t bcdUSB; // 0x0110  usb-1.1,  0x0200  2.0.     
uint8_t bDeviceClass; // 
uint8_t bDeviceSubClass; //
uint8_t bDeviceProtocol; //
uint8_t bMaxPacketSize0; // ep0
uint16_t idVendor; // VID
uint16_t idProduct; // PID
uint16_t bcdDevice_Ver; //  BCD-
uint8_t iManufacturer; //   
uint8_t iProduct; //   
uint8_t iSerialNumber; //  
uint8_t bNumConfigurations; //  (   1)

まず、最初の2つのフィールド（記述子のサイズとそのタイプ）に注意してください。それらはほとんどすべてのUSB記述子に典型的です（おそらくHIDを除く）。さらに、bDescriptorTypeが定数の場合、bLengthは記述子ごとにほぼ手動でカウントする必要があります。ある時点で、私はこれに飽きて、マクロが書かれました

#define ARRLEN1(ign, x...) (1+sizeof((uint8_t[]){x})), x

渡された引数のサイズを計算し、最初の引数の代わりに置き換えます。実際には、記述子がネストされている場合があります。たとえば、1つは最初のバイトに、もう1つは3と4（16ビットの数値）に、3つ目は6と7（16ビットの数値）にサイズが必要です。。マクロは引数の正確な値を気にしませんが、少なくとも数は同じである必要があります。実際には、1、3、4、および6バイトと7バイトの置換用のマクロもありますが、より一般的な例を使用してそれらのアプリケーションを示します。

とりあえず、VIDやPIDのような16ビットフィールドを見てみましょう。 1つの配列に8ビットと16ビットの定数を混在させても機能しないことは明らかです。さらにエンディアン...一般に、マクロが再び役に立ちます：USB_U16（x）。

VIDの選択に関して：PIDは難しい質問です。大量生産を計画している場合でも、個人用のペアを購入する価値があります。個人的な使用のために、あなたは同様のデバイスから他の誰かを拾うことができます。私の例では、AVRLUFAとSTMのペアがあるとしましょう。とにかく、ホストはこのペアからの割り当てではなく、特定の実装バグを決定します。デバイスの目的は特別な記述子で詳細に説明されているためです。

注意、熊手！結局のところ、Windowsはドライバーをこのペアにバインドします。つまり、たとえば、HIDデバイスを組み立て、システムを表示し、ドライバーをインストールしました。次に、VID：PIDを変更せずにMSD（フラッシュドライブ）でデバイスを再フラッシュすると、ドライバーは古いままになり、当然、デバイスは機能しなくなります。「ハードウェア管理」に入り、ドライバーを削除して、システムに新しいドライバーを見つけさせる必要があります。Linuxにこの問題がないことは誰にとっても驚くことではないと思います。デバイスはプラグインして動作するだけです。

StringDescriptor

USB記述子のもう1つの興味深い機能は、文字列が大好きなことです。記述子テンプレートでは、iSerialNumber~~やiPhone~~などのiプレフィックスで示されます。 ..。これらの行は多くの記述子に含まれていますが、率直に言って、なぜそれほど多くの行があるのかわかりません。さらに、デバイスが接続されている場合、iManufacturer、iProduct、およびiSerialNumberのみが表示されます。とはいえ、文字列は同じ記述子です（つまり、bLengthフィールドとbDescriptorTypeフィールドが存在します）が、追加の構造の代わりに、16ビットのUnicodeのような文字のストリームがあります。このような名前は通常英語で与えられ、8ビットASCIIで十分なので、この倒錯の意味は私には理解できません。さて、拡張文字セットが必要なので、UTF-8が使用されます。奇妙な人々...文字列を便利に形成するには、マクロを使用すると便利です。しかし、今回は私のデザインではなく、EddyEmからのスパイです。文字列は記述子であるため、ホストは通常の記述子として文字列を要求します。wValueフィールドでのみ、0x0300（STRING_DESCRIPTOR）に置き換えられます。そして、最下位バイトの代わりに、実際の文字列インデックスがあります。たとえば、クエリ0x0300はインデックス0の文字列であり（デバイス言語用に予約されており、ほとんどの場合u "\ x0409"と同じです）、クエリ0x0302はインデックス2の文字列です。

注意、熊手！文字列だけをiSerialNumberに貼り付けたいという誘惑がどれほど大きくても、u``1.2.3 ''のような正直なバージョンの文字列であっても- しないでください！一部のオペレーティングシステムは、16進数、つまり「0」〜「9」、「A」〜「Z」のみが必要であると考えており、それだけです。ドットすらできません。おそらく、彼らは再接続するときにそれを識別するために、どういうわけかこの「番号」からハッシュを数えます、私は知りません。しかし、Windows 7を搭載した仮想マシンでテストしたときに、このような問題に気づきました。彼女はデバイスに欠陥があると考えました。興味深いことに、WindowsXPと10は問題に気づきませんでした。

ConfigurationDescriptor

ホストの観点からは、デバイスは一連の個別のインターフェイスを表し、それぞれが何らかの問題を解決するように設計されています。インターフェイス記述子は、そのデバイスと関連するエンドポイントを記述します。はい、エンドポイントはそれ自体では記述されませんが、インターフェースの一部としてのみ記述されます。通常、複雑なアーキテクチャのインターフェイスは、SETUP要求によって（つまり、ep0を介して）制御されます。この要求では、wIndexフィールドがインターフェイス番号に対応します。最大値は、割り込みのためにエンドポイントをポケットに入れることができます。また、データインターフェイスから、ホストはエンドポイントの説明のみを必要とし、交換はそれらを通過します。

1つのデバイスには多くのインターフェースがあり、非常に異なるインターフェースが存在する可能性があります。したがって、あるインターフェイスが終了し、別のインターフェイスが開始する場所を混乱させないために、記述子は「ヘッダー」のサイズだけでなく、インターフェイスのフルサイズも個別に（通常は3〜4バイト）示します。したがって、インターフェイスは入れ子人形のように折りたたまれます。共通のコンテナ（「タイトル」のサイズ、bDescriptorType、およびタイトルを含むコンテンツのフルサイズを格納する）内に、いくつかの小さなコンテナを配置できますが、同じ方法。そしてますます内部。プリミティブHIDデバイスの記述子の例を次に示します。


static const uint8_t USB_ConfigDescriptor[] = {
  ARRLEN34(
  ARRLEN1(
    bLENGTH, // bLength: Configuration Descriptor size
    USB_DESCR_CONFIG,    //bDescriptorType: Configuration
    wTOTALLENGTH, //wTotalLength
    1, // bNumInterfaces
    1, // bConfigurationValue: Configuration value
    0, // iConfiguration: Index of string descriptor describing the configuration
    0x80, // bmAttributes: bus powered
    0x32, // MaxPower 100 mA
  )
  ARRLEN1(
    bLENGTH, //bLength
    USB_DESCR_INTERFACE, //bDescriptorType
    0, //bInterfaceNumber
    0, // bAlternateSetting
    0, // bNumEndpoints
    HIDCLASS_HID, // bInterfaceClass: 
    HIDSUBCLASS_NONE, // bInterfaceSubClass: 
    HIDPROTOCOL_NONE, // bInterfaceProtocol: 
    0x00, // iInterface
  )
  ARRLEN1(
    bLENGTH, //bLength
    USB_DESCR_HID, //bDescriptorType
    USB_U16(0x0101), //bcdHID
    0, //bCountryCode
    1, //bNumDescriptors
    USB_DESCR_HID_REPORT, //bDescriptorType
    USB_U16( sizeof(USB_HIDDescriptor) ), //wDescriptorLength
  )
  )
};

ここでは、ネストレベルが小さく、エンドポイントが1つも記述されていないため、より単純なデバイスを選択しようとしました。ここでの混乱は、8ビットと16ビットのゼロに等しいbLENGTH定数とwTOTALLENGTH定数によって引き起こされる可能性があります。この場合、マクロを使用してサイズを計算するため、マクロを複製して手作業でバイトをカウントするのはおかしいでしょう。ゼロを書くのはなんて奇妙なことでしょう。また、定数は注目に値するものであり、コードの明確さに貢献しています。

ご覧のとおり、この記述子は、USB_DESCR_CONFIG「ヘッダー」（それ自体を含むコンテンツのフルサイズを保存します！）、USB_DESCR_INTERFACEインターフェイス（デバイスの詳細を記述します）、およびUSB_DESCR_HIDで構成されます。レンダリングしています。そして、正確に言えば、特定のHID構造は、特別な記述子HID_REPORT_DESCRIPTORで記述されます。これは、私があまりにもよく知っているという理由だけで、ここでは考慮しません。したがって、いくつかの例からコピーアンドペーストに制限します。

インターフェイスに戻りましょう。それらには番号があることを考えると、1つのデバイスに多くのインターフェースが存在する可能性があると想定するのは論理的です。さらに、1つの一般的なタスク（たとえば、USB-CDC制御インターフェイスとデータインターフェイス）と、基本的に無関係なタスクの両方を担当することができます。たとえば、1つのコントローラーで2つのUSB-CDCアダプターとUSBフラッシュドライブに加えて、たとえばキーボードを実装することを妨げるものは何もありません（これまでの知識が不足していることを除いて）。明らかに、フラッシュドライブのインターフェイスはCOMポートを認識していません。ただし、ここには落とし穴があり、いつか検討することを願っています。また、1つのインターフェイスで、エンドポイントの数やポーリングの頻度などが異なる複数の代替構成（bAlternateSetting）を使用できることにも注意してください。実際、それが行われた理由です。ホストが帯域幅を節約する方が良いと考えた場合、彼はインターフェースを彼が最も好きな代替モードに切り替えることができます。

HIDとの通信

一般的に、HIDデバイスは、測定または設定できる特定のパラメーターのセット（SET_REPORT / GET_REPORT要求）ほど多くのデータを持たず、突然の外部イベント（INTERRUPT）についてホストに通知できる実世界のオブジェクトをシミュレートします。したがって、実際には、これらのデバイスはデータ交換を目的としていません...しかし、誰がいつそれを停止したのですか？

割り込みには特別なエンドポイントが必要なので、ここでは割り込みについては触れません。ただし、パラメータの読み取りと設定を検討します。この場合、パラメーターは1つだけです。これは、2バイトの構造であり、設計上、2つのLED、またはボタンとカウンターを担当します。

より単純なものから始めましょう-リクエストHIDREQ_GET_REPORTで読み取ります。実際、これはDEVICE_DESCRIPTORと同じリクエストであり、HIDにのみ固有です。さらに、この要求はデバイス全体ではなく、インターフェイスに送信されます。つまり、1つのデバイスに複数の独立したHIDデバイスを実装した場合、それらはリクエストのwIndexフィールドで区別できます。確かに、これは特にHIDに最適なアプローチではありません。記述子自体を複合化する方が簡単です。いずれにせよ、私たちはそのような倒錯からはほど遠いので、ホストが何をどこに送信しようとしたかを分析することさえしません。インターフェースへのリクエストについて、bRequestフィールドがHIDREQ_GET_REPORTに等しい場合、実際のデータを返します。理論的には、このアプローチは記述子（すべてのbLengthとbDescriptorTypeを含む）を返すことを目的としていますが、HIDの場合、開発者はすべてを単純化し、データのみを交換することにしました。したがって、構造とそのサイズへのポインタを返します。さて、処理ボタンやリクエストカウンターのような少し追加のロジック。

より複雑なケースは、書き込み要求です。 SETUPリクエストで追加データに遭遇するのはこれが初めてです。つまり、ライブラリのコアは最初にリクエスト自体を読み取り、次にデータを読み取る必要があります。そして、それらをユーザー関数に転送します。また、バッファがないことをお知らせします。いくつかの低レベルの魔法の結果として、次のアルゴリズムが開発されました。コールバックは常に呼び出されますが、データがエンドポイント受信バッファーにあるバイト（オフセット）とこのデータのサイズ（サイズ）を通知します。つまり、リクエスト自体が受信されると、オフセットとサイズの値はゼロになります（データはありません）。最初のパケットが受信されたとき、オフセットはまだゼロであり、サイズは受信されたデータのサイズです。 2番目の場合、オフセットはep0のサイズに等しくなり（データを分割する必要がある場合は、エンドポイントのサイズに従って分割するため）、サイズは受信したデータのサイズに等しくなります。等。 重要！データが受け入れられた場合は、それを読み取る必要があります。これは、ハンドラーがusb_ep_read（）を呼び出して1を返す（「自分で考えたので、気にしないでください」）か、単に0（「このデータは必要ありません」）を読み取らずに返すことで実行できます。次に、ライブラリコアがクリーニングを処理します。この関数はこの原則に基づいて構築されています。データが利用可能かどうかを確認し、利用可能な場合はそれを読み取り、LEDを点灯させます。

データ交換ソフトウェア

ここで私は車輪の再発明をしませんでしたが、前の記事から既製のプログラムを取りました。

結論

実際、それがすべてです。 STM32のハードウェアモジュールを使用してUSBを操作する基本を説明しましたが、レーキにも触れました。 STMCubeが生成するホラーよりもはるかに少ない量のコードを考慮すると、それを理解するのは簡単です。実のところ、私はまだキューブヌードルでそれを理解していません、異なる組み合わせで同じものの呼び出しが多すぎます。私が始めたEddyEmのオプションを理解するのにはるかに優れています。もちろん、わき柱がないわけではありませんが、少なくとも理解には適しています。私はまた、私のバージョンのサイズがSTのサイズのほぼ5分の1であることを誇っています（14に対して約2.7 kB）-私は最適化に関与していないという事実にもかかわらず、確かに、それを縮小することができます。

また、疑わしい機器を接続する際のさまざまなオペレーティングシステムの動作の違いにも注意したいと思います。 Linuxは、記述子にエラーがあっても機能します。 Windows XP、7、10、わずかなエラーで、彼らは「デバイスが壊れている、私はそれを扱うことを拒否する」と誓う。そして、XPはBSODでも憤慨することがありました。ああ、そうです、彼らは常に「デバイスはより速く動作することができます」と表示します、私はそれについて何をすべきかわかりません。一般に、Linuxが開発にどれほど優れていても、許しすぎて、ユーザーフレンドリーでないシステムでテストする必要があります。

さらなる計画：他のタイプのエンドポイントを検討してください（これまでのところ、コントロールのみの例がありました）。他のコントローラーを検討してください（たとえば、私はまだat90usb162（AVR）とgd32vf103（RISC_V）を使用しています）が、これらは非常に遠い計画です。同じHIDのような個々のUSBデバイスを詳しく調べることもできますが、優先タスクではありません。

レジスタ上のUSB：STM32L1 / STM32F1