I forgot that you are only dealing with linkUSB rather than DS9097U devices
on a usb-serial connection.
You're right, they should all have the same vid/pid and thus be
identifiable.
So we have several possibilities:
1. started as --link=/dev/ttyUSB0
A. We could use it as currently, with no libusb, just the USB->serial
driver provided by the kernel
B. We could use your modifications to the connection. Apparently you've
been able to connect and alter the device even when it's bound to the
serial driver?
2. started as -d /dev/ttyUSB0
A. linkUSB in DS9097U emulation more
B. Real DS9097U in a USB->serial slot
3. Scan for linkUSB devices
Clearly case 1B should use your speedup code.
We'd have to test if you can speed up 2A and 2B as well.
Case 3, the scan, is a little tricky. It's easy to scan, and even to test
(although we run the risk of confusing a non-llinkUSB device. It just gets
confusing for users explaining why they can scan for linkUSB but not other
serial 1-wire devices, nor links on serial connections, etc.
Scanning was never really possible in the old days of real serial ports.
Now that most ports are USB emulations, perhaps we can move to an
all-scanned solution (i2c, USB, USB/serial, some of the ethernet).
On Mon, Jun 23, 2014 at 9:09 AM, Johan Ström <jo...@stromnet.se> wrote:
> 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> 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> 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
>>> 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
>> Explorationhttp://p.sf.net/sfu/hpccsystems
>>
>>
>>
>> _______________________________________________
>> Owfs-developers mailing
>> listOwfs-developers@lists.sourceforge.nethttps://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
> Explorationhttp://p.sf.net/sfu/hpccsystems
>
>
>
> _______________________________________________
> Owfs-developers mailing
> listOwfs-developers@lists.sourceforge.nethttps://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
>
>
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
