On Mon, Mar 13, 2006 at 07:46:11PM +0100, Jan Kandziora ([EMAIL PROTECTED])
wrote:
> Am Montag, 13. M?rz 2006 17:11 schrieb Evgeniy Polyakov:
> > Hello.
> >
> > On Wed, Mar 08, 2006 at 12:18:33AM -0500, Paul Alfille
> ([EMAIL PROTECTED]) wrote:
> > > Just a progress report:
> > >
> > > After extensive discussions with Evgeniy Polyakov, it looks like OWFS
> > > will be able to use the linux kernel 1-wire drivers as a possible 1-wire
> > > adapter source.
> >
> > ...
> >
> > Found mail archive with this discussion. I'm not subscribed so please
> > Cc: me on replies.
> >
> > Couple of notes after archive reading:
> >
> > 1. w1 supports on-demans searching in the following way:
> > search is performed on $w1_timeout interval basis, which is provided as
> > module parameter. By manipulating w1_master_search sysfs file one can
> > trigger to search or not on next $w1_timeout interval.
> >
> Ok. That would mean I could set $w1_timeout to e.g. 0s and disable it by
> default. Whenever I want to search, I'll enable the sysfs file, then disable
> again immediately. Right?
$w1_timeout should be set to more meaningful alue, since it is also
timeout used for deice state check and possibility to sleep for suspend.
Just setting w1_master_search to 0 is enough to stop repeated searches.
> Searching onewire is a very time-consuming operation, that's why I like to
> have it disabled or controlled by the application program. Otherwise we'll
> get into naughty situation-dependent timing issues.
>
>
> > 2. I plan to create demo code for netlink socket communication interface
> > for w1 this week. This will completely eliminate any kind of races with
> > multiple workers/reset and so on.
> >
> Fine. Thank you.
>
>
> > 3. w1 has it's advantages due to it's in-kernel place:
> > * some processors (Freescale made) have w1 units which can not be
> > accessed
> > from userspace without in-kernel driver
> >
> Ok. Useful in any case.
>
>
> > * GPIO pins can not be accessed from userspace without in-kernel
> > driver (actually there is [1] generic GPIO framwork with w1
> > driver tested with pc3487x and natsemi sc1100, but work was
> > frozen
> > due to lack of hardware)
> >
> I'm in doubt this is really useful - if the onewire protocol is done
> completely in software, things would slow down a lot. It does not add too
> much cost to add a DS2482 on the board, as I2C is available most of the time.
It costs nothing if implemented in software even in kernelspace, since
it is executed in process context and Dallas itself allows not even near
to 100% strict timeouts, although "strict" is subjective by itself.
> Ok, for a few onboard temperature sensors, this will be the best idea. No
> discussion needed.
>
>
> > * w1 supports asynchronous notifications of new devices found,
> > which are multicasted for any process over netlink
> > socket interface.
> >
> How is it with the alarm state? Is asynchrous notification planned here, too?
Hmm, it just requires to add new command to 4 exported:
W1_SLAVE_ADD = 0,
W1_SLAVE_REMOVE,
W1_MASTER_ADD,
W1_MASTER_REMOVE,
W1_SLAVE_ALARMED or something.
I did not implemented alarm searching and setting since I (still) do not
see how it can be used, since monitoring always implies regular checks,
either using alarm search, or by checking each slave device, which is
preferred since allows to check device's state.
But it is just my opinion, I see that it is not the solution for
everyone.
Alarm processing is not that hard to be done, and will be implemented on top
of socket based access to w1 subsystem.
>
> Kind regards
>
> Jan Kandziora
> --
> You cannot kill time without injuring eternity.
--
Evgeniy Polyakov
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
