ReadAD & ReadAD10 do work as expected with PIC16F1788 & PIC18F25K80. The results are unstable & erroneous.
This is likely a problem with All PiCs with 12-Bit differential ADC capability.
Background
Both of these micros/ families have 12-Bit ADC capability and in GCB seem to default to "differential mode" where the returned value is the difference between 2 ADC channels as setup in the ADCON registers.
Observations
A simple ReadAD or ReadAD10 command will result in erroneous data because one of the ADC pair channels is left floating. This can be proven by externally grounding the floating ADC channel, at which point the ReadAD10 returns a correct 12-bit value.
This appears to be an issue with the ADC library, where it does not know that for these PICS with 12-bit differential ADC, that certain registers need to be set to do single ended ADC reads.
IN other words, the default configuration should probably be for single ended ADC where Vref+ = Vdd and Vref- = Vss.
Workaround
The lines following can be added to the main program as a workaround. (Tested only on PIC16F1788)
set chsn0 on
set chsn1 on
set chsn2 on
set chsn3 on
Last edit: William Roth 2014-08-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Hugh. I do not think this is fixable in the code as the knock on impact would be disable the ADC ports which may catch a few users out. If you think differently let us know.
I can add this to the documentation as a way forward.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It should be fixable without affecting other chips. Suggest the following be added to A-D.H right after "IFDEF PIC"
#IFDEF bit(CHSN3) 'For 16F family with 12Bit ADC
set CHSN0 ON
set CHSN1 ON
set CHSN2 ON
set CHSN3 ON
#ENDIF
#IFDEF bit(CHSN0)
#IFNDEF bit(CHSN3) 'For 18F Family with 12Bit ADC
set CHSN0 off
set CHSN1 off
set CHSN2 off
#ENDIF
#ENDIF
Last edit: William Roth 2014-08-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
William, that looks like a good fix. I've had to make changes like that many times, as you can probably see from the mess that is a-d.h! I think I have a PIC18F25K80 here (it's hard to keep track sometimes) and will try it out tomorrow or on the weekend.
Anobium, we shouldn't need any change to the help file to cover that. It looks like the change will make the ReadAD function behave as expected from the documentation?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The above workaround does not work on PIC18F25K80.
According to the datasheet, clearing ADCON1<2:0> (CHSN0 - CHSN2) will internally connect the negative channel to AVss. In practice this does not work per the datasheet. I had to either connect VRef- to ground, or connect the paired Pin to ground for ADC to have a 0V negative reference. Setting the VRef- Pin or the negative channel pin as a digital output (Low) also seems to work. This group of chips is primarily for CAN Applications and will likely not be used much with GCB. I just happened to have one left over from a previous project.
The workaround works fine on PIC16F1788.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ReadAD & ReadAD10 do work as expected with PIC16F1788 & PIC18F25K80. The results are unstable & erroneous.
This is likely a problem with All PiCs with 12-Bit differential ADC capability.
Background
Both of these micros/ families have 12-Bit ADC capability and in GCB seem to default to "differential mode" where the returned value is the difference between 2 ADC channels as setup in the ADCON registers.
Observations
A simple ReadAD or ReadAD10 command will result in erroneous data because one of the ADC pair channels is left floating. This can be proven by externally grounding the floating ADC channel, at which point the ReadAD10 returns a correct 12-bit value.
This appears to be an issue with the ADC library, where it does not know that for these PICS with 12-bit differential ADC, that certain registers need to be set to do single ended ADC reads.
IN other words, the default configuration should probably be for single ended ADC where Vref+ = Vdd and Vref- = Vss.
Workaround
The lines following can be added to the main program as a workaround. (Tested only on PIC16F1788)
set chsn0 on
set chsn1 on
set chsn2 on
set chsn3 on
Last edit: William Roth 2014-08-13
Thank you. Really good information.
@Hugh. I do not think this is fixable in the code as the knock on impact would be disable the ADC ports which may catch a few users out. If you think differently let us know.
I can add this to the documentation as a way forward.
It should be fixable without affecting other chips. Suggest the following be added to A-D.H right after "IFDEF PIC"
Last edit: William Roth 2014-08-14
A good idea.
Do you have any wise words I can include in the Help File to cover this functional change?
William, that looks like a good fix. I've had to make changes like that many times, as you can probably see from the mess that is a-d.h! I think I have a PIC18F25K80 here (it's hard to keep track sometimes) and will try it out tomorrow or on the weekend.
Anobium, we shouldn't need any change to the help file to cover that. It looks like the change will make the ReadAD function behave as expected from the documentation?
Possibly a footnote that indicates that readad10 will return a 12-bit number on PIC chips that support 12Bit ADC?
Update:
The above workaround does not work on PIC18F25K80.
According to the datasheet, clearing ADCON1<2:0> (CHSN0 - CHSN2) will internally connect the negative channel to AVss. In practice this does not work per the datasheet. I had to either connect VRef- to ground, or connect the paired Pin to ground for ADC to have a 0V negative reference. Setting the VRef- Pin or the negative channel pin as a digital output (Low) also seems to work. This group of chips is primarily for CAN Applications and will likely not be used much with GCB. I just happened to have one left over from a previous project.
The workaround works fine on PIC16F1788.