My $0.02: I don't think this approach (unique ID numbers/families/subfamilies for capabilities) is a good approach. This means for each new configuration, a new ID needs to be registered, OWFS needs to be patched to support, etc. As you suggested, this process would only be used on devices/configurations "generally available".
I think that there's a cleaner, easier, more capable method: Have the device identify itself. I don't think it would take much...just have a chip have a "well-known" address that OWFS does a read on to describe what data types are available, where they are, and what to call them. Perhaps this can even be in a form similar to what OWFS currently uses in its code... This way, there is only one family code, and OWFS handles it the same, and yet supports essentially infinite device configurations. This even means that devices electrically identical can have different values assigned. Instead of having "volts.A, volts.B", etc, it could actually be "temperature, batteryVolts", etc. And a second identical chip could be configured with completely different names for the inputs/features available. All this without having to modify OWFS for each new configuration. I think the most serious implication is for those designers experimenting with chips, or doing very custom / not publicly available configurations. In the case suggested in this thread, they'd need to maintain their own patch against OWFS, for some unregistered device ID range that they've selected. Each time they want to upgrade OWFS, they need to make sure their own personal patch applies, or make mods to it, etc. --Jim On Sat, Apr 17, 2010 at 10:13 AM, Jerry Scharf <sch...@lagunawayconsulting.com> wrote: > Given that most of these devices are not so likely to have 4B created > over their lifetime, would you be willing to allow the device designer > to designate more bits of subtype (subsubtype) to identify functional > capability within the device? This would be purely the choice of the > designer. > > As an example: I don't expect more that 1M of my beasts to be built, so > I will allocate the other 12 bits for function sets. If I allocate > function sets from the top and ids from the bottom of the 32 bits this > can be a pretty soft split. The device specific code needs to understand > the function sets... > > I would still recommend that the device id part be unique over the > device and not use the function set to disambiguate. > > This is not quite like the generalized "I have x capability" discussion, > but it is a worthwhile intermediate. > > thanks, > jerry > > Paul Alfille wrote: >> Aggreed. >> >> I think Louis Swart's technique (at least as expressed in the LCD >> datasheet) is that >> FF.0001XXXXXXXX is LCD >> >> So there are 64 bits >> - 8 bits CRC8 >> - 8 bits family code (FF) >> -16 bits 0001 subtype >> ---------------------------- >> = 32 bits for the particular device (>4000000000 unique >> devices) >> >> >> That also allows 2^16 potential subtypes (>64000) >> >> As far as OWFS is concerned, this is extremely easy to implement. >> >> Paul Alfille >> >> >> On Fri, Apr 16, 2010 at 6:38 PM, Dr Nathan Hurst <n...@njhurst.com> wrote: >>> On Fri, Apr 16, 2010 at 09:21:40PM +0000, Matthias Urlichs wrote: >>>> Hi, >>>> >>>> I wrote: >>>>> However, I do think that I'd rather implement a 'tell me what you can >>>>> do' feature command, than allocate a new ID for every crazy ^w >>>>> interesting idea I might have. >>>> On the flip side, Louis Swart <lo...@louisswart.co.za> replied that >>>> he'd be amenable to delegating sub-ID of 'his' 0xFF device ID range to >>>> people if they send him a short description of what the code is supposed >>>> to be doing. I presume that this way would fit into owfs somewhat more >>>> easily. >>> Given the 2^56 ids available under 0xff, I suspect that would do us >>> for the time being. The real problem is overallocation of the space >>> (thus using it up for non-existant instantiations). I suggest that we >>> allocate 32 bit ranges at a time allowing for a wildly successful >>> project to go to everyone on the net, and still allowing 16M projects. >>> >>> njh >>> >>> ------------------------------------------------------------------------------ >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, find bugs >>> proactively, and fine-tune applications for parallel performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev >>> _______________________________________________ >>> Owfs-developers mailing list >>> Owfs-developers@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/owfs-developers >>> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Owfs-developers mailing list >> Owfs-developers@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/owfs-developers > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Owfs-developers mailing list > Owfs-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/owfs-developers > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
