> 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
