On 10/02/16 00:21, Stefano Miccoli wrote:
> 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
>
Thanks for testing!
>
> 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
>
Interesting. When you shut down owsserver --link, does it mention
successfully resetting baudrate, or does that fail too?
When a link is detected, it switches to 19200bps instead of 9600 (double
the speed), and when it shuts down it tries to change back into 9600bps.
I'll see if I can reproduce this on my end, but I'm traveling so it will
be a few days until I can test.
>
> 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
>> <mailto: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/
>> 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/
>> 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=
>>
>> 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
------------------------------------------------------------------------------
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
