Hi Johan,
I just looked through the code, and slurp is only in detection. baud
rate change and error paths. Thus increasing the timeout is safe. From
your tests, it's also advisable.
You are right, we could keep owfs completely agnostic to the type of
serial/usb adapter. We do use libusb for the DS9490R, however, so we
could set USB parameters.
My thoughts are:
1. Keep the main code path ignorant of USB specifics. Just treat the
device path as a serial adapter whether hardware serial or USB-based.
In fact, I think figuring out the USB device from a serial port name
would be difficult. Scan /sys?
2. Add USB scanning to search for linkusb ( and hobbyboard masterhub
soon ) as well as DS9490R as we do now. We'll want to do this in any
case to make configuration more seamless. In that case we'll know the
type of USB adapter and can send any tuning parameters at the start.
1-wire communication messages are pretty short, and often of variable
length. You test shows some nice speed increases with better timing
choices. I'd like to incorporate that eventually.
Paul
On Sun, Sep 21, 2014 at 9:13 AM, Johan Ström <jo...@stromnet.se
<mailto:jo...@stromnet.se>> wrote:
Hi!
Another specific scenario where slurp is required, I guess, is in
DS2480_set_baud, where we cannot rely on proper read-back, if the
baud rate changed.
So, as you say, slurp is probably required, and it's not worth
trying to do proper reading, which is bound to fail anyway.
Thus, my suggestion is to increase the slurp timeout so we can be
sure that we actually any pending bytes.
If slurp is only used during initial resets (which is the case for
the DS2480 and the LINK code, I haven't studied any others), then
it is no harm to increase this to say 100ms.
HOWEVER, if any other device-code is using slurp during the normal
communication flow, a longer timeout would of course hurt.
The thing with the FTDI parameter is that you cannot really change
that unless specific support for libftdi is added. Currently the
DS2480 code only works with a generic serial device, with no
information on the underlying hardware. So, hard to know when to
apply ftdi changes, and even harder to identify which port to change..
As discussed here previously, I've got some ftdi code in owfs
working, although for the LinkUSB. Should be trivial to port to
the DS2480-code, or probably most serial-based code. The question
is if it makes sense to add chip-specific code, when this is only
usable if you actually use a USB-serial-adapter built on that
chip. In the LinkUSB case it makes more sense, since the actual
"1-wire-product" LinkUSB is built around that chip.
Anyway, by just raising the slurp timeout, we solve the main
issue. Controlling the FTDI timeout would however give some speed
increase, some simple tests shows that with a default of 16ms, the
DS2480b reads /28.xxxxxxx/power in ~77ms, vs 27ms with 1ms timeout.
Regarding 0-baud, I think it's only done from serial_powercycle,
not sure why though. Power-cycle adapters powered directly by the
serial-port?
Since I don't know the use of the code, I cannot really say if
this is an issue worth addressing. B0 is defined in termios.h so
it should certainly be a valid value.
Johan
On 9/20/14 03:08 , Paul Alfille wrote:
Thank you, Johan, for the detailed tests.
The idea of "slurp" was to collect any pending serial traffic and
allow communication with the bus master to be synchronized. I
agree that matching expected response exactly is optimal, but
that supposes that you start from a known clean state. I found in
some of my early tests that old data was still delivered with the
system was restarted.
Obviously, testing is hardware-specific. The timing was adjusted
based on my tests -- not very scientific.
It sounds like you think we should adjust the slurp time-out, and
perhaps some of the FTDI timing parameters. Also there is a
0-baud issue which we should look at fixing on our end as well.
Is it the serial "BREAK" or baud changed that does it?
Paul
On Fri, Sep 19, 2014 at 2:57 AM, Johan Ström <jo...@stromnet.se
<mailto:jo...@stromnet.se>> wrote:
Hi,
I've noticed some problems using a FTDI based USB serial
dongle together
with a DS2480B based adapter (also known as DS9097U).
On startup the device was not recognized at all, complaining
about wrong
responses. Anyone else seen these issues?
I've debugged the problem and found the cause.
On startup, this is what happens:
DEBUG: ow_ds9097U.c:(287) Attempt 0 of 3 to initialize the
DS9097U
TRAFFIC OUT <write> bus=0 (/dev/cua-labdesk)
Byte buffer anonymous, length=1
--000: C1
<.>
DEBUG: ow_ds9097U.c:(381) Send the initial reset to the bus
master.
TRAFFIC OUT <write> bus=0 (/dev/cua-labdesk)
Byte buffer anonymous, length=1
--000: 71
<q>
TRAFFIC OUT <write> bus=0 (/dev/cua-labdesk)
Byte buffer anonymous, length=1
--000: 0F
<.>
DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000
seconds
TRAFFIC IN <NETREAD> bus=0 (/dev/cua-labdesk)
Byte buffer anonymous, length=1
--000: 70
<p>
DEBUG: ow_tcp_read.c:(114) read: 1 - 0 = 1
DEBUG: ow_ds9097U.c:(459) wrong response (70 not 00)
After each TRAFFIC OUT byte above, a COM_Slurp() is issued to
read and
remove the response.
The response to the 71 command should be 70.. Which is what
we see..
except that it fails to slurp those bytes, it's actually
reading them as the response to the next command.
After some further debugging and added printf statements, I
realize that
COM_slurp fails to read the bytes, and instead just timeouts
(1ms).
I've been working on my pure-ftdi-branch for the LinkUSB,
where I've
learned that the FTDI chips by default have a 16ms timeout
for small
transfers, making them not very efficient when dealing with
few bytes
like this.
Manually changing my USB-serial dongle's setting to 1ms with
libftdi,
together with a slurp timeout of 2ms, seems to fix the
problem. However,
the slurp still times out, so I guess the accompanying
COM_flush does
the trick.. Running with default 16ms FTDI setting, and a
slurp timeout
of 100ms, DOES succeed with reading the slurped data [1], and
all works
fine.
The "proper" way to solve this is probably to actually read
the bytes we
expect, not just hope that slurp catches them. However, this
might be
problematic when changing bitrates etc?
The solution used above would be to give the slurp a longer
timeout.
Besides that device init would take a few ms longer, would
this have any
other side effects?
>From the DS2480B code at least, it does not seem to slurp
anywhere
except on device init.
For the record, the DS2480B works perfectly fine with my
STLab 2 port
dongle (MosChip mos78x0 chip).. except that the stable
FreeBSD-10 kernel
panics when setting baud rate 0, which happens sometimes in
OWFS when
trying to forcefully reset. This was patched in
https://github.com/freebsd/freebsd/commit/120a212c4b16b5137d6acc436b8f5702a5f5bf35
but until the fix hits the mainline kernel, I'll have to go
with another
dongle.
Regards
Johan
[1]
This is how a proper session looks, with the responses
slurped (FTDI
chip 16ms, COM_slurp timeout set to 100ms):
DEBUG: ow_ds9097U.c:(287) Attempt 0 of 3 to initialize the
DS9097U
TRAFFIC OUT <write> bus=0 (/dev/cua-labdesk)
Byte buffer anonymous, length=1
--000: C1
<.>
TRAFFIC IN <slurp> bus=0 (/dev/cua-labdesk)
Byte buffer anonymous, length=1
--000: CD
<.>
Slurp timeout 100000 us..
DEBUG: ow_ds9097U.c:(381) Send the initial reset to the bus
master.
TRAFFIC OUT <write> bus=0 (/dev/cua-labdesk)
Byte buffer anonymous, length=1
--000: 71
<q>
TRAFFIC IN <slurp> bus=0 (/dev/cua-labdesk)
Byte buffer anonymous, length=1
--000: 70
<p>
Slurp timeout 100000 us..
TRAFFIC OUT <write> bus=0 (/dev/cua-labdesk)
Byte buffer anonymous, length=1
--000: 0F
<.>
DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000
seconds
TRAFFIC IN <NETREAD> bus=0 (/dev/cua-labdesk)
Byte buffer anonymous, length=1
--000: 00
<.>
DEBUG: ow_tcp_read.c:(114) read: 1 - 0 = 1
DEBUG: ow_com_read.c:(83) COM_read, read 1 bytes.
read_get=16302.000000us, tcdrain=0.000000us: 1
------------------------------------------------------------------------------
Slashdot TV. Video for Nerds. Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
<mailto:Owfs-developers@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
Slashdot TV. Video for Nerds. Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
<mailto:Owfs-developers@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
Slashdot TV. Video for Nerds. Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
<mailto:Owfs-developers@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
Slashdot TV. Video for Nerds. Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
