some of you may remember my earlier attempts to add a libftdi based
LinkUSB interface into master. For reference:
the client-timings are generally cut about 2.5 times, depending on
operation. A temp sensor is read in ~50ms instead of ~123ms. More
details can be found at the link.
Last time (2014) it was well received, but got stuck on discussions
about different methods of auto-detection (something which isn't too
easy/possible with FTDI). I have since run that code in production
without any glitches, so the ftdi-part has really proven stable.
In the recent days, I've cleaned up the code to not be LinkUSB
specific, but rather work with any serial-based device (and fixed
some minor issues). There is no auto-detection though (and again, I
don't believe that is possible to do reliable with serial devices;
see discussions in above link).
A cut from the (updated) man page is available below, please see
that for usage details.
I realize that this isn't the simplest thing to explain to a user,
but then again, a regular user who don't really care about those
extra milliseconds shaved off each request can easily use the same
old /dev/ttyS0 addressing. For us who *do* care however, it is very
The ftdi parts of the code has been running since 2014, but only
with LinkUSB. But it's mostly the device setup parts which has
changed lately, so it shouldn't be any unstability. I've tested the
LinkUSB, emulated and --link mode, and DS2480 through a FTDi
adapter without any issues.
I've commited all the changes in the new ftdi branch:
The above is a clean patch based on my earlier work (which may be
interesting for those wanting to check out how it evolved) at
One potential issue could be the
BUS_close related changes in ow_connection.c, could someone take a
look at that please? I think that is actually a bug fix, basically
it calls device-specific BUS_close *before* cleaning up and closing
the device, instead of after.. But an extra set of eyes would be
Another issue could be that I now bring any link-devices into
19200-mode after initial detection (also increases the speed a lot).
This is the mode I've been running my LinkUSB during the last years,
via the FTDI layer, so should be OK. But I have not tested with
older links, or non-USB based links (or the linkusb via old serial
addressing for any longer duration).
To sum it up, I hope we can get this branch merged into master
sooner rather than later! If we want to add a sane auto-detection
scheme somehow, let's add that later..
Any testing and feedback is much appreciated!
* Serial devices
port specifies a serial port, e.g. /dev/ttyS0
If OWFS was built with libftdi support, you may be able
to use the
ftdi: prefix to address a FTDI-based USB device.
For details, see the FTDI ADDRESSING section.
FTDI is a brand of USB-to-serial chips which are very
common. If your
serial device is connected via a USB serial dongle based
on a FTDI
chip, or if your adapter uses a built-in FTDI USB chip
the LinkUSB), you can use this FTDI addressing.
The main benifit with this mode of access is that we can
communication delay, yielding twice as fast 1-Wire
The following values for port can be used to identify a
port. Note that this requires that OWFS is built with
path of bus and device-node (e.g. "003/001") within
tree (usually at /proc/bus/usb/)
first device with given vendor and product id, ids
can be deci-
mal, octal (preceded by "0") or hex (preceded by "0x")
as above with index being the number of the device
with 0) if there are more than one
first device with given vendor id, product id and
The above formats are parsed fully by libftdi, but with the
Simplified device serial-only support
An additional format is supported, for certain bus types.
specifies the USB serial number.
Identifies a FTDI device by serial only.
Currently, this is
only valid for the VID/PID found on the LinkUSB
Note that those VID/PID's are the default for any
and in no way exclusive to LinkUSB.