On 5 November 2016 at 08:30, Enrico Hoepfner <enrico.hoepf...@gmx.de> wrote:
> Hello Colin,
>
> I've found a workaround - only use an other path to read from owfs-server
> and dont need any retry anymore.
> Workaround is to use /bus.x/<ADDRESS>/<VALUE> instead of
> /<ADDRESS>/<VALUE>.
> Have you a possibility to try, if this is working on your system also?
>
Sorry I don't understand exactly what you mean by that. Could you give a
specific example of what you mean?
Colin
>
> I dont found the reason for that, but it works stable (with 0 retry) since
> 24 hours (14 devices, on 4 buses, read/write every 20 seconds) on my
> owfs-server.
>
> So I hope, it would be possible to get this working stable also with
> access over /<ADDRESS>/<VALUE>
>
>
> Could it have do something with this hint in the kernel-driver from 1w-gpio
>
> https://www.kernel.org/doc/Documentation/w1/w1.generic
> =========
> ...
>
> It is possible that between 1. and 2. w1 master thread will reset bus for
> searching
> and slave device will be even removed, but in this case 0xff will
> be read, since no device was selected.
> ...
>
> =========
>
> I've seen in the debuglevel-log from owfs-server that this is searching on
> each bus-master when I access with /<ADDRESS>/<VALUE>.
>
> eni
>
>
>
> On 05.11.2016 09:08, Colin Law wrote:
>
> On 5 November 2016 at 07:03, eni <enrico.hoepf...@gmx.de> wrote:
>
>> Hello Colin,
>>
>> I've exactly the same problem, also with raspberry pi and w1-kernel-modul.
>> I've implemented a retry on client-side (OWNet.pm), this works mostly in
>> the
>> second try, maximum at the fourth time.
>> could it be there is a timing problem with w1-kernel-modul?
>>
>
> I suspect, as Jan suggested that it is due to the fact that the kernel
> uses 'bit banging' which means that it drives the 1-wire directly under s/w
> control. This is inherently unreliable as occasionally something more
> important will come along that the processor needs to do and the 1-wire
> signal gets disrupted. I think probably best just to accept that retries
> are necessary when driving the bus in this way.
>
> Colin
>
>
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
>
>
>
> _______________________________________________
> Owfs-developers mailing
> listOwfs-developers@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
>
> ------------------------------------------------------------
> ------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
