int ext rbo:mandar al pic a interrupcion mientras ejecuta delay!!??

[javierpic]

Hola listeros...me encuentro con el problema que el pic me va a interrupcion sin problemas siempre y cuando el programa no se encuentre haciendo un delay mientras ocurrre la interrupcion...en mi porgrama eso es posible....lei todo el manual y no encuentro  la manera que el pic salte a interrupcion inclusive si esta ejecutando un delay...please help!!!
Saludosss
Javier

[Nocturno]

Pega tu programa para poder darte una respuesta real.

Las interrupciones deben ocurrir aunque los PIC estén haciendo un delay, pero no sé ni a qué tipo de interrupción de refieres, ni de qué tipo de delay estás hablando, por lo que lo ideal es ver tu programa.

[javierpic]

Aca esta el codigo,saque bastante para no confundir,deje en el main solo un loop con un delay..como prueba para demostrar que no va a interrupcion durante el delay..
 

#include "16f648A.h"
#fuses INTRC_IO,NOLVP,WDT,NOPROTECT,NOCPD,NOMCLR
#use delay(clock=4000000,restart_wdt)
#include <tones.c>

#DEFINE RELE PIN_A2
#DEFINE LED_LECT PIN_A7
#DEFINE LED PIN_A1
#DEFINE LED_ROJO PIN_A6
#define D1 PIN_A4
#define D0 PIN_A5
#define puerta PIN_B7 //entrada


//Keypad connection:

#define col0 PIN_B1 //SALIDA
#define col1 PIN_B2 //SALIDA
#define col2 PIN_B3 //SALIDA
#define row0 PIN_A0 //ENTRADA
#define row1 PIN_B6//ENTRADA //
#define row2 PIN_B5//ENTRADA
#define row3 PIN_B4//ENTRADA

short int ALL_ROWS (void);

// Keypad layout:
char const KEYS[4][3] = {{1,2,3},
                         {4,5,6},
                         {7,8,9},
                         {10,11,12}};

#define KBD_DEBOUNCE_FACTOR 100// 33      100   // Set this number to apx n/333 where
                                  // n is the number of times you expect
                                  // to call kbd_getc each second

static int error=0,falla=0;
static int b[3]; //vector


static short CODE_OK=0, blo=0;//bit
static short secure ,teclado,baja=0;//bit
static short bien=0,llamada=0,timeout_error=0,inte=0;
static int i,key;
static int cant_usu,cant_borr;
static short pwd=0,abier=0,beeping=0,molestar=0,jodi=0,inchar=0,prim=0,pswreset=0,pswreset1=0,control=0, new_card=0;
int32 inc=0;



#int_EXT
interrp(){
int timeout,i;
int numer=0;
  output_high(LED_ROJO);
   delay_ms(600);
  output_LOW(LED_ROJO);
}





char kbd_getc( ) {
   static byte kbd_call_count;
   static short int kbd_down;
   static char last_key;
   static byte col;

   byte kchar;
   byte row;

   kchar='\0';
   if(++kbd_call_count>KBD_DEBOUNCE_FACTOR) {
       switch (col) {
         case 0   : output_low(col0);
               output_high(col1);
               output_high(col2);
                    break;
         case 1   : output_high(col0);
               output_low(col1);
               output_high(col2);
                    break;
         case 2   : output_high(col0);
               output_high(col1);
               output_low(col2);
                    break;
       }

       if(kbd_down) {
         if(!ALL_ROWS()) {
           kbd_down=false;
           kchar=last_key;
           last_key='\0';
         }
       }
       else
       {
          if(ALL_ROWS()) {
             if(!input (row0))
               row=0;
             else if(!input (row1))
               row=1;
             else if(!input (row2))
               row=2;
             else if(!input (row3))
               row=3;
             last_key =KEYS[row][col];
             kbd_down = true;
          } else {
             ++col;
             if(col==3)
               col=0;
          }
       }
      kbd_call_count=0;
   }
  return(kchar);
}

short int ALL_ROWS (void)
{
   if (input (row0) & input (row1) & input (row2) & input (row3))
      return (0);
   else
      return (1);
}

