Autor Tema: De la interrupción 232 ya no vuelve a la funcion ppal  (Leído 3123 veces)

0 Usuarios y 1 Visitante están viendo este tema.

Desconectado carafaelet

  • PIC12
  • **
  • Mensajes: 61
De la interrupción 232 ya no vuelve a la funcion ppal
« en: 08 de Febrero de 2009, 16:12:28 »
Hola amigos, llevo ya varios dias dandole vueltas a lo mismo y no consigo dar con el porqué, he reducido el codigo de mi programa al sencillísimo codigo que aparece mas abajo y ni aun así consigo que cuando salta a la rutina por recepción en el puerto serie vuelva de nuevo la funcion principal main (cosa que si consigo sin problemas con la interrupción externa o con interrupción en el puerto B). El programa es muy sencillo, mantiene encendidos dos leds que se apagaran al recibir cualquier cosa en el puerto serie, y de hecho lo hacen, pero ya no vuelven a encenderse, ya no vuelve el programa a la función principal..

Código: [Seleccionar]
#include <16f877A.h>
#fuses XT,NOWDT,NOPROTECT,NOLVP,PUT,NOBROWNOUT 
#use delay(clock=4000000) //Freq. 4MHz
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7)

#use fast_io(a)
#use fast_io(b)
#use fast_io(c)


#int_rda
void rda_isr()
{
output_low(PIN_B1);
output_low(PIN_B2);
}

#int_rb
Interrupcio_hard()
{
output_low(PIN_B1);
output_low(PIN_B2);
}

void main(void)
{
enable_interrupts(int_rda);
enable_interrupts(global);
 
  set_tris_b(0b1110001);

do{
output_high(PIN_B1);
output_high(PIN_B2);
}while(TRUE);
}

No se si sera por algun fuse o porque, la verdad es que no lo entiendo, porque con el buscador he visto que hay muchos códigos similares y funcionan bien. Lo podriais compilar alguien y decirme si a vosotros tampoco os funciona bien.

PS: Realmente si el codigo funciona bien no se llega a apreciar como los leds conectados a B1 y B2 se apagan, sino mas bien parece que siempre esten encendidos, el ojo humano no llega a apreciarlo.

Gracias y un saludo!
En esta vida hay 10 clases de personas, las que saben binario y las que no.

Desconectado pablomanieri

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 639
Re: De la interrupción 232 ya no vuelve a la funcion ppal
« Respuesta #1 en: 08 de Febrero de 2009, 17:00:01 »
Debes utilizar la instrucción getc() dentro de la interrupción para leer el dato que llega y así se limpia el flag de interrupción. ese dato lo puedes usar para algo o no, tu decides.

Desconectado carafaelet

  • PIC12
  • **
  • Mensajes: 61
Re: De la interrupción 232 ya no vuelve a la funcion ppal
« Respuesta #2 en: 08 de Febrero de 2009, 17:23:31 »
 :-/ Muchas gracias Pablomanieri!!, efectivamente eso era. La verdad es que es algo muy obio pero yo realmente el dato lo recogia de forma directa haviendome definido previamente el registro RCEREG y luego limpiando la interrupción poniendo rcif=0 y mas tarde prové con: clear_interrupt(int_rda);  Pero nada de esto funciona, con getc() al ser una funcion implementada por el compilador CCS ya se encarga de limpiar el flag de interrupción de forma totalmente transparente para nosotros.

Mas o menos lo que yo hacia era:

Código: [Seleccionar]
dato=RCREG;
rcif=0;

y funciona y recoge el dato, pero claro el flag de interrupcion por lo visto no lo pone a cero. Si consigo hacerlo de esta forma lo posteare, y si se me complica demasiado la cosa, realizare la recogida de datos con getc() que no falla.. jejej.

Un saludo y gracias de nuevo!  :-)
En esta vida hay 10 clases de personas, las que saben binario y las que no.

Desconectado RALF2

  • Moderadores
  • PIC24H
  • *****
  • Mensajes: 2060
Re: De la interrupción 232 ya no vuelve a la funcion ppal
« Respuesta #3 en: 08 de Febrero de 2009, 17:54:26 »
Que tal amigos!
Carafaelet, mira el problema se debio a que para poder borrar el flag de interrupcion por recepcion debes leer primero el registro RCREG para asi poder borrar el flag, ya que, el flag se borra por hardware al leer el registro RCREG  :mrgreen:
Por eso es que el flag se mantiene en uno dandote problemas  :mrgreen:
En la rutina de interrupcion del rda_isr, intenta leer el buffer por ejemplo haciendo, buffer = RCREG y veras que solventas el problema, borrando el RCIF   :-/

