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
