1A: Yes, this is what regular --link does now
1B: With --linkusb and a serial number. It does not use the serial
driver, but it does use the ow_link layer. See the changes in
(ow_arg|ow_opt|owlib).c.
Eventually it calls ftdi_usb_open_desc(FTDIC(in), vid, pid, NULL,
serial), where vid/pid is static.
2*: I haven't done any work on these, never even tried to use the link
in DS9097U emulation mode.
It could be possible to use 19200bps here, or at least partly. The
DS2480B datasheet has a speed matrix on page 29, which indicates that
search is not recommended at 19200bps, unless manual rate control is
applied. This conforms to the LinkUSB limitation of using 19200 (which
is effectively 9600 on the wire since all bus bytes are hex-encoded),
using a serial speed of 38400bps gives a dead bus.
3: Indeed, will be a bit confusing. And if it doesn't work reliably, it
might not be worth doing..
I've reached out to iButtonLink, asking if there are any way to detect
their devices, waiting for response.
One idea is the serial number, which is normally made up of 2 character
configurable prefix, and a 6 character timestamp. So far I've only had
contact with LinkUSBs with the prefix "A9".. if this could be relied on,
it might be a way to go..
Anyway, even if we cannot add detection, this would be one option:
* If --linkusb is explicitly used, we scan for the VID/PID and probe any
found.
* If --linkusb=<serial> is used, we scan for that particular serial
Another option would be to move it all into the --usb option:
* --usb=3:4 would identify the specific device, using bus number/address
instead of serial (fully possible with libftdi, but if the device moves
around it's not as reliable)
* --usb/--usb=*/--uall would also scan for the FTDI VID/PID
It might make more sense to move it into --usb, ditching the --linkusb
option... What do you think? If we are at all going for autoscanning, I
think moving to USB args is prefered.
Johan
24/06/14 01:06, Paul Alfille wrote:
> 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
> <mailto: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
>> <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
>> <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
>
>
>
>
> ------------------------------------------------------------------------------
> 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
------------------------------------------------------------------------------
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
