Hi tech c adc code not working as expected

Question

I am new to using PIC micro-controllers, and I am working on a project that involves reading an analog value. I am using the PIC16F877A. I have found code for using the ADC posted below however when I try to compile it I get the error Error [192] C:\Users\Owner\Documents\Pic Projects\Analog\Main.c; 20.1 undefined identifier "GO_nDONE". Here is my code

#include<htc.h>
#include<pic.h>
#define _XTAL_FREQ 20000000
__CONFIG(UNPROTECT & PWRTDIS & WDTDIS & HS & LVPDIS);
void InitADC(void)
{
 ADCON1 = 0x80;
 TRISA = 0x2f;
 TRISE = 0x07;
 ADCON0 = 0x81;
}
unsigned int GetADCValue(unsigned char Channel)
{
 ADCON0 &= 0xc7;
 ADCON0 |= (Channel<<3);
 __delay_ms(10);
 GO_nDONE = 1;
 while(GO_nDONE);
 return ((ADRESH<<8)+ADRESL);
}
void main()
{
}

• David: What PIC are you compiling it for? The register bits are named different things on different devices. In HTC you will usually need to reference them as a struct like REGISTERXbits.BITY, unlike C18.
• Markovian8261: I am using PIC16F877A
• David: A quick look at 16f877a.h from the 'include' directory of XC8 suggests that ADCON0bits.GO_nDONE is correct.
• Markovian8261: that gives Error [192] C:\Users\Owner\Documents\Pic Projects\Analog\Main.c; 20.1 undefined identifier "ADCON0bits" Error [196] C:\Users\Owner\Documents\Pic Projects\Analog\Main.c; 20.21 struct/union required Error [196] C:\Users\Owner\Documents\Pic Projects\Analog\Main.c; 21.26 struct/union required

Answer 1

Different versions of the HiTech C Compiler have defined PIC pins/ports in different ways. Then, when Microchip absorbed HiTech C, some were changed again.

If you look into your pic.h file, you will see which definitions file is being referenced for the PIC16F877A. Then, look into that file to find the mapping #defines...

For example, in PICC 9.50, it is defined as ADGO. In 9.83, it is defined as both ADGO and GODONE. I've also seen references to GO_DONE and GO_nDONE.

You could simply try these, and find which one works. I suggest, however, that you find the file so you can see the other pin/port/register mappings, too.

Good luck!

• mlp: The "different ways" were because the port and pin names in the header files were script-generated from data files we got straight from Microchip, and occasionally those files would change. Now we have fewer barriers between to communication with the creators of those data files, and things have also stabilised.
• bitsmack: @mlp Thanks! I wasn't saying that HiTech or Microchip had done anything wrong; these types of issues seem pretty common all over the place! (I just recently found two contradicting code snippets in the CMSIS ARM libraries) :)
• mlp: Likewise, I was not taking offense, but merely attempting to shed some light on the changing definitions. This sort of thing becomes more likely as the separation grows between compiler developers, chip documenters, and silicon designers, on a continuum from inside one highly-talented head to distinct corporate entities.
• bitsmack: @mlp I like that phrase: "from inside one highly-talented head to distinct corporate entities" :)