• AVR Freaks

Help with HID descriptor for brining in numerous ADCs

Page: 12 > Showing page 1 of 2
Author
ericshufro
New Member
  • Total Posts : 18
  • Reward points : 0
  • Joined: 2010/06/29 07:26:28
  • Location: 0
  • Status: offline
2011/02/23 20:45:00 (permalink)
0

Help with HID descriptor for brining in numerous ADCs

Hello.  I am looking for assistance in crafting an HID descriptor for a custom device.  I used the DT tool on the USB Implementers page which parsed the descriptors without error, however, Windows will not enumerate the device (error code #10).

The device contains:

- 48 Primary ADCs
- 03 Secondary ADCs
- 01 Ternary ADCs
- 04 GPIO (Inputs)
- 16 GPIO (Inputs / Outputs)

The ADCs are 10-bit values, but represented as 16-bit values for readability / debugging assistance. There are 16 GPIO's for output which need to be written to as individual 1-bit fields.  These GPIO pins also need to be read back.  Additionally, there are 4 GPIO inputs which are read together as a single 4-bit number.  Similar to the ADC's, it would be OK to consider the 4 DIP switches a single 8-bit value for debugging and even expandability.

I suspect the with enumeration has to do with the report IDs.  I thought it might be advantageous for the host to request input by ID, as opposed to requesting all of the inputs in a single transaction.  However, if I limit the descriptors to 1 report ID (ID = 1), the application  seems to enumerate.  Adding additional report IDs seem to cause problems.

Any idea what the problem might be?  Please see the descriptor data below.

Thank you in advance,

--Eric

{
    0x06, 0x00, 0xff,              // USAGE_PAGE (Vendor Defined Page 1)
    0x09, 0x01,                    // USAGE (Vendor Usage 1)
    0xa1, 0x01,                    // COLLECTION (Application)

    0x06, 0x00, 0xff,              //   USAGE_PAGE (Vendor Defined Page 1)

    0x85, 0x01,                    //   REPORT_ID (1)
    0x95, 0x30,                    //   REPORT_COUNT (48)
    0x75, 0x10,                    //   REPORT_SIZE (16)
    0x27, 0xff, 0xff, 0x00, 0x00,  //   LOGICAL_MAXIMUM (65535)
    0x15, 0x00,                    //   LOGICAL_MINIMUM (0)
    0x09, 0x01,                    //   USAGE (Vendor Usage 1)
    0x81, 0x03,                    //   INPUT (Cnst,Var,Abs)

    0x85, 0x02,                    //   REPORT_ID (2)
    0x95, 0x03,                    //   REPORT_COUNT (3)
    0x75, 0x10,                    //   REPORT_SIZE (16)
    0x27, 0xff, 0xff, 0x00, 0x00,  //   LOGICAL_MAXIMUM (65535)
    0x15, 0x00,                    //   LOGICAL_MINIMUM (0)
    0x09, 0x01,                    //   USAGE (Vendor Usage 1)
    0x81, 0x03,                    //   INPUT (Cnst,Var,Abs)

    0x85, 0x03,                    //   REPORT_ID (3)
    0x95, 0x01,                    //   REPORT_COUNT (1)
    0x75, 0x10,                    //   REPORT_SIZE (16)
    0x27, 0xff, 0xff, 0x00, 0x00,  //   LOGICAL_MAXIMUM (65535)
    0x15, 0x00,                    //   LOGICAL_MINIMUM (0)
    0x09, 0x01,                    //   USAGE (Vendor Usage 1)
    0x81, 0x03,                    //   INPUT (Cnst,Var,Abs)

    0x85, 0x04,                    //   REPORT_ID (4)
    0x95, 0x01,                    //   REPORT_COUNT (1)
    0x75, 0x08,                    //   REPORT_SIZE (8)
    0x26, 0xff, 0x00,              //   LOGICAL_MAXIMUM (255)
    0x15, 0x00,                    //   LOGICAL_MINIMUM (0)
    0x09, 0x01,                    //   USAGE (Vendor Usage 1)
    0x81, 0x03,                    //   INPUT (Cnst,Var,Abs)

    0x85, 0x05,                    //   REPORT_ID (5)
    0x95, 0x10,                    //   REPORT_COUNT (16)
    0x75, 0x01,                    //   REPORT_SIZE (1)
    0x25, 0x01,                    //   LOGICAL_MAXIMUM (1)
    0x15, 0x00,                    //   LOGICAL_MINIMUM (0)
    0x09, 0x01,                    //   USAGE (Vendor Usage 1)
    0xb1, 0x00,                    //   FEATURE (Data,Ary,Abs)

    0xc0}                          //  END_COLLECTION
}



#1

26 Replies Related Threads

    chinzei
    Super Member
    • Total Posts : 2250
    • Reward points : 0
    • Joined: 2003/11/07 12:39:02
    • Location: Tokyo, Japan
    • Status: offline
    Re:Help with HID descriptor for brining in numerous ADCs 2011/02/23 21:50:42 (permalink)
    0
    1) Replace four INPUT (Cnst,Var,Abs) to INPUT (Data,Var,Abs)
    Cnst (Constant) is usually used as bit padding to byte boundary.

    2) Replace FEATURE (Data,Ary,Abs) to FEATURE (Data,Var,Abs)
    This bit array is defined as Var (variable).
    Ary (Array) means index array. You have to define indices using USAGEs or USAGE MIN/MAX, beforehand. A typical usage of Array is a keycode array on keyboard report descriptor.

    keyboard - keycode array

      Report Count (6),
      Report Size (8),
      Logical Minimum (0),
      Logical Maximum(255),
      Usage Page (Key Codes),   // keycode indices
      Usage Minimum (0),
      Usage Maximum (255),
      Input (Data, Array),      // keycode array


    3) Optimization
    LOGICAL_MAXIMUM (65535) appears three times.
    The second and third one can be deleted.
    LOGICAL_MINIMUM (0), too.

    The value of global items, like LOGICAL_MIN/MAX, is carried over.
    Just when the value is changed, new value is defined.
    In this way, your report descriptor is simplified.

    See this post for the details
    http://www.microchip.com/forums/fb.aspx?m=479147

    Tsuneo
    #2
    ericshufro
    New Member
    • Total Posts : 18
    • Reward points : 0
    • Joined: 2010/06/29 07:26:28
    • Location: 0
    • Status: offline
    Re:Help with HID descriptor for brining in numerous ADCs 2011/02/24 17:26:41 (permalink)
    0
    Thanks for the feedback.  I tried making the changes and unfortunately, it still will not enumerate.  I suspect the problem could be with the use of report IDs.  Perhaps I am not using them correctly?  I was hoping that the use of report IDs would make it easier for the host to poll specific items of interest instead of having to collect ALL of the ADCs, and GPIOs on every transaction.  Perhaps I am misunderstanding the use of HID?

    Please find below a full copy of the descriptors being used.

    Thanks again,

    --Eric

                                        // Device Descriptor
    ROM USB_DEVICE_DESCRIPTOR device_dsc=
    {
        0x12,                           // Size of this descriptor in bytes
        USB_DESCRIPTOR_DEVICE,          // DEVICE descriptor type
        0x0200,                         // USB Spec Release Number in BCD format
        0x00,                           // Class Code
        0x00,                           // Subclass code
        0x00,                           // Protocol code
        USB_EP0_BUFF_SIZE,              // Max packet size for EP0, see usb_config.h
        0x04D8,                         // Vendor ID
        0x003F,                         // Product ID: Custom HID demo
        0x0002,                         // Device release number in BCD format
        0x01,                           // Manufacturer string index
        0x02,                           // Product string index
        0x00,                           // Device serial number string index
        0x01                            // Number of possible configurations
    };

                                       
    ROM BYTE configDescriptor1[]={      // Configuration 1 Descriptor
                                        // Configuration Descriptor
        0x09,                           // Size of this descriptor in bytes
        USB_DESCRIPTOR_CONFIGURATION,   // CONFIGURATION descriptor type
        0x29,0x00,                      // Total length of data for this cfg
        1,                              // Number of interfaces in this cfg
        1,                              // Index value of this configuration
        0,                              // Configuration string index
        _DEFAULT | _SELF,               // Attributes, see usb_device.h
        50,                             // Max power consumption (2X mA)
                               
                                        // Interface Descriptor
        0x09,//sizeof(USB_INTF_DSC),    // Size of this descriptor in bytes
        USB_DESCRIPTOR_INTERFACE,       // INTERFACE descriptor type
        0,                              // Interface Number
        0,                              // Alternate Setting Number
        2,                              // Number of endpoints in this intf
        HID_INTF,                       // Class code
        0,                              // Subclass code
        0,                              // Protocol code
        0,                              // Interface string index

                                        // HID Class-Specific Descriptor
        0x09,                           // Size of this descriptor in bytes
        DSC_HID,                        // HID descriptor type
        0x11,0x01,                      // HID Spec Release Number in BCD format (1.11)
        0x00,                           // Country Code (0x00 for Not supported)
        HID_NUM_OF_DSC,                 // Number of class descriptors, see usbcfg.h
        DSC_RPT,                        // Report descriptor type
        91,0x00,                        // Size of the report descriptor
       
                                        // Endpoint Descriptor
        0x07,                           // Size of this descriptor in bytes
        USB_DESCRIPTOR_ENDPOINT,        // Endpoint Descriptor
        HID_EP | _EP_IN,                // EndpointAddress
        _INTERRUPT,                     // Attributes
        0x40,0x00,                      // Size
        0x01,                           // Interval

                                        // Endpoint Descriptor
        0x07,                           // Size of this descriptor in bytes
        USB_DESCRIPTOR_ENDPOINT,        // Endpoint Descriptor
        HID_EP | _EP_OUT,               // EndpointAddress
        _INTERRUPT,                     // Attributes
        0x40,0x00,                      // Size
        0x01                            // Interval
    };

                                        // Language code string descriptor
    ROM struct{BYTE bLength;BYTE bDscType;WORD string[1];}sd000={
    sizeof(sd000),USB_DESCRIPTOR_STRING,{0x0409
    }};

                                        // Manufacturer string descriptor
    ROM struct{BYTE bLength;BYTE bDscType;WORD string[25];}sd001={
    sizeof(sd001),USB_DESCRIPTOR_STRING,
    {'M','i','c','r','o','c','h','i','p',' ',
    'T','e','c','h','n','o','l','o','g','y',' ','I','n','c','.'
    }};

                                        // Product string descriptor
    ROM struct{BYTE bLength;BYTE bDscType;WORD string[22];}sd002={
    sizeof(sd002),USB_DESCRIPTOR_STRING,
    {'S','i','m','p','l','e',' ','H','I','D',' ',
    'D','e','v','i','c','e',' ','D','e','m','o'
    }};

    ROM struct{BYTE report[91];}hid_rpt01={
    {
        0x06, 0x00, 0xff,               // USAGE_PAGE (Vendor Defined Page 1)
        0x09, 0x01,                     // USAGE (Vendor Usage 1)
        0xa1, 0x01,                     // COLLECTION (Application)

        0x06, 0x00, 0xff,               //   USAGE_PAGE (Vendor Defined Page 1)

        0x85, 0x01,                     //   REPORT_ID (1)
        0x95, 0x30,                     //   REPORT_COUNT (48)
        0x75, 0x10,                     //   REPORT_SIZE (16)
        0x27, 0xff, 0xff, 0x00, 0x00,   //   LOGICAL_MAXIMUM (65535)
        0x15, 0x00,                     //   LOGICAL_MINIMUM (0)
        0x09, 0x01,                     //   USAGE (Vendor Usage 1)
        0x81, 0x02,                     //   INPUT (Data,Var,Abs)

        0x85, 0x02,                     //   REPORT_ID (2)
        0x95, 0x03,                     //   REPORT_COUNT (3)
        0x75, 0x10,                     //   REPORT_SIZE (16)
        0x27, 0xff, 0xff, 0x00, 0x00,   //   LOGICAL_MAXIMUM (65535)
        0x15, 0x00,                     //   LOGICAL_MINIMUM (0)
        0x09, 0x01,                     //   USAGE (Vendor Usage 1)
        0x81, 0x02,                     //   INPUT (Data,Var,Abs)

        0x85, 0x03,                     //   REPORT_ID (3)
        0x95, 0x01,                     //   REPORT_COUNT (1)
        0x75, 0x10,                     //   REPORT_SIZE (16)
        0x27, 0xff, 0xff, 0x00, 0x00,   //   LOGICAL_MAXIMUM (65535)
        0x15, 0x00,                     //   LOGICAL_MINIMUM (0)
        0x09, 0x01,                     //   USAGE (Vendor Usage 1)
        0x81, 0x02,                     //   INPUT (Data,Var,Abs)

        0x85, 0x04,                     //   REPORT_ID (4)
        0x95, 0x01,                     //   REPORT_COUNT (1)
        0x75, 0x08,                     //   REPORT_SIZE (8)
        0x26, 0xff, 0x00,               //   LOGICAL_MAXIMUM (255)
        0x15, 0x00,                     //   LOGICAL_MINIMUM (0)
        0x09, 0x01,                     //   USAGE (Vendor Usage 1)
        0x81, 0x02,                     //   INPUT (Data,Var,Abs)

        0x85, 0x05,                     //   REPORT_ID (5)
        0x95, 0x10,                     //   REPORT_COUNT (16)
        0x75, 0x01,                     //   REPORT_SIZE (1)
        0x25, 0x01,                     //   LOGICAL_MAXIMUM (1)
        0x15, 0x00,                     //   LOGICAL_MINIMUM (0)
        0x09, 0x01,                     //   USAGE (Vendor Usage 1)
        0xB1, 0x02,                     //   FEATURE (Data,Var,Abs)

        0xc0}                           //  END_COLLECTION
    };

                                       
    ROM BYTE *ROM USB_CD_Ptr[]=         // Array of configuration descriptors
    {
        (ROM BYTE *ROM)&configDescriptor1
    };

                                       
    ROM BYTE *ROM USB_SD_Ptr[]=         // Array of string descriptors
    {
        (ROM BYTE *ROM)&sd000,
        (ROM BYTE *ROM)&sd001,
        (ROM BYTE *ROM)&sd002
    };

    #3
    chinzei
    Super Member
    • Total Posts : 2250
    • Reward points : 0
    • Joined: 2003/11/07 12:39:02
    • Location: Tokyo, Japan
    • Status: offline
    Re:Help with HID descriptor for brining in numerous ADCs 2011/02/28 04:06:39 (permalink)
    0
    Did you change the value of HID_RPT01_SIZE macro on usb_config.h, too?
    This value is referred by Get_Descriptor( HID report ) handler in usb_function_hid.c

    usb_config.h

    #define HID_RPT01_SIZE          28  // <---- 91


    You assign the value directly to hid_rpt01 structure in usb_descriptors.c
    But usb_function_hid.c refers to this definition on usb_function_hid.h

    usb_function_hid.h

    #if !defined(__USB_DESCRIPTORS_C)
    extern ROM struct{BYTE report[HID_RPT01_SIZE];}hid_rpt01;
    #endif


    Tsuneo
    #4
    ericshufro
    New Member
    • Total Posts : 18
    • Reward points : 0
    • Joined: 2010/06/29 07:26:28
    • Location: 0
    • Status: offline
    Re:Help with HID descriptor for brining in numerous ADCs 2011/03/01 06:39:57 (permalink)
    0
    That was it.  Thank you.  Its a shame most compilers don't generate errors when the declared array size and the extern'ed array size don't match.  Thank you for pointing this out.

    --Eric

    #5
    ericshufro
    New Member
    • Total Posts : 18
    • Reward points : 0
    • Joined: 2010/06/29 07:26:28
    • Location: 0
    • Status: offline
    Re:Help with HID descriptor for brining in numerous ADCs 2011/03/03 20:59:17 (permalink)
    0
    Hello.  I have had descent luck getting Windows to enumerate the device, but I am unable to talk to it using any type of Windows application. 

    Questions:

    1) Can a HID descriptor with multiple reports specify the first report as report ID 0, or is that reserved?  Each one of my report types have an ID associated with them, where the first ID begins at one.

    2) In order to reduce the amount of polling in my application, I have enabled interrupts and use RTOS tasks to service USB events.  I have attempted to modify USER_USB_CALLBACK_EVENT_HANDLER() as follows:

            case EVENT_TRANSFER:
                  u1stat = *(USTAT_FIELDS *)pdata;
                  dir    =  (CPU_INT08U    )USBHALGetLastDirection(u1stat);
                  if (dir == OUT_FROM_HOST) {
                      SemSignal(USB_RxRdySem);
                  } else {
                     SemSignal(USB_TxDoneSem);
                  }
                 break;


    The idea behind the above code being that I can signal a specific task when a transfer has completed instead of calling USBHandleBusy().  Does this seem reasonable?  I very rarely end up in this function and it never seem to be for a receive event, that is, when i attempt to send an output report from the PC.  When i attempt to transmit from the target to the PC (input report), I get here when the transmit completes.  This only occurs a handful of times before transfer complete interrupts appear to stop.

    3) My descriptor(s), shown in earlier posts, require two HID endpoints.  Do i need to specify the number of endpoints being equal to 2?  All of the example applications set usb_config.h, USB_MAX_EP_NUMBER to 1.

    4) When i call HIDRxPacket() or HIDTxPacket(), the EP argument is always HIP_EP.  Should the value be the same for Rx and Tx, or should the value passed differ depending on which call is being made?

    5) When the target transmit back to the host, does the first byte have to contain the report ID being sent?  If so, this would be similar to how windows requires the first byte be set to the report ID of the target device. -- Neither of which report IDs should show up in the receive buffer on either end, correct?

    6) Should the target sent gratuitous input reports to the PC, or should the PC poll the target for data?  What are typical programming patterns used for USB?

    7) When the host enumerates the device, and the HID example application (GenericHID, a free c# based example) finds the device, it prints the following information to the log.

      Usage: 1
      Usage Page: ff00
      Input Report Byte Length: 97
      Output Report Byte Length: 3
      Feature Report Byte Length: 0
      Number of Link Collection Nodes: 1
      Number of Input Button Caps: 1
      Number of Input Value Caps: 4
      Number of Input Data Indices: 5
      Number of Output Button Caps: 1
      Number of Output Value Caps: 0
      Number of Output Data Indices: 1
      Number of Feature Button Caps: 0
      Number of Feature Value Caps: 0
      Number of Feature Data Indices: 0

    This information doesnt seem to jive with my desired descriptor list.  Did i interpret the information wrong, or are there additional problems with my descriptors?  Please see previous posts.

    Thanks for the help.

    --Eric

    #6
    chinzei
    Super Member
    • Total Posts : 2250
    • Reward points : 0
    • Joined: 2003/11/07 12:39:02
    • Location: Tokyo, Japan
    • Status: offline
    Re:Help with HID descriptor for brining in numerous ADCs 2011/03/07 16:54:48 (permalink)
    0

    Sorry for my late response.
    I've been down, suffering from influenza.

    1) Can a HID descriptor with multiple reports specify the first report as report ID 0, or is that reserved?

    6.2.2.7 Global Items (HID1_11.pdf p36) - Report ID
    Report ID zero is reserved and should not be used.

    2) In order to reduce the amount of polling in my application, I have enabled interrupts and use RTOS tasks to service USB events...Does this seem reasonable?

    For RTOS, it's a good idea for task management.
    Not just the transfer direction (USBHALGetLastDirection(u1stat)), check the endpoint number (USBHALGetLastEndpoint(u1stat)), too. And you'll get safe for composite device.

    Do i need to specify the number of endpoints being equal to 2?  All of the example applications set usb_config.h, USB_MAX_EP_NUMBER to 1.

    USB_MAX_EP_NUMBER should be equal to the greatest endpoint address on the config descriptor set. usb_device.c reserves many arrays of this size (plus one), which are essential for the device stack, like Buffer Descriptor Table.

    4) When i call HIDRxPacket() or HIDTxPacket(), the EP argument is always HIP_EP.  Should the value be the same for Rx and Tx, or should the value passed differ depending on which call is being made?

    IN and OUT endpoints are independent, each other, in their operation.
    HID interrupt IN/OUT endpoints may have different addresses, for example, IN 1 and OUT 2.
    But, PIC USB engine and Microchip stack results in smaller code/RAM footprint, when the IN and OUT endpoints have the same address of lower address. Just for efficiency.

    5) When the target transmit back to the host, does the first byte have to contain the report ID being sent?

    Yes, if the report descriptor defines any report ID - same as Windows app.
    When no report ID is defined on the report descriptor, device sends/receives reports without preceding report ID (0) - different from Windows app.

    6) Should the target sent gratuitous input reports to the PC, or should the PC poll the target for data?  What are typical programming patterns used for USB?

    PC (host controller) polls the HID IN endpoint at the bInterval (or less), defined on the endpoint descriptor, using IN transactions. HID device returns an input report at the timing as it likes. For example, USB mouse/keyboard returns input report, just when user moves the mouse, just when user keys in (Microchip examples for these HID devices are bad ones, in this aspect wink)

    When no report is armed to the IN endpoint, the USB hardware returns NAK (data not ready) to the IN transaction. NAK is also a normal response, which consists of USB hardware flow control.

    7) When the host enumerates the device, and the HID example application (GenericHID, a free c# based example) finds the device, it prints the following information to the log.

    Looks like the statistics of the output and feature reports are swapped.
    It's a bug of the PC app
    I don't see any error on your report descriptor.


    Try SimpleHIDWrite, instead. Coded by Robert Marquardt, distributed on Jan's HID page
    http://www.lvr.com/files/SimpleHIDWrite3.zip

    The source (Delphi) is distributed on soft-gems.net
    Human Interface Device controller suite
    http://www.soft-gems.net/...mp;id=14&Itemid=33

    Tsuneo


    post edited by chinzei - 2011/03/07 17:37:00
    #7
    chinzei
    Super Member
    • Total Posts : 2250
    • Reward points : 0
    • Joined: 2003/11/07 12:39:02
    • Location: Tokyo, Japan
    • Status: offline
    Re:Help with HID descriptor for brining in numerous ADCs 2011/03/07 17:21:38 (permalink)
    0

    Ah, I remember.
    The input report of report ID 1 has 97 bytes (report ID + 48 x 2 bytes body) - which is the greatest one among the input reports.

    On the device side,
    This input report is sent split into two transactions (ie. two HIDTxPacket()). The first 64 bytes (including the report ID (1)), the second 33 bytes (the rest of report body). The firmware has to wait for (or sleep in RTOS task) the completion of the first transaction, before it may put the next transaction.

    On the PC app,
    ReadFile() for input reports always requests 97 bytes for nNumberOfBytesToRead parameter. lpNumberOfBytesRead returns actual report size (plus report ID).

    Tsuneo
    #8
    ericshufro
    New Member
    • Total Posts : 18
    • Reward points : 0
    • Joined: 2010/06/29 07:26:28
    • Location: 0
    • Status: offline
    Re:Help with HID descriptor for brining in numerous ADCs 2011/03/08 09:14:08 (permalink)
    0
    Chinzei,


    Thank you for your reply and I hope that you are feeling better.  When i remove all report IDs from the descriptor and leave only a single input and output report (without IDs), the  information seems to flow freely between the PC and target, and vice versa.  When i add the report ID's, data does not appear to flow in either direction.  Does Windows filter improperly structured reports?  Does the Microchip stack filter any reports?  My guess is yes to Windows and no for the Microchip stack.

    Given the set of descriptors shown previously with the report IDs in place, the target is configured to send the report ID plus 96 bytes for a total of 97 bytes.  The application sends the first 1 + 63, waits for notification that transmit has completed and sends another packet with the remaining 33.  In USBTrace, these packets appear back to back.  It is common for USBTrace to indicate 'status not supported' after a the transfer of the report?  This is true whether the report ID is included or not, the exception being that without the report IDs in the data or descriptors, the report is received by the Windows application.  Assuming the target sends the report ID, should i expect the report ID to come out of the Windows application receive buffer, index 0?

    On the PC side, with the report IDs in the descriptor, i send short messages, perhaps 1 byte representing a command.  In this case, the first byte is the report ID, and the second byte is the command.  When i read the buffer on the target side, i should expect the report id and command to both be present in index 0 and 1 of the buffer, correct?  At the moment, the target does not receive anything if the report ID is specified.

    Thanks

    --Eric



    #9
    ericshufro
    New Member
    • Total Posts : 18
    • Reward points : 0
    • Joined: 2010/06/29 07:26:28
    • Location: 0
    • Status: offline
    Re:Help with HID descriptor for brining in numerous ADCs 2011/03/08 09:30:23 (permalink)
    0
    Chinzei,


    You were exactly right.

    First off, i switched to the SimpleHIDWrite application  you recommended.  The problems that I was experiencing seem to have all been Windows application related.  This new application works like a charm when the device IDs are present in the descriptor.

    Thank you again,

    --Eric

    #10
    ericshufro
    New Member
    • Total Posts : 18
    • Reward points : 0
    • Joined: 2010/06/29 07:26:28
    • Location: 0
    • Status: offline
    Re:Help with HID descriptor for brining in numerous ADCs 2011/03/08 09:36:32 (permalink)
    0
    Chinzei,


    A few more questions.

    If a PC application wants to request information from a device, should the report for that information be a feature, or should i define two report IDs, one for the specific IN request, and another for the specific OUT request to service the query?

    Alternatively, should i create a single OUT request ID for all device bound requests, and have the target use data associated with that report to determine which input report to generate and return to the host?

    Thanks,

    --Eric



    #11
    chinzei
    Super Member
    • Total Posts : 2250
    • Reward points : 0
    • Joined: 2003/11/07 12:39:02
    • Location: Tokyo, Japan
    • Status: offline
    Re:Help with HID descriptor for brining in numerous ADCs 2011/03/08 11:46:19 (permalink)
    0

    Does Windows filter improperly structured reports?

    PC HID class driver filters improperly-formatted reports, for both direction. Class driver checks total report size in bytes (including report ID) and Report ID.

    If a PC application wants to request information from a device, should the report for that information be a feature, or should i define two report IDs, one for the specific IN request, and another for the specific OUT request to service the query?

    a) Under single report ID, you may define ONE input, ONE output and ONE feature report, simultaneously, at most.

    b) HID Reports are exchanged over
    - HID interrupt endpoint(s)
    - or using Get_Report/Set_Report request over the default endpoint (EP0)

    Depending on the report type, available pipe is limited.
    Input report: interrupt IN endpoint, or Get_Report request
    Output report: interrupt OUT endpoint, or Set_Report request
    Feature report: Get_Report or Set_Report

    Firmware process of EP0 request is heavier than those of interrupt IN/OUT endpoints. Therefore, if your application exchanges the reports frequently, choose input/output report which passes through interrupt IN/OUT endpoints.

    Tsuneo
    #12
    ericshufro
    New Member
    • Total Posts : 18
    • Reward points : 0
    • Joined: 2010/06/29 07:26:28
    • Location: 0
    • Status: offline
    Re:Help with HID descriptor for brining in numerous ADCs 2011/03/08 21:07:20 (permalink)
    0
    chinzei
    If a PC application wants to request information from a device, should the report for that information be a feature, or should i define two report IDs, one for the specific IN request, and another for the specific OUT request to service the query?

    a) Under single report ID, you may define ONE input, ONE output and ONE feature report, simultaneously, at most.


    I am still uncertain how this applies to a request response mechanism.  Would good practice dictate that each report have an input and output such that the host can request that a given input report be generated?  For example, if an input report is 8 bytes long, then should that report, lets call it ID #2, have an output associated with it such that the host can send a report to the device with ID #2 that triggers the target to generate an ID #2 input report?

    Or should one input report with a unique ID and arguments be used to instruct the target to send particular input reports?

    Does a report with both an input and output share the data size for both the input and output part (max, min, count, and length equal for input and output, or can they be declared separate for each input and output on a given report?

    Thanks

    --Eric
    #13
    chinzei
    Super Member
    • Total Posts : 2250
    • Reward points : 0
    • Joined: 2003/11/07 12:39:02
    • Location: Tokyo, Japan
    • Status: offline
    Re:Help with HID descriptor for brining in numerous ADCs 2011/03/08 21:53:45 (permalink)
    0

    Even when the reports (input/output/feature) share the same report ID, these reports are independent each other. You may assign their report formats other than report ID as you like. 

    In your above report descriptor, the last feature report has report ID of 5. You may change this report ID to 1, which is shared with the first input report.


    In good practice, a same report ID is assigned to reports in pair.
    But it isn't restricted.
    Tsuneo

    post edited by chinzei - 2011/03/08 22:05:09
    #14
    DarioG
    Allmächtig.
    • Total Posts : 54081
    • Reward points : 0
    • Joined: 2006/02/25 08:58:22
    • Location: Oesterreich
    • Status: offline
    Re:Help with HID descriptor for brining in numerous ADCs 2011/03/09 04:25:58 (permalink)
    0
    Yeah, I always like to hear about this Smile
    Basically, it's user choice and in the end it does not make much difference. I like to have an ID for each EP, and usually don't use Feature.

    GENOVA :D :D ! GODO
    #15
    ericshufro
    New Member
    • Total Posts : 18
    • Reward points : 0
    • Joined: 2010/06/29 07:26:28
    • Location: 0
    • Status: offline
    Re:Help with HID descriptor for brining in numerous ADCs 2011/03/09 07:26:57 (permalink)
    0
    All,


    I am not sure the response answers the question.

    If the host PC application wants to obtain data from a device, does he send a unique report ID and an argument that can be detected on the device, such as report ID 10, and an argument [1 to 5] specifying which IN report to generate?

    OR

    Is it better practice to define each report with INPUT and OUTPUT variables, therefore, enabling the host PC application to send a report #1, and receive a report #1 back.  If this method is used, can the count and size of the input and output variables differ for a given report?  If not, does that mean the host PC application has to send an n byte report to receive an n byte report, as opposed to sending a single byte to generate a whole report of a particular ID? 

    As Chinzei mentioned, there can be one input, output and feature for each report number, correct?

    Currently, when i attempt to add an additional variable to a given report, enumeration fails.  I have increased the size of the descriptor accordingly.

    What is your opinion?  What would you design?

    Thank you,

    --Eric




    #16
    ericshufro
    New Member
    • Total Posts : 18
    • Reward points : 0
    • Joined: 2010/06/29 07:26:28
    • Location: 0
    • Status: offline
    Re:Help with HID descriptor for brining in numerous ADCs 2011/03/09 07:36:40 (permalink)
    0
    I solved the enumeration problem because i realize now that each variable declaration requires a usage.  Though, i just hope adding an additional usage to each report is good practice when being used to provide a mechanism for the PC application to stimulate the device to generate the input report of the same ID.

    --Eric

    #17
    DarioG
    Allmächtig.
    • Total Posts : 54081
    • Reward points : 0
    • Joined: 2006/02/25 08:58:22
    • Location: Oesterreich
    • Status: offline
    Re:Help with HID descriptor for brining in numerous ADCs 2011/03/09 08:30:45 (permalink)
    0
    As for myself, I'd say that even a single (non-ID'ed) report - for both input & output - would be more than ok. The point is that *anyway* the transmission will take 1mS, even if you only use 4 bytes or the full 64 so...

    And the "decoding of the proper meaning" happens by reading the first byte in the packet.

    GENOVA :D :D ! GODO
    #18
    ericshufro
    New Member
    • Total Posts : 18
    • Reward points : 0
    • Joined: 2010/06/29 07:26:28
    • Location: 0
    • Status: offline
    Re:Help with HID descriptor for brining in numerous ADCs 2011/03/14 07:08:46 (permalink)
    0
    Gents,


    Is there a way to bring in a 32-bit unsigned HID report value?  When i use the descriptor tool (dt.exe), it comes back with (-1) when i enter FFFFFFFF since the value is interpreted as a signed 32-bit value.

    The hid spec says if the min and max values are both specified and unsigned, then a sign bit is not necessary and the value will be interpreted as an unsigned value.  However, the number of bytes shown in the descriptor to represent this value is only one.  I was expecting at least 0xFF 0xFF 0xFF 0xFF as the argument for the item opcode.

    Any ideas?

    Thanks.

    --Eric
    #19
    chinzei
    Super Member
    • Total Posts : 2250
    • Reward points : 0
    • Joined: 2003/11/07 12:39:02
    • Location: Tokyo, Japan
    • Status: offline
    Re:Help with HID descriptor for brining in numerous ADCs 2011/03/14 11:15:28 (permalink)
    0

    Is there a way to bring in a 32-bit unsigned HID report value?

    Nothing for the current spec.
    The data field of Logical Min/Max and Physical Min/Max is interpreted as a signed integer value.
    So, you can't specify a value greater than 0x7FFFFFFF

    For greater value, HID spec supposes long item format, instead of usual short item.
    But HID spec reserves use of long item.

    The hid spec says if the min and max values are both specified and unsigned, then a sign bit is not necessary and the value will be interpreted as an unsigned value.

    HID spec doesn't say "a sign bit is not necessary" wink

    6.2.2.7 Global Items (HID1_11.pdf p35)
    Remarks
    If both the Logical Minimum and Logical Maximum extents are defined as positive values (0 or greater) then the report field can be assumed to be an unsigned value. Otherwise, all integer values are signed values represented in 2’s complement format.


    Tsuneo
    #20
    Page: 12 > Showing page 1 of 2
    Jump to:
    © 2019 APG vNext Commercial Version 4.5