We are working on USB VCP driver using KMDF for multiple USB devices.
All these devices are having same VID and different PIDs.
My queries:
1> Same device when connected to different USB ports, should take different Com ports? or the same Com-port?
2> Different devices connected to Same USB port (at different time) should take different Com ports? Please clarify
3> When disconnecting a USB device, is it necessary to reset “Com (Port in use)” using registry?
i.e. depending on current PortName (Ex. Com14) , do I need to reset the corresponding “Com Name Arbitrator - ComDB” bit after “Symbolic link removal”?
4> Currently we are supporting installation through DiFxCmd.exe and wrote wrapper MSI for easy installation and uninstallation (with normal and pre-installation options).
It is loading binaries (sys and inf with cat) in DRVSTORE.
However uninstall from the “Device Manager -> Ports -> My device” is not removing these files.
IS THIS the right behavior??
if your device has a usb serial number, the com port # will stay the same as you move the device from port to port. if not, a new com port number will be assigned to as the device is plugged into a different port, the OS treats it as a new device because there is no way to globally identify the device and tell the difference between 2 instances of the same device. serial numbers fix that
yes and no. a com port number is associated with a device instance. if the device has a serial number, 2 instances of the same vid/pid plugged into the same port at different times will be treated as 2 different devices b/c the OS can tell them apart. if the device has no serial number, the OS can’t tell the difference between the 2 devices plugged into the same port so they will be treated as the same instance, htus the same com port number
no, not necessary. you only deal with the com port number arbiter on device install and uninstall, device removal just means the device is phsyically not present. it does not mean you have uninstalled it or done anything to the software install state
–> usbview shows my device iSerialNumber as 0x03.
Do I need to tweak my code anything to retain same com port when same device is connected to different USB ports (i.e. when directly to usb controllers or through external usb hub at different times)
means it also depends on the “instance id” apart from iSerial#.
ok but when device is physically disconnected, it shows Com port as “in use” (say com 3).
If I connected different device, it will get com 4. (even though com3 is free), currently we need to support 10 devices having same vid and different pid,
in this case it will occupy 10 com ports virtually, is this correct?
what is the string descriptor at index 0x03? does each device have its own unique value there?
if you have a correct serial number that the host extracts successfully, the instance ID is the serial number value extracted from the device
yes, it is sitll “in use”. think of “in use” as “claimed”. in use means that it has been assigned to a device instance and when a new instance shows up, it must get a different number since the older device can show up again and expects to use its old number
yes, you will get 10 different com port numbers for 10 different devices.
@Steven : if this device will be for the mass market - consider that users may
disable the “USB serial numbers” on this device and identify the COM ports
by instance ID. Your driver and/or coinstaller should handle this.
@Steven : if this device will be for the mass market - consider that users may
disable the “USB serial numbers” on this device and identify the COM ports
by instance ID. Your driver and/or coinstaller should handle this.
Well, although it is possible, I don’t believe this is very common, and
in any case there isn’t really very much that a driver and/or
coinstaller can (or need) do about it.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
On Tue, Jan 25, 2011 at 2:30 AM, Tim Roberts wrote: > xxxxx@fastmail.fm wrote: >> @Steven : if this device will be for the mass market - consider that users may >> disable the “USB serial numbers” on this device and identify the COM ports >> by instance ID. Your driver and/or coinstaller should handle this. > > Well, although it is possible, I don’t believe this is very common, and > in any case there isn’t really very much that a driver and/or > coinstaller can (or need) do about it. >
The trick is mainly for the manufacturing testing (it will be a huge problem for a USB serial converter manufacturer if the trick does not work), not that meant for the end users.
“Xiaofan Chen” < > wrote in message news:xxxxx@ntdev…
On Tue, Jan 25, 2011 at 2:30 AM, Tim Roberts <> wrote:
> xxxxx@fastmail.fm wrote:
>> @Steven : if this device will be for the mass market - consider that
>> users may
>> disable the “USB serial numbers” on this device and identify the COM
>> ports
>> by instance ID. Your driver and/or coinstaller should handle this.
>
> Well, although it is possible, I don’t believe this is very common, and
> in any case there isn’t really very much that a driver and/or
> coinstaller can (or need) do about it.
>
The trick is mainly for the manufacturing testing (it will be a huge
problem for a USB serial converter manufacturer if the trick does
not work), not that meant for the end users.
Thanks. Yes, for testing - but not only.
The OP may just walk to few computer stores and look at production
of competitors (-_-)
FTDI multiport adapters come with an utility that lets to manage the COM
port names
and even retain ports when the USB adapter is unplugged.
(A very good thing. don’t know how they do this).
If I may continue the discussion in thread “Device Numbers/Names” (18-20
Jan.)
sometimes user wants to distinguish devices, and sometimes - ports/places
where they are attached.
The reason to distinguish devices usually is data contained in the device.
Examples: flash drives, network adapters with unique MAC address.
Above all, serial numbers help to avoid the “new device wizard” nuisance
with unsigned drivers.
IMHO only the last reason applies to serial -USB adapters. There is nothing
unique in them.
People who have only few these adapters (or hate
“new device found” popups) can prefer serial numbers.
I’d like the COMx names for them to be derived
from the USB port where they are plugged. Then I won’t need to remember
which of them is which, and can easily carry them around, swap
and replace lost / damaged pieces.
I’d like the COMx names for them to be derived
from the USB port where they are plugged. Then I won’t need to remember
which of them is which, and can easily carry them around, swap
and replace lost / damaged pieces.
+1
Lots of device driver writers completely focus on their own glorious
devices and completely ignore real-world use cases (such as the one you
mentioned).
(Hence there are so many background daemons waiting to pounce once
“their” device is connected. Which is bad. But not as bad as CONFLICTING
daemons destabilizing the system.)
At work I sometimes need an additional serial port. For these rare
occasions I go to our admins and borrow a USB-to-serial cable for a few
days. Keeping a COM port associated with a USB port saves work.