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
