Currently, the only aggregate we support is the TAI-8570 barometer, which
uses 2 DS2406. In that case, the DS2406 memory is used to point to the
partner chip, so the aggregate can be "autodiscovered". There is certainly
an appeal to autodiscovery. The barrier to entry and use is much lower.
(That is why humidity is present for the DS2438, even though not all chips
are part of such a device).
The database of aggregates needs
1. unique ID
2. vendor/type
3. component IDs (Perhaps in some specific order)
4. Optional parameters/calibration constants
There is some appeal to having the database accessible/modifiable/savable
within OWFS, though that is a design decision that can go either way.
We also need a policy on whether components can be seen/addressed/changed
outside of the aggregate.
For the multi-level design of OWFS (owfs -> owserver for example) it becomes
a little more complex as to which process needs to know about the aggregate.
The level with the actual physical adapter might make the most sense.
Paul Alfille
On 12/5/06, Jan Kandziora <[EMAIL PROTECTED]> wrote:
May I chime in and bring aggregates onto topic? I developed some boards
which
will go into "mass"-production next year.
One is a 8 channel solenoid driver board for 24V~ solenoid valves. It uses
one
(next revision has two, for an additional function per channel) DS2408 as
the
onewire interface.
Second is a 8 channel counter/16 Channel digital input board using four
DS2423
and two DS2408 chips.
Another one is a 8 key keyboard with 12 LEDs (one per key and 4 other). I
think of a numpad keyboard with built-in HD44780 display, too, but that's
not
done yet. These are using three/two DS2408 chips.
And then, a lighted keylock, with a single DS2409 and a single DS2408.
These items are for my vending machine project but, as spare parts, will
be
available to the general public, too. Don't know yet if the price will be
interesting enough for hobbyists, though.
For my machine, I'll have to write some code to identify and control these
aggregates anyway. It may be more useful to the general public if we could
develop a generic aggregate handling for owfs, I think. At least, if there
was aggregate support built into owfs, they could be controlled in single
transactions and the need for a *single* program controlling the hardware
is
gone.
My idea is to have a database which map chip ids to aggregates. At first,
the
user connects the aggregate board as the only device to the onewire. Then
a
maintainer's program, which knows the aggregate types, helps the user to
identify the chips on the aggregate and their function and finally updates
the database.
(For my boards, I will perform these steps and keep an updated database
available for download e.g.)
In a first step, the database only has to contain
* chip ID
* chip number on aggregate
* vendor ID
* aggregate ID
with vendor ID/aggregate ID being a unique item.
Then owfs could present an aggregates/ directory, with all the aggregates
detected on the bus, the database contents and symlinks to the chips. And
vice versa for each chip.
In the second step, handlers for such aggregates could be incorporated
into
owfs (like it is done with the LCD aggregate already). Maybe even by a
plugin
interface?
Hope the text was not too long, too boring or simply unfeasible.
Kind regards
Jan
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
