From: Jason K. <jas...@gm...> - 2010-04-19 21:56:02
|
Hey Tim - Thanks for the reply. Actually nothing works. I say the LED turns on because in my interrupt which doesn't check for anything, I turn on the LED. Putting the code that turns on the LED in the following (bmRequest==VENDOR && bRequest == PEEK) actually does nothing. It doesn't turn on the LED. Regardless, wValue and wIndex do not appear in my device and anything that I report back to the control message, which is supposed to show up in my my data[] buffer, doesn't come back. I end up with garbage. I'm essentially sending down an eeprom address, I return the value at that given address. I don't receive the address in the device, and nothing shows up in my buffer on the host. I should also say that the LED turning on can be a coincidence of me using libusb, the device being recognized as a keyboard, and the host sending down a generic class request. I turned on debugging, nothing really useful shows up, it says sending control request to endpoint 0. Any thoughts or suggestions I would greatly appreciate. Jason On Mon, Apr 19, 2010 at 2:17 PM, Tim Roberts <ti...@pr...> wrote: > Jason Kotzin wrote: > > > > I'm trying to get my firmware and software running with libusb1.0 and > > am having some trouble in windows. > > > > I've successfully ported my entire application to libusb 1.0 and it > > works just fine in OSX. I haven't tested it much in linux, but at > > first glance, everything is fine. > > > > All I really needed to do was change my usb_control_msg calls. > > > > My device appears to the computer as an HID usb keyboard, but I send > > control messages to the device to do some extra functions. It's > > critical that the device stays a keyboard, because that's what it's > > intended to be. > > > > Any control function I send down to the device doesn't really work. I > > know the message is getting down to the device because I turn on an > > LED if I see anything. I haven't turned on my debugger, but at first > > glance it looks only to be libusb_request_type_class and > > libusb_recipent_interface, nothing to do with my control request. > > So, what doesn't work? You say the message is getting to device, > because it turns on an LED. Is that the byte you return is not getting > all the way back to you? If you initialize data to something, do you > see that something remain, or does it get changes? > > BTW, requests that are not aimed at a specific endpoint should use > LIBUSB_RECIPIENT_DEVICE. When you specify LIBUSB_RECIPIENT_ENDPOINT, > Linux requires that you have claimed the interface that contains the > endpoint number in wIndex. In this case, you're specifying 0, which > should be OK, but most generic vendor commands should go to the device. > > -- > Tim Roberts, ti...@pr... > Providenza & Boekelheide, Inc. > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Libusb-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-devel > |