RS232 - Sólo funciona con Force_sw (SOLUCIONADO)

[Menta]

Hola, estuve buscando y no encuentro respuesta a mi dilema.

El siguiente código es el que he generado. El problema es que no se reciben los datos en el pic, es decir puedo mandar datos fuera, pero cuando oprimo mi teclado de la pc no se envía nada o el pic no lo recibe. Mientras que si pongo FORCE_SW anda todo perfecto.. menos la interrupción.

No existe ninguna forma de usar la interrupción INT_RDA usando rs232 por software???

Lo simulo todo en proteus.
Puede ser un error de proteus que no ande por hardware y sí por software?

Código: C

1. #include <16F883.h>
2. #fuses INTRC_IO,NOWDT,NOPROTECT,NOLVP,MCLR,NOBROWNOUT
3. #use delay(clock=4000000)
4. #use rs232(baud=19200, xmit=PIN_C6, rcv=PIN_C7)
5. #use fast_io(a)
6. #use fast_io(b)
7.  
8. #bit led1 = 5.4
9. #bit led2 = 5.5
10. #bit led3 = 5.6
11. #bit led4 = 5.7
12. #bit in1 = 7.0
13. #bit in2 = 7.1
14. #bit boton1 = 7.2
15. #bit boton2 = 7.3
16. #bit sw1 = 7.4
17. #bit sw2 = 7.5
18. #bit relay = 6.0
19. #bit buzz = 6.1
20. #bit out1 = 6.2
21. #bit out2 = 6.3
22. #bit c_relay = 6.4
23. #bit c_buzz = 6.5
24.  
25. int Prefijo,dato;
26. int orden=0;
27. long trama;
28. char tecla;
29.  
30. #INT_RDA
31. void Pedido()
32. {
33.    orden = fgetc();
34.    putc(orden);
35.    delay_us(10);
36.  
37.    dato = (orden && 0x0F);
38.    Prefijo=(orden>>4);
39. }
40.  
41. void main(void)
42. {
43. setup_oscillator(OSC_4MHZ);            // Configuro oscilador interno
44. SET_TRIS_A(0x0F);                      // Inicio puerto A (O-O-O-O-I-I-I-I)
45. Setup_adc_ports(sAN0 |sAN1 |sAN2 |sAN3 | VSS_VDD);        // puerto A (x-x-x-A-x-A-A-A)
46. Setup_adc(adc_clock_internal);
47. Setup_adc(ADC_CLOCK_DIV_32);
48.  
49. SET_TRIS_B(0xF0);                      // Inicio puerto B (I-I-I-I-O-O-O-O)
50. PORT_B_PULLUPS(FALSE);
51.  
52.    enable_interrupts(INT_RDA);
53.    enable_interrupts(GLOBAL);       // Hab. Interrupciones
54.  
55.  printf("TITULO\n\r");
56.  
57.    while( TRUE )
58.    {
59.     do {
60.    tecla=getc();
61.    fputc(tecla);
62.    } while (tecla!='D');
63.    printf("Press any key to begin\r\r");
64.    getc();
65.    }
66. }

Saludos y Gracias por su tiempo.

[migsantiago]

Hola Menta

Una pregunta... en esta parte del código:

  dato = (orden && 0x0F);

¿Para qué haces la comparación? El poner dos veces & creo que verifica si orden y 0x0f son diferentes a cero, y si lo son, hace que dato sea igual a 1. ¿O estoy entendiendo mal el código? 

Si quisieras hacer una máscara solo habría que poner

dato=orden&0x0f;

Sobre i/o del puerto c, no recuerdo es si es necesario poner las terminales de C como entrada y salida o si #use rs232 lo hace automáticamente.

[Menta]

Si tienes toda la razón, lo que en realidad quiero hacer es
dato=orden&0x0f;
es una máscara...
Seguro que tengo varios fallos más y además el programa no hace aún nada de lo que tengo pensado hacer... la razón es que quiero comprobar que tengo conexión rs232 antes de explayarme con mi programa y el código que puse sí se comunica correctamente con Force_sw pero no ejecuta la interrupción al recibir datos y sin Force_sw no recibo datos, la función getch no devuelve nada 

[Gonzalo_BlackHawk]

Hola menta, debes configurar el registro TRIS del puerto C para que RC7 sea entrada, de lo contrario no recibiras datos si estas implementando el UART por HW. Fiajte que si no defines como RC7 como entrada seguramente Proteus detectara una inconsistencia en esa net a la hora de simular, en general el cuadradito que indica el estado lógico (que generalmente oscila entre rojo y azul) se pondra en amarillo o gris.

