Xiaofan,
thanks for your thoughts.
Am 22.01.13 05:56, schrieb Xiaofan Chen:
On Fri, Jan 18, 2013 at 5:49 AM, <derRolf@xxxxxxxxxxxxxx> wrote:
thanks for your thoughts. Yes, we have our own VID/PID. However, our
software needs to operate multiple devices with the same VID/PID
(multi-threaded). The only difference between the devices is the serial
number, which is unique for each device. We have settings and configuration
data for the devices, which applies to the specific device (i.e. serial
number). Depending on the serial number (i.e. device type) we boot different
FPGA bitstreams.
This same VID/PID thingy seems to be quite popular among FTDI
device, one example is Amontec Jtag debuggers, they have
a few device (some of them full-speed, some of them high speed)
but all of them share the same VID/PID. I asked why and the reason
is that they have a WHQL driver (FTDI drivers modified to use their
own PID) and they do not want to break the WHQL signature by
adding another PID. And WHQL process takes time and money.
There are more reasons for this. While we have a WHQL signed driver,
it's INF file covers
all the 8 PIDs we received from FTDI. We are using FTDIs VID (cost reasons).
But we have
- more device types than PIDs (using different PIDs for product families)
- are handling all the devices under one PID with the same software (so
the idea to find the driver by PID/VID is still valid)
But even with just one device type (same VID/PID) it makes sense to
connect more than one device of this type to a computer. And still have
settings per device identified by serial number. This is something that
libftdi can't do without the patch (as far as I understand).
Actually I don't think any application could be broken by the patch. If the
device is not found, the code still returns the error. It's just that right
now the search for the device ends if another device that comes first in the
list has already been opened. From my point of view this is a bug (but one
that only happens if you play with multiple devices from the same process).
I understand that you don't want to apply any changes before the 1.0
release. That's fine, I don't use the release code but the git head. But it
would be good if the patch could be applied after the release is out. Right
now we have patched our git clone and are merging on each pull from
upstream.
I think this patch is good to have post 1.0 release. But before merging,
it needs more testing.
Thanks for supporting this patch.
--
Rolf
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
