> 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
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 doab
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 a
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
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 sugge
