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

さらに低いレベル（avr-vusb）の

USBレジスター：STM32L1 / STM32F1

USBレジスター：大容量ストレージの例のバルクエンドポイント



USBレジスターのUSB：オーディオデバイスの例の等時性エンドポイント



STM32L151コントローラーのUSBを 引き続き扱います。前の部分と同様に、ここではプラットフォームに依存するものはありませんが、USBに依存します。より正確には、3番目のタイプのエンドポイントである割り込みについて検討します。そして、複合デバイス「キーボード+タブレット」（ソースへのリンク）の例を使用してこれを行い ます。

念のため、警告します。この記事は（他のすべての人と同様に）、このトピックを理解しているときに理解したことの概要です。多くのことが「魔法」のままであり、それらを説明できる専門家がいればありがたいです。



まず、HID（Human Interface Device）プロトコルは、大量のデータを交換するためのものではないことを思い出してください。交換全体は、イベントと状態の2つの概念に基づいて い ます。イベントは、外部または内部の影響に応答して発生する1回限りのメッセージです。たとえば、ユーザーがボタンを押したり、マウスを動かしたりします。または、1つのキーボードでNumLockを無効にしました。その後、ホストが強制され、2番目のキーボードが適切なコマンドを送信して 修正し、NumLockキーストローク信号を送信して元に戻しました。インジケーターに表示しました。割り込みポイントは、イベントを通知するために使用されます。状態は、そのように変化しないある種の特性です。さて、気温を考えてみましょう。または、音量レベルを調整します。つまり、ホストがデバイスの動作を制御するものです。これが必要になることはめったにないため、相互作用はep0を介して最も原始的です。



したがって、割り込みポイントの目的は、コントローラーの割り込みと同じです。つまり、まれなイベントをすばやく報告します。ただし、USBはホスト中心のものであるため、デバイスが独自に転送を開始する権利はありません。これを回避するために、USB開発者は松葉杖を思いつきました。ホストは定期的にすべての割り込みポイントを読み取る要求を送信します。リクエストの頻度は、EndpointDescriptorの最後のパラメーターによって構成されます（これはConfigurationDescriptorの一部です）。前の章でbIntervalフィールドをすでに見てきましたが、その値は無視されました。今、彼はついに用途を見つけました。値のサイズは1バイトで、ミリ秒単位で設定されるため、1ミリ秒から2.55秒の間隔でポーリングされます。低速デバイスの場合、最小間隔は10msです。割り込みポイントがポーリングされている松葉杖の存在は、交換がない場合でも、バスの帯域幅を浪費することになります。



論理的な結論：割り込みポイントはINトランザクション専用です。特に、キーボードやマウスからのイベントの送信、COMポートのサービスラインの変更の通知、オーディオストリームの同期などに使用されます。しかし、これらすべてのために、他のタイプのポイントを追加する必要があります。したがって、例を複雑にしないために、HIDデバイスの実装に限定します。実際、最初の部分ですでにそのようなデバイスを作成しましたが、追加のポイントはまったく使用されず、HIDプロトコルの構造は考慮されていませんでした。

ConfigurationDescriptor

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
    2, // bNumEndpoints
    HIDCLASS_HID, // bInterfaceClass: 
    HIDSUBCLASS_BOOT, // bInterfaceSubClass: 
    HIDPROTOCOL_KEYBOARD, // bInterfaceProtocol: 
    0x00, // iInterface
  )
  ARRLEN1(
    bLENGTH, //bLength
    USB_DESCR_HID, //bDescriptorType
    USB_U16(0x0110), //bcdHID
    0, //bCountryCode
    1, //bNumDescriptors
    USB_DESCR_HID_REPORT, //bDescriptorType
    USB_U16( sizeof(USB_HIDDescriptor) ), //wDescriptorLength
  )
  ARRLEN1(
    bLENGTH, //bLength
    USB_DESCR_ENDPOINT, //bDescriptorType
    INTR_NUM, //bEdnpointAddress
    USB_ENDP_INTR, //bmAttributes
    USB_U16( INTR_SIZE ), //MaxPacketSize
    10, //bInterval
  )
  ARRLEN1(
    bLENGTH, //bLength
    USB_DESCR_ENDPOINT, //bDescriptorType
    INTR_NUM | 0x80, //bEdnpointAddress
    USB_ENDP_INTR, //bmAttributes
    USB_U16( INTR_SIZE ), //MaxPacketSize
    10, //bInterval
  )
  )
};
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

