DAC and ADC on the same pin
The goal here is to use the DAC to calibrate the ADC. I was not successful. Tonight I was looking at the documentation and may have figured out why.
M=%00000, T=%0x, OUT high will enable the ADC, but the only way to get an ADC reading would be Goertzel.
M=%00011, OUT high will enable ADC and give a sinc1 measurement over a period that matches the DAC output period.
What I tried to do:
_dirl( io_pin )
wrpin( io_pin, p_dac_124r_3v | p_tt_00 | $00<<8 | p_adc )
wxpin( io_pin, 13 ) ' SINC2 sample mode, 8192 clocks
_dirh( io_pin )
pinhigh( io_pin )
The ADC result comes back as 0, suggesting that it didn't really turn on. Even if the DAC is outputting 0, the ADC count should be more than 0 because of its beyond the rails measurement capability.
So it seems like it's not possible to enable the DAC while the smart pin is operating the ADC in sinc2, sinc3, or scope mode. Is this correct?
I didn't have any luck with bit dac mode either.
Comments
Because I can't remember my precedence rules I never trust myself with things like:
x | 0 << 8 | y
so maybe try this instead..?
p_tt_00 | (0 << 8) | p_adc
EDIT: never mind, just looked it up, I think the shift left has higher precedence than bitwise OR so this should be okay.
By the way, at one point IIRC there was a discrepancy between FastSpin (now flexspin) and PropTool/PNut precedence. I think at the time I mentioned it to Eric so it should have been resolved by now.
You can do this by using a nearby pin to look at the digital ADC values from the pin with the DAC&ADC using the -3..+3 pin offsets of the smartpins...
Because the smartpin is in operation (for ADC bitstream capture), it means that DIR is used for the smartpin rather than enabling the DAC. So replace the
p_tt_00
withP_OE
PS: And this would be a great situation to use the SETDACS instruction too. Err, can't be done. %TT is way overloaded.
EDIT2: Yeah, %TT being limited to two bits definitely nerfs the possible combinations of what can be used together via the existing P field.
If you're wanting to do anything more than preset the DAC level then Rayman's solution is the more flexible.
_
Yes, that is correct, unfortunately. I asked Chip about it once in a live forum, he confirmed it and said there was a reason, but couldn't remember which one.
That doesn't sound right. If it's true then the docs need some corrections. They've clearly stated all along that OUT high will enable the ADC when in a DAC mode.
You can enable the ADC, but you can't use the SINC2 and SINC3 smartpin mode for conversion, you only get the ADC sigma-delta bitstream.
That doesn't make any more sense at all. The smartpin mode is what set, in this case P_ADC (M=%11000). It will count whatever is coming in from the pin.
Worked out why ... It's another limitation of having only the two %TT bits. When in a non-DAC smartpin mode, but using a DAC pin mode, then OUT is used for BITDAC rather than ADC enable. So, ADC modulator won't engage, no bitstream.
Rayman's solution should be fine. The DAC/ADC pin won't have its smartpin operating then ... Or it will be used for dithering the DAC.
EDIT: There's a typo, repeated too, in the silicon docs regarding the %TT bits. Where it says "OUT enables DAC in DAC_MODE" it should say "OUT enables ADC in DAC_MODE" Err, fixed in the online edition already.
Thanks. I don't think it was December 22. I watched that one recently and I think it would have perked my ears up.
I got it to work in mode 3, DAC PWM dither.
M=%00011, OUT high will enable ADC and give a sinc1 measurement over a period that matches the DAC output period.
While it would be nice to use the same sampling mode for calibration, it is easy enough to scale the calibration measurement to be consistent with the sinc2 sampling mode I use for the actual data.
That's a useful mode, and being able to use the DAC to calibrate the ADC allows for better useful ADC precisions.
It will be mainly catching the mid-point offset and the ADC resistor-ratio changes, so those will not vary with filter settings.
It does require that your external circuit can tolerate DAC drive to the ADC-IN pin, but that could be allowed for by design.
James,
I presume you've got two smartpins running. The DAC's one for dithering the DAC. And a nearby one, with input redirection, for the ADC bitstream capture.
Mode words, respectively, would be something like:
P_DAC_124R_3V | P_OE | P_DAC_DITHER_PWM
P_MINUS1_A | P_ADC
For a quick test I did this and it worked fine: (debug() can replace send())
Produces a numerical reading of around $1880
Single pin. The DAC pin modulation is not really desired here, but it shouldn't bother anything.
Ah, that will be reading the DAC dither Z value I think ... certainly not the ADC, that's for sure. Smile, I'm wrong. There's a whole new detail I've not seen before. From the docs:
So there's actually a Sinc1 filter in the DAC dither smartpin mode. It's doing two functions! I'll be damned.
James,
You know Sinc2/Sinc3 is available to you with Rayman's solution, right?