Dan Streetman wrote: > 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. >
Sorry for the confusion. The original code of course treat this number as a binary. I rely on a simple toByte(String s) utility to convert this number (represented as "10000000") to 128. On the other hand, I have to admit that I am not fluent with such 'low-level' byte issues. I typically deal with more abstract application software. 10000000 converts to 128, which in turn with (byte)128 converts to -128, if one prints the value of this byte. One would need to issue a (byteValue & 0xff) to get the original int value. I assume that the usbDevice.createUsbControlIrp understands what is meant (that is, 128 instead of -128). Java of course treats bytes as signed bytes. > >> 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". > Ah, yes, my fault, you are right. I copied the wrong number from http://www.beyondlogic.org/usbnutshell/usb6.htm (second yellow table, first line. The 'b' in the first column obviously refers to 'binary'). > What status are you trying to get? Is this just a "test" command so > you can validate that your code is right so far? > As I did not get any response (as far as I could see), the code above was indeed meant to test the connection by inquiring about the status of the USB device. > >> 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. > OK. > Also FYI - listeners only tell you what happened to UsbIrps that YOU > submitted. Nothing will happen on the listeners without submitting a > UsbIrp. > Yes, I understood that. > >> 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. > I see. In example two, I am not sending the request according to what is expected according to the USB specification. I thought that setData(data) referred to the data part of the request that is send to the USB device and I though that the underlying code would take care of the extra bytes that are needed in the request. But you mean to say that I still would create a byte[] array with the first 8 bytes for 'setup', while the actual command byte(s) would be placed data[8] and up. Is this correct? The 'setup' part would be according to http://www.beyondlogic.org/usbnutshell/usb6.htm (first yellow table). > >> 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. > Your message has clarified quite a number of issues. I appreciate your input, Andre > >> 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 >> >> > > -- 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