注意深い読者は、エンドポイントの説明にすぐに気付くかもしれません。2番目の場合、すべてが順番になります。INポイント（0x80での加算のため）は割り込みタイプであるため、サイズと間隔が指定されます。しかし、最初のものはOUTとして宣言されているようですが、同時に割り込みが発生します。これは、前に述べたことと矛盾します。そして常識も：ホストはいつでもデバイスに何かを転送するために松葉杖を必要としません。ただし、この方法では、他のレーキがバイパスされます。STM32のエンドポイントタイプは1つのポイントではなく、IN / OUTペアに対してのみ設定されるため、0x81番目のポイントを割り込みタイプに設定するのではなく、0x01番目に設定します。コントロール。ただし、これはホストにとって問題ではありません。おそらくバルクポイントでも同じデータを送信します...ただし、これについては確認しません。

HID記述子

HID記述子の構造は、構成ファイル「name = value」に最も似ていますが、それとは異なり、「name」はUSB固有のリストの数値定数であり、「value」も定数または変数です。サイズ0から3バイトまで。



重要：一部の「名前」の場合、「値」の長さは「名前」フィールドの最下位2ビットで指定されます。たとえば、LOGICAL_MINIMUM（この変数が通常モードで取ることができる最小値）を考えてみましょう。この定数のコードは0x14です。したがって、「値」がない場合（これは発生しないようですが、議論はしません-何らかの理由でこのケースが入力されました）、記述子には単一の数値0x14が含まれます。 「値」が1（1バイト）の場合、0x15、0x01が書き込まれます。 2バイトの値の場合、0x1234、0x16、0x34、0x12が書き込まれます-値は低いものから高いものへと書き込まれます。ヒープの前では、番号0x123456は0x17、0x56、0x34、0x12になります。



当然、私はこれらすべての数値定数を覚えるのが面倒なので、マクロを使用します。残念ながら、渡された値のサイズを自分で把握して1、2、3、または4バイトに拡張する方法を見つけられませんでした。したがって、松葉杖を作る必要がありました ：接尾辞のないマクロは最も一般的な8ビット値に責任があり、16ビット値の場合は接尾辞16、24ビット値の場合は24です。マクロは、4、6、または8バイトに拡張される範囲LOGICAL_MINMAX24（最小、最大）のような「複合」値用にも記述されています。



構成ファイルと同様に、目的別にデバイスをグループ化するページ（usage_page）と呼ばれる「セクション」があります。たとえば、キーボード、マウス、ボタンだけなどの基本的な周辺機器を備えたページがあり、ジョイスティックとゲームパッドがあります（どれを見るのを心からお勧めします！戦車、宇宙船、潜水艦などにもあります）、ディスプレイもあります...確かに、これらすべてで動作するソフトウェアをどこで探すべきか、私にはわかりません。



各ページ内で、特定のデバイスが選択されています。たとえば、マウスの場合はポインタとボタンであり、タブレットの場合はスタイラスまたはユーザーの指です（何？！）。また、デバイスの構成部品も指定します。したがって、ポインタの一部はX座標とY座標です。一部の特性は「コレクション」にグループ化できますが、なぜこれが行われるのかよくわかりません。ドキュメントでは、フィールドの目的と操作方法について、フィールドに2文字の文字が付いている場合があります。







もちろん他にもありますが、私の例では使用していません。たとえば、XフィールドがDVとしてマークされている場合、それはゼロ以外の長さの変数と見なされ、レポート構造に含まれます。 MCまたはOSCフィールドもレポートに含まれますが、サイズは1ビットです。



