Problemas encontrados con el compilador de CCS

[pocher]

Otra cosa que acabo de ver con la prueba física.

Para que funcione bien la interrupción RB4..RB7, la lectura/escritura del portB mediante por ejemplo un #asm movf port_b,0 #endasm se tiene que hacer antes del output_toggle(PIN_a0). Este output_toggle es el del primer programa que puse, el que solo tiene la interrupción RB4..RB7. En el otro programa, lo mismo hay que meter el #asm movf port_b,0 #endasm nada más entrar en la interrupción )

[pocher]

Decididamente el tema de las prioridades con interrupciones falla. He estado probando físicamente (y con PROTEUS) otras combinaciones de prioridades (INT_TMR0,INT_EXT y INT_RB) y algunas van bien pero otras fallan.

Lo considero como bug y lo clasifico como tal en el tema con chincheta.

Un saludo

[erdanieee]

Hola a todos! Se que el hilo es un poco antíguo, pero recientemente he tenido un problema con la interupción RB, y como solucionarlo me ha llevabo algún tiempo, he decidido postearlo aquí por si a alguien le es útil.

   Bueno, el problema surgió cuando intenté simular en PROTEUS (v. 7.2) un programa sencillo en CCS (v.4.088) para PIC16f84A que hacía uso de varias interrupciones, entre ellas la RB. Al iniciar la simulación, PROTEUS lanzaba un mensaje de error que decía algo así como "violation access error in module <UNKNOW>".

   Tras debuggearlo me dí cuenta de que fallaba justo al activar la interrupción RB, y que si comentaba esa línea el programa funcionaba perfectamente (salvo que no hacía la interrupción  ). Despues de varias pruebas, se me ocurrió ver el listado en ensamblador y observé que esa línea es codificada por 3 sentencias en ensamblador que ponen a uno los bits 5 y 6 del registro STATUS,  y el bit 3 del registro INTCON. El (INTCON,3) es para habilitar la interrupción RB, (STATUS,5) para seleccionar el banco (lo cual es innecesario ya que INTCON se puede acceder tanto desde el banco 1 como desde el 0), pero lo que me sorprendió fué que modificara (STATUS,6) que en el datasheet pone cláramente que no se usa y debe mantenerse a cero!!!. Al eliminar esta línea la simulación funcionó perfectamente, asiq probablemente PROTEUS no acepta que se modifiquen bits que no deberían ser usados en el PIC.

   Dado que hay más gente que ha usado esta interrupción y no ha tenido este problema, supongo que el bug afectará sólo a algunos PICs. Espero que no sea muy liosa la explicación y que, si a alguien más le ocurre esto, sepa cómo solucionarlo.

Un saludo

[jadacuor]

Chincheta obligatoria. 

Pero hay que editar el título del tema a: "Problema con Interrupción RB4-7" o algo así.

hola, soy nuevo en este foro asi que espero no estar violando ninguna regla...mi problema radica en que tengo un programa hecho en ccs (en el cual manejo interrupciones timer1 y rb4-7) para 16f877a y corre perfectamente en proteus... pero al intentar pasarlo al 18f452 no funcionan bien las interrupciones en especial la #int_rb  ya que algunas veces sin haber cambio en el puerto b , ingresa a la interrupcion y cuando ingresa no sale...como si no borrara la bandera de interrupcion..(creo yo)... espero una ayuda por favor .....gracias

este es el codigo::


#include <18F452.h>
#fuses XT,NOWDT,NOPROTECT,NOLVP, CCP2C1
#use delay(clock=4000000)




#use fast_io(c)
#byte portb = 6
#byte portd = 8


 #INT_TIMER1
 void isr_tmr1()
 {output_toggle(pin_b0);
  set_timer0(0);
  set_timer1(20000);
}


 #INT_RB
 void isr_rb()
{output_toggle(pin_b0);
portd = swap(portb);
}


void main(){
disable_interrupts(GLOBAL);
set_tris_d(0);
set_tris_b(255);
setup_timer_0(RTCC_EXT_L_TO_H|RTCC_DIV_2);
setup_timer_1(T1_INTERNAL|T1_DIV_BY_4);





enable_interrupts(INT_RB);
enable_interrupts(INT_TIMER1);
enable_interrupts(GLOBAL);
output_d(0);
set_timer0(0);
set_timer1(20000);

 while( TRUE )
 {output_c(0);}
}

[Cryn]

Cuando se usa la interrupción por cambio de estado en RB4-RB7, en la rutina de interrupción se debe leer y escribir el puerto, yo hago así:

output_b(input_b());

Entonces tu código por ahí debería quedar:

#INT_RB
void isr_rb(){
   output_toggle(pin_b0);
   portd = swap(portb);
   output_b(input_b());
   clear_interrupt(int_rb);  //se ser necesario se limpia el flag de rb
}

Esto ya esta explicado en otros hilos, te recomiendo busques un poco más.

Saludos

[salchig]

