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 https://lists.sourceforge.net/lists/listinfo/owfs-developers
