We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hello everyone,
please help me find the solution to this problem:
I'm writing a composite device firmware for an Atmel SAM7S256 mcu. The firmware incorporates a usb keyboard and a HID. Because I have only 4 endpoints to use with this MCU, I am assigning 1 endpoint (EP1) to the keyboard interface, and 2 endpoints (EP2 (in) and EP3 (out)) to the other interface.
The problem is that when I write to EP3, my host program hangs (probably because the firmware hangs too). My firmware is an adaptation of the Atmel provided sample keyboard firmware. The composite device enumerates just fine (keyboard + HID).
What could be wrong?
I don't know enough of the AT91 usb stack to understand IF I have to change anything else in the code to add those 2 endpoints to the second interface. My understand is that this change would be enough:
typedef struct { USBConfigurationDescriptor configuration; // first interface USBInterfaceDescriptor interface0; HIDDescriptor hid0; USBEndpointDescriptor interruptIn0; // second interface USBInterfaceDescriptor interface1; HIDDescriptor hid1; USBEndpointDescriptor interruptIn1; USBEndpointDescriptor interruptOut1; } __attribute__ ((packed)) HIDDKeyboardDriverConfigurationDescriptors;
Here's my understanding of how HID device works: when the device firmware receives a SET_REPORT request on the control EP, it reads the content of the control EP and makes a call to USB_Read() passing the number of the endpoint to read and a call back function. So, I am checking the content of the interface #, and if it is 1, I pass the EP3 to USB_Read(). But this mechanism doesn't seem to be working for me. :(
Please help me out with any hints. Is Tsuneo still in the forum?
Thanks a million. Paulo
Ah, sorry. My code analysis was not enough. The Atmel stack requires unified decode of request including standard device requests at class implementation layer. It isn't well organized to plug in class-specific request parser, as I wrote.
> I have actually been able to create a composite of 2 HIDs.., but they have exactly the same descriptors
Do you mean both interfaces are keyboard ones? You can't put Output report from your Windows application to keyboard, because keyboard is a "system" device. For keyboard, just Feature report is allowed to exchange.
Tsuneo
>Do you mean both interfaces are keyboard ones?
No. They are two HID transfer devices. And they work nicely: from the host program, I write to the Interrupt OUT of one interface and read from the Interrupt IN of the other interface.
I was pleased that that scheme worked 'cause that was a stepping stone to this firmware I am writing now: I want to send a command through the Interrupt OUT of one interface (the regular HID transfer one), and have the other interface (the keyboard device) to send a response to the host.
What's so frustrating is that I have not been able to build any composite device from Atmel samples. The closest I got, after some changes, was to build the HIDMSD (keyboard + msd) but the enumeration fails for the MSD device.
Do you have any working composite firmware sample for the AT91SAM7S series?
Anything else I could try?
Thanks. Paulo
Indirectly, I also answered your second point about sending output report to the keyboard. I am not trying to do that; as I said, I write to the interrupt out of the HID transfer device, and expect the keyboard to send an input report back to host.
Paulo