Menu
▾
▴
Re: [Owfs-developers] Issues with FTDI based USB-Serial dongle & DS2480B
|
From: Johan S. <jo...@st...> - 2014-09-21 21:50:05
|
Hi, that sounds great, then I guess a timeout increase is the first simple thing to do. From a FTDI standpoint, anything > 16ms should do it, but a bit higher is probably good. 1. Trying to resolve a serial port TTY name (i.e. /dev/cuaU1 on FreeBSD) to a potential USB device is probably doable, but not without a lot of effort and OS specific code. I don't think it's worth trying to go down that road. 2. That is probably a good thing to do. However, as discussed in my previous thread, there is no way to reliably do autodetect. When searching for the FTDI VID/PID on my machine, I will find two device. One is the LinkUSB, with the link protocol, and the other is a USB serial dongle which is attached to a DS2480B. But there is, unfortunately, no way to find this out without probing the ports. And I don't really like the idea of that, for all we know there could be a serial controlled power-strip which happens to shut down the power to the whole rack when we're probing randomly.. :) So, no, in the case of FTDI based adapters, we do NOT know for sure what kind of device we have. A reminder, my LinkUSB FTDI code can be found at https://sourceforge.net/u/stromnet/owfs/ci/ftdi-linkusb/. It's mostly in ow_ftdi.c, with a new connection_in.type named ct_ftdi. If this type is used instead of ct_serial, the COM_* routines will use owftdi_* instead of serial_*. Thus, any device currently using ct_serial should be easy to get to work with ct_ftdi. Johan On 9/21/14 17:20 , Paul Alfille wrote: > Hi Johan, > > I just looked through the code, and slurp is only in detection. baud > rate change and error paths. Thus increasing the timeout is safe. From > your tests, it's also advisable. > > You are right, we could keep owfs completely agnostic to the type of > serial/usb adapter. We do use libusb for the DS9490R, however, so we > could set USB parameters. > > My thoughts are: > 1. Keep the main code path ignorant of USB specifics. Just treat the > device path as a serial adapter whether hardware serial or USB-based. > In fact, I think figuring out the USB device from a serial port name > would be difficult. Scan /sys? > 2. Add USB scanning to search for linkusb ( and hobbyboard masterhub > soon ) as well as DS9490R as we do now. We'll want to do this in any > case to make configuration more seamless. In that case we'll know the > type of USB adapter and can send any tuning parameters at the start. > > 1-wire communication messages are pretty short, and often of variable > length. You test shows some nice speed increases with better timing > choices. I'd like to incorporate that eventually. > > Paul > > On Sun, Sep 21, 2014 at 9:13 AM, Johan Ström <jo...@st... > <mailto:jo...@st...>> 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...@st... >> <mailto:jo...@st...>> 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 >> Owf...@li... >> <mailto:Owf...@li...> >> 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 >> Owf...@li... <mailto:Owf...@li...> >> 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 > Owf...@li... > <mailto:Owf...@li...> > 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 > Owf...@li... > https://lists.sourceforge.net/lists/listinfo/owfs-developers |