1つのレポート（デバイスによって送信または受信されたデータパケット）には、そこに記述されているすべての変数の値が含まれています。ボタンの説明では、占有されているビットは1つだけですが、相対座標（たとえば、マウスの移動量）の場合は、少なくとも1バイトが必要であり、絶対座標（タッチスクリーンなど）の場合は、少なくとも2バイトが必要です。必要です。さらに、多くのコントロールには独自の物理的制限があります。たとえば、同じタッチスクリーンのADCの解像度はわずか10ビットです。つまり、0から1023までの値を指定できます。これは、ホストがフルスクリーン解像度にスケーリングする必要があります。したがって、各フィールドの目的に加えて、記述子はその許容値の範囲（LOGICAL_MINMAX）に加えて、場合によっては物理値の範囲（ミリメートル単位または度単位）とでの表示も指定しますレポートは必須です。表現は、1つの変数のサイズ（ビット単位）とその数の2つの数値で設定されます。たとえば、作成しているデバイスのタッチスクリーンに触れる座標は次のように設定されます。

USAGE( USAGE_X ), // 0x09, 0x30,
USAGE( USAGE_Y ), // 0x09, 0x31,
LOGICAL_MINMAX16( 0, 10000 ), //0x16, 0x00, 0x00,   0x26, 0x10, 0x27,
REPORT_FMT( 16, 2 ), // 0x75, 0x10, 0x95, 0x02,
INPUT_HID( HID_VAR | HID_ABS | HID_DATA), // 0x91, 0x02,
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

ここでは、0から10000の範囲で変化し、レポートの16ビットの2つのセクションを占める2つの変数が宣言されていることがわかります。



最後のフィールドは、上記の変数がホスト（IN）によって読み取られることを示し、その方法を正確に説明しています。そのフラグについては詳しく説明しません。いくつかだけ説明します。 HID_ABSフラグは、値が絶対値であること、つまり、履歴が値に影響を与えないことを示します。代替値HID_RELは、値が前の値からのオフセットであることを示します。 HID_VARフラグは、各フィールドが独自の変数を担当することを示します。代替値HID_ARRは、リストのすべてのボタンの状態が送信されるのではなく、アクティブなボタンの数のみが送信されることを示します。このフラグは、シングルビットフィールドにのみ適用されます。すべてのキーボードボタンの101/102状態を送信する代わりに、押されたキーのリストを使用して数バイトに制限することができます。次に、最初のパラメーターREPORT_FMTが数値のサイズを担当し、2番目のパラメーターが数値を担当します。



すべての変数のサイズはビット単位で設定されるため、ボタンの数は8の倍数ではない可能性があるため、ボタンについて質問するのが論理的です。これにより、読み取りと書き込みの位置合わせが困難になります。各ボタンにバイトを割り当てることは可能ですが、レポートの量が大幅に増加するため、割り込みなどの高速プログラムには不快です。代わりに、ボタンを互いに近づけて配置しようとし、残りのスペースはHID_CONSTフラグの付いたビットで埋められます。



これで、記述子を最初から書き込まない場合でも、少なくともそれを読み取ろうとすることができます。つまり、このフィールドまたはそのフィールドがどのビットに対応するかを判別できます。 INPUT_HIDと対応するREPORT_FMTを数えるだけで十分です。私がそのようなマクロを思いついたので、他の誰もそれらを使用しないことを覚えておいてください。他の人の記述子では、input、report_size、report_count、さらには数値定数を探す必要があります。



これで、記述子全体を持ってくることができます。

