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

Reply via email to