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 > ------------------------------------------------------------------------- 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
