Hello! Oddly enough I've seen some strange happenings when using an FTDI based dongle to connect to One-Wire devices via a DS9097U device. Typically this is running on Linux with the recent releases as of then. ----- Gregg C Levine gregg.drw...@gmail.com "This signature fought the Time Wars, time and again."
On Sun, Sep 21, 2014 at 9:13 AM, Johan Ström <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> 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 >> 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 > > > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
