TODOPIC

Microcontroladores PIC => Primeros pasos - Iniciación a los microcontroladores => Mensaje iniciado por: ricardinjo en 20 de Febrero de 2015, 14:12:41

Título: Problema con las interrupciones de alta prioridad en xc8
Publicado por: ricardinjo en 20 de Febrero de 2015, 14:12:41
Buenas tardes, me presento, soy nuevo en el foro y aunque de vez en cuando me gusta leer nunca antes había escrito. Acabo de terminar la carrera de Electronica y siempre he trabajo con mplab y c18. El problema viene cuando me meto en xc8 e intento hacer un simple programa con la EUSART y quiero recibir un simple byte que, mediente una interrupcion me lo guarde en una variable. El caso es que si la interrupción de recepción la configuro con alta prioridad y la meto en la función "void interrupt Interrupcion () " ó
"void interrupt high_priority Interrupcion ()" al simularlo en proteus simplemente me aparecen las lineasdel programa pero no las ejecuta.
Si configuro esta interrupción como baja prioridad bajo la función "void interrupt low_priority Interrupcion ()" si que me aparecen en proteus, realiza las operaciones pero no lo guarda bien. Dejo el programita:
#include <xc.h>


char RECIBIDO;

void interrupt Interrupcion (){
    if(RCIF){
        RECIBIDO = RCREG;
        RCIF = 0;
    }
}

void main(void){
    RCONbits.IPEN = 1;
    INTCONbits.PEIE = 1;
    INTCONbits.GIE = 1;
    PIE1bits.RCIE = 1;
    IPR1bits.RCIP = 1;
    TRISCbits.RC6 = 1;
    TXSTA = 0x24;
    RCSTA = 0x90;
    BAUDCON = 0x00;
    SPBRG = 129;
   
while(1){
    }
}
fijaros en la foto que adjunto que despues del vector de alta prioridad 0008 hay lineas de codigo pero no tienen ningún vector.
¿Que pasa aquí?
Gracias
Título: Re: Problema con las interrupciones de alta prioridad en xc8
Publicado por: ricardinjo en 21 de Febrero de 2015, 11:36:59
Nadie tiene idea de esto, ni porque el proteus no me muestra las lineas de codigo bien?
Título: Re: Problema con las interrupciones de alta prioridad en xc8
Publicado por: KILLERJC en 21 de Febrero de 2015, 11:55:01
Sinceramente no entiendo cual es tu preocupacion.

Veo que que esta ubicado en el vector de alta prioridad como deberia ( por ser interrupt ) ( 0x8 )  y si lo pones en baja prioridad deberia estar en (0x18).

Realmente el codigo C como para debug no ayuda en nada... Si podes poner el ASM mejor... ayudaria muchisimo mas

http://microchip.wikidot.com/faq:31

( interrupt para alta, y interrupt low_priority para baja )

Tambien imagino que si vas a usar la prioridad deberias tener ambas declaradas, no se por que en la pagina de microchip declara la misma funcion ( TMR1 ) para ambas interrupciones. Cuando deberia ser TMR1 alta prioridad y TMR0 baja prioridad y listo.

Citar
fijaros en la foto que adjunto que despues del vector de alta prioridad 0008 hay lineas de codigo pero no tienen ningún vector
No se a que vector te referis.. si te referis al de baja prioridad no lo definiste por lo tanto no va a estar.

Y con respecto a que no guarda bien el dato, probaste hacerlo directamente sin interrupciones ? para ver si es la configuracion de baudrate o algo por el estilo?
Título: Re: Problema con las interrupciones de alta prioridad en xc8
Publicado por: ricardinjo en 21 de Febrero de 2015, 14:53:51
Hola! Gracias por las respuestas. Aun estoy luchando con el mplabx. A lo que me refiero es que si te fijas en la fotografía después del vector 0008 que es el de prioridad alta para las interrupciones ya no hay más vectores aunque si que hay más lineas de código. Es decir del vector 0008 pasa al 008E que es el del main y después de aquí cada linea de código tiene su vector menos los que hay dentro de la interrupción y cuando hay una interrupción el proteus si que entra pero no pasa por las lineas de código que dentro de estas.
Un saludo y espero haberme explicado bien.
Título: Re: Problema con las interrupciones de alta prioridad en xc8
Publicado por: KILLERJC en 21 de Febrero de 2015, 20:39:56
Ahora entiendo lo que te causa duda.

Realmente no se como grafica eso el tema de la posicion de memoria donde se almacenan esas instrucciones.

Por eso mismo dije que lo mejor era ver el ASM generado.

Tal ves el compilador al no usarse el "RECIBIDO" directamente lo elimine y suponga que es una instruccion sin sentido y lo quite.. para ams seguro como dije mejor ver el ASM generado
otra es que al leer el registro RCREG se borra el flag de interrupcion. Asi que solo necesitarias 2 instrucciones en ASM para hacer lo que hiciste.

1 leyendo el el registro RCREG ( puede ser un SWAPF que no modifica ninguna bandera ) y la otra el retorno RETFIE ( que no hay un equivalente en el C ) entonces solo podria indicar de la primera instruccion.
Ademas seguro que en las interrupciones hay que salvar el contexto ( STATUS y W ) en ASM pero eso no hay equivalente en las instrucciones de C por lo tanto tampoco apareceria.