👨🏼‍💼 🖊️ 🏳️ STM32 HAL上のCDC + MSC USB複合デバイス 🔚 😨 👩‍🏭

少なくとも半分の読者が記事のタイトルの少なくとも半分を解読できると信じたい:)誰が知らないのか-私は説明する。私のデバイスは、一度に2つのUSB機能を実装する必要があります。

大容量記憶装置 （別名大容量記憶クラス-MSC ）。デバイスに通常のフラッシュドライブのふりをして、SDカードにあるデータを含むファイルを提供してほしい。
もう1つの機能は仮想COMポートです （USB用語では、 通信デバイスクラス-CDCとも呼ばれます）。このチャネルを通じて、私は通常の端末で見るのに便利な、あらゆる種類の借方記入の結論を持っています。

USBを使用したほとんどの例では、USBフラッシュドライブ、マウス、カスタムHIDデバイス、または仮想COMポートという1種類のデバイスのみが実装されています。しかし、少なくとも2つの関数を同時に実装する方法の健全な説明を見つけることはそれほど簡単ではありませんでした。私の記事では、このギャップを埋めたいと思います。

STM32マイクロコントローラーに基づいた複合USBデバイスの作成について説明しますが、アプローチ自体は他のマイクロコントローラーにも適用できます。記事では、各クラスを個別に詳細に分析するとともに、複合デバイスを構築する原理についても分析します。しかし、まず最初に。

さあ、行こう！

理論のビット

USBインターフェースは非常に複雑で、マルチレベルで多面的です。急降下すれば、圧倒されることはありません。記事の1つ（ただし、忘れていました）では、「この記事を2回読んでから朝にもう一度」というスタイルのフレーズを見ました。はい、彼はそのようです、あなたはそれを最初に行うことができなくなります。個人的に、私のインターフェースは多かれ少なかれ、数ヶ月の活発な掘削と読書の仕様の後にのみレイアウトされています。

私はまだUSBの専門家ではないので、何が起こっているのかをより詳しく説明する記事を参照することをお勧めします。私は最も重要な場所を指摘し、それがどのように機能するかを簡単に説明するだけです。まず第一に、 USBの簡単な説明（翻訳）とUSB Made Simpleをお勧めします（自分で読んでいませんが、多くの人がお勧めします）。 USBデバイスの特定のクラスの仕様も必要になります。

おそらく、USBインターフェースで最も重要なのはハンドルです。より正確には、記述子パッケージですらあります。デバイスがバスに接続すると、ホストはデバイスの機能、交換レート、ポーリング頻度、デバイスが実装するインターフェースなどを記述するデバイス記述子を要求します。ハンドルは重要で非常にデリケートなものです-1バイトのミスでもデバイスが動作しなくなります。

デバイスは、さまざまなタイプのいくつかの記述子を使用して自身を記述します。

デバイス記述子 - デバイス全体、デバイスの名前、製造元、シリアル番号について説明します。文字列データは、個別の文字列記述子（文字列記述子）によって記述されます
構成記述子 —デバイスは1つ以上の構成を持つことができます。各構成は、デバイスとの通信速度、インターフェースのセット、および電力設定を決定します。そのため、たとえば、バッテリー電源で動作するラップトップは、デバイスに低い交換レートを使用して（ラップトップバッテリーではなく）独自の電源に切り替えるようにデバイスに要求する（構成を選択する）場合があります。もちろん、これはデバイスがそのような構成を提供する場合にのみ機能します。
インターフェース記述子 -デバイスとの通信のインターフェースを記述します。いくつかのインターフェースがあります。たとえば、さまざまな機能（MSC、CDC、HID）がインターフェースを実装します。一部の機能（CDCやDFUなど）は、作業のために一度に複数のインターフェイスを実装します。複合デバイスの場合、異なる機能からの複数のインターフェースを一度に実装し、それらを相互に連携させる必要があります。
記述子エンドポイント（エンドポイント記述子） -特定のインターフェイス内の通信チャネルを説明し、パケットサイズを設定し、割り込みのパラメーターを説明します。エンドポイントを使用して、データを送受信します。
特定のインターフェースの個々の側面を説明するさまざまな記述子がたくさんあります。

ホストは、単一のバイトストリームで記述子を要求します。記述子が同じ構成内で特定の順序になることは非常に重要です。そうしないと、ホストはどの記述子が何のためにあるか混乱します。各構成は、構成記述子と、インターフェースを記述する記述子のセットで構成されます。各インターフェイスは、インターフェイス記述子とエンドポイント記述子のセットによって記述されます。各エンティティは、その記述子を近くに運びます。

また、USBはホスト指向のプロトコルであることも理解する必要があります。デバイスの構成、受信、送信-USBのすべてはホストによって制御されます。私たちにとって、これはマイクロコントローラーの側面からの制御フローがないことを意味します-すべてのUSB作業は割り込みとコールバックに基づいています。また、これは、長時間の操作を開始したくないことを意味し、他の割り込みと相互作用するときは（優先度を考慮するなど）、非常に注意する必要があります。ただし、このような低レベルに落ちないようにしてください。

また、ホストの方向も関数の名前で明示されます。 USBの用語では、ホストからデバイスへの方向はOUTと呼ばれますが、コントローラーの場合、これは手法です。逆に、デバイスからホストへの方向はINと呼ばれますが、私たちにとってこれはデータの送信を意味します。したがって、マイクロコントローラーでは、DataOut（）関数が実際にデータを受信し、DataIn（）がデータを送信します。しかし、これはそうです、ところで-既製のコードを使用します。

CDC-仮想COMポート

おそらく複合デバイス全体を取り出してすぐにキャストしても機能しません-ニュアンスと落とし穴が多すぎます。各インターフェイスを個別にデバッグしてから、複合デバイスに移行する方が良いと思います。私はCDCから始めます依存関係は必要ありません。

私は最近STM32キューブに移動しました-STM32用の低レベルドライバーのパッケージです。特定のクラスのUSBデバイスを実装したUSB管理コードが含まれています。 USBコアとCDCのテンプレート実装を使用して、自分で鋸引きを開始します。ブランクは、\ Middlewares \ ST \ STM32_USB_Device_Libraryディレクトリーにあります。 STM32F1シリーズコントローラーにはCubeを使用し、Cubeバージョン1.6（2017年4月）、バンドルされたUSBライブラリバージョン2.4.2（2015年12月）

ライブラリのテンプレート実装には、テンプレートと呼ばれるファイルに独自のコードを記述することが含まれます。ライブラリ全体とUSBの原理を理解しないと、これを行うのは困難です。しかし、簡単になります-CubeMXグラフィカルコンフィギュレータを使用してこれらのファイルを生成します。

CubeMXが提供する実装は、すぐに使用できる状態です。コードを書く必要がなかったのは少し残念です。完全に完成した実装の例を使用して、CDCを研究する必要があります。生成されたコードの中で最も興味深い場所を見てみましょう。

最初に、usbd_desc.c（デバイス記述子）およびusbd_cdc.c（構成記述子、インターフェース、エンドポイント）ファイルにある記述子を調べます。一言で言えばusb （ロシア語）には、すべての記述子の非常に詳細な説明があります。各フィールドを個別に説明するのではなく、最も重要で興味深いフィールドのみに焦点を当てます。

デバイス記述子

#define USBD_VID 1155 #define USBD_LANGID_STRING 1033 #define USBD_MANUFACTURER_STRING "STMicroelectronics" #define USBD_PID_FS 22336 #define USBD_PRODUCT_STRING_FS "STM32 Virtual ComPort" #define USBD_SERIALNUMBER_STRING_FS "00000000001A" #define USBD_CONFIGURATION_STRING_FS "CDC Config" #define USBD_INTERFACE_STRING_FS "CDC Interface" #define USBD_MAX_NUM_CONFIGURATION 1 /* USB Standard Device Descriptor */ __ALIGN_BEGIN uint8_t USBD_FS_DeviceDesc[USB_LEN_DEV_DESC] __ALIGN_END = { 0x12, /*bLength */ USB_DESC_TYPE_DEVICE, /*bDescriptorType*/ 0x00, /* bcdUSB */ 0x02, 0x02, /*bDeviceClass*/ 0x02, /*bDeviceSubClass*/ 0x00, /*bDeviceProtocol*/ USB_MAX_EP0_SIZE, /*bMaxPacketSize*/ LOBYTE(USBD_VID), /*idVendor*/ HIBYTE(USBD_VID), /*idVendor*/ LOBYTE(USBD_PID_FS), /*idVendor*/ HIBYTE(USBD_PID_FS), /*idVendor*/ 0x00, /*bcdDevice rel. 2.00*/ 0x02, USBD_IDX_MFC_STR, /*Index of manufacturer string*/ USBD_IDX_PRODUCT_STR, /*Index of product string*/ USBD_IDX_SERIAL_STR, /*Index of serial number string*/ USBD_MAX_NUM_CONFIGURATION /*bNumConfigurations*/ } ; /* USB_DeviceDescriptor */

ここでは、次のフィールドに興味があります。

bDeviceClass、bDeviceSubClass、bDeviceProtocol-ホストにどのような種類のデバイスがあり、何ができるのか、どのドライバーをロードするのかをホストに説明します。この場合、デバイスはCommunication Device Classを実装していると言います。つまり、ホストは仮想COMポートを作成し、このデバイスに接続する必要があります。
PID（製品ID）およびVID（ベンダーID）-これらのフィールドでは、ホストはシステムに接続されているさまざまなデバイスを区別します。同時にデバイスは同じクラスを実装します。彼らは、市場で販売されているデバイスの場合、一意のVID / PIDを持つことが非常に重要であると言いますが、これらのIDが誰とどこで提供されるのかはわかりませんでした。単一コピーのホームデバイスの場合、デフォルト値で十分です。

文字列定数（デバイス名、シリアル番号）は記述子自体には書き込まれないことに注意してください。行は個別の記述子で記述され、残りはすべて行のインデックスのみを示します。 STのライブラリの場合、文字列記述子はオンザフライ（grrrrrr）で生成されるため、説明しません。

