Re: [Owfs-developers] LinkUSB with libftdi [was: Issue with LinkUSB dropping + baudrate test]

[Johan S. <jo...@st...>]

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...@st... 
> <mailto:jo...@st...>> 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
>