Am Montag, 13. März 2006 21:56 schrieb Evgeniy Polyakov:
> > > 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.
>
Hm. I'm concerned about bus load if all devices on the bus are scanned
isochronously.
I design a semiautomatic vending machine. It's planned so far with 50..200
onewire chips on one bus. I need a time slice of ~250ms in my application,
but only for the few chips which are "active" in a certain, user-application
controlled process.
As adressing and such needs ~50Bit, 100Bit per chip read/write cycle is my
"thumb value" for any operation. At 16kBaud, that would limit isochronous
operation to 120..140 operations per second. Which on the other hand means,
30..35 chips are the maximum for isochronous operation and 250ms time slice.
I don't know how overdrive speed improves this, but overdrive speed certainly
would limit the cable length, too.
For such applications as mine, it would be better to have more control over
which chips are "interesting" in some situation, and should be updated more
often and which are not. Maybe you (or we) can put some "rating" on each
chip, and an interface for the application program.
Or did I misunderstood your wohle concept?
> >
> > 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.
>
Understood completly.
> > 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.
>
Yes, that comes with isochronous checking. For most chips, alarms are only
useful if you don't check each chip everytime.
> Alarm processing is not that hard to be done, and will be implemented on
> top of socket based access to w1 subsystem.
>
Ok.
Kind regards
Jan Kandziora
--
MCSE: Minesweeper Consultant and Solitaire Expert
-------------------------------------------------------
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&kid0944&bid$1720&dat1642
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
