• AVR Freaks

An HID report > 8 bytes...

Page: 12 > Showing page 1 of 2
Author
psycho
Starting Member
  • Total Posts : 55
  • Reward points : 0
  • Joined: 2008/06/29 18:02:09
  • Location: 0
  • Status: offline
2008/12/23 15:40:34 (permalink)
0

An HID report > 8 bytes...

This is using Jan Axelson's Generic HID example from her site. I have v 2.3 of the stack, I believe.

I am trying to implement an HID project and I noticed that there is a comment that says:

// This firmware version doesn't support reports > 8 bytes.

I am trying to get a 24 byte feature report so I have it as:


        // The Feature report
        0x09, 0x05,         // Usage ID - vendor defined
        0x15, 0x00,         // Logical Minimum (0)
        0x26, 0xFF, 0x00,   // Logical Maximum (255)
        0x75, 0x08,            // Report Size (8 bits)
        0x95, 0x18,         // Report Count    (24 fields)               
        0xB1, 0x02,         // Feature (Data, Variable, Absolute) 


When I send the report from the PC, it seems to be coming to the mySetReportHandler routine 8 bytes at a time - which makes sense.

Is there a way to get a single feature report that is 24 (or more) bytes??? i.e. not split into chunks

Thanks
Kevin
#1

21 Replies Related Threads

    bob_barr
    Super Member
    • Total Posts : 5428
    • Reward points : 0
    • Joined: 2003/11/07 12:35:23
    • Location: Morgan Hill, CA
    • Status: offline
    RE: An HID report > 8 bytes... 2008/12/23 16:55:21 (permalink)
    0
    Is there a way to get a single feature report that is 24 (or more) bytes??? i.e. not split into chunks

    It's been a while since I've dug into the details of the USB but, as I recall, the 8-byte report limit is part of the definition of either the HID protocol or the low-speed requirements. By sending the data 8 bytes at a time, the transfer continues until a block less than 8 bytes is transmitted. (If the data size is an exact multiple of 8 bytes, a zero-length packet needs to be sent to terminate the transfer.)

    While it's always good to learn from one's mistakes, it's much easier to learn from the mistakes of others.
    Please don't PM me with technical questions. I'll be quite happy to help (if I can) on the forums.
    #2
    psycho
    Starting Member
    • Total Posts : 55
    • Reward points : 0
    • Joined: 2008/06/29 18:02:09
    • Location: 0
    • Status: offline
    RE: An HID report > 8 bytes... 2008/12/23 17:21:14 (permalink)
    0
    I looked it up and, in fact, you are quite correct. Low speed devices are limited to 8 bytes / transfer. I will figure out a way to use multiple packets.

    Thanks!
    Kevin

    #3
    xiaofan
    Super Member
    • Total Posts : 6247
    • Reward points : 0
    • Joined: 2005/04/14 07:05:25
    • Location: Singapore
    • Status: offline
    RE: An HID report > 8 bytes... 2008/12/23 18:55:36 (permalink)
    0
    But in the firmware, it is a full speed device, not a low speed device.

      USB_Links and libusb
    #4
    psycho
    Starting Member
    • Total Posts : 55
    • Reward points : 0
    • Joined: 2008/06/29 18:02:09
    • Location: 0
    • Status: offline
    RE: An HID report > 8 bytes... 2008/12/23 19:06:47 (permalink)
    0
    Have you gotten a > 8 byte Feature Report to work (all in one transfer)?

    The Feature report is coming 8 bytes at a time. That would be fine if I could figure out how to check the size of the actual data that comes in each packet. It would come 8 bytes at a time and the last packet would be either A) smaller than 8 bytes (OR) B) an extra zero length packet would be sent if the total length (of the multiple packets) is an even 8 byte chunk.

    The problem I am having is finding out how many bytes are new to the current packet. If I use  HID_OUTPUT_REPORT_BYTES, it always reports 24 because that it what the descriptor says. If I use SetupPkt.wLength it returns 10, which is not correct (should be 8, I would think). Unless it is counting other information in the length. But, even then, the last packet, which should be 0 bytes is shown as 10 bytes.

    Ideas???

    Kevin

    #5
    xiaofan
    Super Member
    • Total Posts : 6247
    • Reward points : 0
    • Joined: 2005/04/14 07:05:25
    • Location: Singapore
    • Status: offline
    RE: An HID report > 8 bytes... 2008/12/23 19:56:05 (permalink)
    0
    If you look at the PICkit 2 firmware, you will find that the input/output report are of 64Bytes size. The Stack V2.3 also has examples for output report of 64Bytes.

    Microchip firmware does not implement feature report like Jan Axelson's HID and WinUSB firmware.

    In the firmware example,

    Receives Output reports using interrupt OUT transfers and sends the report data back to the host in Input reports using interrupt IN transfers.

    Receives Output reports using control transfers (Set_Report request) and sends the report data back to the host in Input reports using control transfers (Get_Report requests.)

    Receives Feature reports using control transfers (Set_Report request) and sends the report data back to the host in Feature reports using control transfers (Get_Report requests.)


    So if you want to extend the feature report size, you will have to modify the firmware. I am not so sure if 24Bytes is even possible given that the allowable maximum control transfer data payload sizes for full-speed devices is 8, 16, 32, or 64 bytes.

      USB_Links and libusb
    #6
    xiaofan
    Super Member
    • Total Posts : 6247
    • Reward points : 0
    • Joined: 2005/04/14 07:05:25
    • Location: Singapore
    • Status: offline
    RE: An HID report > 8 bytes... 2008/12/23 20:15:35 (permalink)
    0
    Just wondering what is the reason you want to use feature report. Why not input/output report? 

      USB_Links and libusb
    #7
    xiaofan
    Super Member
    • Total Posts : 6247
    • Reward points : 0
    • Joined: 2005/04/14 07:05:25
    • Location: Singapore
    • Status: offline
    RE: An HID report > 8 bytes... 2008/12/23 20:26:48 (permalink)
    0
    And I think your first post is valid since the max packet size for control endpoint is set to EP0_BUFF_SIZE ( // Max packet size for EP0)=8 Bytes.

    It is defined in usb_config.h
    #define EP0_BUFF_SIZE           8   // 8, 16, 32, or 64

    This defined the division unit for transactions.

    I think this will help you more.
    http://www.keil.com/forum/docs/thread12679.asp

    And I believe it is better to use INPUT/OUTPUT report for your case.

      USB_Links and libusb
    #8
    chinzei
    Super Member
    • Total Posts : 2250
    • Reward points : 0
    • Joined: 2003/11/07 12:39:02
    • Location: Tokyo, Japan
    • Status: offline
    RE: An HID report > 8 bytes... 2008/12/23 23:54:52 (permalink)
    0
    Original: psycho

    This is using Jan Axelson's Generic HID example from her site. I have v 2.3 of the stack, I believe.
    ...
    When I send the report from the PC, it seems to be coming to the mySetReportHandler routine 8 bytes at a time - which makes sense.

    It doesn't make any sense.
    mySetReportHandler should be called just once, at the end of the DATA stage. It is done by the stack through the function pointer, outPipes[0].pFunc.

    The call to mySetReportHandler for every 8 bytes is caused by this false modification on "2. In usb_device.c:" section of the readme.txt

    http://www.lvr.com/files/Generic_HID_c18_fsusb_fwv2-3.zip

    Drop the modification.

    You'll find related discussions on these topics.

    "usb_function_hid pointers and misc"
    http://forum.microchip.com/tm.aspx?m=390508

    "pFunc does what?"
    http://forum.microchip.com/tm.aspx?m=390770

    Tsuneo
    #9
    psycho
    Starting Member
    • Total Posts : 55
    • Reward points : 0
    • Joined: 2008/06/29 18:02:09
    • Location: 0
    • Status: offline
    RE: An HID report > 8 bytes... 2008/12/24 00:19:45 (permalink)
    0
    I took both of your's advice and didn't use feature reports...

    Thanks for the help!
    Kevin

    #10
    friesen
    Super Member
    • Total Posts : 2125
    • Reward points : 0
    • Joined: 2008/05/08 05:23:35
    • Location: Indiana, USA
    • Status: offline
    RE: An HID report > 8 bytes... 2008/12/24 06:23:58 (permalink)
    0
    I am curious to know why chinzei and xiafon do not recommend feature reports.  Perhaps they prefer non control style report handling.  For my project I ended up using feature reports to control what the firmware does with control in/out reports.  It seems a little simpler to me but then again I know microchip uses only input/output reports with the pickit2.  By using control transfer reports I was able to send and receive reports without active intervention by the main program.



    Erik Friesen
    #11
    chinzei
    Super Member
    • Total Posts : 2250
    • Reward points : 0
    • Joined: 2003/11/07 12:39:02
    • Location: Tokyo, Japan
    • Status: offline
    RE: An HID report > 8 bytes... 2008/12/24 08:23:04 (permalink)
    0
    Original: friesen

    I am curious to know why chinzei and xiafon do not recommend feature reports. Perhaps they prefer non control style report handling.

    As you supposed, it's because feature reports are carried by Control transfer over the default endpoint. For the stack, the handling of Control transfer is heavier than interrupt transfer. Microchip stack requires 100 us polling interval to ensure successful handling of control transfer, when the host sends control transfer contiguously. Then, overuse of Control transfer makes the firmware tight in timing.

    Feature reports are good for single use, for example, initialization just after enumeration - Host app or device driver send initial setting to the device. Or, the device reports its current setting to the host side.

    Input/output reports over interrupt endpoints are suitable to repeated use, such as communication channel for command-reply exchange, or for main data stream.

    By using control transfer reports I was able to send and receive reports without active intervention by the main program.

    The stack provides framework for class requests handling - request parser, splitting/joining transactions for long data. Then, you may think it's easier to implement your commands/data transfer to class requests. I agree with you.

    But, the stack also offers help for handling of interrupt/bulk endpoints.
    For HID,
    - HIDTxHandleBusy, HIDTxPacket
    - HIDRxHandleBusy, HIDRxPacket

    Using these functions, you can write the communication process like UART.
    Actually, the code flow of endpoint handling is quite similar to buffered UART handler.

    a) For TX of input report,
    when HIDTxHandleBusy is not busy, you'll pass a report buffer to HIDTxPacket. Then, the endpoint goes to busy, until it finishes to send the buffer.

    if ( ! HIDTxHandleBusy(USBInHandle) ) {
    //
    // fill ToSendDataBuffer[] with input report
    //
    USBInHandle = HIDTxPacket( HID_EP, (BYTE*)ToSendDataBuffer, 64 );
    }

    b) For RX of output report,
    when HIDRxHandleBusy is not busy, you'll retrieve output report from the buffer. When you finish to process the data on the buffer, you return the buffer to the stack using HIDRxPacket. Then, the endpoint goes to busy, until it receives next transaction.

    if ( ! HIDRxHandleBusy(USBOutHandle) ) {
    //
    // process output report on ReceivedDataBuffer[]
    //
    USBOutHandle = HIDRxPacket( HID_EP, (BYTE*)ReceivedDataBuffer, 64 );
    }

    c) The stack expects above endpoint processes in ProcessIO(), after "if((USBDeviceState < CONFIGURED_STATE...)" line.

    d) The HID examples on v2.3 stack declare buffers (ToSendDataBuffer, ReceivedDataBuffer) explicitly in main.c
    But you can use the buffers defined in usb_device.c, instead of these buffers.
    ToSendDataBuffer - hid_report_in[]
    ReceivedDataBuffer - hid_report_out[]

    It reduces the requirement of RAM space.


    These are all the rules.
    Is it too difficult? Smile

    Tsuneo
    post edited by chinzei - 2008/12/25 04:10:13
    #12
    janaxelson
    Starting Member
    • Total Posts : 77
    • Reward points : 0
    • Joined: 2006/02/09 18:43:28
    • Location: 0
    • Status: offline
    RE: An HID report &gt; 8 bytes... 2008/12/24 09:37:47 (permalink)
    0
    Feature reports can be useful where fast transmission isn't critical. They use control transfers, which don't have guaranteed bandwidth except for 10% of the (low- and full-speed) bandwidth reserved for control transfers to all devices. Interrupt endpoints, used for Input and Output reports, have guaranteed bandwidth.

    Because of the three stages, Feature reports have more overhead (require more bus time) than interrupt transfers.

    Every HID must have an interrupt IN endpoint, so you're wasting bus time if the device just NAKs its interrupt endpoint and sends everything in Feature reports.

    If there are multiple report IDs, Feature reports enable the host to request a specific report, while with interrupt transfers, the device decides what if anything to send.

    I've deleted the redundant edit to usb_device.c from the readme. Thank you, Tsuneo, for pointing that out.

    Jan Axelson
    www.Lvr.com 
    #13
    juanfhj
    New Member
    • Total Posts : 9
    • Reward points : 0
    • Joined: 2006/12/28 08:07:42
    • Location: 0
    • Status: offline
    RE: An HID report &gt; 8 bytes... 2009/01/03 18:45:10 (permalink)
    0
    Back in 2005 I was using Jan Axelson's v.1.x firmware for a HID loopback with 64 byte input/output reports. Just now for v2.3, I was trying to get 64 byte reports to no avail, then found that comment telling size 8 max. This struck me as odd, was there some fundamental change in the framework so that larger reports don't work now? On the other hand, the original poster seems to tell he fixed the problem, but not how. How could I do that? By naively changing endpoint descriptor sizes and i/o report sizes in usb_descriptors.c, I can't do it. Should I make changes also elsewhere?

    Thanks,

    Juan
    #14
    chinzei
    Super Member
    • Total Posts : 2250
    • Reward points : 0
    • Joined: 2003/11/07 12:39:02
    • Location: Tokyo, Japan
    • Status: offline
    RE: An HID report &gt; 8 bytes... 2009/01/06 07:43:26 (permalink)
    0
    Original:juanfhj

    Back in 2005 I was using Jan Axelson's v.1.x firmware for a HID loopback with 64 byte input/output reports. Just now for v2.3, I was trying to get 64 byte reports to no avail, then found that comment telling size 8 max.


    Which example are you working on?

    The MCHPFSUSB v2.3 has two examples for vendor-specifc HID
    - USB Device - HID - Custom Demos
    - USB Device - HID - Simple Custom Demo

    Both of the firmwares on above examples seem to support 64 bytes input/output reports over the interrupt endpoints, without any change.

    Tsuneo
    #15
    juanfhj
    New Member
    • Total Posts : 9
    • Reward points : 0
    • Joined: 2006/12/28 08:07:42
    • Location: 0
    • Status: offline
    RE: An HID report &gt; 8 bytes... 2009/01/06 18:05:23 (permalink)
    0
    Original:juanfhj

    Back in 2005 I was using Jan Axelson's v.1.x firmware for a HID loopback with 64 byte input/output reports. Just now for v2.3, I was trying to get 64 byte reports to no avail, then found that comment telling size 8 max.
    Which example are you working on?
    ...
    Both of the firmwares on above examples seem to support 64 bytes input/output reports over the interrupt endpoints, without any change.


    I'm working with the "usb device - generic hid" example for framework 2.3. The file "usb_descriptors.c" tells (in line 155:)

    // This firmware version doesn't support reports > 8 bytes.

    Now, version 1.x could be easily modified for more than 8 bytes, but I haven't been able to do the same with this version.

    Maybe it's possible with some more work, but I thought I'd ask first in case that comment *really* tells that it's known it can't be done.

    Thank you.

    Regards,

    Juan Herrera
    #16
    chinzei
    Super Member
    • Total Posts : 2250
    • Reward points : 0
    • Joined: 2003/11/07 12:39:02
    • Location: Tokyo, Japan
    • Status: offline
    RE: An HID report &gt; 8 bytes... 2009/01/06 18:34:09 (permalink)
    0
    I'm working with the "usb device - generic hid" example for framework 2.3.

    I can't find "usb device - generic hid" example in v2.3
    Maybe it's carried from the older version - when v2.3 is installed over the older one.

    Tsuneo
    #17
    xiaofan
    Super Member
    • Total Posts : 6247
    • Reward points : 0
    • Joined: 2005/04/14 07:05:25
    • Location: Singapore
    • Status: offline
    RE: An HID report &gt; 8 bytes... 2009/01/06 18:53:49 (permalink)
    #18
    chinzei
    Super Member
    • Total Posts : 2250
    • Reward points : 0
    • Joined: 2003/11/07 12:39:02
    • Location: Tokyo, Japan
    • Status: offline
    RE: An HID report &gt; 8 bytes... 2009/01/07 22:23:46 (permalink)
    0
    I see. Thanks, Xiaofan.

    Original: juanfhj

    By naively changing endpoint descriptor sizes and i/o report sizes in usb_descriptors.c, I can't do it. Should I make changes also elsewhere?

    You've already changed these points in usb_descriptors.c
    - wMaxPacketSize fields of the endpoint descriptors for interrupt IN and OUT
    - Report Count for input and output reports on the report descriptor

    Still the handler for the input and output reports is left untouched. The handler is ReportLoopBack() in generic_hid.c. Looking in this subroutine, you'll pick up these points.

    a) The buffers for the the reports
    - hid_report_out
    - hid_report_in

    These buffers should have enough size for the reports.
    The v2.3 stack reserves these buffers in usb_device.c

    usb_device.c

    #if defined(USB_HID)
    volatile unsigned char hid_report_out[ HID_INT_OUT_EP_SIZE ];
    volatile unsigned char hid_report_in[ HID_INT_IN_EP_SIZE ];
    #endif

    These constants are defined in usb_config.h
    - HID_INT_OUT_EP_SIZE
    - HID_INT_IN_EP_SIZE
    Set them to 64.

    b) The size constants for the reports
    - HID_OUTPUT_REPORT_BYTES
    - HID_INPUT_REPORT_BYTES
    usb_config.h defines these constants. Set them to 64.

    Tsuneo
    #19
    petdocvmd
    New Member
    • Total Posts : 7
    • Reward points : 0
    • Joined: 2009/06/20 19:58:16
    • Location: 0
    • Status: offline
    RE: An HID report &gt; 8 bytes... 2009/06/30 12:04:09 (permalink)
    0
    This thread has been very helpful. Might I ask for verification of a summary of the steps needed to change report size? This is in reference to the aforementioned custom HID examples, and framework v2.4.

    1. In usbconfig.h:

    A. set "#define USB_EP0_BUFF_SIZE" to size where size = 8, 16, 32 or 64
    B. set "#define HID_INT_OUT_EP_SIZE" to that size
    C. set "#define HID_INT_IN_EP_SIZE " to that size (assuming you want equivalent I/O EP sizes)
    D. set "#define HID_INPUT_REPORT_BYTES" to that size
    E. set "#define HID_OUTPUT_REPORT_BYTES" to that size (same assumption)

    2. In usb_descriptors.c:

    // The Input report
    0x09, 0x03, // Usage ID - vendor defined
    0x15, 0x00, // Logical Minimum (0)
    0x26, 0xFF, 0x00, // Logical Maximum (255)
    0x75, 0x08, // Report Size (8 bits)
    0x95, 0x20, // Report Count (2 fields) (Try 32d [0x20] just to see)
    0x81, 0x02, // Input (Data, Variable, Absolute)

    // The Output report
    0x09, 0x04, // Usage ID - vendor defined
    0x15, 0x00, // Logical Minimum (0)
    0x26, 0xFF, 0x00, // Logical Maximum (255)
    0x75, 0x08, // Report Size (8 bits)
    0x95, 0x20, // Report Count (2 fields)(Try 32d [0x20] just to see)
    0x91, 0x02, // Output (Data, Variable, Absolute)

    --> Set the bolded entries to that size (in hex) - 32d in my case.

    Note that when I tried this with a value of 64 I got a compile time error stating 'BDT' section was out of space. I'm guessing the current framework memory map has a ceiling too low for that choice..? I'm using a 4550 in a customized version of the PicDem FS USB demo board with HID bootloader firmware.

    Also, is it necessary to increase these values if time is not a huge constraint? At 8 bytes/transaction and 1 ms polling we can get our 64 bytes in roughly 8 ms, correct? Looking at the "ReportLoopback" function, it appears as if the "HIDRxPacket" and "HIDTxPacket" automatically buffer up to 64 bytes of data each way - or am I reading that incorrectly?

    Is my summary above of the necessary changes correct (I have not quite reached the point of development so as to have tested this or the buffering)? If not, any corrections and advice would be appreciated.

    Thanks!

    -Scott
    #20
    Page: 12 > Showing page 1 of 2
    Jump to:
    © 2020 APG vNext Commercial Version 4.5