1. SkipROM (Convert all)
Three problems I'm still wrestling with:
A. Multiple paths (branching) makes this idea far more complex.
An nnnnnnn/aux path must be selected before the SkipROM/Convert is
sent. We would have to remember which path was selected, Send convert to
that path, and check that requests are on that path. Feasible, just
detailed and less elegant.
B. Simultaneous covert should only be done for powered devices. (not
parasitic). Note that using many threads, multiple powered devices is
already handled quite efficiently. We'd have to check that all 18x20's
are powered before sending the command.
C. The 1922/1923 tolerate conversion poorly if their clock is
disabled. (It kills them). This will need some investigation.
2. Lasttemp, lastvolt is fine. Note that cached values might already be
present. What are your timing constraints.
On Wed, 2004-09-22 at 09:59, Serg Oskin wrote:
> In my project plenty DS18S20 and DS2450 is used. Sequential interrogation
> demands a lot of time because of sequential execution of Convert command on
> each device. In 1-wire protocol there is SkipROM (0xCC) command who allows
> to execute Convert command on all devices simultaneously. Taking into
> account spirit OWFS it will not allow to receive fast value of
> temperature/volts, but will allow devices to react adequately on
> Conditional Search. In my project it will allow to inspect fast parameters
> of set of sensors without dependence on their quantity.
> Now it is necessary to think up a way of start of commands such as
> SkipROM+Convert. For 1-wire devices there are some varieties of Convert
> command, for example for the devices used in my project they are those:
> Convert temperature (0x44): DS18S20, DS18B20, DS1822, DS2438
> Convert volts (0x3c,XX,XX): DS2450
> Convert volt+current (0xB4): DS2438 (optionally)
> I assume a variant with creation of the directory /skiprom in root
> directory OWFS and in it such files as /skiprom/tempconv, /skiprom/voltconv.
> Write any data to these files for start appropriate Convert commands
> There are other ideas?
> Also it was - useful to have possibility to read values temperature/volts
> from devices without mandatory start a Convert - for example from such files
> as 10.XXXXXXXXX/lasttemperature and 20.XXXXXXXXX/lastvolt.A is will allow to
> check a reason of alarm fast. I think it does not contradict spirit OWFS as
> the external program reading these files assumes, that these data can be