El código c adc de alta tecnología no funciona como se esperaba

Soy nuevo en el uso de microcontroladores PIC y estoy trabajando en un proyecto que implica leer un valor analógico. Estoy usando el PIC16F877A. He encontrado el código para usar el ADC publicado a continuación, sin embargo, cuando intento compilarlo, aparece el error Error [192] C:\Users\Owner\Documents\Pic Projects\Analog\Main.c; 20.1 identificador indefinido "GO_nDONE". Aquí está mi código

#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()
{

}
¿Para qué PIC lo estás compilando? Los bits de registro tienen nombres diferentes en diferentes dispositivos. En HTC, normalmente deberá hacer referencia a ellos como una estructura como REGISTERXbits.BITY, a diferencia de C18.
estoy usando PIC16F877A
Una mirada rápida a 16f877a.h desde el directorio 'include' de XC8 sugiere que ADCON0bits.GO_nDONE es correcto.
eso da el error [192] C:\Users\Owner\Documents\Pic Projects\Analog\Main.c; 20.1 identificador indefinido "ADCON0bits" Error [196] C:\Users\Owner\Documents\Pic Projects\Analog\Main.c; 20.21 estructura/unión requerida Error [196] C:\Users\Owner\Documents\Pic Projects\Analog\Main.c; 21.26 estructura/unión requerida

Respuestas (1)

Las diferentes versiones del HiTech C Compiler tienen pines/puertos PIC definidos de diferentes maneras. Luego, cuando Microchip absorbió HiTech C, algunos se cambiaron nuevamente.

Si observa su archivo pic.h, verá a qué archivo de definiciones se hace referencia para el PIC16F877A. Luego, busque en ese archivo para encontrar el mapeo #defines...

Por ejemplo, en PICC 9.50, se define como ADGO. En 9.83, se define como ADGO y GODONE. También he visto referencias a GO_DONE y GO_nDONE.

Simplemente puede probar estos y encontrar cuál funciona. Sin embargo, le sugiero que busque el archivo para poder ver también las otras asignaciones de pin/puerto/registro.

¡Buena suerte!

Las "diferentes formas" se debieron a que los nombres de puerto y pin en los archivos de encabezado se generaron mediante secuencias de comandos a partir de archivos de datos que obtuvimos directamente de Microchip y, en ocasiones, esos archivos cambiaron. Ahora tenemos menos barreras entre la comunicación con los creadores de esos archivos de datos y las cosas también se han estabilizado.
@mlp ¡Gracias! No estaba diciendo que HiTech o Microchip hubieran hecho algo malo; ¡Este tipo de problemas parecen bastante comunes en todas partes! (Recientemente encontré dos fragmentos de código contradictorios en las bibliotecas ARM de CMSIS) :)
Del mismo modo, no me ofendí, sino que simplemente intenté arrojar algo de luz sobre las definiciones cambiantes. Este tipo de cosas se vuelve más probable a medida que crece la separación entre los desarrolladores de compiladores, los documentadores de chips y los diseñadores de silicio, en un continuo desde el interior de una cabeza altamente talentosa hasta distintas entidades corporativas .
@mlp Me gusta esa frase: "desde el interior de una cabeza de gran talento a distintas entidades corporativas" :)
El código c adc de alta tecnología no funciona como se esperaba
RespuestasAquíPolítica de privacidad1y, 0v