//****************************MAIN!!!!!!!!!*****PROGAMA ANDANDO *******************************
void main() {
int32 incr=0;
short din=0;
int ind=0;
SET_TRIS_B(241);
SET_TRIS_A(49);
port_b_pullups(TRUE);
enable_interrupts(INT_EXT);
enable_interrupts(GLOBAL);
ext_int_edge( H_TO_L );

output_low(PIN_A6);
OUTPUT_LOW(RELE);
OUTPUT_LOW(LED_LECT);
OUTPUT_LOW(LED_ROJO);
OUTPUT_high(LED);
OUTPUT_LOW(Col0);
OUTPUT_HIGH(Col1);
OUTPUT_HIGH(Col2);

while(true){

delay_ms(2000);




      }
     
}

[Nocturno]

Pues algo raro tienes por ahí; la interrupción debe saltar durante el delay_ms

¿Has probado alguna situación sin "delay_ms" en la que la interrupción funcione bien, y por eso piensas que es culpa del "delay_ms", o por el contrario no has conseguido que funcione nunca la interrupción?

[DarkVect]

Todavía no domino mucho el tema pero por lo que he podido leer, no es muy buena idea introducir delay's dentro de las interrupciones. Hay que salir de estas lo antes posible.

Una solución es usar el timer. Lo lees y dependiendo del valor enciendes o apagas el LED. No es complicado y así evitas el delay en la interrupción.

[vszener]

Cuando compilas un código con interrupciones y delay's, el compilador, generalmente, te dá un warning, diciendo que a la llamada de las funciones delay's, se desactiva la interrupciones, es decir, la función delay es una función interna del compilador, y al entrar, pues parece que le han desactivado las interrupciones, por eso no salta a tu interrupción.

Creo que en el manual, en la parte delay, te lo dicen también.

Hazlo con el timer, lo cargas, lo activas y espera a que el respectivo flag de aviso d einterrupción se active.


Suerte!!!

[RedPic]

Exacto vszener, con delays no hay nada más mientras el delay está ejecutandose.

Estoy haciendo unos trabajos que involucran casi todos los pines de i/o del pic, cada uno de ellos con su correspondiente periodo de high, low o entrada. Con un solo delay para una salida durante un tiempo me dejaba el resto del PIC esperando a ese delay transcurra, con lo que todas las demás funciones se iban al güano.

Ejemplo: Uno de los pines comanda un relé al que mediante la correspondiente orden vía Rx de la USART activaba durante dos segundos. Con el output_high, delay de 2000 ms y output_low correspondiente mi PIC se quedaba "sordo", no recibía nada por Rx, durante esos dos segundos.

Solución: una interrupción con un timer girando sin cesar contando periodos de tiempo relativamente cortos y una serie de variables de contadores, una por cada funcion "temporizable", que cargo con el valor de periodos que deseo contar. La interrupción va decrementándo cada contador, en caso de ser mayor que cero, cada vez que salta, y cuando llega dicho contador a cero me levanta un flag indicando que para dicha función el periodo ha concluído.

Con este sistema tengo control absoluto de lo que está ocurriendo en cada pin y durante cuanto tiempo. Los delays, salvo durante la fase de inicialización del PIC o con aplicaciones muy sencillas, mejor olvidarlos.

[Nocturno]

¿Que no interrumpe mientras hay un delay?, es la primera vez que lo escucho. Pues vaya cosa rara.

[RedPic]

Si interrumpe. Lo que pasa es que el tiempo gastado durante la interrupción no computa para el delay por lo que los resultados de éste son impredecibles. Tardará mas o menos dependiendo de tu/s rutina/s de interrupciones.

[maunix]

¿Que no interrumpe mientras hay un delay?, es la primera vez que lo escucho. Pues vaya cosa rara.

Manolo, aclaro que esto en C18 esto no ocurre.  En C18 la función delay1KTCYx() por ejemplo ejecuta una cuenta de 1000 ciclos con un par de registros que se decrementan.  Esto es así con todas las emás funcioens de retardo, no hacen más que eso.  No toca ni afecta al GIEH ni al GIEL.

