Hi, I was able to perform some very preliminary testing with a raspberry pi 2,
a LinkUSB and a single MS-TH.
Here my environment:
LSB Version: 1.4
Distributor ID: Arch
Description: Arch Linux
Release: rolling
Codename: n/a
Linux 4.1.17-1-ARCH #1 SMP Mon Feb 1 18:55:49 MST 2016
git branch:
* ftdi b1c0ccf owusbprobe: Added detection/identification of DS9490,
DS9481, DS9481P-300
Basic functionality seems OK, but there is a sequence that breaks the server.
$ owserver --link ftdi:i:0x0403:0x6001 --foreground
^C
$ owserver -d ftdi:i:0x0403:0x6001 --debug
Now owserver enters an endless loop:
DEBUG MODE
libow version:
3.1p1
DEBUG: ow_daemon.c:(170) main thread id = 1995825152
DEBUG: ow_inotify.c:(80) No configuration files to monitor
CALL: ow_parsename.c:(104) path=[]
DEBUG: owlib.c:(77) Global temp limit 0C to 100C (for fake and mock adapters)
DEBUG: ow_ds9097U.c:(471) Attempt 0 of 3 to initialize the DS9097U
DEBUG: ow_ftdi.c:(199) Sending FTDI break..
DEBUG: ow_ftdi.c:(480) ftdi_write: 4294967297 = actual 2126956933
DEBUG: ow_ds9097U.c:(565) Send the initial reset to the bus master.
DEBUG: ow_ftdi.c:(480) ftdi_write: 4294967297 = actual 14824048
DEBUG: ow_ftdi.c:(480) ftdi_write: 4294967297 = actual 1995446176
DEBUG: ow_ftdi.c:(397) attempt 21474836481 bytes Time: 0.2126956855 seconds
DEBUG: ow_ftdi.c:(458) ftdi_read: 1 - 0 = 1 (3 retries)
DEBUG: ow_ds9097U.c:(643) wrong response (E7 not 00)
DEBUG: ow_ds9097U.c:(660) Failed first attempt at resetting baud rate of bus
master ftdi:i:0x0403:0x6001
DEBUG: ow_ftdi.c:(480) ftdi_write: 4294967297 = actual 14824048
DEBUG: ow_ftdi.c:(480) ftdi_write: 4294967297 = actual 1995446176
DEBUG: ow_ftdi.c:(397) attempt 21474836481 bytes Time: 0.1995157928 seconds
DEBUG: ow_ftdi.c:(458) ftdi_read: 1 - 0 = 1 (3 retries)
DEBUG: ow_ds9097U.c:(643) wrong response (E7 not 00)
DEBUG: ow_ds9097U.c:(665) Failed second attempt at resetting baud rate of bus
master ftdi:i:0x0403:0x6001
DEBUG: ow_ftdi.c:(480) ftdi_write: 4294967297 = actual 14827816
DEBUG: ow_ftdi.c:(397) attempt 21474836481 bytes Time: 0.1995157928 seconds
CONNECT: ow_ftdi.c:(425) TIMEOUT after 0 bytes
DEBUG: ow_ftdi.c:(480) ftdi_write: 8589934594 = actual 2126956900
DEBUG: ow_ftdi.c:(397) attempt 21474836481 bytes Time: 0.14821608 seconds
CONNECT: ow_ftdi.c:(425) TIMEOUT after 0 bytes
DEBUG: ow_ftdi.c:(480) ftdi_write: 4294967297 = actual 14827816
DEBUG: ow_ftdi.c:(397) attempt 21474836481 bytes Time: 0.1995157928 seconds
CONNECT: ow_ftdi.c:(425) TIMEOUT after 0 bytes
DEBUG: ow_ftdi.c:(480) ftdi_write: 4294967297 = actual 14824048
DEBUG: ow_ftdi.c:(480) ftdi_write: 4294967297 = actual 1995446176
DEBUG: ow_ftdi.c:(397) attempt 21474836481 bytes Time: 0.1995157928 seconds
DEBUG: ow_ftdi.c:(458) ftdi_read: 1 - 0 = 1 (3 retries)
DEBUG: ow_ds9097U.c:(643) wrong response (E7 not 00)
DEBUG: ow_ds9097U.c:(660) Failed first attempt at resetting baud rate of bus
master ftdi:i:0x0403:0x6001
DEBUG: ow_ftdi.c:(480) ftdi_write: 4294967297 = actual 14824048
DEBUG: ow_ftdi.c:(480) ftdi_write: 4294967297 = actual 1995446176
DEBUG: ow_ftdi.c:(397) attempt 21474836481 bytes Time: 0.1995157928 seconds
DEBUG: ow_ftdi.c:(458) ftdi_read: 1 - 0 = 1 (3 retries)
DEBUG: ow_ds9097U.c:(643) wrong response (E7 not 00)
DEBUG: ow_ds9097U.c:(665) Failed second attempt at resetting baud rate of bus
master ftdi:i:0x0403:0x6001
DEBUG: ow_ftdi.c:(480) ftdi_write: 4294967297 = actual 14827816
DEBUG: ow_ftdi.c:(397) attempt 21474836481 bytes Time: 0.1995157928 seconds
CONNECT: ow_ftdi.c:(425) TIMEOUT after 0 bytes
DEBUG: ow_ftdi.c:(480) ftdi_write: 8589934594 = actual 1995374248
DEBUG: ow_ftdi.c:(397) attempt 21474836481 bytes Time: 0.14821608 seconds
CONNECT: ow_ftdi.c:(425) TIMEOUT after 0 bytes
DEBUG: ow_ftdi.c:(480) ftdi_write: 4294967297 = actual 14827816
DEBUG: ow_ftdi.c:(397) attempt 21474836481 bytes Time: 0.1995157928 seconds
CONNECT: ow_ftdi.c:(425) TIMEOUT after 0 bytes
DEBUG: ow_ftdi.c:(480) ftdi_write: 4294967297 = actual 14821456
DEBUG: ow_ftdi.c:(397) attempt 21474836481 bytes Time: 0.1995157928 seconds
DEBUG: ow_ftdi.c:(458) ftdi_read: 1 - 0 = 1 (2 retries)
DEBUG: ow_ds9097U.c:(627) wrong response (F7 not 44)
DEBUG: ow_ftdi.c:(199) Sending FTDI break..
DEBUG: ow_ftdi.c:(480) ftdi_write: 4294967297 = actual 0
DEBUG: ow_ds9097U.c:(565) Send the initial reset to the bus master.
DEBUG: ow_ftdi.c:(480) ftdi_write: 4294967297 = actual 14827696
DEBUG: ow_ftdi.c:(480) ftdi_write: 4294967297 = actual 1995446176
DEBUG: ow_ftdi.c:(397) attempt 21474836481 bytes Time: 0.1995157928 seconds
DEBUG: ow_ftdi.c:(458) ftdi_read: 1 - 0 = 1 (3 retries)
DEBUG: ow_ds9097U.c:(643) wrong response (E7 not 00)
DEBUG: ow_ds9097U.c:(660) Failed first attempt at resetting baud rate of bus
master ftdi:i:0x0403:0x6001
DEBUG: ow_ftdi.c:(480) ftdi_write: 4294967297 = actual 14827696
DEBUG: ow_ftdi.c:(480) ftdi_write: 4294967297 = actual 1995446176
DEBUG: ow_ftdi.c:(397) attempt 21474836481 bytes Time: 0.1995157928 seconds
DEBUG: ow_ftdi.c:(458) ftdi_read: 1 - 0 = 1 (3 retries)
DEBUG: ow_ds9097U.c:(643) wrong response (E7 not 00)
DEBUG: ow_ds9097U.c:(665) Failed second attempt at resetting baud rate of bus
master ftdi:i:0x0403:0x6001
^C
In other words: if I use '-d ftdi:xxx’ no problem. But after ‘—link ftdi:xxx’
there is no way to use ‘-d ftdi:xxx’ again, except to unplug and replug the
adapter.
Is this a known problem?
S.
> 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=272487151&iu=/4140
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
