What's wrong with a simple string in a 1-wire accessable location. The decoding should all be done in the driver, so we just need to be able to distinguish devices and features. Leave that to the device designer.
njh On Tue, Apr 20, 2010 at 01:45:29PM +0000, Matthias Urlichs wrote: > On Mon, 19 Apr 2010 19:59:20 -0700, Jim Kusznir wrote: > > > I think that there's a cleaner, easier, more capable method: Have the > > device identify itself. > > It's a trade-off. The downside, unfortunately, to what you're suggesting > is that the information needs to be stored on-chip. That eats Flash > (or EEPROM). The typical amount of storage on these little things already > _is_ best described with the words "not enough". > > The structure also needs to be expressive enough to say exactly what to do > when you want to read/write a value, including features like CRC checks > and confirmation commands -- I wouldn't want my central heating controller > to try to deliver 160°C instead of 60°C because of a single stupid bit > error. :-/ > > If you have some idea what that could look like, go ahead, but personally > I think that debugging the support for such a thing, both in OWFS and in > whatever program prepares the struct for programming onto 1wire devices, > will require a lot of bugfixes and new versions until it's stable. > > Me? I'd rather spend that effort on developing more interesting devices. ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/owfs-developers
