I would be using a USB hub to connect multiple devices. I want to fix a specific USB device to a particular slot. Then check if it is done properly.
The way I am planning to achieve this is to get the complete USB path like
PCIROOT(0)#PCI(1D00)#USBROOT(0)#USB(1)#USB(2)#USB(3)#USB(3)
I can get this particular string in w7 via device property but the same is not available in wXP.
You can build this path by using the SetupAPI.
The device manager is built with this.
You start with CM_Locate_DevNode and enumerate children with CM_Get_Child.
I strongly advise you against what you're planning to do. AFAIK a USB device MUST function regardless on the USB port it's plugged in. If you'll creating such a device, forget e.g. about the "Certified for Windows" logo.
Just handle WM_DEVICECHANGE message, then use e.g. WMI to search for the USB device you're interested in. Here's my article about it: that time I coded C# language, however WMI has C++ API as well.
Related
I'm trying to write a program that sends COM port information to devices that may get unplugged and end up with a different COM port number. Using SetupDi, I know it's possible to list all the COM ports on a computer by number, but given that the number might change I'm trying to find a better way to access the COM ports.
The COM devices I'm using are FTDI serial-to-com adapters that let me program the device model. I'd love to be able to choose a COM port based on the device model. I've tried (almost) all of the properties that I can get to using SetupDi, but no dice. It looks like there's a difference between the device list SetupDi lets me access, and the devices that show up under Devices and Printers (where the model name does show up). Is there any way to get devices in the Devices and Printers window programmatically and map them to COM port using Windows APIs?
The link below is a great (if not the only) comprehensive overview on how to enumerate COM ports on Windows and extract extra information in various ways:
http://www.naughter.com/enumser.html
What we use in our own software (Docklight) is according to what the "UsingSetupAPI1" way from the enumser.cpp file shows (SetupAPI - GUID_DEVINTERFACE_COMPORT). The UsingSetupAPI1 example demonstrates how to extract the device name as shown in the Windows Device Manager, along with the COM number. This is called "friendlyNames" in the enumser.cpp code.
Another way to identify and communicating to your device could be not asking Windows in the first place, but the FTDI D2XX API:
http://www.ftdichip.com/Support/SoftwareExamples/CodeExamples.htm
We use the D2XX API for communication when we know it is always a FTDI device. Identification is simpler and we have much better performance / less latency than using Windows Communications API via "virtual COM port".
If we need to correlate between COM port numbers and a FTDI device ID, we use the FTDI D2XX API's ListDevices and GetComPortNumber functions.
I have managed to enumerate all the connected USB ports using SetupDi calls. Sample code is available at this link.
Please could any one tell me how can I find what device is connected to USB port like whether it is any HID device or any Disk drive?
Thanks.
I would recommend looking at the USBView sample in the WDK. If you are unfamiliar with this, simply run it - this tool walks the entire USB tree on the system and prints out information and descriptor listings for each device.
In your case, I'd start at the RefreshTree() function in this sample, you can then follow the code to see how it enumerates the host controllers, hubs and finally devices. For each device that you find you can look at the bInterfaceClass in the interface descriptors to find out what types of interfaces it is advertising (in your case 0x03 for HID Interface Class and 0x08 for Mass Storage Class).
The easiest way to get the source to this sample is to install the 7.1.0 WDK which is currently available here:
http://www.microsoft.com/en-us/download/details.aspx?id=11800
I'm looking to write an application that will allow me to control music, etc with a remote control. The infrared receiver I have is built into my MacBook Pro which is running Windows.
What I want to know is how can I go about this? Most of the information I can find online is specific to writing Windows device drivers and I'm having trouble finding out how to use drivers that already exist for a device.
Is it absolutely necessary for me to write my own drivers or is there a way to use the drivers provided by Apple?
On Windows you communicate with a driver by first opening it using CreateFile and subsequently sending commands to it using DeviceIoControl. You need documentation for the driver's API though to understand what functionality is available through which control codes and what parameters they expect. Digging up that information is probably the hard part.
First of all, we are working with a 3rd party software that ties itself to a USB device. When this USB device is disconnected and reconnected, the software cannot communicate with the device will stop working until the program is restarted. i.e. It only detects the USB device on startup.
Windows is able to see the device, but goes through the full detection/driver installation procedure every time it is reconnected, even if it is reconnected to the same USB port.
The difficulty here is that we have no way of modifying the third party software to poll for the appropriate USB device after the device is unplugged.
As such, we would like to ask if anyone has knowledge on how to go about writing a c++ program to save a USB state/register, prevent Windows from re-enumerating the USB port upon re-connection, and restoring the saved state/register. If so, we would appreciate some guidance in this endeavor. Naturally, we are open to other approaches to solving this issue.
You can't do this at application level. USB is managed by drivers. Furthermore, while the details of USB devices are managed by specific drivers, the basics (such as enumeration) are handled by the standard Windows USB driver. That's logical: Windows has to enumerate the device first to determine its Vendor ID and Product ID, which then determines the specific driver to load.
As for the full reinstallation on every reinsertion, that suggests a violation of the USB spec by the device or the Windows API by the driver. My first guess would be that the device doesn't have a proper serial number.
I'm trying to write an application that will take specific action when it detects an overcurrent condition on any USB port.
However, my googlefu is not able to come up with anything useful (though I can now tell you 101 ways to fix a USB overcurrent problem).
Is there are standard windows API to retrieve USB status info?
If not is there another/better way to detect USB overcurrent conditions programatically?
As far as I can see here http://msdn.microsoft.com/en-us/library/ff539687 you need to turn to the WDK (Window Driver Kit).