static const uint8_t USB_HIDDescriptor[] = {
  //keyboard
  USAGE_PAGE( USAGEPAGE_GENERIC ),//0x05, 0x01,
  USAGE( USAGE_KEYBOARD ), // 0x09, 0x06,
  COLLECTION( COLL_APPLICATION, // 0xA1, 0x01,
    REPORT_ID( 1 ), // 0x85, 0x01,
    USAGE_PAGE( USAGEPAGE_KEYBOARD ), // 0x05, 0x07,
    USAGE_MINMAX(224, 231), //0x19, 0xE0, 0x29, 0xE7,    
    LOGICAL_MINMAX(0, 1), //0x15, 0x00, 0x25, 0x01,
    REPORT_FMT(1, 8), //0x75, 0x01, 0x95, 0x08     
    INPUT_HID( HID_DATA | HID_VAR | HID_ABS ), // 0x81, 0x02,
     //reserved
    REPORT_FMT(8, 1), // 0x75, 0x08, 0x95, 0x01,
    INPUT_HID(HID_CONST), // 0x81, 0x01,
              
    REPORT_FMT(1, 5),  // 0x75, 0x01, 0x95, 0x05,
    USAGE_PAGE( USAGEPAGE_LEDS ), // 0x05, 0x08,
    USAGE_MINMAX(1, 5), //0x19, 0x01, 0x29, 0x05,  
    OUTPUT_HID( HID_DATA | HID_VAR | HID_ABS ), // 0x91, 0x02,
    //  1 
    REPORT_FMT(3, 1), // 0x75, 0x03, 0x95, 0x01,
    OUTPUT_HID( HID_CONST ), // 0x91, 0x01,
    REPORT_FMT(8, 6),  // 0x75, 0x08, 0x95, 0x06,
    LOGICAL_MINMAX(0, 101), // 0x15, 0x00, 0x25, 0x65,         
    USAGE_PAGE( USAGEPAGE_KEYBOARD ), // 0x05, 0x07,
    USAGE_MINMAX(0, 101), // 0x19, 0x00, 0x29, 0x65,
    INPUT_HID( HID_DATA | HID_ARR ), // 0x81, 0x00,           
  )
  //touchscreen
  USAGE_PAGE( USAGEPAGE_DIGITIZER ), // 0x05, 0x0D,
  USAGE( USAGE_PEN ), // 0x09, 0x02,
  COLLECTION( COLL_APPLICATION, // 0xA1, 0x0x01,
    REPORT_ID( 2 ), //0x85, 0x02,
    USAGE( USAGE_FINGER ), // 0x09, 0x22,
    COLLECTION( COLL_PHISICAL, // 0xA1, 0x00,
      USAGE( USAGE_TOUCH ), // 0x09, 0x42,
      USAGE( USAGE_IN_RANGE ), // 0x09, 0x32,
      LOGICAL_MINMAX( 0, 1), // 0x15, 0x00, 0x25, 0x01,
      REPORT_FMT( 1, 2 ), // 0x75, 0x01, 0x95, 0x02,
      INPUT_HID( HID_VAR | HID_DATA | HID_ABS ), // 0x91, 0x02,
      REPORT_FMT( 1, 6 ), // 0x75, 0x01, 0x95, 0x06,
      INPUT_HID( HID_CONST ), // 0x81, 0x01,
                
      USAGE_PAGE( USAGEPAGE_GENERIC ), //0x05, 0x01,
      USAGE( USAGE_POINTER ), // 0x09, 0x01,
      COLLECTION( COLL_PHISICAL, // 0xA1, 0x00,         
        USAGE( USAGE_X ), // 0x09, 0x30,
        USAGE( USAGE_Y ), // 0x09, 0x31,
        LOGICAL_MINMAX16( 0, 10000 ), //0x16, 0x00, 0x00, 0x26, 0x10, 0x27,
        REPORT_FMT( 16, 2 ), // 0x75, 0x10, 0x95, 0x02,
        INPUT_HID( HID_VAR | HID_ABS | HID_DATA), // 0x91, 0x02,
      )
    )
  )
};
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

前述のフィールドに加えて、REPORT_IDなどの興味深いフィールドもあります。コメントから明らかなように、私たちのデバイスは複合であるため、ホストは受信するデータを何らかの方法で決定する必要があります。このためには、このフィールドが必要です。



