Ports
April 23, 2014, 12:48:56 pm *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: SMF - Just Installed!
 
   Home   Help Search Login Register  
Welcome to the PORTS Forum. Please post your questions, answers, and comments relating to USB and other hardware interfaces in the appropriate forums below.

IMPORTANT! This forum is is moving to JANAXELSON.COM. The new site is live now. Try it: http://janaxelson.com/forum. Please update your bookmarks and links. After June 1, 2014, this forum will be available ONLY at janaxelson.com and links to content at lvr.com will no longer work. - Jan
Pages: [1]
  Print  
Author Topic: USB descriptors from User mode application  (Read 2376 times)
J.R. Heisey
Member
*
Posts: 3


« on: April 03, 2012, 11:08:50 pm »

I have been looking at the UsbView sample application in the latest DDK. I find it very confusing to determine how to read a specific USB deviceís string descriptors.
 
- I would like the simplest way in which to read the iProduct string.
  - I have code to determine the device path.
  - The USB device may be under control by a user mode application using WinUSB at the time I want to read the string descriptors. This makes connecting to the control endpoint not possible.
  - Obviously the USBView application does not need to open the control endpoint to read the string descriptors.
 
Do you have knowledge of a user mode sample application which is simpler than USBView what will demonstrate the capability I seek?
 
My goal is to be able to distinguish between three different hardware versions of a USB device.
- I donít want to change the idProduct value because I would need to change my INF file resulting in Microsoft WHQL recertification.
- The device class is 0xFF for propriety.
- This not a consumer device and is not being sold commercially.
- I am open to other options. Perhaps I can create a custom data item in the Device Descriptor? I would need a 16 bit WORD value.

Thanks
Logged
Jan Axelson
Administrator
Frequent Contributor
*****
Posts: 2041


WWW
« Reply #1 on: April 04, 2012, 08:55:17 am »

USBView is the only example code I'm aware of.

If you are writing the WinUSB application, you can probably share the Product ID string with another application. See:

http://www.codeguru.com/csharp/csharp/cs_syntax/remoting/article.php/c6901/NET-Remoting-in-Visual-C.htm

If you are writing the device firmware, you could add a HID or other interface whose only function is to return the Product ID string.

Why do you need the Product ID string? What will you do with it when you have it?

Jan
« Last Edit: April 04, 2012, 09:43:07 am by Jan Axelson » Logged
J.R. Heisey
Member
*
Posts: 3


« Reply #2 on: April 06, 2012, 01:30:09 am »

My intention is to identify the specific hardware implementation.
It would be preferable to use a hardware ID which is accessible one a exclusive connection is made.
The product ID string has a name that coincides with the hardware ID if I can get it without explicitly connecting to the device.

It appears that the USBView app requests the product ID from the parent hub by the port address.
Can I query for a device's parent without having to enumerate everything to find it?
Logged
Jan Axelson
Administrator
Frequent Contributor
*****
Posts: 2041


WWW
« Reply #3 on: April 07, 2012, 08:25:11 pm »

Why do you need to identify the specific hardware implementation? What will you do with that information? Knowing the answer might bring up a different solution.

Jan
Logged
J.R. Heisey
Member
*
Posts: 3


« Reply #4 on: April 08, 2012, 01:29:33 am »

Simply to identify the hardware implementation.
This is then used to determine some specific capabilities.

Your link gave me an idea. I have an API which all apps use. The API can create a shared memory block. A connected app will cause the API to write the hardware ID into the shared memory from where the other apps can read it.

J.R.
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!