[Owfs-developers] Issues with FTDI based USB-Serial dongle DS2480B

2014-09-19 Thread Johan Ström
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.00 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 10 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 10 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.00 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.00us, tcdrain=0.00us: 1


--
Slashdot TV.  Video for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers


Re: [Owfs-developers] Issues with FTDI based USB-Serial dongle DS2480B

2014-09-19 Thread Paul Alfille
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 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.00 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 10 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 10 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.00 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.00us, tcdrain=0.00us: 1



 --
 Slashdot TV.  Video for Nerds.  Stuff that Matters.