Examples & Usage
Temporary storage of device properties.
Reading data from the 1-wire bus is relatively slow. In some cases, a
script or program needs to refer to the same value several times in a
calculation. Caching stores the value read temporarily, bypassing the
need for bus access and making the data read seem faster.
An alternative to caching is to store the value in your program as a
variable , and use that variable in the calculation. Either method will
Several points about caching:
The caching system can either not be included in compilation (saving
space for embedded systems), or the timeout can
be set to 0 seconds, effectively turning off caching.
Different types of data are handled differently. More volatile data is
read from the chip more frequently than the stable settings. The cache
system purges itself of old data regularly, and thus won't become a
memory hog. The cache updates it's stored data whenever pertainant data
is read from the bus.
Despite careful design, there is the risk of old stored data being
displayed -- i.e. the chip and the cache won't agree. The timeout
feature is an attempt to force periodic refreshing without causing too
great a performance hit.
There is a directory called "uncached" with holds a mirror of the main
directory, but without any caching being done. Data read will still be
added to the cache, allowing a method of starting a calculation with a
new value. Thus reading temperture with the command:
will answer with the result of a recent temperature conversion or cause
a new conversion if a recent one is not available. On the other hand:
will force a new conversion (but store the new result in the cache as
Types of data
The caching system handles different types of data differently. There
are three main classes:
Data that doesn't change is not cached. For example, the chip's class
name (e.g. DS18B20) is
not cached. This includes type, address, ID, CRC8, port, and
Statistics (e.g. bytes read) are not static, but are more easily
recomputed than cached, so statistics are not cached.
Data that changes only on command, like PIO settings, is cached. This
data is more stable, it should only change under your program's
control, so is
only reluctantly re-read. This includes settings (strobe, PIO, memory
contents. In theory, the system should be making all the changes, so
should always know the state of these properties and not need to
reread. Because the BUS can lose power, and devices can lose thier
settings, the data IS reread, but infrequently. The default timeout for
stable data is 10 times longer than for volatile data. Reading from the
directory will also force a reread.
Data that is generated by the chip, like temperature is considered
volatile. It is cached, but only for a
short time. Counters, voltage readings, external power, chip presence,
and sensed PIO pins are also volatile. The clock
counter is a special case. it is cached only 1 second.
Directory listings are generated by scanning the 1-wire bus. This is a
clever, but relatively slow process. The directory contents will be
cached. They will be treated as less volatile than "volatile" but less
stable than "stable".
Reading the "/uncached" directory will force a rescan of the 1-wire
From the command line, the -t option takes a parameter giving hte
timeout for volatile data in seconds. The stable data will be held 10
Examples (3 second timeout):
/opt/owfs/owfs -t 3 /dev/ttyS1 /mnt/1wire
/opt/owfs/owhttpd -t 3 -d /dev/ttyS1 -p 3001
Found under the stats_cache directory: See the statistics page for more
information and example code.
|Calls to the caching
system. Attempts to match a cachable value.
|Valid cached values returned.
|Cache attepts that were
|Number of times the database
has been purged (flipping the new hash table into the old one).
|Data values added or updated.
|Data valused deleted (not
including purged data).
|Data that was found, but had
- The cache is designed as a hash from the filename (e.g.
/29.4707000000/power) to a time and value. The when the time has
passed, the value is stale (expired in the statistics).
- Current implementation uses the intrisic gcc binary tree
- Prior to version 1, the underlying database is an in-memory Berkley db -- version 3 or higher.
- Two hash databases are actually used, with new entries or
updates only going in the new one. The newer one is flipped to older
when the old one has timed out, purging very old data.