構成記述子

 __ALIGN_BEGIN const uint8_t USBD_CDC_CfgHSDesc[USB_CDC_CONFIG_DESC_SIZ] __ALIGN_END = { /*Configuration Descriptor*/ 0x09, /* bLength: Configuration Descriptor size */ USB_DESC_TYPE_CONFIGURATION, /* bDescriptorType: Configuration */ USB_CDC_CONFIG_DESC_SIZ, /* wTotalLength:no of returned bytes */ 0x00, 0x02, /* bNumInterfaces: 2 interface */ 0x01, /* bConfigurationValue: Configuration value */ 0x00, /* iConfiguration: Index of string descriptor describing the configuration */ 0xC0, /* bmAttributes: self powered */ 0x32, /* MaxPower 100 mA */

ここでは、次のことに興味があります。

wTotalLength-この構成の記述子パッケージ全体のサイズ-ホストは、この構成がどこで終了して次の構成が始まるかを知ることができます。複合デバイスを作成するときに修正する必要があります。この構成のすべてのインターフェイスはソリッドブロックである必要があり、値wTotalLengthがこのブロックの長さを決定することを思い出させてください。
bNumInterfaces：通信デバイスクラスは、2つのインターフェイスを使用して実装されます。 1つは管理用、もう1つは送信される実際のデータ用です。
bmAttributesとMaxPowerは、デバイスが独自の電源を持っているが、同時にUSBポートから最大100 mAを消費したいことを示しています。これらのパラメーターは、将来的に明らかに再生する必要があります。

次に、最初のCDCインターフェイスへのハンドルが来ます。このクラスのデバイスは、いくつかの異なる通信モデル（電話、直接接続、多国間接続）を実装できますが、この場合は抽象制御モデルになります。

CDC管理インターフェイスハンドル

 /*Interface Descriptor */ 0x09, /* bLength: Interface Descriptor size */ USB_DESC_TYPE_INTERFACE, /* bDescriptorType: Interface */ /* Interface descriptor type */ 0x00, /* bInterfaceNumber: Number of Interface */ 0x00, /* bAlternateSetting: Alternate setting */ 0x01, /* bNumEndpoints: One endpoints used */ 0x02, /* bInterfaceClass: Communication Interface Class */ 0x02, /* bInterfaceSubClass: Abstract Control Model */ 0x01, /* bInterfaceProtocol: Common AT commands */ 0x00, /* iInterface: */

このインターフェースには、1つのエンドポイント（bNumEndpoints）のみが存在します。しかし、最初に一連の機能記述子-このクラスのデバイスに固有の設定があります。

機能記述子

  /*Header Functional Descriptor*/ 0x05, /* bLength: Endpoint Descriptor size */ 0x24, /* bDescriptorType: CS_INTERFACE */ 0x00, /* bDescriptorSubtype: Header Func Desc */ 0x10, /* bcdCDC: spec release number */ 0x01, /*Call Management Functional Descriptor*/ 0x05, /* bFunctionLength */ 0x24, /* bDescriptorType: CS_INTERFACE */ 0x01, /* bDescriptorSubtype: Call Management Func Desc */ 0x00, /* bmCapabilities: D0+D1 */ 0x01, /* bDataInterface: 1 */ /*ACM Functional Descriptor*/ 0x04, /* bFunctionLength */ 0x24, /* bDescriptorType: CS_INTERFACE */ 0x02, /* bDescriptorSubtype: Abstract Control Management desc */ 0x02, /* bmCapabilities */ /*Union Functional Descriptor*/ 0x05, /* bFunctionLength */ 0x24, /* bDescriptorType: CS_INTERFACE */ 0x06, /* bDescriptorSubtype: Union func desc */ 0x00, /* bMasterInterface: Communication class interface */ 0x01, /* bSlaveInterface0: Data Class Interface */

私たちのデバイスは（電話をかけるという意味で）「呼び出し」の概念を知らないが、同時にコマンドラインパラメーター（速度、ストップビット、DTR / CTSビット）を理解していると言います。最後の記述子は、2つのCDCインターフェースのどちらがコントロールであるか、およびデータが実行される場所を記述します。一般に、ここでは何にも興味がなく、何も変更しません。

最後に、制御インターフェースのエンドポイント記述子

  /*Endpoint 2 Descriptor*/ 0x07, /* bLength: Endpoint Descriptor size */ USB_DESC_TYPE_ENDPOINT, /* bDescriptorType: Endpoint */ CDC_CMD_EP, /* bEndpointAddress */ 0x03, /* bmAttributes: Interrupt */ LOBYTE(CDC_CMD_PACKET_SIZE), /* wMaxPacketSize: */ HIBYTE(CDC_CMD_PACKET_SIZE), 0x10, /* bInterval: */

このエンドポイントは割り込みに使用されると書かれています。ホストは、0x10（16）msごとにデバイスをポーリングし、デバイスに注意が必要かどうかを尋ねます。また、制御チームはこのエンドポイントを通り抜けます。

2番目のインターフェース（データが実行される）の説明はより単純になります。

CDCデータインターフェイスとそのエンドポイント

 /*Data class interface descriptor*/ 0x09, /* bLength: Endpoint Descriptor size */ USB_DESC_TYPE_INTERFACE, /* bDescriptorType: */ 0x01, /* bInterfaceNumber: Number of Interface */ 0x00, /* bAlternateSetting: Alternate setting */ 0x02, /* bNumEndpoints: Two endpoints used */ 0x0A, /* bInterfaceClass: CDC */ 0x00, /* bInterfaceSubClass: */ 0x00, /* bInterfaceProtocol: */ 0x00, /* iInterface: */ /*Endpoint OUT Descriptor*/ 0x07, /* bLength: Endpoint Descriptor size */ USB_DESC_TYPE_ENDPOINT, /* bDescriptorType: Endpoint */ CDC_OUT_EP, /* bEndpointAddress */ 0x02, /* bmAttributes: Bulk */ LOBYTE(CDC_DATA_HS_MAX_PACKET_SIZE), /* wMaxPacketSize: */ HIBYTE(CDC_DATA_HS_MAX_PACKET_SIZE), 0x00, /* bInterval: ignore for Bulk transfer */ /*Endpoint IN Descriptor*/ 0x07, /* bLength: Endpoint Descriptor size */ USB_DESC_TYPE_ENDPOINT, /* bDescriptorType: Endpoint */ CDC_IN_EP, /* bEndpointAddress */ 0x02, /* bmAttributes: Bulk */ LOBYTE(CDC_DATA_HS_MAX_PACKET_SIZE), /* wMaxPacketSize: */ HIBYTE(CDC_DATA_HS_MAX_PACKET_SIZE), 0x00 /* bInterval: ignore for Bulk transfer */

バルクタイプの2つのエンドポイントがインターフェイスに存在します。1つは受信用、もう1つは送信用です。実際、USBの用語では、これは1つのエンドポイントであり、双方向です。

自分で完全に理解していないという理由だけで（たとえば、ホストがデバイスから取得する必要のあるデータの量をどのように知っているかなど）、すべての仕組みを説明しません。最も重要なことは、ライブラリがすべてを実装していることです。アーキテクチャをよく見てみましょう。

STのUSBライブラリは非常に階層化されています。そのような建築レベルを強調します

クラスドライバー （CDCの場合、これらはusbd_cdcおよびusbd_cdc_ifファイルです）：デバイスの特定のクラスのロジックを実装します-仮想COMポートのCDC、データストレージデバイスのMSC、キーボード/マウスのHID、およびユーザーインターフェイスを備えた特定のデバイス。
USBコア （usbd_core.c、usbd_ctlreq.c、usbd_ioreq.c）：USBデバイスのすべてのクラスの動作の一般的なロジックを実装し、要求された記述子をホストに送信し、ホストからの要求を処理し、USBデバイス全体を構成します。また、データストリームをクラスドライバーレベルから下位レベルに、またはその逆にリダイレクトします。
USB HWドライバー （usbd_conf.c）：上にあるレイヤーはプラットフォームに依存せず、いくつかのマイクロコントローラーシリーズで同じように機能します。コードには、特定のマイクロコントローラー用の低レベル関数呼び出しはありません。 usbd_conf.cファイルは、USBコアと、選択したマイクロコントローラー用の低レベルドライバーのライブラリであるHALの間のレイヤーを実装します。基本的に、呼び出しを上から下にリダイレクトし、コールバックを下から上にリダイレクトする単純なラッパーがあります。
HAL （stm32f1xx_hal_pcd.c、stm32f1xx_ll_usb.c）：マイクロコントローラーハードウェアとの通信に従事し、レジスターで動作し、割り込みに応答します。

この段階では、最上位層とusbd_conf.cの1つの関数のみに関心があります。最後のものから始めましょう：

USBD_LL_Init（）関数

 /** * @brief Initializes the Low Level portion of the Device driver. * @param pdev: Device handle * @retval USBD Status */ USBD_StatusTypeDef USBD_LL_Init (USBD_HandleTypeDef *pdev) { /* Init USB_IP */ /* Link The driver to the stack */ hpcd_USB_FS.pData = pdev; pdev->pData = &hpcd_USB_FS; hpcd_USB_FS.Instance = USB; hpcd_USB_FS.Init.dev_endpoints = 8; hpcd_USB_FS.Init.speed = PCD_SPEED_FULL; hpcd_USB_FS.Init.ep0_mps = DEP0CTL_MPS_8; hpcd_USB_FS.Init.low_power_enable = DISABLE; hpcd_USB_FS.Init.lpm_enable = DISABLE; hpcd_USB_FS.Init.battery_charging_enable = DISABLE; if (HAL_PCD_Init(&hpcd_USB_FS) != HAL_OK) { Error_Handler(); } HAL_PCDEx_PMAConfig((PCD_HandleTypeDef*)pdev->pData , 0x00 , PCD_SNG_BUF, 0x18); HAL_PCDEx_PMAConfig((PCD_HandleTypeDef*)pdev->pData , 0x80 , PCD_SNG_BUF, 0x58); HAL_PCDEx_PMAConfig((PCD_HandleTypeDef*)pdev->pData , 0x81 , PCD_SNG_BUF, 0xC0); HAL_PCDEx_PMAConfig((PCD_HandleTypeDef*)pdev->pData , 0x01 , PCD_SNG_BUF, 0x110); HAL_PCDEx_PMAConfig((PCD_HandleTypeDef*)pdev->pData , 0x82 , PCD_SNG_BUF, 0x100); return USBD_OK; }

この関数は、マイクロコントローラーのUSB周辺機器を初期化します。最も興味深いのは、HAL_PCDEx_PMAConfig（）関数の一連の呼び出しです。実際には、マイクロコントローラのボード上には、USBバッファ専用に割り当てられた512バイトのメモリ全体があります（このメモリはPMA-パケットメモリ領域と呼ばれます）。ただし、デバイスはエンドポイントの数とパラメーターを事前に知らないため、このメモリは割り当てられません。したがって、USBメモリを使用する前に、選択したパラメーターに従って割り当てる必要があります。

しかし、奇妙なことに、2つのエンドポイントだけがアナウンスされ、コールは5でした。実際、不要なものはありません。実際、各USBデバイスには、デバイスを初期化してから制御するための1つの双方向エンドポイントが必要です。このエンドポイントには常に0の番号が付けられます。この関数はエンドポイントを初期化しませんが、バッファーを初期化します。ゼロエンドポイントの場合、2つのバッファが作成されます-受信用の0x00と送信用の0x80（最上位ビットは送信の方向を示し、最下位ビットはエンドポイントの番号を示します）。残りの3つの呼び出しは、エンドポイント1（データの受信と送信）とエンドポイント2（コマンドの受信とステータスの送信-これは同期的に行われるため、バッファーは1つだけです）のバッファーを記述します

各呼び出しの最後のパラメーターは、共有バッファー内のエンドポイントバッファーのオフセットを示します。フォーラムで、「この魔法の定数0x18（最初のバッファーの開始アドレス）とは何ですか？」という質問を見ました。この問題については後で詳しく検討します。 PMAメモリの最初の0x18バイトがバッファ割り当てテーブルによって占有されているとだけ言います。

しかし、これらはすべて内臓とその他の内臓です。そして、外には何がありますか？

ユーザーコードは、usbd_cdc_if.cファイルにある受信および送信関数で動作します。デバイスがホストに向かう仮想COMポートにデータを送信できるように、関数CDC_Transmit_FS（）が提供されました

関数CDC_Transmit_FS（）

 /** * @brief CDC_Transmit_FS * Data send over USB IN endpoint are sent over CDC interface * through this function. * @note * * * @param Buf: Buffer of data to be send * @param Len: Number of data to be send (in bytes) * @retval Result of the operation: USBD_OK if all operations are OK else USBD_FAIL or USBD_BUSY */ uint8_t CDC_Transmit_FS(uint8_t* Buf, uint16_t Len) { uint8_t result = USBD_OK; USBD_CDC_HandleTypeDef *hcdc = (USBD_CDC_HandleTypeDef*)hUsbDeviceFS.pClassData; if (hcdc->TxState != 0){ return USBD_BUSY; } USBD_CDC_SetTxBuffer(&hUsbDeviceFS, Buf, Len); result = USBD_CDC_TransmitPacket(&hUsbDeviceFS); return result; }

受信はもう少し複雑です。データを受信すると、USBコアはCDC_Receive_FS（）関数をプルします。この関数では、受信したデータを処理する独自のコードを追加する必要があります。または、次のように、処理を処理するコールバックを呼び出します。

関数CDC_Receive_FS（）

 /** * @brief CDC_Receive_FS * Data received over USB OUT endpoint are sent over CDC interface * through this function. * * @note * This function will block any OUT packet reception on USB endpoint * untill exiting this function. If you exit this function before transfer * is complete on CDC interface (ie. using DMA controller) it will result * in receiving more data while previous ones are still not sent. * * @param Buf: Buffer of data to be received * @param Len: Number of data received (in bytes) * @retval Result of the operation: USBD_OK if all operations are OK else USBD_FAIL */ static int8_t CDC_Receive_FS (uint8_t* Buf, uint32_t *Len) { uint16_t len = *Len; CDCDataReceivedCallback(Buf, len); // Prepare for next reception USBD_CDC_ReceivePacket(&hUsbDeviceFS); return (USBD_OK); }

これらの関数は、構造のないバイト配列で機能することに注意してください。私の場合、文字列を送信する必要がありました。これを便利にするために、文字列をフォーマットしてポートに送信するprintf関数の類似物を作成しました。速度を上げるために、ダブルバッファリングにも困惑しました。詳細については、「USBのダブルバッファリング」および「printf」のセクションを参照してください。

同じファイルには、仮想COMポートの初期化/非初期化機能、およびポートパラメーター（速度、パリティ、ストップビットなど）を変更する機能も含まれています。デフォルトの実装では速度が制限されず、私に適しています。初期化も同様に良好です。そのままにしておきます。

最終的なバーコードは、すべてを実行するコードです。

すべてを実行するコード

  USBD_Init(&hUsbDeviceFS, &FS_Desc, DEVICE_FS); USBD_RegisterClass(&hUsbDeviceFS, &USBD_CDC); USBD_CDC_RegisterInterface(&hUsbDeviceFS, &USBD_Interface_fops_FS); USBD_Start(&hUsbDeviceFS);

ここで、異なるドライバレベルが初期化されます。最後のコマンドにはUSB割り込みが含まれます。 USBでのすべての作業は、ホストからの要求に応じて行われることを理解することが重要です。この場合、ドライバー内部で割り込みが呼び出され、ドライバー自体がリクエストを処理するか、コールバックを介して別のコードに委任します。

これが機能するには、オペレーティングシステムのドライバーが必要です。原則として、これは標準ドライバーであり、システムは特別なインストール手順なしでデバイスを取得できます。私の知る限り、STMの仮想COMポートドライバー（ST Flash Utilityで提供）は既にシステムにインストールされており、デバイスはそれ自体でピックアップされています。 Linuxでも、すべてがハーフキックで始まりました。

MSC-ストレージデバイス

CDCドライバーを使用すると、すべてが簡単になりました。原則として、デバイス自体がデータの最終消費者（たとえば、ホストからコマンドを受信）またはジェネレーター（たとえば、センサー読み取り値をホストに送信）です。

大容量記憶クラスはもう少し複雑になります。 MSCドライバーは、一方ではホストとUSBバス、もう一方ではストレージデバイスの間の単なるレイヤーです。 SDIO、SPIフラッシュ、RAMドライブ、ディスクドライブ、またはネットワークドライブを介して接続されたSDカードを使用できます。一般に、ほとんどの場合、ストレージデバイスは特定のドライバー（通常は重要ではない）で表され、MSCの実装とドッキングする必要があります。

私のデバイスは、SPIで接続されたSDカードを使用しています。このマップ上のファイルにアクセスするには、 SdFatライブラリを使用します。また、いくつかの抽象化レベルに分けられます。

ユーザーにはFileクラスが提供されます。このクラスを使用して、ファイルの作成/オープン、データの読み取りおよび書き込みを行うことができます。クライアントコードは、記憶媒体とのやり取りやファイルシステムの微妙な違いによって増大することはありません。
Volumeクラスは、ファイルシステム、ディレクトリ、クラスター、FATなどを処理するためのキッチン全体を処理します。データキャリアとの通信は下位レベルに委任されます。
SDカードドライバー-このコンポーネントは、カードとの通信方法、送信するコマンド、および応答を聞くコマンドを認識しています。このライブラリは、SPIおよびSDIOを介して接続されたカード用にいくつかのタイプのドライバーを提供します。理論的には、たとえばRAMディスクの代わりにドライバーを使用できます。
その上にあるレイヤーはクロスプラットフォームであり、データがカードにどのように正確に書き込まれるか、またはそこから読み取られるかについては何も知りません。これにより、異なるプラットフォーム（Arduinoとその他の両方）のライブラリを構築できます。特定のプラットフォームまたはマイクロコントローラー用に、必要なインターフェースを介したデータ転送を実装するドライバーを作成できます。デフォルトでは、ライブラリは以下を含むいくつかのドライバーを提供します Arduino SPI向けですが、混乱し、HALに基づいたDMA伝送を介して~~、好みと詩人で~~ドライバーを書きました。
最後に、HALは特定のマイクロコントローラーのレジスターでの作業を提供します

USB大容量ストレージの場合、USBフラッシュドライブ上のファイルを操作しません。ホストがファイルシステムの解釈に関するすべての作業を行います。デバイスは、特定のデータブロックの読み取りまたは書き込み要求を受け取ります。したがって、マップドライバー以下のレベルに興味があります。

MSCの実装には、ストアからの特定のインターフェイスが必要です。読み取りと書き込みが可能で、サイズとステータスを提供するためです。 SdFatライブラリのSDカードドライバーインターフェイスによって、ほぼ同じ機能が提供されます。あるインターフェースを別のインターフェースに導くアダプターを書くことだけが残っています。

移動の方向を決めました。実装に取り組みましょう。私は再びCubeMXコンフィギュレーターを使用し、USBコンポーネントに必要なファイルを生成しました。もちろん、記述子から研究を開始します。

デバイス記述子

 * USB Standard Device Descriptor */ __ALIGN_BEGIN uint8_t USBD_FS_DeviceDesc[USB_LEN_DEV_DESC] __ALIGN_END = { 0x12, /*bLength */ USB_DESC_TYPE_DEVICE, /*bDescriptorType*/ 0x00, /* bcdUSB */ 0x02, 0x00, /*bDeviceClass*/ 0x00, /*bDeviceSubClass*/ 0x00, /*bDeviceProtocol*/ USB_MAX_EP0_SIZE, /*bMaxPacketSize*/ LOBYTE(USBD_VID), /*idVendor*/ HIBYTE(USBD_VID), /*idVendor*/ LOBYTE(USBD_PID_FS), /*idVendor*/ HIBYTE(USBD_PID_FS), /*idVendor*/ 0x00, /*bcdDevice rel. 2.00*/ 0x02, USBD_IDX_MFC_STR, /*Index of manufacturer string*/ USBD_IDX_PRODUCT_STR, /*Index of product string*/ USBD_IDX_SERIAL_STR, /*Index of serial number string*/ USBD_MAX_NUM_CONFIGURATION /*bNumConfigurations*/ } ; /* USB_DeviceDescriptor */

デバイス記述子はあまり変更されていません。唯一の違いは、デバイスクラスを定義するフィールドにあります。現在、デバイスクラス全体は定義されていません（bDeviceClassのゼロ）が、インターフェイスレベルで設定されます（これは仕様要件です）。

構成記述子

  0x09, /* bLength: Configuation Descriptor size */ USB_DESC_TYPE_CONFIGURATION, /* bDescriptorType: Configuration */ USB_MSC_CONFIG_DESC_SIZ, 0x00, 0x01, /* bNumInterfaces: 1 interface */ 0x01, /* bConfigurationValue: */ 0x04, /* iConfiguration: */ 0xC0, /* bmAttributes: */ 0x32, /* MaxPower 100 mA */

CDCの類似の記述子と非常に類似-インターフェイスの数（1）とバスからの電力パラメーター（最大100 mA）が決定されます。

インターフェイス記述子

  0x09, /* bLength: Interface Descriptor size */ 0x04, /* bDescriptorType: */ 0x00, /* bInterfaceNumber: Number of Interface */ 0x00, /* bAlternateSetting: Alternate setting */ 0x02, /* bNumEndpoints*/ 0x08, /* bInterfaceClass: MSC Class */ 0x06, /* bInterfaceSubClass : SCSI transparent*/ 0x50, /* nInterfaceProtocol */ 0x05, /* iInterface: */

インターフェイス記述子は、2つのエンドポイント（伝送の各側に1つ）を宣言します。また、ハンドルは、特定の大容量記憶サブクラスがバルク専用転送であるかどうかを決定します。これがどのようなサブクラスであるかを正確に説明する説明は見つかりませんでした。これは、2つのエンドポイントを介した双方向のデータ送信によってのみ通信するデバイスであると想定しています（他のモデルでも割り込みを使用できます）。この通信のプロトコルはSCSIコマンドです。

エンドポイント記述子

  0x07, /*Endpoint descriptor length = 7*/ 0x05, /*Endpoint descriptor type */ MSC_EPIN_ADDR, /*Endpoint address (IN, address 1) */ 0x02, /*Bulk endpoint type */ LOBYTE(MSC_MAX_FS_PACKET), HIBYTE(MSC_MAX_FS_PACKET), 0x00, /*Polling interval in milliseconds */ 0x07, /*Endpoint descriptor length = 7 */ 0x05, /*Endpoint descriptor type */ MSC_EPOUT_ADDR, /*Endpoint address (OUT, address 1) */ 0x02, /*Bulk endpoint type */ LOBYTE(MSC_MAX_FS_PACKET), HIBYTE(MSC_MAX_FS_PACKET), 0x00 /*Polling interval in milliseconds*/

バルクタイプの2つのエンドポイントがここで定義されています-USBインターフェイスは、そのようなエンドポイントでの速度を保証しませんが、データの配信を保証します。パケットサイズは64バイトに設定されます。

エンドポイントについて話しているので、対応するPMAバッファーが決定されるusbd_conf.cファイルを調べる価値があります。

PMAバッファーの調整

 HAL_PCDEx_PMAConfig((PCD_HandleTypeDef*)pdev->pData , 0x00 , PCD_SNG_BUF, 0x18); HAL_PCDEx_PMAConfig((PCD_HandleTypeDef*)pdev->pData , 0x80 , PCD_SNG_BUF, 0x58); HAL_PCDEx_PMAConfig((PCD_HandleTypeDef*)pdev->pData , 0x81 , PCD_SNG_BUF, 0x98); HAL_PCDEx_PMAConfig((PCD_HandleTypeDef*)pdev->pData , 0x01 , PCD_SNG_BUF, 0xD8);

次に、反対側からMSCを見てみましょう。このUSBクラスは、ホストから読み取り/書き込みコマンドを受信し、それらの特殊なインターフェイスUSBD_StorageTypeDefを変換します。実装のみを代用できます。

デバイスインターフェース

 /** @defgroup USB_CORE_Exported_Types * @{ */ typedef struct _USBD_STORAGE { int8_t (* Init) (uint8_t lun); int8_t (* GetCapacity) (uint8_t lun, uint32_t *block_num, uint16_t *block_size); int8_t (* IsReady) (uint8_t lun); int8_t (* IsWriteProtected) (uint8_t lun); int8_t (* Read) (uint8_t lun, uint8_t *buf, uint32_t blk_addr, uint16_t blk_len); int8_t (* Write)(uint8_t lun, uint8_t *buf, uint32_t blk_addr, uint16_t blk_len); int8_t (* GetMaxLun)(void); int8_t *pInquiry; }USBD_StorageTypeDef;

これはC ++ではなくCであるため、これらの各エントリは対応する関数へのポインタです。前述したように、MSCインターフェイスをSDカードインターフェイスに駆動するアダプターを作成する必要があります。

インターフェースの実装を始めましょう。最初は初期化関数です

初期化関数

 int8_t SD_MSC_Init (uint8_t lun) { (void)lun; // Not used // if(!initSD()) // return USBD_FAIL; return (USBD_OK); }

したがって、SDカードは、簡単な操作であれば、ここからすぐに初期化できます。しかし、SDカードの場合、これは常に当てはまるとは限りません。さらに、これらの関数はすべてコールバックであり、USB割り込みから呼び出されることを忘れないでください。また、割り込みを長時間ブロックしないでください。したがって、USBの初期化の前にmain（）からinitSD（）関数を直接呼び出しますが、SD_MSC_Init（）は何もしません

マップの初期化

 SdFatSPIDriver spiDriver; SdSpiCard card; bool initSD() { return card.begin(&spiDriver, PA4, SPI_FULL_SPEED); }

ドライバーが多すぎるように見えるかもしれませんが、アーキテクチャを思い出させてください。SdFatライブラリのSdSpiCardクラスは、SPIを介してSDカードと通信する方法、いつどのコマンドを送信し、何を応答を待つかを知っています。しかし、彼はSPI自体の操作方法を知りません。これらの目的のために、SPIを介したカードとの通信とDMAを介したデータ転送を実装するSdFatSPIDriverクラスを作成しました。

どうぞ

カード音量受信機能

 int8_t SD_MSC_GetCapacity (uint8_t lun, uint32_t *block_num, uint16_t *block_size) { (void)lun; // Not used *block_num = card.cardSize(); *block_size = 512; return (USBD_OK); }

SD_MSC_GetCapacity（）の実装は簡単です-SdSpiCardはマップのサイズをすぐにブロック単位で返すことができます

読み取りおよび書き込み機能

 int8_t SD_MSC_Read (uint8_t lun, uint8_t *buf, uint32_t blk_addr, uint16_t blk_len) { (void)lun; // Not used if(!card.readBlocks(blk_addr, buf, blk_len)) return USBD_FAIL; return (USBD_OK); } int8_t SD_MSC_Write (uint8_t lun, uint8_t *buf, uint32_t blk_addr, uint16_t blk_len) { (void)lun; // Not used if(!card.writeBlocks(blk_addr, buf, blk_len)) return USBD_FAIL; return (USBD_OK); }

読み取りと書き込みも非常に簡単に実装されます。

その他の機能

 int8_t SD_MSC_IsReady (uint8_t lun) { (void)lun; // Not used return (USBD_OK); } int8_t SD_MSC_IsWriteProtected (uint8_t lun) { (void)lun; // Not used return (USBD_OK); // Never write protected }

私たちのカードは常に準備ができており（将来的にはステータスをさらに詳しく調べます）、書き込み保護されていません。

もう一つ

 int8_t SD_MSC_GetMaxLun (void) { return 0; // We have just 1 Logic unit number (LUN) which is zero }

LUN-論理ユニット番号。理論的には、ストレージデバイスは複数のメディアで構成される場合があります（たとえば、RAIDのハードドライブ）。すべてのSCSIプロトコル機能は、使用するメディアを示します。GetMaxLun関数は、最後のデバイスの番号（デバイスの数から1を引いた値）を返します。フラッシュドライブが1つあるため、0を返し

ます。最後のことです。

ストレージ記述子

 const uint8_t SD_MSC_Inquirydata[] = {/* 36 */ /* LUN 0 */ 0x00, 0x80, 0x02, 0x02, (STANDARD_INQUIRY_DATA_LEN - 5), 0x00, 0x00, 0x00, 'S', 'T', 'M', ' ', ' ', ' ', ' ', ' ', /* Manufacturer : 8 bytes */ 'P', 'r', 'o', 'd', 'u', 'c', 't', ' ', /* Product : 16 Bytes */ ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', '0', '.', '0' ,'1' /* Version : 4 Bytes */ };

正直に言うと、なぜそれが必要なのか本当に理解していませんでした。 SCSI仕様を調べると、理解できない多くの意味のあるフィールドを見ました。私が習得したものから、それは直接（シーケンシャルではない）アクセスを備え、取り外し可能（取り外し可能）な標準デバイスについて説明しています。幸いなことに、私が見たすべての例で、この配列は同じですので、そうしてください。結局デバッグされました。

今、これはすべて正しく初期化する必要があります

初期化

  USBD_StatusTypeDef res = USBD_Init(&hUsbDeviceFS, &FS_Desc, DEVICE_FS); USBD_RegisterClass(&hUsbDeviceFS, &USBD_MSC); USBD_MSC_RegisterStorage(&hUsbDeviceFS, &SdMscDriver); USBD_Start(&hUsbDeviceFS);

接続して確認します。非常にゆっくりですが、すべてが機能します-接続されたディスクは約50秒間開きますが、これは、このようなインターフェイスを介したフラッシュドライブの読み取りの線形速度が約200 kb / sであるという事実によるものです。 USB大容量記憶装置がコンピューターに接続されると、オペレーティングシステムはFATテーブルを読み取ります。私は8ギガバイトのフラッシュドライブを使用していますが、FATはすでに7.5メガバイトです。さらに、MBR、ブートセクター、ファイルテーブルを読み取ります。これはほぼ50秒です。

また、SDカードを使用する場合はDMAを無効にする必要がありました-それが含まれているため、それほど単純ではありません。実際、ドライバーの実装（判明したように）は割り込みからは機能せず、USBではすべてが割り込みを介してのみ機能します。ありふれたHAL_Delay（）でも動作しません。また、FreeRTOSを使用した同期は言うまでもなく、割り込みにも関連付けられています。これはやり直す必要がありますが、これは別の話であり、USB複合デバイスには適用されません。やり直すと、必ずそれについての記事を書いて、ここにリンクを残します。

更新：約束どおりここにリンクします。私はなんとか650kb / sまでの速度をポンピングすることができました

CDC + MSC複合デバイス

そして、このすべてのゴミを使って、冗談を飛ばそうとします（C）。

だから、CDCまたはMSCのいずれかを実装できるUSBデバイスを構築する方法を既に知っています。両方のインターフェイスを同時に実装する複合デバイスを作成してみましょう。私は複合USBデバイスを実装した他のプロジェクトをいくつか見てきましたが、そのアプローチは理にかなっているようです。つまり、独自のクラスドライバーを実装し、両方の機能を実装します。

STM32 Cubeパッケージ（ミドルウェア\ ST \ STM32_USB_Device_Library \ Class \ Template）からクラスの空白を取得します。充填はここから創造的に作り直されたコードになります。

USBデバイスの構造は次のとおりです。

構成は1つだけで、その中に3つのインターフェイスがあります
1つのインターフェイスはMSCを実装します
- 双方向のエンドポイントが1つあります-送受信用
CDCは2つのインターフェイスによって実装されます。
- 最初に制御します。インターフェイスを制御する1つの単方向エンドポイントがあります。
- データ用の2番目のCDCインターフェイス。双方向のエンドポイントがあります-送受信用
デバイス全体を制御するには別のエンドポイントが必要です（USBライブラリのコアによって実装されます）

複合デバイスの説明の例を説明する美しい写真。IAD仕様 からの適合：

便宜上、エンドポイントとインターフェイス番号をコードで宣言します。

インターフェイスとエンドポイント番号

 #define MSC_INTERFACE_IDX 0x0 // Index of MSC interface #define CDC_INTERFACE_IDX 0x1 // Index of CDC interface // endpoints numbers // endpoints numbers #define MSC_EP_IDX 0x01 #define CDC_CMD_EP_IDX 0x02 #define CDC_EP_IDX 0x03 #define IN_EP_DIR 0x80 // Adds a direction bit #define MSC_OUT_EP MSC_EP_IDX /* EP1 for BULK OUT */ #define MSC_IN_EP MSC_EP_IDX | IN_EP_DIR /* EP1 for BULK IN */ #define CDC_CMD_EP CDC_CMD_EP_IDX| IN_EP_DIR /* EP2 for CDC commands */ #define CDC_OUT_EP CDC_EP_IDX /* EP3 for data OUT */ #define CDC_IN_EP CDC_EP_IDX | IN_EP_DIR /* EP3 for data IN */

エンドポイントの番号付けは、インターフェイスの番号付けに続きます。 MSCには1番、CDC制御には2番、CDCを介したデータ送信には3番を使用します。一般的なデバイス管理用のゼロエンドポイントもありますが、USBカーネルの腸内で処理されるため、これらの番号を宣言する必要はありません。

STのUSBライブラリインターフェイスは貧弱です。場合によっては、エンドポイント番号は、送信方向のフラグと共に使用されます-設定された上位ビットは、ホストへのINの方向を意味します（このために定数IN_EP_DIRを設定します）。ただし、他の関数は単にエンドポイント番号を使用します。元のデザインとは異なり、これらすべての数値を分離し、適切な場所で正しい定数を使用することを好みました。接尾辞EP_IDXが付いた定数が使用される場合、方向フラグは使用されません。

重要！USB仕様によると、エンドポイントの数は何でも構いませんが、記述子で宣言されているのと同じ順序で順番に並べる方が良いでしょうこの知識は、Windows USBドライバーが頑固に間違ったエンドポイントに侵入し、何も機能しなかった1週間のハードデバッグによって私に与えられました。

いつものように記述子から始めましょう。ほとんどの記述子はクラス実装（usbd_msc_cdc.c）に存在しますが、デバイス記述子といくつかのグローバルなものはusbd_desc.cファイルのUSBカーネルで定義されます

最初に少しの定数

 #define USBD_VID 0x0483 #define USBD_PID 0x5741 #define USBD_LANGID_STRING 0x409 #define USBD_MANUFACTURER_STRING "STMicroelectronics" #define USBD_PRODUCT_FS_STRING "Composite MSC CDC" #define USBD_SERIALNUMBER_FS_STRING "00000000055C" #define USBD_CONFIGURATION_FS_STRING "Config Name" #define USBD_INTERFACE_FS_STRING "Interface Name"

デバイス記述子

 __ALIGN_BEGIN const uint8_t USBD_FS_DeviceDesc[USB_LEN_DEV_DESC] __ALIGN_END = { 0x12, /*bLength */ USB_DESC_TYPE_DEVICE, /*bDescriptorType*/ 0x00, /*bcdUSB */ 0x02, 0xEF, /*bDeviceClass*/ 0x02, /*bDeviceSubClass*/ 0x01, /*bDeviceProtocol*/ USB_MAX_EP0_SIZE, /*bMaxPacketSize*/ LOBYTE(USBD_VID), /*idVendor*/ HIBYTE(USBD_VID), /*idVendor*/ LOBYTE(USBD_PID), /*idVendor*/ HIBYTE(USBD_PID), /*idVendor*/ 0x00, /*bcdDevice rel. 2.00*/ 0x02, USBD_IDX_MFC_STR, /*Index of manufacturer string*/ USBD_IDX_PRODUCT_STR, /*Index of product string*/ USBD_IDX_SERIAL_STR, /*Index of serial number string*/ USBD_MAX_NUM_CONFIGURATION /*bNumConfigurations*/ };

一般に、ここではすべてが同じであり、デバイスクラス（bDeviceClass）を定義するフィールドのみが異なります。現在、これらのフィールドは、これが複合デバイスであることを示しています。ホストは一生懸命働き、他のすべての記述子を把握し、各コンポーネントの正しいドライバーをロードする必要があります。bDeviceProtocolフィールドは、複合デバイスの部分が特別な記述子であるInterface Association Descriptorで記述されることを意味します。彼についてもう少し低い。

構成記述子は以前とほぼ同じですが、違いはインターフェースの数のみです。今、3つあります

構成記述子

 #define USB_MSC_CDC_CONFIG_DESC_SIZ 98 /* USB MSC+CDC device Configuration Descriptor */ static const uint8_t USBD_MSC_CDC_CfgDesc[USB_MSC_CDC_CONFIG_DESC_SIZ] = { 0x09, /* bLength: Configuation Descriptor size */ USB_DESC_TYPE_CONFIGURATION, /* bDescriptorType: Configuration */ USB_MSC_CDC_CONFIG_DESC_SIZ, /* wTotalLength: Bytes returned */ 0x00, 0x03, /*bNumInterfaces: 3 interface*/ 0x01, /*bConfigurationValue: Configuration value*/ 0x02, /*iConfiguration: Index of string descriptor describing the configuration*/ 0xC0, /*bmAttributes: bus powered and Supports Remote Wakeup */ 0x32, /*MaxPower 100 mA: this current is used for detecting Vbus*/ /* 09 bytes */

次は、MSCのインターフェイスとエンドポイントの宣言です。この順序（最初のMSC、次にCDC）の理由はわかりません。だから、私が見つけてそこからコピーした例の1つにありました。原則として、インターフェイスの順序は重要ではありません。主なことは、追加の記述子をすべて近くに持っていることです。まあ、エンドポイントの番号付けとジョークも重要です。

MSC記述子

  /******************** Mass Storage interface ********************/ 0x09, /* bLength: Interface Descriptor size */ 0x04, /* bDescriptorType: */ MSC_INTERFACE_IDX, /* bInterfaceNumber: Number of Interface */ 0x00, /* bAlternateSetting: Alternate setting */ 0x02, /* bNumEndpoints*/ 0x08, /* bInterfaceClass: MSC Class */ 0x06, /* bInterfaceSubClass : SCSI transparent command set*/ 0x50, /* nInterfaceProtocol */ USBD_IDX_INTERFACE_STR, /* iInterface: */ /* 09 bytes */ /******************** Mass Storage Endpoints ********************/ 0x07, /*Endpoint descriptor length = 7*/ 0x05, /*Endpoint descriptor type */ MSC_IN_EP, /*Endpoint address (IN, address 1) */ 0x02, /*Bulk endpoint type */ LOBYTE(USB_MAX_PACKET_SIZE), HIBYTE(USB_MAX_PACKET_SIZE), 0x00, /*Polling interval in milliseconds */ /* 07 bytes */ 0x07, /*Endpoint descriptor length = 7 */ 0x05, /*Endpoint descriptor type */ MSC_OUT_EP, /*Endpoint address (OUT, address 1) */ 0x02, /*Bulk endpoint type */ LOBYTE(USB_MAX_PACKET_SIZE), HIBYTE(USB_MAX_PACKET_SIZE), 0x00, /*Polling interval in milliseconds*/ /* 07 bytes */

MSC記述子は、前のセクションの記述子と違いはありません。

そして、ここに新しいタイプの記述子-IAD（Interface Association Descriptor）-インターフェース関連記述子があります。ここでの関連付けは、組織という意味ではなく、どのインターフェイスをどの機能に関連付けるかという意味です。

インターフェイス関連付け記述子

  /******** IAD should be positioned just before the CDC interfaces ****** IAD to associate the two CDC interfaces */ 0x08, /* bLength */ 0x0B, /* bDescriptorType */ CDC_INTERFACE_IDX, /* bFirstInterface */ 0x02, /* bInterfaceCount */ 0x02, /* bFunctionClass */ 0x02, /* bFunctionSubClass */ 0x01, /* bFunctionProtocol */ 0x00, /* iFunction (Index of string descriptor describing this function) */ /* 08 bytes */

このトリッキーなハンドルは、USBデバイス（MSC）の以前の機能の説明が終わったことをホストに伝え、今では完全に異なる機能があります。そして、それはすぐに示されます-CDC。また、それに関連付けられているインターフェイスの数と最初のインターフェイスのインデックスも示します。

IAD記述子はMSCには必要ありません。インターフェイスは1つだけです。ただし、CDCが2つのインターフェイスを1つの機能にグループ化するには、IADが必要です。これは、この記述子の仕様に記載されています

最後に、CDC記述子。これらは、単一のCDC機能の記述子と完全に一貫しており、インターフェイス番号とエンドポイントに対して正確です。

CDC記述子

  /******************** CDC interfaces ********************/ /*Interface Descriptor */ 0x09, /* bLength: Interface Descriptor size */ USB_DESC_TYPE_INTERFACE, /* bDescriptorType: Interface */ /* Interface descriptor type */ CDC_INTERFACE_IDX, /* bInterfaceNumber: Number of Interface */ 0x00, /* bAlternateSetting: Alternate setting */ 0x01, /* bNumEndpoints: One endpoints used */ 0x02, /* bInterfaceClass: Communication Interface Class */ 0x02, /* bInterfaceSubClass: Abstract Control Model */ 0x01, /* bInterfaceProtocol: Common AT commands */ 0x01, /* iInterface: */ /* 09 bytes */ /*Header Functional Descriptor*/ 0x05, /* bLength: Endpoint Descriptor size */ 0x24, /* bDescriptorType: CS_INTERFACE */ 0x00, /* bDescriptorSubtype: Header Func Desc */ 0x10, /* bcdCDC: spec release number */ 0x01, /* 05 bytes */ /*Call Management Functional Descriptor*/ 0x05, /* bFunctionLength */ 0x24, /* bDescriptorType: CS_INTERFACE */ 0x01, /* bDescriptorSubtype: Call Management Func Desc */ 0x00, /* bmCapabilities: D0+D1 */ CDC_INTERFACE_IDX + 1, /* bDataInterface: 2 */ /* 05 bytes */ /*ACM Functional Descriptor*/ 0x04, /* bFunctionLength */ 0x24, /* bDescriptorType: CS_INTERFACE */ 0x02, /* bDescriptorSubtype: Abstract Control Management desc */ 0x02, /* bmCapabilities */ /* 04 bytes */ /*Union Functional Descriptor*/ 0x05, /* bFunctionLength */ 0x24, /* bDescriptorType: CS_INTERFACE */ 0x06, /* bDescriptorSubtype: Union func desc */ CDC_INTERFACE_IDX, /* bMasterInterface: Communication class interface */ CDC_INTERFACE_IDX + 1, /* bSlaveInterface0: Data Class Interface */ /* 05 bytes */ /*Endpoint 2 Descriptor*/ 0x07, /* bLength: Endpoint Descriptor size */ USB_DESC_TYPE_ENDPOINT, /* bDescriptorType: Endpoint */ CDC_CMD_EP, /* bEndpointAddress */ 0x03, /* bmAttributes: Interrupt */ LOBYTE(CDC_CMD_PACKET_SIZE), /* wMaxPacketSize: */ HIBYTE(CDC_CMD_PACKET_SIZE), 0x10, /* bInterval: */ /* 07 bytes */ /*Data class interface descriptor*/ 0x09, /* bLength: Endpoint Descriptor size */ USB_DESC_TYPE_INTERFACE, /* bDescriptorType: */ CDC_INTERFACE_IDX + 1, /* bInterfaceNumber: Number of Interface */ 0x00, /* bAlternateSetting: Alternate setting */ 0x02, /* bNumEndpoints: Two endpoints used */ 0x0A, /* bInterfaceClass: CDC */ 0x00, /* bInterfaceSubClass: */ 0x00, /* bInterfaceProtocol: */ 0x00, /* iInterface: */ /* 09 bytes */ /*Endpoint OUT Descriptor*/ 0x07, /* bLength: Endpoint Descriptor size */ USB_DESC_TYPE_ENDPOINT, /* bDescriptorType: Endpoint */ CDC_OUT_EP, /* bEndpointAddress */ 0x02, /* bmAttributes: Bulk */ LOBYTE(CDC_DATA_PACKET_SIZE), /* wMaxPacketSize: */ HIBYTE(CDC_DATA_PACKET_SIZE), 0x00, /* bInterval: ignore for Bulk transfer */ /* 07 bytes */ /*Endpoint IN Descriptor*/ 0x07, /* bLength: Endpoint Descriptor size */ USB_DESC_TYPE_ENDPOINT, /* bDescriptorType: Endpoint */ CDC_IN_EP, /* bEndpointAddress */ 0x02, /* bmAttributes: Bulk */ LOBYTE(CDC_DATA_PACKET_SIZE), /* wMaxPacketSize: */ HIBYTE(CDC_DATA_PACKET_SIZE), 0x00, /* bInterval */ /* 07 bytes */

すべての記述子の準備ができたら、構成の合計サイズを計算できます。

 #define USB_CDC_CONFIG_DESC_SIZ 98

コードの記述に移りましょう。USBカーネルは、このインターフェイスを使用してクラスドライバーと通信します

クラスドライバーインターフェイス

 typedef struct _Device_cb { uint8_t (*Init) (struct _USBD_HandleTypeDef *pdev , uint8_t cfgidx); uint8_t (*DeInit) (struct _USBD_HandleTypeDef *pdev , uint8_t cfgidx); /* Control Endpoints*/ uint8_t (*Setup) (struct _USBD_HandleTypeDef *pdev , USBD_SetupReqTypedef *req); uint8_t (*EP0_TxSent) (struct _USBD_HandleTypeDef *pdev ); uint8_t (*EP0_RxReady) (struct _USBD_HandleTypeDef *pdev ); /* Class Specific Endpoints*/ uint8_t (*DataIn) (struct _USBD_HandleTypeDef *pdev , uint8_t epnum); uint8_t (*DataOut) (struct _USBD_HandleTypeDef *pdev , uint8_t epnum); uint8_t (*SOF) (struct _USBD_HandleTypeDef *pdev); uint8_t (*IsoINIncomplete) (struct _USBD_HandleTypeDef *pdev , uint8_t epnum); uint8_t (*IsoOUTIncomplete) (struct _USBD_HandleTypeDef *pdev , uint8_t epnum); const uint8_t *(*GetHSConfigDescriptor)(uint16_t *length); const uint8_t *(*GetFSConfigDescriptor)(uint16_t *length); const uint8_t *(*GetOtherSpeedConfigDescriptor)(uint16_t *length); const uint8_t *(*GetDeviceQualifierDescriptor)(uint16_t *length); #if (USBD_SUPPORT_USER_STRING == 1) uint8_t *(*GetUsrStrDescriptor)(struct _USBD_HandleTypeDef *pdev ,uint8_t index, uint16_t *length); #endif } USBD_ClassTypeDef;

USBバス上のステータスまたはイベントに応じて、カーネルは対応する関数を呼び出します。

どれ建築問題追加の抽象化レイヤを導入することで解決することができる...（C）は、別の逸話である

もちろん、我々は全体の完全な機能を実装していないだろう、 - CDCおよびMSCクラスの実装のためには、既存のコードを満たしています。呼び出しを1つまたは別の実装にリダイレクトするレイヤーのみを記述します。

初期化と初期化解除

 /** * @brief USBD_MSC_CDC_Init * Initialize the MSC+CDC interface * @param pdev: device instance * @param cfgidx: Configuration index * @retval status */ static uint8_t USBD_MSC_CDC_Init (USBD_HandleTypeDef *pdev, uint8_t cfgidx) { /* MSC initialization */ uint8_t ret = USBD_MSC_Init (pdev, cfgidx); if(ret != USBD_OK) return ret; /* CDC initialization */ ret = USBD_CDC_Init (pdev, cfgidx); if(ret != USBD_OK) return ret; return USBD_OK; } /** * @brief USBD_MSC_CDC_Init * DeInitialize the MSC+CDC layer * @param pdev: device instance * @param cfgidx: Configuration index * @retval status */ static uint8_t USBD_MSC_CDC_DeInit (USBD_HandleTypeDef *pdev, uint8_t cfgidx) { /* MSC De-initialization */ USBD_MSC_DeInit(pdev, cfgidx); /* CDC De-initialization */ USBD_CDC_DeInit(pdev, cfgidx); return USBD_OK; }

ここではすべてが簡単です。両方のクラスを初期化（初期化解除）します。呼び出された関数自体がエンドポイントを作成/削除します。

おそらく、最も難しい機能はセットアップです。

セットアップハンドラー

 /** * @brief USBD_MSC_CDC_Setup * Handle the MSC+CDC specific requests * @param pdev: instance * @param req: usb requests * @retval status */ static uint8_t USBD_MSC_CDC_Setup (USBD_HandleTypeDef *pdev, USBD_SetupReqTypedef *req) { // Route requests to MSC interface or its endpoints to MSC class implementaion if(((req->bmRequest & USB_REQ_RECIPIENT_MASK) == USB_REQ_RECIPIENT_INTERFACE && req->wIndex == MSC_INTERFACE_IDX) || ((req->bmRequest & USB_REQ_RECIPIENT_MASK) == USB_REQ_RECIPIENT_ENDPOINT && ((req->wIndex & 0x7F) == MSC_EP_IDX))) { return USBD_MSC_Setup(pdev, req); } return USBD_CDC_Setup(pdev, req); }

これは、USBバス経由の標準リクエストの1つへのコールバックですが、このリクエストは非常に多面的です。これは、データの受信（取得）または設定（設定）のいずれかです。これは、デバイス全体、デバイスのインターフェースまたはエンドポイントへのリクエストである可能性があります。また、ここでは、基本的なUSB仕様で定義された、または特定のデバイスまたはクラスに固有の標準リクエストとして提供されます。詳細はこちら（セクション「セットアップパッケージ」）。

さまざまなケースが豊富にあるため、セットアップパッケージハンドラーの構造は非常に複雑です。ここではifやswitchを書くことはできません。 USBカーネルコードでは、処理は3〜4個の大きな機能に分散され、特定のケースでは別の専用プロセッサに転送されます（さらに多くの機能があります）。唯一の良いニュースは、リクエストのわずかな部分のみがクラスドライバーレベルに渡されることです。

どのパケットがこの機能を通過するかを調べましたが、受信者がナビゲートできるようです。パケットの受信者がインターフェイスの場合-wIndexフィールドにはインターフェイス番号があり、エンドポイントの場合はwIndexにエンドポイント番号があります。これに基づいて、リクエストを適切なハンドラにリダイレクトします。

ちなみに、これが機能するためには、インターフェイスの数を決定する定義を変更することを忘れてはなりません。そうしないと、リクエストは単に到達せず、USBカーネル内で切断されます

 #define USBD_MAX_NUM_INTERFACES 3

DataInとDataOutの呼び出しは簡単です。エンドポイントの番号があります-その上に、リクエストをリダイレクトする場所を決定します

DataIn（）およびDataOut（）

 /** * @brief USBD_MSC_CDC_DataIn * handle data IN Stage * @param pdev: device instance * @param epnum: endpoint index * @retval status */ static uint8_t USBD_MSC_CDC_DataIn (USBD_HandleTypeDef *pdev, uint8_t epnum) { if(epnum == MSC_EP_IDX) return USBD_MSC_DataIn(pdev, epnum); return USBD_CDC_DataIn(pdev, epnum); } /** * @brief USBD_MSC_CDC_DataOut * handle data OUT Stage * @param pdev: device instance * @param epnum: endpoint index * @retval status */ static uint8_t USBD_MSC_CDC_DataOut (USBD_HandleTypeDef *pdev, uint8_t epnum) { if(epnum == MSC_EP_IDX) return USBD_MSC_DataOut(pdev, epnum); return USBD_CDC_DataOut(pdev, epnum); }

送信方向フラグはエンドポイント番号では使用されないことに注意してください。すなわち一部の関数がMSC_IN_EP（0x81）を使用している場合でも、この関数ではMSC_EP_IDX（0x01）を使用する必要があります。

データがゼロのエンドポイントに到達する場合があり、このための特別なコールバックがあります。両方のクラス（CDCとMSCの両方）がこの場合のハンドラーを持っている場合、どうすればよいかわかりません-インターフェースまたはエンドポイント番号は、このようなリクエストで指定されていません。リクエストの宛先が誰であるかを理解することは不可能です。幸いなことに、このようなリクエストを処理できるのはCDCクラスのみです-ここでは送信します

EP0_RxReadyハンドラー

 /** * @brief USBD_MSC_CDC_EP0_RxReady * handle EP0 Rx Ready event * @param pdev: device instance * @retval status */ static uint8_t USBD_MSC_CDC_EP0_RxReady (USBD_HandleTypeDef *pdev) { return USBD_CDC_EP0_RxReady(pdev); }

取るに足らないハンドラーはもうありません。記述子にはいくつかのゲッターがありますが、それらのコードは標準であり、興味の対象ではありません。「仮想機能の表」に記入する

関数ポインタテーブル

 USBD_ClassTypeDef USBD_MSC_CDC_ClassDriver = { USBD_MSC_CDC_Init, USBD_MSC_CDC_DeInit, USBD_MSC_CDC_Setup, NULL, //USBD_MSC_CDC_EP0_TxReady, USBD_MSC_CDC_EP0_RxReady, USBD_MSC_CDC_DataIn, USBD_MSC_CDC_DataOut, NULL, //USBD_MSC_CDC_SOF, NULL, //USBD_MSC_CDC_IsoINIncomplete, NULL, //USBD_MSC_CDC_IsoOutIncomplete, USBD_MSC_CDC_GetCfgDesc, USBD_MSC_CDC_GetCfgDesc, USBD_MSC_CDC_GetCfgDesc, USBD_MSC_CDC_GetDeviceQualifierDesc, };

今初期化コード

初期化コード

 USBD_Init(&hUsbDeviceFS, &FS_Desc, 0); USBD_RegisterClass(&hUsbDeviceFS, &USBD_MSC_CDC_ClassDriver); USBD_CDC_RegisterInterface(&hUsbDeviceFS, &USBD_Interface_fops_FS); USBD_MSC_RegisterStorage(&hUsbDeviceFS, &SdMscDriver); USBD_Start(&hUsbDeviceFS);

USBカーネルを初期化し、クラスドライバーをインストールして、セカンダリインターフェイスを構成します。それだけですか？いいえ、すべてではありません。このフォームでは、開始されません。

ここにあります。各クラスには、ドライバーの状態、ドライバーのさまざまな機能で使用できるいくつかの変数など、一定量のプライベートデータがあります。さらに、これらは単にグローバル変数にすることはできません-特定のUSBデバイスに関連付けられています（そうでなければ、必要に応じて複数のデバイスを同時に操作することはできません）。そのため、このような場合のいくつかのフィールドがUSBハンドルに一度に入力されました。

USBハンドルデータフィールド

 /* USB Device handle structure */ typedef struct _USBD_HandleTypeDef { ... void *pClassData; void *pUserData; void *pData; } USBD_HandleTypeDef;

問題は、各クラスがこれらのフィールドをそのプロパティと見なし、その構造にしがみついていることです。

これを解決する方法はいくつかあります。同志ここでは、そのすべての実装クラスに何かを理解するために行くには、両方のドライバ（CDCとMSC）からのすべてのコードを同梱。別のアプローチは、両方のクラスのデータの余地があるこれらのフィールドに構造を配置することです。その後、部分的にも、また、（我々は唯一のUSBポートを持っている場合はOKです）グローバル変数に転送されたデータの一部には、このアプローチを使用

私たちは、より簡単で行きますよ。クラスドライバーが排他的なフィールドを必要とする場合は、これらのフィールドを提供します

「正しい」USBハンドルフィールド

 typedef struct _USBD_HandleTypeDef { ... USBD_MSC_BOT_HandleTypeDef *pClassDataMSC; const USBD_StorageTypeDef *pClassSpecificInterfaceMSC; USBD_CDC_HandleTypeDef *pClassDataCDC; const USBD_CDC_ItfTypeDef *pClassSpecificInterfaceCDC; PCD_HandleTypeDef *pPCDHandle; } USBD_HandleTypeDef;

最初に、私は各クラスにフィールドを与えました-彼らに彼らが望むように苦しませてください。第二に、これらのフィールドに実際にあるものに応じてこれらのフィールドに名前を付けました-UserDataはありませんが、インターフェースへのポインターがあります。

もちろん、長所では、より美しく、よりエレガントになります（メモリとCPUの消費量は同じです）。しかし、Cは人間的に行うことができます。ハンドル構造で小さな手を始めてから、理解できないvoid *を人間のタイプに変更しました（ところで、void * pDataフィールドは、対応するタイプのpPCDHandleと呼ばれるようになりました）。また、必要に応じてconstも配置しました。確かに、私は前方宣言をいじる必要がありました。

プロジェクトの組織について。一部のIDEでは、プロジェクトを次のように構築できます。クラスドライバーのUSBライブラリとソースコードはSTM32キューブに付属していますが、一部のファイルはユーザーに書き込むことが提案されています。ライブラリが共通の場所にあり、複数のプロジェクトで使用されていることがあります。USBライブラリのコードを変更しているため、だれにも邪魔されないように独自のコピーを作成することをお勧めします。

もちろん、フィールド名の変更はドライバーコードに反映される必要があります。しかし、ここでは、すべてが簡単です-コンテキスト置換により問題が解決します。

ここでの主なことは無理をしないことです。私は、それぞれの使用を見て、手を変えました。そこで、コードに「バグ」を見つけて修復し、それが機能しない理由を理解するために3日間の議論をしました。

「バグ」と入力します

 USBD_StatusTypeDef USBD_LL_Reset(USBD_HandleTypeDef *pdev) { ... if (pdev->pClassData) pdev->pClass->DeInit(pdev, pdev->dev_config); ... }

ここでは大丈夫でした-pClassDataを確認し、pClassに戻ります。修正した場合（pClassを確認）、機能しません。すなわちpClassDataは、クラスが初期化される一種のマーカーです。

ドライバーに戻ります。Init（）は両方のpClassDataXXX変数を初期化するため、このコードでチェックできます。

更新：frondersが気付いた重要なニュアンス。

初期化関数（USBD_CDC_Init（）など）の元のクラス実装（CDC、HID、MSC、およびその他すべて）では、pClassDataXXXフィールドのバッファーは、テンプレート実装でmalloc（）で定義されているUSBD_malloc（）を使用して割り当てられます。特別なものではないようです-作品を選択し、そのアドレスを使用します。

USBD_CDC_Init（）の標準実装

 static uint8_t USBD_CDC_Init (USBD_HandleTypeDef *pdev, uint8_t cfgidx) { ... pdev->pClassData = USBD_malloc(sizeof (USBD_CDC_HandleTypeDef)); ... }

しかし、一部のプロジェクト（STMicroelectronics自体からの例を含む）では、メモリを節約することを決定し、アロケーターの実装を作成しました。

正しくないアロケーター

 void *USBD_static_malloc(uint32_t size) { static uint32_t mem[(sizeof(USBD_CDC_HandleTypeDef)/4+1)];/* On 32-bit boundary */ return mem; }

原則として、このアプローチは機能しますが、これまでのところ、デバイスクラスは1つしかありません。いくつかのクラスがそのようなアロケータを介してメモリを「割り当て」ようとするとすぐに、すべてが壊れます。複数のクラスが同じバッファを苦しめます。

実際、いくつかの同一の機能を持つデバイス（たとえば、2つ以上のCDCを実装するデバイス）を構築する場合にのみ、メモリを割り当てる必要があります。まあ、多分それは、いくつかのエキゾチックなケースで、インターフェースがその場で作成および削除されるとき、まだ必要でしょう。他のすべての場合（その大部分は）、メモリの割り当てとバッファの静的な割り当てを気にしません。私のプロジェクトでは、これを行いました（同時に、データ型は白色になりました）。

静的割り当て

 // A CDC object USBD_CDC_HandleTypeDef cdcInstance; ... uint8_t USBD_CDC_Init (USBD_HandleTypeDef *pdev, uint8_t cfgidx) { ... pdev->pClassDataCDC = &cdcInstance; hcdc = pdev->pClassDataCDC; ... }

最終タッチ-PMAバッファーの割り当て

PMA分布

  HAL_PCDEx_PMAConfig(pdev->pPCDHandle , 0x00 , PCD_SNG_BUF, 0x20); HAL_PCDEx_PMAConfig(pdev->pPCDHandle , 0x80 , PCD_SNG_BUF, 0x60); HAL_PCDEx_PMAConfig(pdev->pPCDHandle , MSC_IN_EP, PCD_SNG_BUF, 0xA0); HAL_PCDEx_PMAConfig(pdev->pPCDHandle , MSC_OUT_EP, PCD_SNG_BUF, 0xE0); HAL_PCDEx_PMAConfig(pdev->pPCDHandle, CDC_CMD_EP, PCD_SNG_BUF, 0x100); HAL_PCDEx_PMAConfig(pdev->pPCDHandle, CDC_IN_EP, PCD_SNG_BUF, 0x140); HAL_PCDEx_PMAConfig(pdev->pPCDHandle, CDC_OUT_EP, PCD_SNG_BUF, 0x180);

エンドポイントには、7つのバッファが必要です。2つはゼロエンドポイント（コントロールポイント）、2つはMSC、3つはCDCです。ただし、ここで最も興味深いのは、開始アドレス（最後のパラメーター）です。何らかの理由で、このニュアンスはすべてのチュートリアルで慎重に管理されています。データシートには、PMAのバッファーの割り当てとレジスタレベルでの表示について記載されていますが、HALの対応する関数の使用方法に関する情報はありません。このギャップを埋めます。

だから。コントローラには、特別なメモリ-PMA（パケットメモリ領域）があります。これは、プログラムがデータを書き込むことができ、USB周辺機器がデータを読み取る（およびその逆の）メモリです。このメモリは事前に割り当てられていません。さまざまなエンドポイントをさまざまなパケットサイズに設定できます。したがって、どのバッファーがどこにあるかを示すテーブルBTABLEがあります。さらに、このテーブル自体もPMAにあります。テーブルはPMAの任意の場所に移動して配置できますが、HALはテーブルを最初にしか配置できません。

リファレンスマニュアルSTM32F103シリーズマイクロコントローラーの写真

それでは、バッファオフセットをどのように計算しますか？テーブルのサイズは、使用されるエンドポイントの数によって異なります。テーブル内の各エンドポイントは、4つの16ビット値のレコードで表されます（方向の1つが使用されない場合でも、受信用に2つ、送信用に2つ）。 4つのエンドポイントを使用します-0、MSC、およびCDCに2つ（バッファーの数と混同しないでください-エンドポイントごとに2つありますが、エンドポイントごとに2つですが、1つのポイントは単一方向なので、バッファーは1つだけです）。したがって、テーブルのサイズは4ポイント* 4レコード* 2バイト= 32バイトになります。

すでに述べたように、HALはPMAエリアの先頭にのみ配置できます。したがって、最初のバッファーはオフセット0x20（32バイト-テーブルのサイズ）にのみ配置できます。エンドポイントバッファは、オーバーラップしない限り、PMAメモリのどこにでも配置できます。各エンドポイントは、処理する準備ができている最大パケットサイズを決定します。バッファはこのサイズ以上である必要があります。

バッファーを64バイト単位（USBフルスピードデバイスの最大推奨バッファーサイズ）で配置しましたが、一部のエンドポイントではこれよりも少なくすることができました。そのため、CDC制御エンドポイントに沿って実行されるデータは多くありません（CDC_CMD_PACKET_SIZEは8バイトです）。したがって、バッファーは8バイトのみにすることができます。しかし、残念ながら32バイトでした-ちょうどラウンド数を取得するために。

コンパイルして実行する時間です。私のWindowsはすぐにデバイス自体を特定し、2つのコンポーネントも見ました。これは朗報です。しかし、悪いものがあります。Mass Storageデバイスがすぐに検出された場合、CDCは検出されません。

関係ありません-正しいドライバーをWindowsに挿入するだけです。実際、デバイスは標準であり、特別なドライバーは必要ありません。このデバイスを標準ドライバー（この場合はusbser.sys）に関連付けるだけで十分

です。実際、このキッチンではあまり理解していません。原則として、STサイトからSTMicroelectronics Virtual COM Portドライバーをダウンロードする必要があります。ドライバーはC：\ Program Files（x86）\ STMicroelectronics \ Software \ Virtual comportドライバーにインストールされますが、内部にはstmcdc.infファイルがあります-それが必要です。このファイルには2つのセクションがあり、次の形式の行があります。

%DESCRIPTION%=DriverInstall,USB\VID_0483&PID_5740

したがって、VID / PIDをデバイスドライバーに接続します。これだけでは不十分です-CDCを制御するインターフェイスの番号を指定する必要があります。私の場合、これが最初のインターフェースです（MSCを担当するのはヌルです）。これを行うには、行は次のようになります

%DESCRIPTION%=DriverInstall,USB\VID_0483&PID_5741&MI_01

。実際、元の行は変更できず

、適切なセクションに行を追加するだけです。

すべての準備が完了したら、デバイスのリストで動作していないデバイスを見つけます。ドライバーを更新し、infファイルが存在するディレクトリを指定してください。ドライバーがインストールされます。 Windows自体がこのデバイスにCOMxxという名前を割り当てます。お気に入りの端末を使用して、このCOMポートを開くことができます。

Linuxを使用すると、すべてがシンプルになります。~~タンバリン~~ドライバーと踊ることなく、すべてがそこから始まります。Fronders

による更新：Windows10では、すべてが自動的に起動します。さらに、ST自体は10kのvcpドライバを推奨していませんが、標準のドライバを使用することを提案しています。

おわりに

いくつかのフォーラムで、「このUSBではすべてが複雑になっていること、一部のドライバーは…今すぐ登録するほうがいい」というメッセージを見ました。みんな、それはそれほど簡単ではありません。レジスタレベルがおそらく最も簡単な部分です。しかし、それ以外にも、デバイスが実装すべきロジックの巨大な層があります。そして、ここではプロトコルの知識や何百ページもの仕様書は一切ありません。

しかし、すべてがそれほど悪いわけではありません。人々はすでに注意を払い、すべてのロジックを作成しました。ほとんどの場合、目的の値を置き換えて一部のパラメーターを調整するだけです。はい、STのライブラリはまだモンスターです。しかし、USB In A Nutshell、特定のクラスのデバイスのいくつかの仕様、スニッファーとの連携を熟読した後、多くのものが適切に配置されます。ライブラリは多少なりともスリムに見え始めます。比較的少ない労力でカスタムクラスドライバーを作成することもできますが、成功しました。

複合CDC + MSCデバイスの実装を行いましたが、ほぼ同じアプローチを他の組み合わせ（CDC + HID、MSC +オーディオ、CDC + MSC + HIDなど）に適用できます。私の実装はSTM32F103シリーズのマイクロコントローラーで動作するように設計されていますが、原理自体は他のマイクロコントローラー（STM32を含む）に適合させることができます。

この記事では、USBがどのように機能するかを詳しく説明するタスクを自分で設定しませんでした-まず、それをよく伝える記事や本があります（ほんの少しだけ触れました）、そして次に、元のソース（仕様）。

仕様を改めて説明する代わりに、STのUSBスタックの実装がどのように機能するかを説明しようとしました。また、特別な瞬間に注意を払って、なぜそうなのかを説明しようとしました。

私は「チュートリアル」にチェックを入れるかどうか長い間疑っていました。一方で、私は推奨事項と段階的な指示を与え、特別なポイントに注意を払い、ソースへのリンクを与えます。一方、プロジェクトにダウンロードして埋め込むための既製のライブラリを提供することはできません。

実際、私のプロジェクトの作業の過程で、このライブラリのファイル、ジグソーパズル、およびその他のツールを使用して良い仕事をしました。デバイスに必要のないコードを大量に捨て、一部を変更し、気に入らないものを修復しました。 USBライブラリは、ST Webサイトにあるものとは大きく異なります。変更の一部は私のプロジェクトに固有のものであり、他の状況には適さない場合があります。しかし、私のリポジトリへようこそ-勉強、自分へのコピー、質問、改善の提案。

最後に、私の実装で何らかの形で私を助けてくれたすべての人に感謝したいと思います。みんなありがとう！

STM32 HAL上のCDC + MSC USB複合デバイス

理論のビット

CDC-仮想COMポート

MSC-ストレージデバイス

CDC + MSC複合デバイス

おわりに

More articles: