USB HID rom driver

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

USB HID rom driver

455 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by mindless on Sun Jun 20 15:06:52 MST 2010
Hello:

I'm playing around with the HID rom-based driver.
I'm having some questions regarding its behaviour and cannot find any related documentation.

I modified the example so that the packet size is 64 byte long and single write/read reports works ok. However, if I try to read a larger amount of data in 64B chunks I'm unable to do it.

The  src and dst buffers in the report callbacks are located in USB ram space and both point to the same address. My polling interval is set to 32ms and as far as I can see with the JTAG, the GetInReport function is called periodically (SetOutReport isn't). My problem is that I cannot distinguish between a periodic call or a real reading from the PC host side and thus, the responses got mixed up and I read random packets every time.

This happens because I increment a pointer in each call to GetInReport to point to the next 64B chunk but not every call to GetInReport belongs to the multiple read in the PC side...

I guess that the rom-based driver might not be intended to do this but if somebody could shed a light on it, it'll be much appreciated.

Regards,
mindless
0 Kudos
Reply
4 Replies

395 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by mindless on Wed Jun 23 02:47:57 MST 2010
Tsuneo helped me directly and indirectly on different topics regarding USB and, particularly on this one I fully agree with him. The usage of the HID rom driver is very limited and doesn't fit most practical applications.

Cheers, mindless.
0 Kudos
Reply

395 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by igorsk on Wed Jun 23 02:42:15 MST 2010
Tsuneo Chinzei has some harsh words to say about the ROM driver:

Quote:
LPC13xx on-chip HID driver (AN10904) is useless for practical application,
including the examples in this appnote. In this driver (stack), GetInReport() is
called directly from the IN endpoint ISR, like above Keil example. As you've
experienced, there is no option for the IN EP ISR to finish without sending any
input report.
[...]
Of course, if we would replace entire isr(), we could manage to customize the
stack as we like. But it means we have to supply almost all of the stack by
ourselves. So, this driver (stack) is useless.
[...]
I have doubt that the programmer of this ROM driver would have any experience of practical application.



I wonder if NXP has any comments ;)

He also links to this thread with pretty in-depth explanation of how HID is supposed to work.
0 Kudos
Reply

395 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by mindless on Wed Jun 23 00:54:20 MST 2010
Hi Johnny,

Thanks for your answer.
I think that my problem is the limitation that the HID rom driver offers - to my eyes - whenever the user tries to do something different from the example provided.


The callbacks for in/out reports are:

void GetInReport (uint8_t src[], uint32_t length)
void SetOutReport (uint8_t dst[], uint32_t length)

In the rom implementation there's no way to send a Report to the PC asynchronously and there's no way to not answer a report when an IN report arrives either.

Are the following facts correct?
1. The GetInReport callback is called ONLY periodically.
2. The SetOutReport callback is called ONLY when the PC app sends an output report.

In my non-working application, the PC side attemps to read 1024B in 64B chunks so after a specific OUT report arrives, I reset a pointer and start filling out the src buffer with 64B chunks in every call to GetInReport.

However I can't get the 1024B on the PC side. Debugging the PC side I found out that there are missing chunks and also the first received chunk on the PC is not always the same - sometimes it's the 2nd one I meant to send from the LPC, some others it's the 3rd and so forth... -

Cheers,
mindless
0 Kudos
Reply

395 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by jhalfmoon on Tue Jun 22 12:53:19 MST 2010
Hi,

The USB HID specs indicate a max packet size of 64 for high-speed devices, so you seem to be okay what that is concerned, if you are using high-speed mode. See

http://www.usb.org/developers/hidpage/

and specifically

http://www.usb.org/developers/devclass_docs/HID1_11.pdf

Quote from page 27:

<quote>
5.6 Reports
Using USB terminology, a device may send or receive a transaction every USB frame (1 millisecond). A transaction may be made up of multiple packets (token, data, handshake) but is limited in size to 8 bytes for low-speed devices and 64 bytes for high-speed devices. A transfer is one or more transactions creating a set of data that is meaningful to the device—for example, Input, Output, and
Feature reports. In this document, a transfer is synonymous with a report.
</quote>

I didn't really dig any further at this point, but I suspect you may find the answer to your question in the HID specs document.

Hope that helps. Cheers,

Johnny
0 Kudos
Reply