Good news.
In a few days I will have an old LinkUSB available for testing, although with a
limited number of sensors only: I will try-out your implementation.
Let me just add a few remarks.
Auto-detection (or plug and play). I’m an old Unix guy and configuration and
tuning is just part of the fun: I do not see a big problem here. Explicit is
better than implicit.
User space vs. kernel space. OWFS is a user space tool, and it makes sense to
keep everything in user-space: direct driving of the FTDI chip is an
improvement (although configuration becomes a little bit more complicated).
Ease of use: maybe a little helper program could help: something that scans the
USB bus, looks for FTDI chips, and prints the relevant libftdi description
string.
Documentation: stress that the only sensible (permanent) address is
s:<vendor>:<product>:<serial>. All other are basing on assumption that cannot
always be met.
Instruction for the user could be:
1) unplug linkUSB
2) start libftdi-discover program
3) plug linkUSB
4) read output of libftdi-discover
5) edit owfs.conf
libftdi-discover could even be (on *nix) just a couple of bash lines.
Stefano
> On 25 Jan 2016, at 21:39, Johan Ström <jo...@stromnet.se> wrote:
>
> Hi,
>
> some of you may remember my earlier attempts to add a libftdi based LinkUSB
> interface into master. For
> reference:http://sourceforge.net/p/owfs/mailman/message/32492037/
> <http://sourceforge.net/p/owfs/mailman/message/32492037/>
> In short, 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 useful.
>
> 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:
> http://sourceforge.net/p/owfs/code/ci/2982df8ca648bd9cec4d820151046b044ef504e0/
>
> <http://sourceforge.net/p/owfs/code/ci/2982df8ca648bd9cec4d820151046b044ef504e0/>
> 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
> http://sourceforge.net/u/stromnet/owfs/ci/ca85d64eefaaa9f1e90bbc079db65cfda623c472/log/?path=
>
> <http://sourceforge.net/u/stromnet/owfs/ci/ca85d64eefaaa9f1e90bbc079db65cfda623c472/log/?path=>
>
> 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 great.
>
> 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!
>
> Regards
> Johan
>
> Man-page cut:
> -------
> * 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 ADDRESSING
> 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 (for example,
> the LinkUSB), you can use this FTDI addressing.
>
> The main benifit with this mode of access is that we can decrease the
> communication delay, yielding twice as fast 1-Wire communication in
> many cases.
>
> The following values for port can be used to identify a specific FTDI
> port. Note that this requires that OWFS is built with libftdi support.
>
> ftdi:d:<devicenode>
> path of bus and device-node (e.g. "003/001") within usb device
> tree (usually at /proc/bus/usb/)
>
> ftdi:i:<vendor>:<product>
> first device with given vendor and product id, ids can be deci-
> mal, octal (preceded by "0") or hex (preceded by "0x")
>
> ftdi:i:<vendor>:<product>:<index>
> as above with index being the number of the device (starting
> with 0) if there are more than one
>
> ftdi:s:<vendor>:<product>:<serial>
> first device with given vendor id, product id and serial string
>
> The above formats are parsed fully by libftdi, but with the ftdi: pre-
> fix stripped.
>
> Simplified device serial-only support
> An additional format is supported, for certain bus types. This only
> specifies the USB serial number.
>
> ftdi:<serial>
> Identifies a FTDI device by serial only. Currently, this is
> only valid for the VID/PID found on the LinkUSB (i.e. --link).
> Note that those VID/PID's are the default for any FT232R device,
> and in no way exclusive to LinkUSB.
>
> -----
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140_______________________________________________
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
