Hi,

just took a closer look at the patch Hans-Frieders sent earlier. The only thing it (effectively) does, when applied to the current owfs version, is to do more identical probes: It sets baud/flow to something, then calls LINK_detect_serial(..). If it fails, it does this with a few different baud/flow settings. The thing is that the current version of LINK_detect_serial will overwrite those baud/flow settings anyway, and probe with a bunch of combinations. So effectively, that patch is just calling LINK_detect_serial() 4 times instead of 1 time.

Or at least, that's what I thought first.. For the ct_serial path, it also makes sure that gbGOOD is actually returned. In current code, the ct_ftdi path will return gbGOOD, but ct_serial path will only explicitly return BAD from LINK_detect_serial, not gbGOOD. For gbGOOD it drops through and returns gbBAd...

Can (both of you, if possible) try the following patch? It will hopefully help you.

diff --git a/module/owlib/src/c/ow_link.c b/module/owlib/src/c/ow_link.c
index 34eed196..93c45935 100644
--- a/module/owlib/src/c/ow_link.c
+++ b/module/owlib/src/c/ow_link.c
@@ -282,6 +282,8 @@ GOOD_OR_BAD LINK_detect(struct port_in *pin)
                                // ensure still found
                                RETURN_GOOD_IF_GOOD( LINK_version(in) ) ;
                                ERROR_CONNECT("LINK baud reconfigure failed, cannot find it after 19200 change.");
+                       } else {
+                               return gbGOOD;
                        }
                        break;
                }


If you can verify that it helps, I'll patch the code I broke when introducing ftdi support.. and it will go in next release.. :)


Johan

On 11/09/17 08:09, Martin Patzak (GMX) wrote:
Thanks for confirming.
If you want to, you can try the patch that Hans-Frieder Vogt sent to this board. It worked for the LinkUSB.

On 10.09.2017 22:45, Nicolas Huillard wrote:
Le vendredi 21 juillet 2017 à 10:47 +0200, Martin Patzak (GMX) a
écrit :
I am trying to start owserver with a LinkUSB V 1.7 as bus master
using
the option /--link/.
I am able to start owserver with the LinkUSB V 1.7 and V 1.4 using
the
option "d" for device without any problems.
I can confirm the same behaviour here. I just upgraded my Raspberry Pi
to Raspbian stretch with owfs 3.1p5 (from squeeze with owfs 2.8). The
serial LINK is not recognised with the --link option, but OK with --
device. I didn't change anything else, juste upgraded the system.
Here are the logs :

root@raspberry:~# owserver -V
owserver version:
         3.1p5
libow version:
         3.1p5
root@raspberry:~# owserver --link=/dev/owlink --foreground --error_level=9
   DEBUG: ow_daemon.c:(170) main thread id = 3069931600
   DEBUG: ow_inotify.c:(80) No configuration files to monitor
CONNECT: ow_dnssd.c:(81) Zeroconf/Bonjour is disabled since dnssd library isn't 
found
    CALL: ow_parsename.c:(104) path=[]
   DEBUG: owlib.c:(77) Global temp limit 0C to 100C (for fake and mock adapters)
   DEBUG: ow_com.c:(47) Auto initialization of /dev/owlink
   DEBUG: ow_link.c:(328) Detecting serial LINK using 9600 bps
   DEBUG: ow_link.c:(360) Slurp in initial bytes
   DEBUG: ow_link.c:(431) Checking LINK version
   DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.000000 seconds
   DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
   DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.000000 seconds
   DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
   DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.000000 seconds
   DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
   DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.000000 seconds
   DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
   DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.000000 seconds
   DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
   DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.000000 seconds
   DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
   DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.000000 seconds
   DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
   DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.000000 seconds
   DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
   DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.000000 seconds
   DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
   DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.000000 seconds
   DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
   DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.000000 seconds
   DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
   DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.000000 seconds
   DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
   DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.000000 seconds
   DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
   DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.000000 seconds
   DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
   DEBUG: ow_link.c:(199) Link version Found 1.0
CONNECT: owlib.c:(216) Cannot open LINK bus master at /dev/owlink
   DEBUG: ow_serial_free.c:(40) COM_close: flush
   DEBUG: ow_serial_free.c:(42) COM_close: restore
DEFAULT: owlib.c:(52) No valid 1-wire buses found
   DEBUG: ow_exit.c:(17) Exit code = 1
...
root@raspberry:~# ls -l /dev/owlink
lrwxrwxrwx 1 root root 7 sept. 10 21:39 /dev/owlink -> ttyUSB2

What seams to be the problem? Anybody seen this before?
I've never seen that before. owfs and my serial LINK have both been
very reliable since at least 2003...




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Reply via email to