Quick report: I have successfully implemented libftdi support in owfs
now, it works but a few things to polish up, such as retry handling etc.
A question regarding LinkUSB: have you gotten the "BREAK" functionality
to work? From the manual:
--
Key , (comma) - Switches the device to the 19,200 baud serial port data
rate. The host terminal will be required to switch to 19,200 baud before
it can communicate with the LinkUSBTM further. When a "break" condition
is detected, the device resets and returns to the 9600 baud data rate,
so sending the "^" followed by more 9600 baud data will often find the
device resetting and the speed returning to 9600 baud.
--
I haven't been able to reset to 9600 besides doing a power-on reset...
I've tried sending break through 'cu', through tcsendbreak, and through
libftdi, without any success. It simply ignores it, and keeps at 19200.
Kind of makes the startup procedure trickier, since we cannot force it
to 9600 and work from there..
Anyone who have success with break?
On 6/10/14 01:55 , Roberto Spadim wrote:
Nice news :)
Maybe others tunes are possible i used other usb serial adapter
anither day with a very nice latency, i will check what chip
Em segunda-feira, 9 de junho de 2014, Johan Ström <jo...@stromnet.se
<mailto:jo...@stromnet.se>> escreveu:
A quick, positive (40% faster) update:
I've implemented mode-toggling as described below (keep mode
between LINK_sendback_data). This didn't give much at all, at
least not with these small "packets".
Since the big time-consumer is the double bytes, I dug a bit
deeper and noticed that the byte-level read/write routines took a
bit longer per byte than the DS2480 did.
So, whats the difference?
My DS2480 is connected via a umcs7840 based dongle.
The LinkUSB uses a FTDI FT232R Usb-serial bridge.
Quick google reveals that the FT232R chip has a latency timer
which buffers data coming from the device to the PC. By default,
this is set to 16ms. So I did a quick standalone program which
reconfigured the FTDI chip using libftdi, setting the timeout to
1ms instead.
Results:
DS2480B (old reference): ~ 28ms
LinkUSB, regular mode @ 9600, 16ms ftdi timeout: ~142ms
LinkUSB, "smart" mode @ 9600, 16ms ftdi timeout: ~122ms (smart
mode == not jumping to/from Send Byte all the time)
LinkUSB, "regular" mode @ 9600, 1ms ftdi timeout: ~63ms
LinkUSB, "smart" mode @ 9600, 1ms ftdi timeout: ~63ms
LinkUSB, "smart" mode @ 19200, 1ms ftdi timeout: ~41ms
So, the bottom line is:
* Setting the ftdi latency timer shaves of a LOT of time (142->63ms)
* Keeping track of the mode does not give much at all, it seems.
* 19200bps gives yet ~20ms, which lands us at just 10ms more than
the DS2480B, rather than 122ms..
So, the digging was well worth the time :)
I'll keep on experimenting, and I'll work on a proper patch
(libftdi optional of course)!
/Johan
On 6/7/14 12:47 , Johan Ström wrote:
On 6/6/14 16:23 , Johan Ström wrote:
...
I did some speed experiments, with interesting outcome...
This was done by manually telling the LINK to use a certain
baudrate, and then start owserver with that setting.
At 9600 bps, a full owdir (uncached) takes ~ 1700ms on my 30
devices. A owread on one temp sensors "power" value, takes ~100ms
At 19200 bps, the owdir takes 1460ms and the owread ~80ms.
At 38400 bps, the owdir takes ~1300ms.
However, the owread fails, and renders the device inaccessible!
I cannot get it back in working shape, without pulling the USB plug.
Sending a break in any baudrate does not help, it won't give any
response at all.
I've tried both with a USB hub, and without one.
A closer look at the LinkUSB manual:
--
Key ` (single quote under ~) - Switches the device to the 38,400
baud serial port data rate. The host terminal will be required to
switch to 38,400 baud before it can communicate with the
LinkUSBTM further. When a "break" condition is detected, the
LinkUSBTM resets and returns to the 9600 baud data rate, so
sending the "^" followed by more 9600 baud data will often find
the device resetting and the speed returning to 9600 baud. See
note (1) below
...
Note 1: The 1-Wire bus with relaxed timing suitable for long
lines can only process bits at a rate of about 14,000 per second.
Streaming bytes using the (b) command will fail if the baud rate
is set to more than 19,200 because the host will overrun the
1-Wire bus. When the baud rate is set to any value greater than
19,200 the host commands must be paced to assure that 1-Wire bus
overrun does not occur.
--
This could explain why it totally fails in 38400bps. The scanning
works because it is done using link-specific commands, which
would overflow the net. But the actual read operation fails since
it overflows the bus.. Or does it? The note talks about the
"relaxed timing" mode, which I'm not using.. Maybe the note is
applicable to regular mode as well?
Another interesting benchmark note, on a separate bus powered
with an plain old DS2480b @ 9600bps, the same read operation
takes ~30ms rather than ~100ms with the Link @ 9600bps.
After adding some transaction timing, studying the manual and the
ow_link.c source and learning a bit, I think this comes down to
each byte requires two serial wire-level bytes (since it is
read+written in hex). Thus, a write1 on DS2480 is write 1
wire-byte, read back 1 wire-byte. On the Link it becomes write 2
wire-bytes, read 2 wire-bytes, which effectively doubles the time
required. In addition, for every sequence (32 bytes) of bytes
written, two extra command bytes are written to take the Link in
and out of byte mode.
With the simple power READ we need to do Reset(1 byte), then
Match ROM (9), write command (1), read response(1) = 11 bytes
(written + read on the serial level = 22b)
On the DS2480, we're in DATA mode for the whole transaction (I
think?), but in LINK we jump in and out of the write-byte mode
for every transaction component (every call to
LINK_sendback_data). The link thus requires 11*2+2+2+ 3*2 = 32
bytes instead of just 12 (11+1, we need to switch to data mode at
least once).
This makes the Link ~2.7 times slower, and my timings above (30
vs 100ms) matches this quite well, with some extra overhead.
First of all, is my analysis correct?
If so, could we not improve the speed at least a bit, by keeping
track of the mode we're in, and avoid switching to/from byte mode
all the time? Would not give much extra, since the majority of
the bytes gets lost in the hex encoding, but at least a bit saved
time... In combination with 19200bps it would be even more
improvement.
Too bad the link is not using the double-byte-encoding the DS2480
uses...
Well, after going through the numbers above I realize it might
not give enough speed gain to motivate changes... but now that
I've written it down I might just hit send and see what you think :)
/Johan
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