Hola amigos..   
Soy nuevo el el tema de programacion de Microcontroladores y estoy empesando por el lenguaje C.
A mi me surgio el mismo problema que a "erdanieee"  que no puedo simular en Proteus  interrupciones en el puerto B con el PIC 16f84A. Me sale este error "violation access error in module <UNKNOW>". siempre que habilito la interrupcion    enable_interrupts(int_rb);  Estoy usando el CCS 4.023 y proteus 7.6 sp0
Pongo un codigo de muestra.. Agradeceria cualquier ayuda
 

#include <16F84A.h>

#FUSES NOWDT                    //No Watch Dog Timer
#FUSES XT                       //Crystal osc <= 4mhz
#FUSES NOPUT                    //No Power Up Timer
#FUSES NOPROTECT                //Code not protected from reading

#use delay(clock=4000000)

int t=10,p=5;
void setear();
#int_rb

rb_isr() {
output_b(0x07);
delay_ms(1000);
    }

void main()
{

   setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1);
   enable_interrupts(int_rb);        //registro de int_rb
   enable_interrupts(global);        //activa interrupts
   // TODO: USER CODE!!
   output_b(p);
   output_low(pin_a4);
   output_low(pin_a1);
   while(1){
   output_high(pin_A0);
   delay_ms(t*p);
   output_low(pin_A0);
   delay_ms(100-t*p);
   
   }

}

[Rock_Isaac]

La interrupcion RB0 siempre es de alta prioridad, no es configurable.

Las demas pueden ser configuradas como alta o baja prioridad...
saludos...

Oido cocina, mañana que es domingo, no puedo, pero el lunes le pongo una chincheta.

La idea que yo tengo es poner aquí en este tema un determinado "bug" de CCS (de cualquier cosa), discutirlo entre todos y si se llega a la conclusión que efectivamente es un "bug" hacer una buena explicación y copiarlo en limpio en el tema con chincheta. El título del Tema con chincheta podría ser "Posibles bugs del compilador de CCS" si os parece bien.

Antes de seguir con esta cruzada he de decir que para mí el compilador de C que más me gusta es el de CCS, no porque sea el mejor, que quizá no lo sea, sino por la gran cantidad de personas que lo usan y que en un momento dado te pueden ayudar a resolver una duda.

Esta tarde se vé que tengo ganas de fastidiar al compilador y creo que he descubierto otra cosa que no funciona bien. Ojala me equivoque, por eso lo pongo aquí para discutirlo.

Se trata de la prioridad de las interrupciones en los PIC18.

Si un PIC18 tengo 2 interrupciones y una de ellas la declaro como de alta prioridad, pués si cuando se está ejecutando la instrucción de baja prioridad, llega la de alta prioridad pués se debe de abandonar inmediatamente la primera rutina e ir a atender a la rutina de alta prioridad.

Cuando finalice la rutina de alta prioridad retornará al punto donde se había quedado en la rutina de baja prioridad. Bueno, el caso es que creo que esto no funciona.

Os pongo un programa de ejemplo y os digo como reacciona.

Código: [Seleccionar]

#include <18F452.h>

#DEVICE HIGH_INTS=true

#use delay(clock=4000000)

#use fast_io(B)

#byte port_a = 0xF80
#byte port_b = 0xF81

//#PRIORITY int_ext,int_rb
//#PRIORITY int_rb,int_ext

#INT_TIMER0                        // Interrupción externa en RB0                     
interrupcion_TIMER0()          // Función de atención a la interrupción
{
delay_ms(3000);
  output_toggle(PIN_B1);
  disable_interrupts(INT_TIMER0); 
}

#INT_EXT                        // Interrupción externa en RB0                     
interrupcion_RB0()          // Función de atención a la interrupción
{
delay_ms(3000);
output_toggle(PIN_A0);
}

//#INT_RB                        // Interrupción externa en RB4-RB7   
#INT_RB HIGH
//#INT_RB FAST                     
interrupcion_RB4_RB7()          // Función de atención a la interrupción
{
delay_ms(3000);
  #asm movf port_b,0 #endasm //Hace falta leer el portb, si no va mal
  output_toggle(PIN_B3);
}

main()
{
set_tris_b(0xF5); // RB4 salida, RB4-RB7,RB0 entradas.
  set_tris_a(0x00);
  bit_clear(port_a,0);
bit_clear(port_b,1);
bit_clear(port_b,3);
//output_low(PIN_B3);

setup_counters(RTCC_8_BIT,RTCC_DIV_128);

  enable_interrupts(GLOBAL);
  enable_interrupts(INT_RB);
  enable_interrupts(INT_EXT);

  while(1)
  {
  if(input(pin_b2))
  enable_interrupts(INT_TIMER0);
  }
}



La interrupción de RB0 es de baja prioridad y la de RB4..RB7 de alta.

Si activamos la interrupción RB0 y a continuación activamos la de RB4..RB7 tendría que ejecutar primero la interrupción RB4..RB7 y activar la salida RB3 para luego regresar a la interrupción RB0 y activar la salida RA0. Pués no, hace justamente lo contrario, primero activa la salida RA0 y luego la salida RB3.

Aquí os lo dejo, pensarlo.