Hello again,
the good news first: I have been running the code for ~18 days now
without a single hickup, so it seems stable!
The not so good news: I have unfortunately not yet heard anything from
iButtonLink regarding neither the break condition nor identification of
the device. And without more information on serial prefix or anything
else, I'm leaning towards not providing full autoscan; I don't like the
idea of just sending data to unidentified serial ports (FTDI chips)..
How about this, slight alteration of the previously mentioned alternative:
1) Move from --link to --usb, and let it look for FTDI vid/pid (as previous)
2) If a single FTDI device is found, probe it. However, if more than one
is found, require the user to explicitly provide bus num/addr.
This change would make it work automatically for most users with only a
LinkUSB plugged in... however, users which use some other USB, and who
has a single FTDI device plugged in, would be (possibly) harmed by the
probe..
Let me know what you feel is most fitting, and I'll see if I can get it
working. Then we can probably look at inclusion in the master branch :)
If we cannot decide on anything, I'm OK with leaving it as is (or
possibly just move to --usb with specific identification), I only have a
single LinkUSB anyway..
Johan
On 6/24/14 08:43 , Johan Ström wrote:
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
