On Wed, Oct 14, 2009 at 3:49 PM, Andre Juffer <ajuf...@sun3.oulu.fi> wrote: > UsbDevice usbDevice = .... > byte[] data = new byte[2]; > byte bmRequestType = (byte)10000000;
I think you do not quite understand the different between decimal (the default base for numbers) and binary. I suspect you want *binary* 10000000, or hex 0x80, or decimal 128. You are quite lucky as 10000000 decimal just happens to be 0x989680 hex, which casts to a byte of 0x80 so your code "works" although only by luck. > byte bRequest = (byte)0x00; > short wValue = 0; > short wIndex = 2; Oops, you are violating the spec here. You can't send a Device Status request with a non-zero wIndex. See the usb spec section 9.4.5. Specifically the device response to this is "undefined". What status are you trying to get? Is this just a "test" command so you can validate that your code is right so far? > UsbControlIrp controlIrp = > usbDevice.createUsbControlIrp(bmRequestType, > bRequest, wValue, wIndex); > controlIrp.setData(data); > usbDevice.asyncSubmit(controlIrp); > > > I observe that the request has been sent. Attached to the UsbDevice is a > UsbDeviceListener, which informs me that the data has been sent. I have > also attached to all USB pipes (there are two endpoints, call them > DIRECTION_IN and DIRECTION_OUT) listeners. The device response will be in those 2 data bytes, since this is a control-type IN (Device to Host) transfer. Check the actual length of the irp to see how many bytes the device sent. Also FYI - listeners only tell you what happened to UsbIrps that YOU submitted. Nothing will happen on the listeners without submitting a UsbIrp. > Another example: the device also has its own set of command bytes, e.g. > there is a simple ping command (according to the documentation of the > device, the data buffer would contain just one byte): > > usbPipe usbPipeOut = ..... // Attached to DIRECTION_OUT > byte[] data = new byte[1]; > data[0] = (byte)0x00; > UbIrp irp = usbPipeOut.createUsbIrp(); > irp.setData(data); > usbPipeOut.asyncSubmit(irp); > > Again, I see that the request is made (no exceptions, everything seems > fine). The listener reports to me that it was notified accordingly. > > In both examples, the device is suppose to send a response. E.g. in the > second example, the first byte of data buffer would contain (again) an > 0x00 (which it actually has, but of course is was already there). And in > the first example (the status request), the device should return a two > byte status report (I think, the USB standard is really massive, my > interpretation may be completely wrong). > > My question is two-fold: > 1. Is the code given above correct? It is semantically correct (except your binary/decimal confusion) but I can't say that is is correct with respect to your specific device protocol (in example 2), since that isn't specified by the USB spec. In example 1, since that is a standard USB request, if you fix the spec violation as I indicated it should work fine. > 2a. Example 2: Should I expect a response of the device sent through the > USB pipe attached to DIRECTION_IN (so not through the USB pipe that was > used to -send- the (control) command, attached to DIRECTION_OUT)? Since getting a response on a (non-control) OUT pipe is impossible, you'll never get any response on it. You can get responses on an IN pipe, but you have to provide a buffer for the response to go into. > 2b. Example 1: Is the response by the device stored in the data buffer. > But upon return, the data buffer is not modified at all. If you submit a correct get status request, then yes the data buffer you provided will be filled with the device response. Check the actual length to find how many bytes the device sent. > > > Until now, I have not seen response (or there may have been a response, > but I just don't know where to look for it). For example 1, the device "response" is in the actual data buffer you sent. For communication with the device on the non-control IN pipe, you need to provide a data buffer, meaning you have to submit a UsbIrp with an appropriately sized buffer (for interrupt and isochronous pipes, it should be the endpoint's wMaxPacketSize; for bulk pipes, it can be any size you want). After asyncSubmitting that buffer, it will remain "pending" (i.e. the USB Host Controller hardware will poll the device) until the device responds with data, at which time you will get the UsbIrp back and it will show up in your pipe listener. You must submit another UsbIrp if you want to get any more data from the device (you can submit another buffer in the listener's handler method, for example). You can submit multiple buffers with multiple asyncSubmits to "queue up" buffers on the pipe so there will never be any "gap" in the polling. The USB spec goes into more detail on how IN direction pipes provide data via polling and the associated timing requirements. For interrupt IN pipes, you need to use multiple buffers to guarantee that polling interval requirement. > > Thanks for your help, > > -- > Andre H. Juffer | Phone: +358-8-553 1161 > Biocenter Oulu and | Fax: +358-8-553-1141 > Department of Biochemistry | Email: andre.juf...@oulu.fi > University of Oulu, Finland | WWW: www.biochem.oulu.fi/Biocomputing/ > StruBioCat | WWW: www.strubiocat.oulu.fi > NordProt | WWW: www.nordprot.org > Triacle Biocomputing | WWW: www.triacle-bc.com > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > javax-usb-devel mailing list > javax-usb-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/javax-usb-devel > ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ javax-usb-devel mailing list javax-usb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/javax-usb-devel
