Sorry to be blunt, but this is exactly what I want to avoid. Just because you are implementing your DAC in one form doesn't mean that others will. We need to have a common model that allows OWFS to present a rational access model to differing implementations of the same functionality. That's the whole idea of hardware abstraction, which is what OWFS is. It's why OWFS is so much better than random devices that I have to handle directly from a user layer on things like 485 multidrop.
Also, I think we want a given address so that what the board returns is what it is currently doing and not what it is capable of. If I have a common pin as a BLAH, OWFS doesn't want to know about pins or what other things that pin could do or what other things other pins can do. It wants to say that this address is currently offering a BLAH and here are the register offsets for standard BLAH control. So you need to be able to tell the device what it is doing right now and then OWFS gets that info. If there are 6 BLAHs, then I would expect 6 of these BLAH descriptors. Does the descriptor need to have a string available that can be read back through OWFS a la SNMP object description text? The best things I can point you at in terms of what I am thinking of is a very very simple take on an SNMP MIBs or the stream descriptors in an MPEG file. These are a couple different takes on allowing different things to self identify within a larger context. There's some minor fun with this, because the capabilities can in theory be changed on the fly. How often is capability polling required for this dynamic situation? I think this argues against a persistent object index. We may want to have a persistent identifier separate from index or punt this to a higher level. An example that I am thinking of is wanting to be able to have a pair of control or sensor points that a user can recognize as common and handle failover or other possible functions. I want the tag to reside with the low level representation of the point to OWFS to make reconfigs and other things seamless. I would like to build a protocol scaffold that makes no design commitments but still puts things in a rational form (done this many times before.) I will use or refer to some Internet RFC standards and concepts, it's the horse I know best. The best thing right now is to come up with common and wild ideas for possible devices. We need what things the device is doing, how much is happening at the low level and what kind of common controls would make sense. Using the DAC as an example: I tossed out that the common representation should have a pair of 16 bit R/W registers, one for signed value and one for log gain. I would argue you don't really need to know if the gain is variable. Just write a different value and read it back, if it's unchanged it's fixed. Since we have the gain value, implementers should always fill in the max output so it can be easily queried. Do we need to indicate current vs voltage vs frequency or whatever form of output? If so, we will need to keep an agreed list of numbers and meaning [This is the IANA function in the internet. I would nominate Paul as the the 1ANA.] Do we need to add something to allow for units that can slew rather than jump to a new value (my VFDs do this?) Do we need a zero offset value (4-20ma technically has a range of 16ma and a zero offset of 4ma?) If so, does the gain represent the max value (20ma) or the max range (16ma?) We can have more than one DAC implementation with different capabilities, but there needs to be a compelling reason to do so. For a simple DAC, almost all the values are constant and simple to respond to. Would someone be up for taking a stab at something like a counter or a timer? I could also do one of these for a multiple thermocouple interface device if people think another example would help. It's one I have both need and thoughts for. warmly, jerry [email protected] wrote: >> First, I would love to see a model for DAC as well as PWM for output. > > Well, i view DAC as primarily a hardware interface to either PWM or PIO > features. The chips themselves (at least AVR) do not directly support DAC, > but you can either do PWM with a Resitor+capacitor smoother, or a R2R > resistor network. Feed the output to an op amp and you're done. I'm sure > there are similar HW interfaces to 4-20ma type interfaces also (probably also > op-amp related) > > In other words, i can't make the chip do things it has no hardware for :) > > I think the DAC feature could be added to OWFS similar to how thermocouples > are: if you have standard HW interface, it can abstract that and you can just > tell it to 'set 2.2v' or whatever. > > >> ... >> 2-10V/4-20ma is such a common control point model that this kind of >> capability would be quite useful for things like HVAC damper >> positioning. > > Funny, that's exactly what i was planning on doing with mine: PWM -> RC -> op > amp > >> Now that we are stepping into this world of programmable 1-wire devices, >> there is the problem of discovery. How can we well what capabilities are > available from a given serial number? Here is a modest proposal that > would seem to fit the overall model of the system. > >> Since synthesized read address space is cheap on these beasts, perhaps >> we can have something that has a given read only address block that >> 1-wire can read and see what standard options the device has and how >> many of them are implemented on a given board. If this block also gave >> the address offset of where to control the block, then the 1-wire code >> can stay fairly stupid in granular implementation. We end up with some >> representation details like how do you expose 4 PWMs under a single >> address. I worry less about these since I tend toward programatic >> control rather than web based. > > My thoughts: > * AVR hardware has specific functions locked to specific pins > * multiple functions can be on the same pin > * therefore in order to properly implement, we need to have some sort of > resource model > > I would propose something like a memory location that when read, gives a > function, and a pin mask with which pins support that function. It will keep > returning functions till it's out, and then will return an 'EOF' type > message, eg > > FN pins exclusive? EOM > pwm 0x0300 EX EOM (pins 8,9) > counter 0x0300 EX EOM (pins 8,9) > ADC 0x003f NEX (pins 0-5) > PIO 0xffff NEX (pins 0-15) > EOF > > Then the higher level could see that counter conflicts with PWM, adc is on > its own, and PIO can be had on all pins. > > The exclusivity flag means that the pwm will take over all pins, so you can't > use counter + pwm at the same time. > > thoughts? seems simple enough to use and to implement. The exclusive flag bit > could probably be shared with the EOM flag bits in the final byte. > > -tmk > > ------------------------------------------------------------------------------ > 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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/owfs-developers
