Eureka! It works. Thanks Dan. I'd never have gotten there without your help.
I'm going to create a lib for this device and will post back here when it's done. Cheers Jem Dan Streetman wrote: > Close, but look down where is says "SetupPacket". This is what you're > interested in. I don't know why it lists the > "RequestTypeReservedBits" different from the actual bmRequestType > (which is byte 0 of the setup packet), but in any case this shows it > as 0x48. So try > > UsbControlIrp usbControlIrp = device.createUsbControlIrp( > (byte)0x48, (byte)0x12, (short) 0x20a, (short)0x006); > usbControlIrp.setData(new byte[0]); > > > On Sun, Aug 17, 2008 at 3:23 AM, Jeremy Mawson <[EMAIL PROTECTED]> wrote: >> Thanks Dan >> >> I'm really amazed at the amount of help you've been able to give me. >> Thank you. >> >> I think your guess is spot-on, although it still has not worked for me. >> I say this because I have used the device successfully under windows >> (using manufacturers software) and have used SniffUsb to trace the >> control message values. For turning the light green it reported: >> >> [463107 ms] UsbSnoop - FilterDispatchAny(b3c27fd2) : >> IRP_MJ_INTERNAL_DEVICE_CONTROL >> [463107 ms] UsbSnoop - FdoHookDispatchInternalIoctl(b3c281ea) : >> fdo=854f76a8, Irp=85618008, IRQL=0 >> [463107 ms] >>> URB 6 going down >>> >> -- URB_FUNCTION_VENDOR_DEVICE: >> TransferFlags = 00000000 (USBD_TRANSFER_DIRECTION_OUT, >> ~USBD_SHORT_TRANSFER_OK) >> TransferBufferLength = 00000000 >> TransferBuffer = 00000000 >> TransferBufferMDL = 00000000 >> >> no data supplied >> UrbLink = 00000000 >> RequestTypeReservedBits = 00000008 >> Request = 00000012 >> Value = 0000020a >> Index = 00000006 >> [463109 ms] UsbSnoop - MyInternalIOCTLCompletion(b3c28126) : >> fido=00000000, Irp=85618008, Context=8559b538, IRQL=2 >> [463109 ms] <<< URB 6 coming back <<< >> -- URB_FUNCTION_CONTROL_TRANSFER: >> PipeHandle = 857a0958 >> TransferFlags = 0000000a (USBD_TRANSFER_DIRECTION_OUT, >> USBD_SHORT_TRANSFER_OK) >> TransferBufferLength = 00000000 >> TransferBuffer = 00000000 >> TransferBufferMDL = 00000000 >> UrbLink = 00000000 >> SetupPacket = >> 00000000: 48 12 0a 02 06 00 00 00 >> >> I translated these values into my test code: >> >> UsbDevice device = locateDevice( >> rootHub, "Delcom Engineering", "USB Visual Indicator"); >> UsbControlIrp usbControlIrp = device.createUsbControlIrp( >> (byte)0x08, (byte)0x12, (short) 0x20a, (short)0x006); >> usbControlIrp.setData(new byte[0]); // have also tried byte[8] & [255] >> device.syncSubmit(usbControlIrp); >> >> The result is still: javax.usb.UsbStallException: Error submitting IRP >> >> I checked the USB 2.0 spec and learnt that STALL infers that the control >> IRP I'm sending is not understood by the device. At this stage it feels >> like I need to tweak the control IRP just a little, but how I'm not >> sure. All the tweaking I do continues to yield only STALL. >> >> Does the trace provided above indicate where I might be getting it wrong? >> >> >> >> Dan Streetman wrote: >>> Nothing in that spec corresponds to anything in USB. But my best >>> guess - and purely a guess - based solely on the size of their >>> "command", is it maps: >>> >>> "Recipient" -> bmRequestType >>> "Device Model" -> bRequest >>> "Major/Minor Command" -> wIndex >>> "Data LSB/MSB" -> wValue >>> "Length" -> data length >>> "DataExtension" -> data >>> >>> You'll have to convert the major/minor command and data lsb/msb into >>> shorts for the wIndex and wValue. Note that the USB spec requires >>> them to be in little endian. >>> >>> >>> >>> On Sat, Aug 16, 2008 at 1:17 AM, Jeremy Mawson <[EMAIL PROTECTED]> wrote: >>>> This is the device: >>>> http://www.delcom-eng.com/productdetails.asp?productnum=804005-B >>>> >>>> The "spec" is linked in that page as "USB Indicator Manual" ( >>>> http://www.delcom-eng.com/downloads/USBVIDM.pdf ) >>>> >>>> The document describes how you can use the Windows driver, or you can >>>> use the direct method. I'm following instructions from the latter >>>> section (5.3), specifically "Device I/O Control" on p12. >>>> >>>> DeviceIOControl is a Windows library function. >>>> http://msdn.microsoft.com/en-us/library/aa363216(VS.85).aspx So whilst >>>> it's called the "Direct Method", it's direct to Windows system services >>>> and may still be Windows specific. >>>> >>>> >>>> >>>> >>>> >>>> Dan Streetman wrote: >>>>> That really doesn't seem like it corresponds to the control parameters >>>>> at all, at least not from any of the text. Are you sure that spec is >>>>> for a usb version of your device? Also, it mentioned the >>>>> "DeviceIOControl" function - maybe this "spec" is not a device spec at >>>>> all, but a libarary spec, that tells you how to interface with a >>>>> proprietary library they provide, which then converts the library >>>>> calls you make into the actual USB requests to send to the device. If >>>>> this is the case, the spec will almost certainly not help you at all, >>>>> since the actual USB work would be done inside the proprietary >>>>> library, and hidden from you. >>>>> >>>>> If you explain in detail what you have, including the "spec" and any >>>>> other components and/or software, as much as you know about the >>>>> device, web links, what the device is, etc., it might help. >>>>> >>>>> >>>>> On Fri, Aug 15, 2008 at 11:39 PM, Jeremy Mawson <[EMAIL PROTECTED]> wrote: >>>>>> Thanks for your patience Dan. >>>>>> >>>>>> The device spec is very Windows & C-centric, so the information is not >>>>>> obvious to me. >>>>>> >>>>>> It mentions the need to construct a CTL (control?) code to send to the >>>>>> DeviceIOControl() function. The CTL code definition seems to roughly >>>>>> match the four parameters required by UsbDevice.createUsbControlIrp(). >>>>>> >>>>>> "The CTL Codes are predefined codes that describe the desired action >>>>>> to take place. There are many different codes but for our purposes we >>>>>> are only concerned with the send packet code. >>>>>> Below is the CTL_CODE generation shown in C." >>>>>> >>>>>> #define CTL_CODE( DeviceType, Function, Method, Access ) ( \ >>>>>> ((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | >>>>>> (Method)) >>>>>> #define METHOD_BUFFERED 0 >>>>>> #define FILE_ANY_ACCESS 0 >>>>>> #define FILE_DEVICE_UNKNOWN 0x00000022 >>>>>> // --------------------------------------------------------- // >>>>>> #define DELCOM_USBIO_IOCTL_VENDOR 0x0800 // Vendor defined >>>>>> #define IOCTL_USBIO_WRITE_PACKET CTL_CODE(FILE_DEVICE_UNKNOWN, \ >>>>>> DELCOM_USBIO_IOCTL_VENDOR+10,\ >>>>>> METHOD_BUFFERED, \ >>>>>> FILE_ANY_ACCESS) >>>>>> >>>>>> This resolves to 0x222028, but that value doesn't help me to get the >>>>>> arguments to usbDevice.createUsbControlIrp(). >>>>>> >>>>>> At a guess I've tried mapping DeviceType->bmRequestType, >>>>>> Function->bRequest, Method->wValue & Access->wIndex. But >>>>>> Function=0x2028, which is too large for the byte value bRequest. >>>>>> >>>>>> Can anyone help me to decipher the correct usb control irp parameters >>>>>> from the #defines? >>>>>> >>>>>> >>>>>> >>>>>> Dan Streetman wrote: >>>>>>> On Fri, Aug 15, 2008 at 6:03 PM, Jeremy Mawson <[EMAIL PROTECTED]> >>>>>>> wrote: >>>>>>>> Indeed it does. It says: >>>>>>>> >>>>>>>> So the command is easy to construct, but how to transmit it? As far as >>>>>>>> I >>>>>>>> can see, there's no concept of a USB command in the javax.usb API. >>>>>>> No, you misunderstand - you doc needs to tell you what endpoint/pipe >>>>>>> to send the "command" to (there are no "commands" in the USB spec). >>>>>>> If that endpoint/pipe is a control endpoint/pipe, then your spec also >>>>>>> needs to tell you what to fill in the control-specific fields with. >>>>>>> The section you listed regards ONLY the data portion of the "command". >>>>>>> >>>>>>>> The only method in StandardRequest that will accommodate a freeform >>>>>>>> byte[] is setDescriptor, but that doesn't sound right. >>>>>>>> >>>>>>>> I've tried the UsbControlIrp strategy without success. It may be that >>>>>>>> I'm setting the constructor params incorrectly. >>>>>>>> >>>>>>>> Once I've constructed the command, which method transmits it? >>>>>>> Again, *your spec needs to tell you this*. >>>>>>> >>>>>>> >>>>>>>> Dan Streetman wrote: >>>>>>>>> You need to figure out how to format those fields into a USB command. >>>>>>>>> I would expect your manual to have that info somewhere in it. >>>>>>>>> >>>>>>>>> On Fri, Aug 15, 2008 at 9:37 AM, Jem <[EMAIL PROTECTED]> wrote: >>>>>>>>>> Hi >>>>>>>>>> >>>>>>>>>> I have a manual for the USB device I'm trying to control that >>>>>>>>>> describes the >>>>>>>>>> bytes I need to transmit to the device in order to perform functions. >>>>>>>>>> >>>>>>>>>> For example if I wish to turn it green (it's a light) I'd transmit: >>>>>>>>>> >>>>>>>>>> Recipient Byte: 8 >>>>>>>>>> Device Model Byte: 18 >>>>>>>>>> Major Command Byte: 10 >>>>>>>>>> Minor Command Byte: 34 >>>>>>>>>> Data LSB: 0 >>>>>>>>>> Data MSB: 80 >>>>>>>>>> Length Short: 0, 0 >>>>>>>>>> >>>>>>>>>> I'm not sure how I translate this to methods in the API. Can I use a >>>>>>>>>> method >>>>>>>>>> on StandardRequest? >>>>>>>>>> >>>>>>>>>> Alternatively, I tried the following, which resulted in a >>>>>>>>>> usbStallException: >>>>>>>>>> >>>>>>>>>> byte bmRequestType = >>>>>>>>>> UsbConst.REQUESTTYPE_DIRECTION_OUT | >>>>>>>>>> UsbConst.REQUESTTYPE_TYPE_STANDARD | >>>>>>>>>> UsbConst.REQUESTTYPE_RECIPIENT_DEVICE; >>>>>>>>>> byte bRequest = UsbConst.REQUEST_SET_FEATURE; >>>>>>>>>> short wValue = UsbConst.DESCRIPTOR_TYPE_DEVICE << 8; >>>>>>>>>> short wIndex = 0; >>>>>>>>>> >>>>>>>>>> byte[] buffer = new byte[]{8,18,10,34,0,80,0,0}; >>>>>>>>>> UsbControlIrp usbControlIrp = >>>>>>>>>> usbDevice.createUsbControlIrp(bmRequestType, bRequest, wValue, >>>>>>>>>> wIndex); >>>>>>>>>> usbControlIrp.setData(buffer); >>>>>>>>>> usbDevice.syncSubmit(usbControlIrp); >>>>>>>>>> >>>>>>>>>> Am I on the right track? >>>>>>>>>> >>>>>>>>>> Thanks for any help >>>>>>>>>> Jeremy >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> javax-usb-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/javax-usb-devel >> > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ javax-usb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/javax-usb-devel