Diego, yo también uso la técnica del "tickcount" que comentas.  Eso y la máquina de estados son tal vez los elementos más comunes para gestionar una multitarea que evite que algún proceso interrumpa a otro.

A propósito, también me he sorprendido con esto de que no permita las interrupciones durante una rutina de retardo.  Tu que visitas el foro de CCS seguido, ¿hay alguna razón técnica que lo justifique?

[Nocturno]

Si interrumpe. Lo que pasa es que el tiempo gastado durante la interrupción no computa para el delay por lo que los resultados de éste son impredecibles. Tardará mas o menos dependiendo de tu/s rutina/s de interrupciones.

Bien, ya vamos entendiéndonos.

while(true){
delay_ms(2000);
}

Puesto que debería interrumpir habiendo delays, y puesto que el único uso de los delays en el "main" es tener al PIC haciendo nada, ese efecto de retrasar el delay nos da igual.

Ahora insisto en mi anterior pregunta:
¿Has probado alguna situación sin "delay_ms" en la que la interrupción funcione bien, y por eso piensas que es culpa del "delay_ms", o por el contrario no has conseguido que funcione nunca la interrupción?

[RedPic]

"La experiencia es la madre de la ciencia" Así que nada de suposiciones, ni de declaraciones de yo creo o yo pienso, "Los readme son para cobardes ¡¡¡Ejecuta!!! "  :

Me voy al PIC y ...

• Le coloco un delay de 5 segundos.
• Lo disparo mediante el canal serie, con su interrupción int_rda respondiendo a la recepción del caracter "R".
• Tras el delay me muestra lo que ha recibido mediante dicha interrupción.
• Y mientras está en pleno delay le envío otro caracter.

Luego ...

• Si el nuevo caracter no interrumpe el delay me debe mostrar el "R" original.
• Si el nuevo caracter si interrumpe el delay me debe mostrar el nuevo caracter enviado.

Cualquiera de ambos me lo debe mostrar tas consumirse el tiempo de delay.

El hardware que estoy utilizando dispone de dos canales con el PC, el uno es el que utiliza el monitor de la izquierda de la imagen y el otro es el de la derecha. La interrupción serie se maneja con el de la izquierda mientras que el otro solo sirve de dump de la prueba.

Ejecuto ...

• Pulso "?" y me muestra el menu de comandos implementado -> En la ventana dump me lo muestra como ">>?".
• Pulso "R" y se activa el delay. No hago nada mas -> En la ventana dump me lo muestra como ">>R" tras 5 segundos.
• Pulso "R" de nuevo y un segundo después pulso "B" -> En la ventana dump me lo muestra como ">>B" tras 5 segundos.

Conclusión : Un PIC 18F2550 con un programa compilado con CCS C v.3.242 parece que "interrumpe" la ejecución de un delay_ms.

Muy probablemente el primer delay tardó lo esperado, 5 segundos, pero el segundo delay tardó esos 5 segundos mas el tiempo de descargar y guardar en RAM el caracter "B" o lo que es lo mismo el tiempo que estuvo ejecutandose mi rutina ISR int_rda.



P.D.: Aunque uso el Siow para conexiones Serie (Puertos COM) realmente un canal es TCP/IP mediante una utilidad de Tibbo Technologies que permite crear un puerto COM virtual conectando vía Ethernet con uno de sus módulos, y el otro canal es también un puerto COM virtual pero vía USB mediante el firmware CDC de Microchip. De ahí que ambas velocidades de conexión estén ajustadas a 115200 baudios.

[Nocturno]

Yo uso un programa cargado de interrupciones de Timer y Externas en el que hay delays en el main() y te garantizo que saltan en su debido momento, no esperan al delay

De hecho, estaba seguro desde el principio en base a experiencia, pero no me gusta llevaros la contraria 

[RedPic]

Yo uso un programa cargado de interrupciones de Timer y Externas en el que hay delays en el main() y te garantizo que saltan en su debido momento, no esperan al delay

De hecho, estaba seguro desde el principio en base a experiencia, pero no me gusta llevaros la contraria 

Doy fé de ambas cosas: Que la interrupciones interrumpen los delays y de que no te gusta llevar la contraria (salvo en el fútbol) ja ja ja