Am 03.02.2016 um 09:53 schrieb Stefano Miccoli:
> OK I agree… mine was a misguided suggestion (due to the lack of
> understanding of what a write to /simultaneous/temperature actually
> does.)
>
> If I got it right, everything boils down to these points.
>
> - By simultaneous conversion, we mean a broadcast that tells all
> sensors to start a temperature conversion. The single sensors do not
> report back when and if the conversion was done.
>
Yes. It's just "Reset, 0xCC, 0x44" put on the bus. That was it. A chip
may do something upon receiving that sequence or it may ignore it. The
temperature sensor chips start their A/D conversion cycle with the
resolution stored in their scratchpad[4].
You can start a simultaneous conversion for a single bus, for an
owserver or for all buses known.
> - There is no way from the client side to have the owserver lock the
> 1-wire bus and avoid that during the background temperature
> conversion other clients start conflicting operations on the 1-wire
> bus. The assumption here is that you have complete control of all
> owserver clients: due to the lack of owserver synchronisation/lock
> primitives, everything has to be done with IPC primitives client
> side.
>
You don't have this safety against conflicting operations for any other
function either. One client may turn a PIO and assume it stays in the
direction it was set. However, another client may turn the very same PIO
a blink later.
In general, there is no safe way to have multiple applications access
the same hardware without doing a logical partitioning first. So far, we
rely on applications being cooperative and properly configured to
coexist with each other.
> - Due to the atomic nature of the scratchpad update, race conditions
> cannot occur: a very loose client synchronisation is enough for most
> applications.
>
Yes. For temperature conversions, as stated, there is no need for bus
locking as the update of the sampled temperature value inside the chip
is atomic. The only reason OWFS helds the transaction open for single
temperature conversions is to expose the "ready" function the chips
have. You can sample the bus line for end of conversion. But then again,
this is limited to the folks who power their sensors.
> A section 4 manpage (src/man/man4/owfs.man) would be very useful to
> document the bunch of special nodes in the OWFS tree, and their use.
> Docs about the working of the special nodes (like
> /simultaneous/temperature) is a little bit scattered and not easily
> accessible. (Sorry I do not volunteer for writing this manpage,
> because my understanding of the inner working of owfs is a little
> weak, as my posts demonstrate.)
>
Ah, yes, documentation is sparse. But I don't think manpages help much,
being scattered is their nature.
I'm up to write a recipe book with lots of useful information how to
build a reliable OWFS based process control system, hardware and
software. As I did this myself and sell such machines with some success,
I feel able to do so.
Writing a comprehesive documentation about OWFS is another task which I
don't want to do yet.
Kind regards
Jan
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
