Analog Input reading problem

[Omer]

I have a problem reading 2 Analog inputs on a PIC18F87K22 MCU. I need to read the Analog In 19/Pin G1 and 18/Pin G2. I have connected a 0-5VDC variable voltage source to these inputs and have a precision 5VDC source connected to VREF+/Pin27. Avdd is connected to VCC 5V, Avss is connected to Gnd/VSS. I'm reading input values on my PC via UART1. My PCH compiler version is 5.051.
The problem I'm having is with 0V at either or both of the inputs I read value 0 but when I connect say 2.5VDC the reading goes up to 95 and stays there. It should read 2048 since I set ADC=12. When I reduce the input to 0VDC the value goes down to 0. Anybody have any idea on what maybe wrong here? Here is my code:

[Omer]

I just noticed I made an error in the printf format I changed the %2Lu to %5Lu but the problem still persists. Instead of the value 95 now I read 65520 continuously even though the input is at 0V. Weird! Any ideas?

Here is what I read on my PC using RealTerm:

Read analog input channel:
Temp_Read1: 65520 Temp_Read2: 65520
Read analog input channel:
Temp_Read1: 65520 Temp_Read2: 65520
Read analog input channel:
Temp_Read1: 65520 Temp_Read2: 65520
Read analog input channel:
Temp_Read1: 65520 Temp_Read2: 65520

[Ttelmah]

First, 9/10. You tell us everything we need to know, including compiler version, and a good description. Also including a short program. Hurrah. Except you forgot the code buttons in the original post. So nearly perfect.

Now there are several things about the pins, These are used by the ECCP3, EUSART2, and comparator 3. The ECCP PWM, and comparators in particular have the habit if interfering with other things, so explicitly disable these.

Then the number you are getting, looks to me as if the chip is possibly being configured to give the result 'left justified', so is giving the data as the top twelve bits, and seeing the value as -1 (remember this ADC supports differential operation, so can give -ve results). This is controlled by the ADFM bit, and this needs to be set to '1' for right justified operation. A quick look at the code generated, shows CCS leaving this bit unchanged, and the data sheet has it as defaulting to '0', which gives left justified operation. It looks as though this has been assumed to be set to '1' on boot (on many chips it is...). So you need to add (however see below!):

[Omer]

Hi Ttelmah,

Thank you for your kind words and great support. I fixed the problem with your suggestions now I can read both analog input channels. However I had to set ADC_CLOCK_DIV_16 to ADC_CLOCK_DIV_2. With 16 setting the 2 channels interfered with each other in other words there was cross talk. I tried various settings and it worked best at setting 2. Don't know why but it worked so I'm happy

I did not know that I had to add the code buttons. I don't know what that is. I looked into the forum help but could not find any description.

Thanks again for your help!
Omer

[Ttelmah]

The crosstalk will still be there. You are over-clocking the ADC, which has the effect of reducing it's accuracy (very significantly). You are probably only getting about an 7bit ADC, clocking it this fast. So this is hiding the noise....

[gaugeguy]

You should try
setup_adc(ADC_CLOCK_DIV_16|ADC_TAD_MUL_4);

I have found this can improve the A/D performance even if you have the proper delay before reading the ADC. I haven't used this processor but I have used others in the k22 and k80 family where this helped.

[Ttelmah]

Yes. It is interesting. You will find that CCS won't actually give you a 0 Tad MUL. They will code as a _minimum_ of 1 on most of these processors. Actually pausing a little more at the start of the conversion using the Tad MUL ability often seems to reduce processor noise noticeably.