Con respecto a lo de la interrupción cuando utilizamos el UART por SW, tendria que andar pero la verdad que nunca lo he usado y no puedo dar fe de ello.

Saludos.

[RedPic]

No, Menta. Por Software no funciona la interrupción #INT_RDA.

Esta interrupción, como las otras del PIC, son interrupciones "físicas" que actúan sobre los registros PCH y PCL haciendo que salte la ejecución al vector de interrupciones.

Nuestra rutina por Software no deja de ser una función más en nuestro programa y no hay enlace entre ninguna interrupción "física" y ella. La única forma que hay de ejecutarla es llamándolo dentro de nuestro bucle principal.

Y cuanto mas veces la llamemos mas seguro estaremos de no perder datos. Pero nadie nos va a asegurar que no nos ocurra precisamente eso.

Yo personalmente desaconsejo mucho utilizar una USART por software. Solo le veo utilidad en un par de casos:

- Solo para transmitir información (va a nuestro ritmo), no para recibir (no es segura).
- Para recibir a muy baja velocidad y con nuestro PIC corriendo a mucha velocidad (en un intento de no perder info entrando muchas veces en el chequeo de si hay algo pendiente de recibir)

Lo siento pero creo es un recurso muy limitado.

[MLO__]

Hola

Pues, como recomendacion, no es bueno utilizar la USART u otro protocolo de comunicacion, cuando se trabaja con el oscilador interno, debido a las fluctuaciones que el oscilador tiene. En este link hay una presentacion en flash donde recomiendan el no uso de esas comunicaciones con esa configuracion.

Yo la he utilizado ( haciendo caso omiso pues  ), pero me toco a muuy baja velocidad ( 300 baudios ) para que me corriera bien. La aplicacion fue en un PIC12 asi que la que use es la rutina por SW.

Saludos

[firepic]

Saludos!
Si que aprende uno con todos sus comentarios! 
Pos no más quería acotar que yo estoy usando recepción serial por software y me ha funcionado muy bien, claro que también ha sido a baja velocidad (4800 baudios). Tuve que hacerlo así porque estaba usando la parte de hardware para comunicarme con la pc a una velocidad mayor (19200). Y la recepción a 4800 es para comunicación con un modulo gps. Claro que lo que hago es recibir una cadena de caracteres y creo que tal vez debido a que es algo muy sencillo me ha funcionado perfectamente.
Ok nos leemos! 

[MGLSOFT]

La forma util de hacer la transmicion por software es asignarle un pin de interrupcion al RX y ejecutar la parte de software dentro de la interrupcion de ese pin, pero eso es necesario solo cuando necesitas dos puertos de transmicion y recepcion veloces...

[Menta]

Bueno gracias a todos! muchas gracias. Mi problema se ha solucionado 

Cuando gonzalo me dijo lo del tris, le estaba por responder que ya lo había probado así, pero entonces me di cuenta que había puesto el tris pero que no había declarado al puerto como fast_io(C) simplemente al agregar eso funcionó tanto la recepción en el pic como la interrupción.

Conclusión: RS232 por hardware ==>  fast_io(X) y setear el TRIS adecuadamente.

Gracias migsantiago por tu interés y tu rápida respuesta, i/o del puerto, el tema era por ahí nomás.
Gracias Gonzalo_BlackHawk, tu comentario me hizo darme cuenta de lo que estaba mal.
Gracias RedPic, coincido en todo contigo! pero te comento que la única vez que había implementado rs232 fue con un 16f84 con XT=4mhz y transmitiendo hacia una pc a 19200 baudios los datos de 2 eeproms 24FC1025 y recibiendo ordenes simples desde la pc. Y funcionaba de lujo.
Gracias MLO__ ya que no voy a usar cristal, usaré baja velocidad, pues no es imperativo que el sistema sea veloz.
Gracias firepic, bueno a ver si me pasas el dato sobre ese proyecto con gps que parece super interesante. Tengo unas ganas de entrarle a ese tema. Me vendría bien rastrear a la bruja las 24hs 
Gracias MGLSOFT es interesante esa idea, en determinadas aplicaciones es muy útil aportar seguridad a la transmición.

[firepic]

Siempre a la orden en lo poco que pueda ayudar...
Luego cuando esté más avanzado publicaré lo del proyecto con el gps...
Aunque por ahí puedes ver algunos post que he creado haciendo algunas preguntas al respecto.
Por ahora tengo muchas dudas y pocas respuestas. Por cierto que en el foro he encontrado gran apoyo para lo que estoy haciendo. Por eso en lo que tenga la cosa más segura lo publicaré, seguro.
Ok nos leemos! 

[MLO__]

 

Que bueno que lo solucionaras!!!! 

Saludos