Saludos

Desconectado carafaelet

  • PIC12
  • **
  • Mensajes: 61
Re: De la interrupción 232 ya no vuelve a la funcion ppal
« Respuesta #4 en: 08 de Febrero de 2009, 18:24:18 »
No entiendo RALF2, eso es precisamente lo que hago, leer primero el registro RCREG y de hecho como digo lee el dato correctamente y luego ya es cuando intento poner rcif a cero, aunque esto como bien dices creo que lo hace el pic a nivel interno, que no se puede poner a cero mediante el codigo sino que es el propio pic el que lo pone a cero una vez lees el dato. Pero asi no me funciona, lee el dato correctamente y se queda ahi bloqueado en la interrupcion.

Concretamente yamo a: rece_232(); que es una funcion que recoge los datos mediante RCREG y los interpreta, cuando termina la funcion vueve el programa a: #int_rda para intentar devolver rcif a cero, pero con esas se queda con el intento porque como digo se queda bloqueado y no vuelve a la funcion principal main.
En esta vida hay 10 clases de personas, las que saben binario y las que no.

Desconectado RALF2

  • Moderadores
  • PIC24H
  • *****
  • Mensajes: 2060
Re: De la interrupción 232 ya no vuelve a la funcion ppal
« Respuesta #5 en: 08 de Febrero de 2009, 18:34:28 »
Que tal crafelet!
Mira eso no lo veo en el programa que colocastes arriba, pero una observacion.
Si envias dos o mas datos por rs232 y solo lees uno el el RCREG no borrara el flag RCIF ya que aun quedan datos en el buffer, eso podria ser lo que pasa, tambien puede ser que el compilador necesite la instruccion clear_interrupt(int_rda), para que el compilador sepa que ya dbe salir de la interrupcion  :?

Si probando eso aun sigue el problema entonces abra que hacerlo como te dijo pablomanieri  :mrgreen:

SAludos

Desconectado carafaelet

  • PIC12
  • **
  • Mensajes: 61
Re: De la interrupción 232 ya no vuelve a la funcion ppal
« Respuesta #6 en: 08 de Febrero de 2009, 19:45:37 »
No no.. en el programa que he puesto arriba en la primera intervenció no, sino lo que he puesto despues de la respuesta de Pablomanieri. Como decia primero leo el registro en una variable que se llama dato (una y otra vez hasta tener todos los datos que se han recibido) y luego pongo rcif a cero y tambien probé con: clear_interrupt(int_rda). Así es como lo estaba haciendo desde un principio pero tuve que hacerlo mediante el codigo que expongo en mi primer mensaje para ver si asi solucionaba el problema. No se si me explico Ralf2, de todas formas decir que por una parte si que leo todo lo que recibo (en concreto es un paquete formado por 5bytes) y en segundo lugar como he dicho ya probé con clear_interrupts(int_rda) pero nada.. A ti esto si que te funciona? Un saludo!!!  :-)
En esta vida hay 10 clases de personas, las que saben binario y las que no.

Desconectado RALF2

  • Moderadores
  • PIC24H
  • *****
  • Mensajes: 2060
Re: De la interrupción 232 ya no vuelve a la funcion ppal
« Respuesta #7 en: 08 de Febrero de 2009, 22:19:02 »
Citar
A ti esto si que te funciona?
Por supuesto que yes!  :mrgreen:

Velo tu mismo  :-/

Luego me diras  como te fue  :mrgreen:

Saludos

Desconectado carafaelet

  • PIC12
  • **
  • Mensajes: 61
Re: De la interrupción 232 ya no vuelve a la funcion ppal
« Respuesta #8 en: 10 de Febrero de 2009, 16:16:12 »
Fantastico! A mi tambien me funciona! Pero solo una vez...  :? A partir de la primera vez los leds se quedan encendidos de forma permanente,es como si se desabilitara o no se volviese a habilitar o limpiar la interrupción por 232, por ello he probado o siguiente:

Código: [Seleccionar]
#include <16f877A.h>
#fuses XT,NOWDT,NOPROTECT,NOLVP,PUT,NOBROWNOUT 
#use delay(clock=4000000) //Freq. 4MHz
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7)

#use fast_io(a)
#use fast_io(b)
#use fast_io(c)
#byte RCREG = 0x1A

#int_rda
void rda_isr()
{
   int dato;
   output_low(PIN_B1);
   output_low(PIN_B2);
   dato = RCREG;
   delay_ms(1000);
}

#int_ext
void Interrupcio_hard()
{
   output_low(PIN_B1);
   output_low(PIN_B2);
   delay_ms(1000);
}

