Am Dienstag, 5. Dezember 2006 18:31 schrieb Gregg C Levine:
> Hello!
> That series of issues with the LCD display device that Hobby Boards
> developed independently of Maxim brought to mind an interesting issue.
>
> For example what boards made by them are directly supported? And what
> boards are an inference? Consider this, the company (Hobby Boards) makes a
> gizmo who will lend One Wire support to a conventional LCD display exactly
> as if it were installed in the same housing as the one to which the both of
> you were discussing support issues for.
>
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
--
You have acquired a scroll entitled 'irk gleknow mizk'(n).--More--
This is an IBM Manual scroll.--More--
You are permanently confused.
-- Dave Decot
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
