Using FVR on a adc channel

[mnfisher]

I got something working - so at least the hardware is good?

My first test - I used the potentiometer component - and didn't get the result I was expecting
I'd connected 3v3 from an Arduino to rd1 as a simple test value (and of course connected the ground pins) I connected the UART Tx to a logic analyser to read the results (though a USB-UART FTDI device would have been better!)
The MCU is powered from a PSU - set at 5v (although it insists this is 5.02V) and I used a PICKit5 to program.

I then tried a simple ADC setup in C - and this works AOK (I get 3.28V with slight variations +/- in the 6 digits result)

As a further sanity check - I changed the gain to 2 (2.048v) and got the expected overflow value.

So this is hardcoded to rd1 - and I am using a external 20MHz crystal - but the code **should** work pretty much as is on your hardware after tweaking the pin if needed (and the target/clock) In GetADC - the pin address is 0x19 (for RD1) - this should really be set using a constant or calculated to allow a different pin to be selected...
I also setup the ADC and then leave it enabled - unless you are doing continuous readings (as here) then you should probably disable it after a measurement.

Next - why doesn't the potentiometer give the correct result?

Martin

[siliconchip]

hi martin
thanks for the reply, im a little baffled about setting up the fvr, i originally set FVRCON and thought then the rest of the setting up was done by the properties box for the potentiometer acting as the adc input, therefore i dont understand why in your 'setupadc' macro you have gone to great lengths to set this up, am i missing something, this isnt a critisism, im baffled by the concept and interested to learn

cheers bob

[mnfisher]

Hi Bob,

I did everything myself - as using the component wasn't giving the expected result. I wanted to check that the hardware was playing nicely. It should be possible to use the component - with the extra FVR setup (although i didn't have time to check this morning) but if the component sets these registers every 'sample' it might not be - although there is the FVR option...

Martin

[siliconchip]

Hi all
first off id like to thank ben and martin for their help in me getting the FVR to work, but at this point im at a brick wall as nothing seems to work, ive attached my original program that measures resistance well up to a point the ref resistor can handle and this is fine, when compared to a fluke DMM im not far out and thought if i could utilize the chips FVR i may be able to make it slightly more accurate but i just cant get the correct results when trying to use the FVR, is this a problem on this chip or a bug with flowcode ?? i was of the understanding that when using the pot on my input and configuring within the pot properties the FVR would be set but it seems i require additional code in a c block, any more info would be gratefully appreciated

cheers bob

[BenR]

Hi Bob,

It would help me a lot to be able to see you're measurement circuit. That way I will be able to confirm if my assumptions about how you've wired things are correct.

[siliconchip]

hi ben
thanks for the reply ive sent a pdf with a basic schematic hope this is ok

cheers bob

[medelec35]

Hi Bob.
You are using a fixed resistor connected to VDD and an unknown resistor connected to ground. Since the formula relies on Vref being the same as VDD, they cancel out.
If you want to use FVR, since FVR isn't the same as VDD anymore, you will need a different formula and you will need to know VDD.
If your supply is stable, the easiest way is to measure VDD once with a multimeter and use that figure in the formula.
The microcontroller can work VDD out for itself too, but that's only worth doing if VDD changes while it's running, like on a battery. For most setups, a fixed measured value is fine.
read is your ADC reading from the pin with the unknown resistor connected, taken with the ADC reference set to FVR.
Assuming FVR is 2.048V & VDD is measured with a multimeter at 5.1V
First turn that reading into an actual voltage:

Code: Select all

mV = (Float read *2048.0) / 1023.0

Then work out the resistor value:

Code: Select all

R = PullUpResistor * Float mV / (5100.0 - Float mV)

Note the Float keyword and .0 just makes sure all values are float and not typecast to ints.

If you've set everything up with the formulas above, you can use them the other way round to check FVR is actually set correctly.
Feed in a voltage equal to FVR itself (2048mV if that's what you've set it to), and the ADC should read full scale, 1023.
Then drop that voltage by 100mV below FVR and check the reading follows:

Code: Select all

ADC = (mV * 1023) / FVR_mV = ((2048 - 100) * 1023) / 2048 = 973

So you'd expect:

2048mV in → ADC reads 1023

1948mV in → ADC reads 973

If your readings come out close to that, FVR's set correctly. If they're noticeably off, FVR isn't outputting what you think it is, and you'll need to sort that out before trusting the resistor readings

I hope this helps.

[medelec35]

Just thought on the original method.
You can check the expression is not being type cast by adding in a calculation box just after ADC component

Code: Select all

read = 320

THen check both hardware and simulation shows the same values of

Code: Select all

121.5

[mnfisher]

In my experiment - the potentiometer component always seems to return VRef (so 4.096V) - hence my play above.

Looking at the CAL code - there is some to handle FVR mode and I tried modding this to be more like my setup code above (which does return the correct result) - it doesn't set all the FVR registers. However, I haven't managed to get it to work yet...

I added

Code: Select all

		
		ADCON0 = (Channel << 2);
		if (Vref == 3)	{						//assign VREF functionality
			FVRCONbits.FVREN = 1;   // Enable FVR

			ADCON0bits.ADFRM0 = 1;
    			FVRCONbits.ADFVR = 2;
			while (!FVRCONbits.FVRRDY);
			ADREF = 0x03;   // Set to FVR module 
		} 		

Martin

[mnfisher]

Something like might do the trick - I hadn't realised the check was done for so many different ADCC types - and I'd just used the first

So, for my case, adding the code to the PIC16F188xx code does seem to make a difference. Still not returning the right value - but at least it's not 1023 any more!