Afaik, the LinkUSB is only using a single VID/PID (0403/6001), which is
shared by all FTDI serial adapters. The latency/buffer sizes are
identical on power up as well. As far as I know, I have no way of
knowing if the FTDI USB device is a LinkUSB or a random serial dongle
connected to who-knows-what.
The problem is thus not that we don't know the VID/PID, the problem is
that OTHER things have the SAME VID/PID.
With a regular link, the user has to specify --link=<device>.. correct?
There is no autodetect for those. So the threshold would just be that we
have another way of identifying the linkusb.
Is the USB monitor code active by default if libusb is present, or do
you have to enable it on startup with --usb-monitor or something?
We could update the USB monitor code to scan for 0403/6001, and unless
explicitly told (via --linkusb=<serial> or --linkusb=none), we send a "
" to all those FTDI devices and see what it might reply.
* Most users will have one LinkUSB device, and it would be autodetected.
* Users with LinkUSB devices, and non-LinkUSB ftdi devices, would have
to use --linkusb=<explicitserial> to disable monitoring and only use
that serial.
* Users with NO LinkUSB devices, and non-LinkUSB ftdi devices, would
have to use --linkusb=none to disable monitoring totally.
Problems could arise in case user has a FTDI device which fails if a
space is received.. which we cannot really know for sure.. :)
An alternative would be to add a standalone "scanner" mode, which just
outputs command line string with detected serials.
Another barrier is that the user has to ensure that the running user has
access to the device, or the bus scan won't find it at all. We cannot
even tell the user "We failed to find the device", unless explicitly
told that we should be looking for one. If we are explicitly told which
serial to use though, we can try to open it, but will get permission
denied if that is the case (if I recall correct).
On 23/06/14 14:39, Paul Alfille wrote:
> How about imbedding a list of known good vid/pid numbers and including
> a command-line switch of "--forceftdi" to let people test others.
>
> Or actually probe for the latency and buffer sizes you mentioned.
>
> I'm not a big fan of command-line switches. They raise the barrier for
> new users. I'd rather things "just work" perfectly. But since this
> would only be an optional test it might be a good solution.
>
>
> On Mon, Jun 23, 2014 at 1:54 AM, Johan Ström <jo...@stromnet.se
> <mailto:jo...@stromnet.se>> wrote:
>
> Thank you! Looking forward to feedback from more experienced
> owfs-eyes.. :)
>
> Scanning the USB bus for vid/pid should be no problem. However,
> the DS9490R seems to use a special vid/pid, where the LinkUSB uses
> a generic "any-kind-of-ftdi-based-adapter"-vid/pid. Unfortunately
> the dumped strings doesn't seem to help much either:
>
> My LinkUSB:
>
> ugen4.2: <FT232R USB UART FTDI> at usbus4, cfg=0 md=HOST spd=FULL
> (12Mbps) pwr=ON (90mA)
> bLength = 0x0012
> bDescriptorType = 0x0001
> bcdUSB = 0x0200
> bDeviceClass = 0x0000
> bDeviceSubClass = 0x0000
> bDeviceProtocol = 0x0000
> bMaxPacketSize0 = 0x0008
> idVendor = 0x0403
> idProduct = 0x6001
> bcdDevice = 0x0600
> iManufacturer = 0x0001 <FTDI>
> iProduct = 0x0002 <FT232R USB UART>
> iSerialNumber = 0x0003 <A900fx3D>
> bNumConfigurations = 0x0001
>
> Compared to another RS232-dongle (identical fields omited):
> ugen3.3: <USB FAST SERIAL ADAPTER FTDI> at usbus3, cfg=0 md=HOST
> spd=FULL (12Mbps) pwr=ON (44mA)
> bcdUSB = 0x0110
> iProduct = 0x0002 <USB FAST SERIAL ADAPTER>
> iSerialNumber = 0x0003 <FTCDDBSX>
>
> Not so much to go on.. the iProduct string is different, but I bet
> the chip is not exactly the same, and that any FT232R based design
> identifies itself as "FT232R USB UART"..
>
> Johan
>
>
> On 23/06/14 00:44, Paul Alfille wrote:
>> This is incredible work. Definitely will add to the master branch
>> once the final touches and test are done.
>>
>> It's easy, using libusb, to read the vendor/product code. We do
>> it for DS9490R adapters now. Beyond vendor/product codes, there
>> are many other USB strings. One of them might be characteristic
>> of all the relevant FTDI adapters, even custom runs.
>>
>> Paul
>>
>>
>> On Sun, Jun 22, 2014 at 5:20 PM, Johan Ström <jo...@stromnet.se
>> <mailto:jo...@stromnet.se>> wrote:
>>
>> ....
>>
>> > I do have one thing on the todo list, and that is
>> auto-detection.
>>
>> > Currently you have to explicitly specify a LinkUSB FTDI
>> serial number
>> > (Linux: lsusb, FreeBSD: usbconfig). This is not very
>> optimal. However,
>> > at least my device uses the standard FTDI Vendor/product
>> ID. This means
>> > I cannot distinguish a random FTDI-based RS232-adapter and
>> a LinkUSB,
>> > without actually talking to the device. This can of course
>> be done, but
>> > I'm not sure it's "acceptable" to start writing to every
>> FTDI adapter
>> > found..
>> >
>> > How is this solved with other auto-detected devices?
>> >
>> >
>> > Looking forward to any and all feedback! :)
>> > Johan
>> >
>> >
>> > [1]
>> >
>>
>> https://sourceforge.net/p/owfs/mailman/owfs-developers/thread/53905A08.40906%40stromnet.se/#msg32422357
>> > [2] https://sourceforge.net/p/owfs/code/merge-requests/1/
>>
>>
>>
>> ------------------------------------------------------------------------------
>> HPCC Systems Open Source Big Data Platform from LexisNexis
>> Risk Solutions
>> Find What Matters Most in Your Big Data with HPCC Systems
>> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>> Leverages Graph Analysis for Fast Processing & Easy Data
>> Exploration
>> http://p.sf.net/sfu/hpccsystems
>> _______________________________________________
>> Owfs-developers mailing list
>> Owfs-developers@lists.sourceforge.net
>> <mailto:Owfs-developers@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
>> Find What Matters Most in Your Big Data with HPCC Systems
>> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
>> http://p.sf.net/sfu/hpccsystems
>>
>>
>> _______________________________________________
>> Owfs-developers mailing list
>> Owfs-developers@lists.sourceforge.net
>> <mailto:Owfs-developers@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk
> Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> <mailto:Owfs-developers@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
>
>
> _______________________________________________
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
