HID class and interrupts

[Jacob Portukalian]

Are the

CALLBACK_HID_Device_CreateHIDReport

and

CALLBACK_HID_Device_ProcessHIDReport

functions in the Generic HID example program called from an interrupt or in the main code?

Thanks,

Jacob Portukalian

[Dean Camera]

Potentially both - if INTERRUPT_CONTROL_ENDPOINT is specified, the
callbacks will fire from both interrupt (via the control endpoint) and
non-interrupt (data endpoint(s)) contexts.

- Dean

[Jacob Portukalian]

Thanks.  So if I understand this correctly, if you _don't_ add the INTERRUPT_CONTROL_ENDPOINT token then those callbacks get called only in the main program context.

I have been having some weird issues where I can modify data from those callbacks but if I call a function that modifies the same data from those callbacks the data does not get modified.  I thought I was having an issue due to interrupts but I guess that's not it.

Jacob

--
You received this message because you are subscribed to the Google Groups "LUFA Library Support List" group.
To post to this group, send email to lufa-s...@googlegroups.com.
To unsubscribe from this group, send email to lufa-support...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lufa-support?hl=en.

[Jacob Portukalian]

OK, so I'm exposing my lack of USB understanding here.  I realize now that CALLBACK_HID_Device_CreateHIDReport is getting called multiple times, not just when I want to get my data from the chip.

Now I just have to figure out how to identify when the callback is a result of me trying to get data.  Any suggestions?

Jacob

[Dean Camera]

> OK, so I'm exposing my lack of USB understanding here. I realize now that
> CALLBACK_HID_Device_CreateHIDReport is getting called multiple times, not
> just when I want to get my data from the chip.

Yes - the HID class isn't designed for generic data transfers, and
instead is geared towards volatile data from sensors that are attached
to humans (hence the class name, "Human Interface Device") which can
be polled at any point in time. The host will query the current report
values on enumeration after the device is inserted into the host, and
then poll the device periodically thereafter asking for new data.

> Now I just have to figure out how to identify when the callback is a result
> of me trying to get data. Any suggestions?

Most people use a handshake system; you send a generic "Query New
Information" packet to the device via a SET REPORT request, with an
ID. The device then performs any processing needed, and on the next
poll request from the host, you would return the ID last sent from the
host plus a "No Data" indicator or the requested data. As long as the
ID from the host keeps changing you can use that to associate specific
requests and responses for proper communications.

Cheers!
- Dean

On Aug 17, 9:34 am, Jacob Portukalian <jportukal...@gmail.com> wrote:
> OK, so I'm exposing my lack of USB understanding here.  I realize now that
> CALLBACK_HID_Device_CreateHIDReport is getting called multiple times, not
> just when I want to get my data from the chip.
>
> Now I just have to figure out how to identify when the callback is a result
> of me trying to get data.  Any suggestions?
>
> Jacob
>
> On Tue, Aug 16, 2011 at 9:14 AM, Jacob Portukalian

> <jportukal...@gmail.com>wrote:

>
>
>
>
>
>
>
> > Thanks.  So if I understand this correctly, if you _don't_ add the
> > INTERRUPT_CONTROL_ENDPOINT token then those callbacks get called only in the
> > main program context.
>
> > I have been having some weird issues where I can modify data from those
> > callbacks but if I call a function that modifies the same data from those
> > callbacks the data does not get modified.  I thought I was having an issue
> > due to interrupts but I guess that's not it.
>
> > Jacob
>