そして、私が注目したいもう1つのフィールドは、OUTPUT_HIDです。名前が示すように、レポートの受信（IN）ではなく、送信（OUT）を担当します。キーボードセクションにあり、CapsLock、NumLock、ScrollLockインジケーター、および2つのエキゾチックなインジケーター（Compose（á、µ、またはなどの独自のボタンを持たない文字を入力するためのフラグ）とKana（象形文字を入力する））について説明します。 。実際、この分野のために、OUTポイントを開始しました。そのハンドラーで、CapsLockインジケーターとNumLockインジケーターを点灯する必要があるかどうかを確認します。ボードにはダイオードが2つだけあり、配線されています。



データ交換に関連する3番目のフィールドであるFEATURE_HIDがあり、最初の例で使用しました。 INPUTとOUTPUTがイベントの送信を目的としている場合、FEATUREは読み取りまたは書き込みが可能な状態です。確かに、これは専用のエンドポイントではなく、適切な要求によって通常のep0を介して行われます。



記述子をよく見ると、レポートの構造を復元できます。より正確には、2つのレポート：

struct{
  uint8_t report_id; //1
  union{
    uint8_t modifiers;
    struct{
      uint8_t lctrl:1; //left control
      uint8_t lshift:1;//left shift
      uint8_t lalt:1;  //left alt
      uint8_t lgui:1;  //left gui.   hyper,   winkey
      uint8_t rctrl:1; //right control
      uint8_t rshift:1;//right shift
      uint8_t ralt:1;  //right alt
      uint8_t rgui:1;  //right gui
    };
  };
  uint8_t reserved; //        
  uint8_t keys[6]; //   
}__attribute__((packed)) report_kbd;

struct{
  uint8_t report_id; //2
  union{
    uint8_t buttons;
    struct{
      uint8_t touch:1;   //  
      uint8_t inrange:1; //   
      uint8_t reserved:6;//  1 
    };
  };
  uint16_t x;
  uint16_t y;
}__attribute__((packed)) report_tablet;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

また、ボード上のボタンを押してお送りします。完全なデバイスではなく、実装の例を書いているだけなので、野蛮な方法でそれを行います。最初はキーを「押す」、2番目は「解放する」という2つのレポートを送信します。さらに、メッセージ間に大きな「ばかげた」遅延があります。 「リリースされた」キーを使用してレポートを送信しない場合、システムはキーがまだ押されていると見なし、それを繰り返します。当然のことながら、効率や安全性にも問題はありませんが、テストには問題ありません。そうそう、別の熊手なしで ！構造のサイズは、記述子に記述されているものと一致する必要があります。一致しない場合、Windowsは、構造から何を求めているのかを理解していないように見せかけます。いつものように、Linuxはそのようなエラーを無視し、何も起こらなかったかのように動作します。



テスト中に、面白い副作用に遭遇しました。Windows7では、「タッチスクリーン」をクリックすると、手書きウィンドウがポップアップします。私はこの機能について知りませんでした。

完成したデバイスがある場合

...そして私はそれを内側から見たいと思います。まず第一に、もちろん、私たちは、通常のユーザーであるConfigurationDescriptorからでも可能です。

lsusb -v -d <VID:PID>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

HID記述子の場合、ルートからよりも良い方法を見つけられませんでした（そして探しませんでした）。

cat /sys/kernel/debug/hid/<address>/rdes
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

完全を期すために、他のオペレーティングシステムで同様のものを調べる方法をここに追加する価値があります。しかし、私には関連する知識がありません、多分彼らはコメントであなたに言うでしょう。もちろん、サードパーティのソフトウェアをインストールしないことが望ましいです。

結論

実際、これが私がHIDで掘り下げたすべてです。既製の記述子を読み取り、同時に複数のデバイスをエミュレートし、タブレット入力を実装する方法を学ぶための最小限の計画が完了しました。さて、同時に割り込みポイントの哲学も考慮されました。



悪い時期のように、USB-IF設計者がサイトを再び台無しにすることにした場合に備えて、リポジトリに小さなドキュメントを残しました。