void main(void)
{
   
     
     set_tris_b(0b1110001);   

   do{
   clear_interrupt(int_rda);
   enable_interrupts(int_rda);
   enable_interrupts(int_ext);
   enable_interrupts(global);
   output_high(PIN_B1);
   output_high(PIN_B2);
   }while(TRUE);
}

Pero nada de nada...   :(

Que puede ser?.. voy a seguir averiguando y si consigo algo lo posteo..
En esta vida hay 10 clases de personas, las que saben binario y las que no.

Desconectado carafaelet

  • PIC12
  • **
  • Mensajes: 61
Re: De la interrupción 232 ya no vuelve a la funcion ppal
« Respuesta #9 en: 10 de Febrero de 2009, 18:07:47 »
Parece ser que a otro compañero tambien le ocurria lo mismo:
 Problemas con RS232: Interrupcion INT_RDA
 , voy a probar a implementar la función del código de RedPic! y os cuento a ver, concretamente es:
Ejemplito 16F876A: Recibiendo del RS232 sobre un Buffer y procesandolo posteriormente.
En esta vida hay 10 clases de personas, las que saben binario y las que no.

Desconectado sander

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 624
Re: De la interrupción 232 ya no vuelve a la funcion ppal
« Respuesta #10 en: 10 de Febrero de 2009, 20:49:07 »
Que problema mas raro, deberia bastar con leer el RCREG , a no ser que envies mas de 3 bytes y el buffer se desborde y te produzca un error que no estas manejando, ahora si estas enviando un byte a la vez deberia funcionar, estas simulando en el proteus o armaste el  circuito?.

Saludos.
La electrónica es el arte de manipular señales eléctricas que transportan información
Jan Davidse

Visita mi blog
Visita mi canal de youtube

Desconectado RALF2

  • Moderadores
  • PIC24H
  • *****
  • Mensajes: 2060
Re: De la interrupción 232 ya no vuelve a la funcion ppal
« Respuesta #11 en: 10 de Febrero de 2009, 22:08:46 »
Que tal amigos!
Carafaelet, el programa que coloque funciona bien  :mrgreen:
Porque a ti no?  :shock:
Probaste el codigo y la simulacion?
Alli se ve que opera fino y todas las veces.

Como lo estas probando, con el proteus o fisicamente?
Si lo probaste en el proteus, con el codigo que adjunte, el problema puede ser otro.
Avisanos para ver que podemos hacer

Saludos
« Última modificación: 10 de Febrero de 2009, 22:11:16 por RALF2 »

Desconectado carafaelet

  • PIC12
  • **
  • Mensajes: 61
Re: De la interrupción 232 ya no vuelve a la funcion ppal
« Respuesta #12 en: 12 de Febrero de 2009, 05:52:30 »
No he tenido tiempo aun de probar la version de RedPic (a ver si esta tarde me pongo en ello). Respecto al actual programa, efectivamente envio mas de 3 bytes, concretamente 5 bytes, pero no deja de ser curioso que los 5 bytes los reciba perfectamente y los interprete sin problemas (lo se seguro porque entre otras cosas muestro el contenido de estos a través de una Lcd) y en cambio no es capaz de volver al programa principal una vez interpretados y leidos estos bytes. El programa lo pruebo fisicamente enviando los bytes a través de 232 desde una aplicación realizada con Labview.

Saludos
En esta vida hay 10 clases de personas, las que saben binario y las que no.

Desconectado carafaelet

  • PIC12
  • **
  • Mensajes: 61
Re: De la interrupción 232 ya no vuelve a la funcion ppal
« Respuesta #13 en: 12 de Febrero de 2009, 18:25:51 »
Bueno he conseguido permitir nuevas interrupciones al setear la lógica tal y como indica el datasheet, haciendo:

Código: [Seleccionar]
CREN=0;
CREN=1;

Pero sigo sin conseguir que el programa vuelva a la función principal main.. sigo probando...
« Última modificación: 12 de Febrero de 2009, 18:42:45 por carafaelet »
En esta vida hay 10 clases de personas, las que saben binario y las que no.

Desconectado carafaelet

  • PIC12
  • **
  • Mensajes: 61
Re: De la interrupción 232 ya no vuelve a la funcion ppal
« Respuesta #14 en: 12 de Febrero de 2009, 20:10:00 »
Bien, ya he conseguido que vuelva a la función principal habiendo recibido 5 bytes, pero ahora tengo problemas con los bytes recibidos ya que estan desordenados, supongo que será cuestión de código y en donde poner adecuadamente CREN=0  y CREN=1, cuando consiga que todo vaya bien lo posteo..

Saludos.
En esta vida hay 10 clases de personas, las que saben binario y las que no.