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 Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers