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
