# PIC12F675 y módulo de R.F, no recibe datos



## AlanB (Mar 18, 2015)

Hola amigos, estoy tratando de hacer un circuito que controle la bomba de agua de mi tanque y quiero hacerlo por radiocontrol con un modulo rf FS1000A (TX) y un MY-MK-5V (RX) y dos pics 12f675, mi problema es que no logro hacer que funcionen entre si, alguien me dice si mi codigo está mal? Según mi entender y basandome en ejemplos de la web y el manual de PIC CCS debería funcionar, pero no! Ya probe conectando directamente pin a pin pero tampoco lo logro hacer...

Estos son mis códigos...

TX:

```
#include <12F675.h>
#fuses INTRC_IO
#fuses NOWDT
#fuses NOPUT
#fuses NOPROTECT
#fuses NOCPD
#fuses NOMCLR
#rom 0x03FF = {0x342C}
#use delay(clock=4000000)
#use rs232(baud=1200, xmit=PIN_A2, parity=N, bits=8)

void main()
{
   byte s=0;
   
   while (true)
   {
      s=0x00;
      putc(s);
      delay_ms(100);
   }
}
```

RX

```
#include <12F675.h>
#fuses INTRC_IO
#fuses NOWDT
#fuses NOPUT
#fuses NOPROTECT
#fuses NOCPD
#fuses NOMCLR
#rom 0x03FF = {0x344C}
#use delay(clock=4000000)
#use rs232(baud=1200, rcv=PIN_A2, parity=N, bits=8)

void main()
{
   byte c;
   output_low(PIN_A5);
   
   while (true)
   {
      c = getc();
      if (c)
      {
         output_high(PIN_A5);
      }  
      else
      {
         output_low(PIN_A5);
      }
   }
}
```

Espero alguien me pueda ayudar y orientar, es la primera vez que trato de hacer un desarrollo asi...

Saludos, AlanB!


----------



## papirrin (Mar 18, 2015)

reviza/define  los registros CMCON de ambos pic


----------



## D@rkbytes (Mar 18, 2015)

papirrin dijo:


> Revisa/define  los registros CMCON de ambos PICs


No, por eso no están fallando sus programas.
Por tratarse de un PIC12F675 el registro involucrado para Digital/IO es el registro ANSEL.
Y tanto el registro CMCON como el registro ANSEL son configurados automáticamente por el PIC C Compiler para que el PIC funcione en modo digital si no se configuran las opciones del ADC.


AlanB dijo:


> Estoy tratando de hacer un circuito que controle la  bomba de agua de mi tanque y quiero hacerlo por radiocontrol con un  modulo rf FS1000A (TX) y un MY-MK-5V (RX) y dos PICs 12F675.
> Mi problema es que no logro hacer que funcionen entre si.
> ¿Alguien  me dice si mi codigo está mal? Según mi entender y basándome en  ejemplos de la web y el manual de PIC CCS debería funcionar, pero no!
> Ya probé conectando directamente pin a pin pero tampoco lo logro hacer.


Por tratarse de RS-232 por software, debes usar KBHIT() para determinar cuando se reciben datos.

Mira ahora cual es tu problema:
En el programa del receptor estás realizando una mala comparación.
Si escribes...
*if(c)
{
// Código*
*}*
*else
{
// Código
}*
Se está esperando que *c* tenga cualquier valor que no sea 0.
Entonces si en el programa transmisor mandas un 0, jamás se cumplirá la primer parte de la sentencia.

Tampoco es necesario que uses  *#rom 0x03FF = {Valor de OSCCAL}
*Esto ya lo hace también el PIC C Compiler por defecto, pero estableciendo el valor que tiene el PIC.
El hacer eso limita el código a un solo PIC y no servirá para otros.
Lo mejor es que apuntes el valor de calibración de fábrica del oscilador.
Lo puedes hacer pintando la parte de arriba de cada pin con el valor binario de los 8 bits de OSCCAL.

Así es como debe funcionar el programa del receptor:

```
#include <12F675.h>
#fuses   NOMCLR
#use     delay(internal = 4MHz)
#use     rs232(baud=1200, rcv=PIN_A2)

void main()
{
   byte c;
   output_low(PIN_A5);
   
   while (true)
   {
      if(kbhit())
      {
         c = getc();
         if (c == 0)
         {
            output_high(PIN_A5);
         }  
         else
         {
            output_low(PIN_A5);
         }
      }
   }
}
```
Si requieres comparar varios datos, puedes hacer uso de una selección con *Switch()*


----------



## AlanB (Mar 19, 2015)

Hola, amigo. Antes que nada, gracias por la respuesta.
Te comento que de esa forma ya la probé y tampoco obtengo resultados.
Lo que si no modifiqué fueron los fuses como en tu código de ejemplo. ¿La configuración de los míos está mal?
Porque veo que sólo declaras en tu ejemplo NOMCLR.

Lo de KBHIT() lo había probado sin resultados, pero leí que es necesario su uso si se hace un RS-232 por software, como me mencionas en tu ejemplo.
¿Dónde puede estar el error? Al encender el circuito y conectar directamente el pin rcv y el xmit de ambos PICs, mi LED ni siquiera enciende.
Ahora, si desconecto el cable que los une, éste empieza a parpadear sin frenos.
¿Dónde está mi error?

Saludos y gracias de nuevo!
AlanB!


----------



## D@rkbytes (Mar 19, 2015)

Esa forma de configurar el PIC es simplificada y de esa manera el compilador usa la palabra de configuración adecuada para usar el oscilador interno.
En los PIC12 y 16 es una forma fácil de configurar los fuses y funciona correctamente.
Como MCLR es un fuse que por defecto se encuentra activo y se requiere desactivado, únicamente declaré  ese fuse como inactivo.
Los fuses que el compilador agrega por defecto de esa forma, son los fuses necesarios para una correcta operación.

El programa debe funcionar pues es muy sencillo y funciona físicamente.

Para que salgas de dudas, adjunto los programa de ejemplo con el agregado de la selección con SWITCH().
Los programas funcionan correctamente y al momento de escribir este post están funcionando los dos PIC  en un protoboard.

Si al probar los programas adjuntos continúas con problemas, seguramente alguno de los PICs perdió el valor de calibración de fábrica para OSCCAL o no tiene el valor original.

Por la conexión no creo que tengas problemas porque es muy sencilla, así como se muestra en la foto adjunta.
​ 
Notas:
Los programas fueron probados con PIC12F675 y PIC12F629.
También se incluye la simulación funcionando y el esquema.

Suerte.


----------



## AlanB (Mar 19, 2015)

Amigo D@rkbytes, sos un genio.  

Configuré los fuses a tu manera y además corregí un par de cosas mirando tu código como ejemplo, y funcionó. Gracias!
Mis errores creo que eran en principio que tenía mal iniciado mi RS-232 y además que pasaba mal los datos con los PUTC y PUTS.
Al final mi código quedo así y funcionando, gracias a la gran mano que me diste. 

Dejo mis códigos por si a alguien también le sirve o le pasa algo parecido.

TX

```
#include <12F675.h>
#fuses NOMCLR
#use delay(internal = 4MHz)
#use rs232(baud=1200, xmit=PIN_A2)

void main()
{
   putc(0x00);
   
   while (true)
   {
      puts("s");
      delay_ms(1000);
   }
}
```
RX

```
#include <12F675.h>
#fuses NOMCLR
#use delay(internal = 4MHz)
#use rs232(baud=1200, rcv=PIN_A2)

void main()
{
   byte c;
   output_low(PIN_A5);
   
   while (true)
   {
      if (kbhit())
      {
         c = getc();
         if (c == "s")
         {
            output_high(PIN_A5);
         }  
         else
         {
            output_low(PIN_A5);
         }
      }
   }
}
```
Otra consulta. ¿Siempre se inicializa así (putc=0x00) el rs232? Una nueva duda a tener en cuenta para futuros proyectos mediante el RS-232

Saludos y gracias, GENIO!


----------



## D@rkbytes (Mar 19, 2015)

AlanB dijo:


> Otra consulta. ¿Siempre se inicializa así (putc=0x00) el rs232? Una nueva duda a tener en cuenta para futuros proyectos mediante el RS-232


Si. Es conveniente inicializar el bus RS-232 enviando un 0 antes del envío de información, porque cuando se realiza el primer envío suele ser erróneo.
Con esto el bus ya queda preparado para "enviar información sin errores".
Y lo digo entre comillas, porque algunas veces puede ser que el dato enviado no sea correcto.

Los datos posteriores al primer envío ya suelen ser correctos, pero el primero casi siempre falla si no se inicializa el bus.


----------



## AlanB (Mar 20, 2015)

Hola amigo de nuevo! Antes que nada, como siempre, gracias por tu ayuda e información me sirve mucho de prendizaje 

Queria comentarte que tengo de nuevo el mismo problema, no recibe datos RX... Modifique un poco TX...

TX

```
#include <12F675.h>
#fuses NOMCLR
#use delay(internal = 4MHz)
#use rs232(baud=1200, xmit=PIN_A2)

void main(void)
{
   putc(0x00);
   int contador = 0;
   
   while (input(PIN_A3)) 
   {
      contador++;
      delay_ms(1000);
   }
   
   if (contador > 5)
   {
      output_high(PIN_A5);
      puts("s");
      delay_ms(100);
      output_low(PIN_A5);
   }
}
```

RX

```
#include <12F675.h>
#fuses NOMCLR
#use delay(internal = 4MHz)
#use rs232(baud=1200, rcv=PIN_A2)

void main()
{
   byte c;
   output_low(PIN_A5);
   
   while (true)
   {
      if (kbhit())
      {
         c = getc();
         if (c == "s")
         {
            output_toggle(PIN_A5);
         }  
      }
   }
}
```

Lo que hice fue agregar una función para el botón que va a comandar el encendido y apagado de mi bomba de agua, esta además tiene high/low de un led piloto que indica cuando se envia/termina el dato... En cuanto al "while" creo que no hace falta que te lo explique como funciona ya que la tenés mas que clara  pero de todas formas lo digo porque a lo mejor estoy equivicado, el bucle lo que hace es incrementar "contador" mientras se presiona el botón y el "if" se encarga de enviar o no el dato de acuerdo al valor incrementado... A simple vista debería funcionar ya que sin la función del botón lo hace, cual es mi error en la función creada?

Saludos y gracias!
AlanB!


----------



## D@rkbytes (Mar 21, 2015)

Al programa del transmisor le falta lo siguiente:


Debes envolver dentro de un bucle infinito las instrucciones.
Envolver dentro del mismo bucle la sentencia IF del contador.
Regresar a 0 el contador para que no se siga incrementando.
Sobre el caso No. 1:
Si no usas un bucle para ingresar las instrucciones el programa será ejecutado una sola vez y se detendrá.

Caso No. 2:
Si realizas un bucle para el conteo mientras se encuentre presionado el pulsador, éste se seguirá incrementando hasta que se desborde.
Esto ocasionará que la sentencia siempre se cumpla cuando la variable contador sea superior a 5.

Caso No. 3:
Se debe regresar la variable contador a 0 una vez que se cumpla el valor requerido, para que cuando ocurra una nueva pulsación se inicie siempre el conteo desde 0.


De esta forma es como debe funcionar el programa del transmisor añadiendo lo que te mencioné:

```
void main (void)
{
   int8 contador = 0;
   
   output_low(PIN_A5);              // Estado inicial de GP5
   
   putc(0x00);                      // Inicializar el bus.
   delay_ms(100);                   // Esperar 100 ms para una mejor estabilización.
   
   while (true)
   {
   
      while (input(PIN_A3))         // Mientras GP3 = 1...
      {
         contador++;                // Incrementar contador.
         delay_ms(1000);            // Retardo de 1 segundo.
   
         if (contador > 5)          // Si contador es mayor a 5...
         {  
            contador = 0;           // Regresar contador a 0
            output_high(PIN_A5);    // GP5 = 1
            puts("s");              // Se envía el dato.
            delay_ms(100);          // Retardo de 100 ms.
            output_low(PIN_A5);     // GP5 = 0
         }
      }
      // Mantener contador en 0 en caso de no completar el conteo.
      contador = 0;
   }
}
```
Otra mejora que puedes agregar, es que el receptor envíe un indicador del estado del pin de control.
De esa forma se puede saber cuando el dispositivo a controlar está encendido o apagado.

Te menciono esto porque estás usando una instrucción de cambio de estado en el receptor (Output_Toggle) y se usa un único dato para realizar el cambio.


----------



## AlanB (Mar 24, 2015)

D@rkbytes como va!

No entendí mucho el tema de un indicador de estado... De todas formas estoy tratando de agregar una función más al proyecto que trata de lo siguiente...

#F1. Activar/desactivar la bomba, presionando el botón (TX) entre 5 y 10 segs, esto lo modifique con lo siguiente:

TX

```
if (contador > 5 && contador <= 10) //MODIFICADO
{
 contador = 0;          
 output_high(PIN_A5);
 puts("s");              
 delay_ms(100);       
 output_low(PIN_A5);
}
```

#F2. Probar conectividad entre TX y RX (función que quiero agregar)...

TX

```
if (contador > 10) //AGREGADO
{
 contador = 0;          
 output_high(PIN_A5);
 puts("prueba_conexion");              
 delay_ms(100);       
 output_low(PIN_A5);
}
```

RX

```
if (c == "prueba_conexion") //AGREGADO
{
 int i;

 for (i=0; i<10; i++)
 {
  output_high(PIN_A5);
  delay_ms(100);
  output_low(PIN_A5);
  delay_ms(100);
  output_high(PIN_A5);
  delay_ms(100);
  output_low(PIN_A5);
  delay_ms(100);
 }
}
```

De esta forma la idea es que al presionar o no se active la bomba de agua, pero si lo presiono mas de 10segs el led solo encienda/apague por diez veces pero sin exito y a simple vista deberia funcionar... Cual es mi error en este caso? Se puede meter un for dentro de un if?

Saludos y gracias 
AlanB!


----------



## D@rkbytes (Mar 24, 2015)

Lo del indicador de estado no es complicado. Se trata de que el receptor envíe al transmisor el estado del pin de control.
El transmisor debe estar monitoreando los datos que llegan del receptor y activar o desactivar un LED para indicar en que estado se encuentra el pin de control.

Sobre las condiciones:
Si declaras *if (contador > 5)*, entonces la sentencia se cumple cuando contador sea 6 porque ya es superior a 5.
Y si requieres 5 segundos con un retardo de 100 ms, entonces el conteo tienen que ser superior a 49.
Así el contador llegará a 50 y serán 5000 ms. 50 x 100 = 5000

Ahora sobre esta sentencia: *if (contador > 5 && contador <= 100)*
Lo primero que se cumplirá será cuando contador llegue a 6 y la segunda parte no se cumplirá.
Esto es porque cuando contador supere 5 ya se está cumpliendo la sentencia.
La segunda parte sólo se cumpliría si el valor de la variable "contador" viniera de otra rutina y no precedente de un incremento consecutivo.
Es decir, si la variable contador se va incrementando desde 0 y a continuación se le compara, lógicamente al llegar a 6, en la sentencia IF se dará por cumplida la sentencia.

Y sí, si se pueden incluir bucles FOR dentro de sentencias IF y viceversa.


----------



## AlanB (Mar 24, 2015)

Hola amigo de nuevo, quería comentarte que logré el funcionamiento correcto (aunque solo entre pics conectando pin a pin, ya que creo que ahora el error está en los modulos), me sirvio de mucho tu ayuda, gracias por brindarme tus conocimientos  Utilizando en RX la sentencia SWITCH me funcionó a la perfección, aun no logro entender porque no lo hizo con los IF... De todas formas dejo los códigos por si a alguien le sirve de ayuda, ambos están un poco modificados...

TX

```
#include <12F675.h>
#fuses NOMCLR
#use delay(internal = 4MHz)
#use rs232(baud=1200, xmit=PIN_A2)

void menu()
{
   int contador = 0;  
   
   while (input(PIN_A3))
   {
      contador++;
      delay_ms(50);
   }  
    
   if (contador >= 1 && contador <= 10)
   {
      contador = 0; //Reseteo contador a 0
      output_high(PIN_A5);
      puts("e");
      delay_ms(100);
      output_low(PIN_A5);
   }  
   
   if (contador > 10)
   {
      contador = 0; //Reseteo contador a 0
      output_high(PIN_A5);
      puts("p");
      delay_ms(100);
      output_low(PIN_A5);
   }   
}

void main (void)
{
   output_low(PIN_A5);
   
   while (true)
   {
      putc(0x00);
      delay_ms(100); 
      menu();
   }
}
```

RX

```
#include <12F675.h>
#fuses NOMCLR
#use delay(internal = 4MHz)
#use rs232(baud=1200, rcv=PIN_A2)

void main()
{
   byte c;
   output_low(PIN_A5);
   int i = 0;
   
   while (true)
   {
      if (kbhit())
      {
         c = getc();      
         switch (c)
         {
            case 'e':
            output_toggle(PIN_A5);
            break;
            case 'p':
            for (i=0; i<10; i++)
            {
               output_high(PIN_A5);
               delay_ms(100);
               output_low(PIN_A5);
               delay_ms(100);
            }           
         }         
      }
   }
}
```

Consulta y esto si no lo logré entender... Porque cuando coloco en "case 'encender':" me genera un error de compilación y no así cuando coloco 'e' por ejemplo?

Saludos y como siempre gracias 
AlanB!


----------



## D@rkbytes (Mar 24, 2015)

AlanB dijo:


> ¿Por qué cuando coloco en "case 'encender':" me genera un error de compilación y no así cuando coloco 'e', por ejemplo?


Porque no se pueden usar cadenas. Solo puedes usar valores numéricos o una sola letra.

Para comparar cadenas tienes que hacer uso de éstas  instrucciones:
*GETS* para recibir la cadena.
*STRCPY* para copiar la cadena a un arreglo. (Array)
*STRCMP* para realizar la comparación.

Mira este ejemplo para que lo comprendas mejor: _*Recibir y comparar cadenas*_

Saludos.


----------



## AlanB (Mar 25, 2015)

D@rkbytes como va!

No logro implementar el ejemplo mencionado en el link que me posteaste, me mencionaste que para trabajar con el RS232 por soft era necesario hacer una llamada a KBHIT(), siguiendo esto trate de codear lo siguiente sin resultados... Es más o menos como tendria que hacerlo? En TX modifique los PUTS por PRINTF... Tambien agregue las librerias stdio.h y string.h...

RX

```
#include <12F675.h>
#include <stdio.h>
#include <string.h>
#fuses NOMCLR
#use delay(internal = 4MHz)
#use rs232(baud=1200, rcv=PIN_A2)

void main()
{      
   char rcv_datos[8];
   char cmp_dato1[8];
   char cmp_dato2[8];
   int i = 0;
   
   output_low(PIN_A5);
   strcpy(cmp_dato1, "encender");
   strcpy(cmp_dato2, "testcon");
   
   while (true)
   {
      if (kbhit())
      {                  
         gets(rcv_datos);
         
         if (!strcmp(rcv_datos, cmp_dato1))
         {
            output_toggle(PIN_A5);            
         }
         
         if (!strcmp(rcv_datos, cmp_dato2))
         {
            for (i=0; i<10; i++)
            {
               output_high(PIN_A5);
               delay_ms(100);
               output_low(PIN_A5);
               delay_ms(100);
            }        
         }
      }
   }
}
```

Con esto entiendo lo siguiente, si KBHIT() detecta algun dato enviado, GETS lo guarda en la variable "rcv_datos" y bueno despues hago la comparación con la sentencia mencionada, pero sin resultados!

Saludos y gracias 
AlanB!


----------



## D@rkbytes (Mar 25, 2015)

Espero que en el transmisor no estés omitiendo el envío del ASCII número 13 (Retorno de carro o CR)
Esto se hace escribiendo "*\r*" al final de la cadena a enviar.
Si no lo haces, la instrucción *GETS* permanecerá en un bucle esperando esa condición.

Como ya estás usando *GETS ();* ya puedes eliminar el *IF (KBHIT () )*
Y algo importante. Debes tener en cuenta el tamaño de la cadena.
Si la cadena "encender" tiene 8 caracteres, (8 bytes) el buffer siempre debe ser mayor.
O sea que debes aumentar a 9 el tamaño de los buffers, al menos el que recibirá 8 letras u 8 bytes.

PD:
Como el PIC12F675 no tiene módulo USART, puedes usar la interrupción externa por GP2 para la recepción de datos.


----------



## AlanB (Mar 26, 2015)

D@rkbytes!

Te comento como lo tengo en mis códigos por partes, como dijo jack! 

1.- Desde TX hago el envío del string con printf("encender\r");
2.- En RX elimine KBHIT(); y tomando como ejemplo tu código, modifique lo siguiente... Te pego el mismo para que se entienda mejor...

RX

```
#include <12F675.h>
#include <stdio.h>
#include <string.h>
#fuses NOMCLR
#use delay(internal = 4MHz)
#use rs232(baud=1200, rcv=PIN_A2)

char rcv_datos[10]; // Modificado tomando tu ejemplo, ademas agregue bytes a 10.
#INT_EXT  
void INT_EXTERNA()  
{
    gets(rcv_datos);
}

void main()
{      
   char cmp_dato1[10]; // bytes a 10.
   char cmp_dato2[10]; // bytes a 10.
   int i = 0;
   
   output_low(PIN_A5);
   strcpy(cmp_dato1, "encender");
   strcpy(cmp_dato2, "testcon");
   
   enable_interrupts(INT_EXT); //agregado
   enable_interrupts(GLOBAL); //agregado

   while (true)
   {
        
         if (!strcmp(rcv_datos, cmp_dato1))
         {
            output_toggle(PIN_A5);            
         }
         
         if (!strcmp(rcv_datos, cmp_dato2))
         {
            for (i=0; i<10; i++)
            {
               output_high(PIN_A5);
               delay_ms(100);
               output_low(PIN_A5);
               delay_ms(100);
            }        
         }
   }
}
```

Básicamente es igual al tuyo reemplazando el INT utilizado en tu code con INT_EXT, según ejemplos de uso de esta instrucción debería de funcionar pero aún nada, y se me generó la duda aquí, puede que el error esté en que estoy usando el mismo pin de la interrupción para recibir los datos por el RS232 por soft? 

Saludos y gracias! 
AlanB!


----------



## D@rkbytes (Mar 26, 2015)

Te faltó agregar que la interrupción se produzca por flanco descendente.
Agrega esto: *INT_EXT_EDGE (H_TO_L);*


AlanB dijo:


> Se me generó la duda aquí: ¿Puede que el error esté  en que estoy usando el mismo pin de la interrupción para recibir los  datos por el RS-232 por software?


No. De hecho ese es el objetivo.
Cuando llega un dato el pin GP2 pasa de alto a bajo y entonces se produce la interrupción.
Ese cambio de estado se tomará como inicio de recepción y a continuación entra la función GETS() para recibir la información.

PD:
Seguramente cuando se ejecute la comparación que tiene el bucle "FOR()" se ejecute permanentemente, porque la cadena a comparar permanecerá sin cambios.


----------



## AlanB (Mar 27, 2015)

D@rkbytes!

Sigo sin tener exito con mi proyecto, agregue la linea "ext_int_edge(H_TO_L);" que es como figura en el archivo de configuracion PIC CCS 5 del 12F675... También probé agregando en vez de la mencionada "enable_interrupts(INT_EXT_H2L);" pero sin resultados exitosos... Probe con ambas lineas arriba, abajo, en el medio y nada aún... De momento quedó con la modificación que me dijiste de esta forma (sin exito)...

RX

```
#include <12F675.h> 
#include <stdio.h> 
#include <string.h> 
#fuses NOMCLR 
#use delay(internal = 4MHz) 
#use rs232(baud=1200, rcv=PIN_A2) 

char rcv_datos[10]; // Modificado tomando tu ejemplo, ademas agregue bytes a 10. 
#INT_EXT   
void INT_EXTERNA()   
{ 
    gets(rcv_datos); 
} 

void main() 
{       
   char cmp_dato1[10]; // bytes a 10. 
   char cmp_dato2[10]; // bytes a 10. 
   int i = 0; 
    
   output_low(PIN_A5); 
   strcpy(cmp_dato1, "encender"); 
   strcpy(cmp_dato2, "testcon"); 
  
   ext_int_edge(H_TO_L); //agregado recientemente, sin exito!  
   enable_interrupts(INT_EXT); //agregado 
   enable_interrupts(GLOBAL); //agregado 

   while (true) 
   { 
         
         if (!strcmp(rcv_datos, cmp_dato1)) 
         { 
            output_toggle(PIN_A5);             
         } 
          
         if (!strcmp(rcv_datos, cmp_dato2)) 
         { 
            for (i=0; i<10; i++) 
            { 
               output_high(PIN_A5); 
               delay_ms(100); 
               output_low(PIN_A5); 
               delay_ms(100); 
            }         
         } 
   } 
}
```

Que puede estar fallando en el código?

Saludos y gracias como siempre! 
AlanB!


----------



## D@rkbytes (Mar 27, 2015)

Por algún extraño motivo se genera un error cuando se usan 1200 Bps con la interrupción externa. 
​
¿Es necesario que uses esa velocidad?
Porque con el oscilador interno a 4 MHz, puedes usar 2400 o 4800 Bps sin problemas.
Con 2400 Bps o más, ya no se genera ese problema.


----------



## AlanB (Mar 28, 2015)

D@rkbytes como va!

Te comento que modifique los baudios a 2400 como me dijiste y la comunicación funciona, al menos el led piloto de pruebas funciona... Pero tengo un nuevo problema, el led se apaga al pasar unos segundos y la segunda función directamente no funciona XD, esto empezó como un simple proyecto para practicar pero ya es un reto jajaja 

Existe forma de utilizar "GETS();" sin la interrupción externa, o de pasar strings y utilizar la función "KBHIT();" como ya lo estaba haciendo en los primeros codes?

Según el manual de CCS también podría utilizar la función "bit_test(var, bit);" de 0:15 bits para pasar palabras (strings), como sería esto? Tenés algún ejemplo?

Saludos, AlanB!


----------



## D@rkbytes (Mar 28, 2015)

AlanB dijo:


> ¿Existe forma de utilizar "GETS();" sin la interrupción externa, o de  pasar strings y utilizar la función "KBHIT();" como ya lo estaba  haciendo en los primeros codes?
> 
> Según el manual de CCS también podría utilizar la función "bit_test(var,  bit);" de 0:15 bits para pasar palabras (strings) ¿Cómo sería esto?  ¿Tenés algún ejemplo?


El problema de usar GETS() es que se queda en un bucle esperando un "\r" (ASCII 13 o Retorno de carro)
Entonces si se usa dentro del bucle del programa, éste se congelará hasta que GETS() retorne.
Y obviamente esto se hará indefinidamente, por eso de preferencia se usa GETS() por servicio de interrupción.

Sobre la instrucción BIT_TEST, podría funcionar realizando varias comparaciones.
No lo he hecho comparando las letras de una cadena pero tendría que ser una por una, realizando una especie de concatenación.

Como dato adicional:
El problema al usar 1200 Bps, no tan solo se presenta con PIC C Compiler, también sucede con el Basic de Proton IDE.
Con PIC C se presenta de una manera constante cada vez que se produce la interrupción externa y entra en ejecución la instrucción GETS.
Este problema de escritura indirecta hace que el programa deje de funcionar y no se puede solucionar aún utilizando punteros.

Con Proton IDE se presenta de vez en cuando, sin embargo el programa logra seguir su ejecución.


----------



## AlanB (Mar 29, 2015)

D@rkbytes como va!

Se me ocurrió otra forma que creo podría funcionar, estoy por realizar las pruebas... Te copio los códigos, te parecen funcionales?

TX

```
#include <12F675.h>
#fuses NOMCLR
#use delay(internal = 4MHz)
#use rs232(baud=2400, xmit=PIN_A2)

void menu()
{
   int contador = 0;  
   
   while (input(PIN_A3))
   {
      contador++;
      delay_ms(50);
   }  
    
   if (contador >= 1)
   {
      contador = 0;
      output_high(PIN_A5);
      puts("t");
      delay_ms(100);
      puts("e");
      delay_ms(100);
      puts("s");
      delay_ms(100);
      puts("t");
      delay_ms(100);      
      output_low(PIN_A5);
   }     
}

void main (void)
{
   putc(0x00);
   delay_ms(100);
   output_low(PIN_A5);
   
   while (true)
   { 
      menu();
   }
}
```

RX

```
#include <12F675.h>
#include <stdio.h>
#include <string.h>
#fuses NOMCLR
#use delay(internal = 4MHz)
#use rs232(baud=2400, rcv=PIN_A2)

void main(void)
{
   char rcv_dato[10] = "";
   char buffer[10] = "";;
   
   output_low(PIN_A5);          
   
   while (true)
   {        
      if (kbhit())
      {
         buffer = getc();
         delay_ms(100);
         strcat(rcv_dato, buffer);
         
         if (rcv_dato == "test")
         {
            rcv_dato = "";
            output_high(PIN_A5);
         }         
      }
   }
}
```

Que te parecen? Se me ocurrió esto porque no logro comprender como enviar y recibir palabras/strings con "BIT_TEST"...

La idea del código es que TX envie una a una las letras o caracteres y en RX mediante la función "STRCAT" (según leí esta función sería algo parecido a concatenar ya que en C no existe "+" para hacerlo) la vaya almacenando en el array correspondiente para luego hacer la comparación con el condicional...

Saludos, AlanB!


----------



## D@rkbytes (Mar 30, 2015)

No funcionará de esa forma porque GETC no puede guardar datos en un arreglo.
Se puede, pero indicando en que parte del arreglo se almacenará el dato, o sea, byte por byte.
Aparte, con tantos retardos no creo que se logre una buena sincronización.

Si ya estás usando 2400 Bps, ya no existe el problema de escritura indirecta que ocurre con 1200 Bps.

Mira el proyecto adjunto, está funcionando físicamente con comunicación bilateral a 4800 Bps.
Ahí se muestra lo que te mencionaba sobre monitorear el estado del pin de control en el receptor.

PD:
También adjunto el proyecto en Basic del Proton IDE.


----------



## AlanB (Mar 31, 2015)

D@rkbytes como va!

Logré el cometido gracias a tus explicaciones/ejemplos de código y a mis compañeros "Manual del Compilador CCS C" y "El Lenguaje de Programación en C SE" jajajaja   

Ya me funciona correctamente la conexión entre ambos pics y el bucle "FOR" no se queda permanentemente en ejecución, aún así tengo un par de dudas a consultarte... Para limpiar mi buffer  ( char buffer[10]; ) se realiza de la siguiente forma ( buffer = ""; )???

Y otra consulta más, porque cuando acerco mis dedos sobre el pic que funciona como RX se apaga la función que se esta ejecutando en ese momento? Por ejemplo, si justo dejé el led encendido y acerco mi dedo este se apaga...

Además modifiqué un poco los códigos para optimizar un poco el consumo de la memoria ram del pic RX, bajando su consumo en un 10% aproximadamente...

Para aquellos que les pueda servir de ejemplo, pego mis códigos funcionales gracias a la ayuda de D@rknytes y mis compañeros manuales como mencioné jajaja 

TX

```
#include <12F675.h>
#fuses NOMCLR
#use delay(internal = 4MHz)
#use rs232(baud=2400, xmit=PIN_A2)

void menu()
{
   char *On_Off = "on_off";
   char *Test_Con = "test_con";
   int contador = 0;  
   
   while (input(PIN_A3))
   {
      contador++;
      delay_ms(50);
   }  
    
   if (contador >= 1 && contador <= 10)
   {
      contador = 0;
      output_high(PIN_A5);
      printf("%s\r", On_Off);
      delay_ms(100);      
      output_low(PIN_A5);
   }
   
   if (contador > 10)
   {
      contador = 0;
      output_high(PIN_A5);
      printf("%s\r", Test_Con);
      delay_ms(100);      
      output_low(PIN_A5);   
   }
}

void main (void)
{
   putc(0x00);
   delay_ms(100);
   output_low(PIN_A5);
   
   while (true)
   { 
      menu();
   }
}
```

RX

```
#include <12F675.h>
#include <stdio.h>
#include <string.h>
#fuses NOMCLR
#use delay(internal = 4MHz)
#use rs232(baud=2400, rcv=PIN_A2)

char buffer[10];
#INT_EXT
void RCV_BUFFER(void)
{
   gets(buffer);
}

void main(void)
{  
   char *fn_onoff = "on_off";
   char *fn_testc = "test_con";
   int i;
   
   output_low(PIN_A5);          

   enable_interrupts(INT_EXT);
   enable_interrupts(GLOBAL);
   ext_int_edge(H_TO_L);   
    
   while (true)
   {            
      if (strcmp(buffer, fn_onoff) == 0)
      {
         buffer = "";
         output_toggle(PIN_A5);
      }
      else if (strcmp(buffer, fn_testc) == 0)
      {
         buffer = "";
         for (i=0; i<10; i++)
         {
            output_high(PIN_A5);
            delay_ms(110);
            output_low(PIN_A5);
            delay_ms(60);          
            output_high(PIN_A5);
            delay_ms(110);
            output_low(PIN_A5);
            delay_ms(400);            
         }
      }      
   }
}
```

Saludos y como siempre gracias 
AlanB!


----------



## D@rkbytes (Mar 31, 2015)

AlanB dijo:


> ¿Para limpiar mi buffer  ( char buffer[10]; ) se realiza de la siguiente forma ( buffer = ""; )?


No. obtén la dimensión del buffer con *strlen*, ésta función te retornará la longitud ocupada del array.
Después realiza un bucle *for* que se repita las veces del resultado de *strlen * y lo limpias de esta forma:
*buffer[x] = '\0';*
También lo puedes hacer sin obtener la dimensión del buffer, pero así es mejor por si la cambias.


AlanB dijo:


> Y otra consulta más. ¿Por qué cuando acerco mis dedos sobre el pic que funciona como RX se apaga la función que se esta ejecutando en ese momento? Por ejemplo, si justo dejé el led encendido y acerco mi dedo éste se apaga?


Cuando la comunicación es de PIC a PIC eso no debería suceder, pero cuando se reciben datos de otro dispositivo, puede ser porque GP2 que es el pin de interrupción externa, esté detectando cambios de nivel.
Verifica que éste pin tenga un 1 lógico en estado de espera.
Al PIC12F675 se le pueden activar resistencias pull-up independientes a algunos pines.
Mira los registros OPTION_REG bit 7 y el registro WPU.
Por medio de la instrucción *port_x_pullups(value/mask/unmask);* puedes activar las que necesites. En este caso GP2.


AlanB dijo:


> Además modifiqué un poco los códigos para optimizar un poco el consumo de la memoria ram del pic RX, bajando su consumo en un 10% aproximadamente...
> 
> Para aquellos que les pueda servir de ejemplo, pego mis códigos funcionales gracias a la ayuda de D@rknytes y mis compañeros manuales como mencioné jajaja


Que bien.  No he revisado los programas pero me daré un tiempo para ello.


Edit:
Ya revisé los programas y están funcionando bien.

Mira, esta es la forma que te mencioné acerca de limpiar el buffer:

```
[B]         x = strlen(buffer);
         
        [COLOR=Blue] for[/COLOR](i=[COLOR=SeaGreen]0[/COLOR];i<=x;i++)
         {
            buffer[i] = [COLOR=Purple]'\0[/COLOR]';
         }[/B]
```
Saludos.


----------



## AlanB (Mar 31, 2015)

D@rkbytes como siempre gracias por tu enseñanza 

Estoy leyendo sobre las pullups! Y con respecto a la limpieza del buffer, esto estaría bien no?

Clear Buffer

```
j = (strlen(buffer) - 1;

for (x=0; x<j; x++)
{
    buffer[x] = '\0';
}
```

Saludos y gracias amigo! 
AlanB!


----------



## D@rkbytes (Mar 31, 2015)

Si, pero quita el -1 para que se limpie bien el buffer o no se limpiará la última locación ocupada.

Sobre las pull-ups, no es complicado.
Aunque el 12F675 no tenga un puerto de 8 bits, debes considerarlo como si los tuviera.
Entonces si quieres activar la resistencia pull-up del bit 2, tendrías esto: "00000100" =  4 en decimal.
Por lo tanto, cargas el valor 4 en la instrucción: *port_a_pullups (0x04);*

PD:
Me di cuenta que el bit 0 (GP0) mantiene un estado lógico 1.
Esto lo provoca la directiva *#USE RS232 (Options)*
Aunque no tenga establecido el pin Tx (XMIT), toma GP0 como el pin de Tx.

Esto se puede evitar haciendo uso de *#USE FAST_IO (Port)*
Y estableciendo con *SET_TRIS_X (Value);* los pines de entrada y salida.
Por ejemplo: *set_tris_a (0F);* // Únicamente GP5 como salida.

Otros detalles:
La librería *stdio.c* no se está usando, así que la puedes quitar.

En el inicio del programa y después del retardo de 100 ms, escribe lo siguiente:
*printf("on_off\r");
*Esto hará que no se tenga que presionar dos veces el pulsador cuando inicie el programa y se active el pin de control en el receptor.


----------



## AlanB (Abr 1, 2015)

D@rkbyes como va!

Consulta algo que nunca entendi muy bien, set_tris_a(0xdf), es lo mismo si lo pongo en binario "set_tris_a(0b11011111);" o si lo pongo en decimal asi "set_tris_a(223);"?

Hex = 0x00
Bin = 0b00000000
Dec = 000

Lo de las pullups no me funcionó, si acerco mi dedo sigue haciendo lo mismo, se apaga la funcion que se esta ejecutando en el momento... Igual sigo haciendo las pruebas...

Saludos AlanB


----------



## D@rkbytes (Abr 1, 2015)

Si. Para el compilador es lo mismo que escribas en binario, decimal o hexadecimal.

Se me hace extraño que te suceda eso, yo tengo montado el circuito en protoboard y eso no sucede.
Incluso puedo tocar directamente todos los pines y el PIC sigue funcionando perfectamente.
No hace ninguna cosa extraña, ni en estado de espera y tampoco cuando está encendido el LED.

La prueba la hice con el último código que pusiste, solo con el agregado para limpiar el buffer.
De hecho desde las primeras pruebas nunca se ha presentado lo que mencionas.

Lo que si te puedo decir, es que únicamente cuando GP2 se encuentra en estado flotante, sucede lo que mencionas.
Con acercare unos cuantos centímetros al PIC, éste ya detecta cambios de estado.


----------



## AlanB (Abr 1, 2015)

En estado flotante? Como sería eso? Además de bucle para limpiar el buffer, agregaste otro código más?


----------



## D@rkbytes (Abr 1, 2015)

AlanB dijo:


> ¿En estado flotante? ¿Cómo sería eso?


Estado flotante es cuando un pin no tiene ninguna referencia lógica.
O sea, cuando el pin está configurado como entrada y carece de una resistencia pull-up o pull-down.
También se puede dar el caso en las salidas, cuando son con drenador o colector abierto.


AlanB dijo:


> ¿Además de bucle para limpiar el buffer, agregaste otro código más?


Pues no, solo que te mencioné anteriormente.
Este es el código del receptor con los agregados mencionados:

```
#include <12F675.h>
#include <string.h>
#fuses   NOMCLR
#use     delay(internal = 4MHz)
#use     rs232(baud=2400, rcv=PIN_A2)
#use     fast_io(a)

char buffer[10];

#INT_EXT
void RCV_BUFFER(void)
{
   gets(buffer);
}

void main(void)
{  
   char *fn_onoff = "on_off";
   char *fn_testc = "test_con";
   int i,x;
   
   set_tris_a(0xDF);
   output_low(PIN_A5);
   port_a_pullups(0x04);

   enable_interrupts(INT_EXT);
   enable_interrupts(GLOBAL);
   ext_int_edge(H_TO_L);   
    
   while (true)
   {            
      if (strcmp(buffer, fn_onoff) == 0)
      {
         x = strlen(buffer);
         
         for(i=0;i<=x;i++)
         {
            buffer[i] = '\0';
         }
         
         output_toggle(PIN_A5);
      }
      else if (strcmp(buffer, fn_testc) == 0)
      {
         x = strlen(buffer);
         
         for(i=0;i<=x;i++)
         {
            buffer[i] = '\0';
         }
         
         for (i=0; i<10; i++)
         {
            output_high(PIN_A5);
            delay_ms(110);
            output_low(PIN_A5);
            delay_ms(60);          
            output_high(PIN_A5);
            delay_ms(110);
            output_low(PIN_A5);
            delay_ms(400);            
         }
      }      
   }
}
```
Si continúas con el problema, adjunta el archivo ejecutable para realizar una prueba.
Eso también sirve para analizar los registros.

Una pregunta: ¿La comunicación es directa entre los PICs, o por medio de otro dispositivo?


----------



## AlanB (Abr 1, 2015)

D@rkbytes antes que nada gracias por tu tiempo!

Te comento, en estos momentos tengo compilado y cargado en el pic RX el source que publiaste con las modificaciones mencionadas "clear buffer", "port_a_pullups", "set_tris_a" y sigo teniendo el bug que te mencioné... La comunicación por ahora es de pic a pic, aún espero que me lleguen los modulos RF...

¿Cuál sería el ejecutable para analizar los registros?

Saludos, AlanB!


----------



## D@rkbytes (Abr 1, 2015)

Si. Lo supuse, porque esos agregados no solucionan el problema que tienes.

El archivo ejecutable es el archivo *.hex que grabas en el PIC.


----------



## AlanB (Abr 2, 2015)

D@rkbytes como va! 

Te dejo adjunto el HEX del RX!

Saludos, AlanB! 

EDITADO:

Me llegaron los modulos rf RWS-371 y TWS-433 del fabricante "Whenshing", pero al conectarlos no existe comunicación con los pics  vi en un montón de webs que todo el mundo los usa mediante el rs232... Porque no se comunican? Estan a unos 10cm uno del otro y nada... Alguna vez utilizaste estos?


----------



## asherar (Abr 2, 2015)

AlanB dijo:


> Me llegaron los modulos rf RWS-371 y TWS-433 del fabricante "Whenshing", pero al conectarlos no existe comunicación con los pics  vi en un montón de webs que todo el mundo los usa mediante el rs232... Porque no se comunican? Estan a unos 10cm uno del otro y nada... Alguna vez utilizaste estos?



Fijate en las hojas de datos del receptor de qué ancho es la banda de recepción y si puede recibir 
algo en la frecuencia del transmisor. 
Hojas de datos: https://www.forosdeelectronica.com/f22/rws-433-tws-433-modular-voz-98273/
Segun tengo entendido el receptor tiene una banda ancha o se puede sintonizar en algún rango con 
la  bobina atornillable.
También podés usar el buscador por si alguien ha tenido un problema similar. 
Fijate de usar la salida digital del RX, la otra tiene un comportamiento "lineal" que nunca entendí. 

Saludos.


----------



## D@rkbytes (Abr 2, 2015)

AlanB dijo:


> Te dejo adjunto el HEX del RX!


OK. Ya revisé el archivo .hex y es correcto en cuanto a los registros. 
No sé si cambiaste los Baudios o hay algo diferente en tu programa, porque no pude establecer comunicación.

Con el programa del _post #31_ si logro la comunicación. O sea, el receptor sí responde.
Puede ser que el valor de OSCCAL del PIC receptor sea algo incorrecto, así que se me ocurre que hagas una prueba con oscilador a cristal. (Misma frecuencia, 4MHz.)
Obviamente tendrás que cambiar el pin de control, pero es para salir de dudas.

Ésta es la configuración de registros que tengo en el PIC receptor con el programa del post #31: 
Si te fijas, tienen el mismo valor, pero algo diferente tiene tu programa que no me funciona. ​


----------



## AlanB (Abr 2, 2015)

D@rkbytes como va!

Los baudios estan en 2400, a lo mejor el problema es que los strings enviados los cambie a "test" y "test2" y ese debe ser el problema de que no se comunican, perdón por olvidar mencionarlo... Según leí en la web muchos ponen al pin GP3 con una resistencia pullup externa ya que este pin carece de la misma de forma interna en este pic, justo ahora estoy haciendo la prueba, ademas cambie de pic y sigo teniendo el problema nose ya a que se debe, ya que en tu prueba no sucede lo mismo, será ruido por la protoboard?

Otra cosa, mis modulos son del tipo ASK y según leí también es muy dificil que me funcione el proyecto con ellos ya que el RS323 es de tipo NRZ, asi que me encuentro buscando una forma de que se comuniquen mediante algun dato preciso y que no tomen cualquier dato para asi evitar que el proyecto se encienda con cualquier señal que recibe...

Existe alguna librería para este proposito? Vi que un usuario de otro foro lo solucionó haciendo su propio protocolo... Alguna vez trabajaste con modulos rf con modulacion ASK?

Saludos, AlanB!


----------



## D@rkbytes (Abr 2, 2015)

AlanB dijo:


> Los baudios están en 2400, a lo mejor el problema es que los strings enviados los cambie a "test" y "test2" y ese debe ser el problema de que no se comunican, perdón por olvidar mencionarlo.


He ahí el detalle. 
Pero bueno, como quiera los valores de los registros es lo que importaba saber, y son idénticos al que tengo.


AlanB dijo:


> Según leí en la web muchos ponen al pin GP3 con una resistencia pull-up externa ya que este pin carece de la misma de forma interna en este PIC.
> Justo ahora estoy haciendo la prueba, ademas cambié de PIC y sigo teniendo el problema.


Así es, el pin 4 o GP3 no tiene resistencia interna.
Cuando se usa normalmente como pin de reset, la resistencia obviamente debe ser pull-up.
Pero cuando se usa como pin de entrada (MCLR deshabilitado), la resistencia externa puede ser pull-up o pull-down, ya que eso depende de la programación del código.


AlanB dijo:


> No sé ya a qué se debe, ya que en tu prueba no sucede lo mismo. ¿Será ruido por la protoboard?


Si. si puede deberse a ruido.
Yo le conecto un capacitor de 470 uF a cada lado del mismo. (Sobre las líneas VDD y VSS)


AlanB dijo:


> Otra cosa. Mis módulos son del tipo ASK y según leí también es muy difícil que me funcione el proyecto con ellos ya que el RS323 es de tipo NRZ.
> 
> ¿Existe alguna librería para este propósito? Vi que un usuario de otro foro lo solucionó haciendo su propio protocolo.
> ¿Alguna vez trabajaste con módulos R.F con modulación ASK?


No creo que tengas problemas por el tipo de modulación.
He visto ejemplos que usan ese tipo de módulos y se comunican por RS-232.

Y no. No he usado ese tipo de módulos, pero he visto por aquí en el Foro que si han tenido problemas con ellos.
Problema PICs + Módulos *RF ASK*
Duda sobre transmisor y receptor *rf* 7000 a 433MHz arlex
Modulos *radiofrecuencia ASK* y pic
Control remoto *RF* para alarma con pic ¿como?


----------



## AlanB (Abr 2, 2015)

D@rkbytes!

Leyendo un poco sobre el tema... Tenés algun ejemplo sobre este pic y su timer, se me ocurrio hacer algo que entienda un pulso alto y un pulso bajo leyendo el timer, de esta forma podria enviar datos con pulsos y lograr decodificar estos basándome en sus tiempos y generando una onda cuadrada (creo que estoy en lo correcto no?), podria enviar los siguientes valores...

| DEC | HEX | BIN  |
|  0  |  0  | 0000 |
|  1  |  1  | 0001 |
|  2  |  2  | 0010 |
|  3  |  3  | 0011 |
|  4  |  4  | 0100 |
|  5  |  5  | 0101 |
|  6  |  6  | 0110 |
|  7  |  7  | 0111 |
|  8  |  8  | 1000 |
|  9  |  9  | 1001 |
| 10  |  A  | 1010 |
| 11  |  B  | 1011 |
| 12  |  C  | 1100 |
| 13  |  D  | 1101 |
| 14  |  E  | 1110 |
| 15  |  F  | 1111 |

Donde 0 seria bajo y 1 alto... 

Enviar un "0" podria ser por ejemplo

```
void Send0()
{
  output_high(PIN_AX);
  delay_ms(1);
  output_low(PIN_AX);
  delay_ms(3);
}
```

Y enviar un "1" podria ser por ejemplo

```
void Send1()
{
  output_high(PIN_AX);
  delay_ms(3);
  output_low(PIN_AX);
  delay_ms(1);
}
```

Y para enviar por ejemplo "3 (0011)" seria

```
while (true)
{
  Send0();
  Send0();
  Send1();
  Send1();
}
```

Y con esto mis modulos se podrian comunicar... Nose realmente si se entiende lo que quiero hacer pero renegando con mi proyecto se me acaba de ocurrir y no encuentro algun ejemplo que me ayude a entender el timer... Desde ya muchas gracias por tu tiempo!

AlanB!


----------



## D@rkbytes (Abr 2, 2015)

Para eso necesitas crear un protocolo de comunicación y ya se está usando el RS-232.
La verdad no entiendo por qué quieres hacerlo de otra forma que sería más complicado. 
Mira como lo hacen por aquí: Wireless data transmission between two PIC using low-cost RF modules
Es por RS-232 usando módulos R.F con modulación ASK.


----------



## AlanB (Abr 3, 2015)

D@rkbytes!

Basandome en el link que me dejaste realice estos códigos, la unica diferencia que tiene es que utilizo KBHIT() ya que mi rs232 es por software, y aun asi no logro conexion rf, ahora si lo conecto de pic a pic la funcion se ejecuta correctamente (blink led)... De ahi nace la idea de hacer algo un poco mas complicado 

TX

```
#include <12F675.h>
#fuses NOMCLR
#use delay(internal = 4MHz)
#use rs232(baud=1200, xmit=PIN_A2, bits=8, parity=N)

void main()
{
   putc(0x00);
   delay_ms(100);
   while (true)
   {
      puts("e");
      delay_ms(100);
   }
}
```

RX

```
#include <12F675.h>
#fuses NOMCLR
#use delay(internal = 4MHz)
#use rs232(baud=1200, rcv=PIN_A2, bits=8, parity=N)

void main()
{
   byte c;
   output_low(PIN_A5);
   
   while (true)
   {
      if (kbhit())
      {
         c = getc();      
         switch (c)
         {
            case 'e':
            output_toggle(PIN_A5);          
         }         
      }
   }
}
```

No logro entender cual es mi error ya que como me decis vi que muchos lo hacen con el rs232, ¿el error será hacerlo por rs232 por soft? ¿alguien alguna vez tuvo el mismo problema que el mio?

Saludos, AlanB!

EDITADO:
Es posible enviar estos mismos datos a través de un encode/decoder um3750? Es decir, PIC TX -> UM3750 (Encoder) -> RF TX <-> RF RX -> UM3750 (Decoder) -> PIC RX, alguien lo probó de esta forma? En el datasheet del ic no especifica esto...


----------



## D@rkbytes (Abr 3, 2015)

AlanB dijo:


> Basándome en el link que me dejaste realice éstos códigos.
> La única diferencia que tiene es que utilizo KBHIT() ya que mi RS-232 es por software, y aún así no logro conexión R.F.
> Ahora, si lo conecto de PIC a PIC, la función se ejecuta correctamente (blink led)
> De ahí nace la idea de hacer algo un poco mas complicado


Primero debes lograr que funcione con algo sencillo y después ya pasar a lo complicado.
Si con  RS-232 por software no logras comunicación, con algo complicado será peor.

¿Ya verificaste la compatibilidad entre tus módulos?
Tienes el  RWS-371 como receptor y el TWS-433 como transmisor, y viendo sus hojas de datos, son algo diferentes.
Datos del RWS-371


Datos del TWS-433


Según veo, para el TWS-433 la velocidad típica es de 2400 Bps.

Desconozco si ésta pueda variar desde un mínimo X hasta un máximo de 3 Kbps.​Pero... ¿Por qué no haces una prueba con Tx y Rx a 2400 Bps.?


----------



## AlanB (Abr 3, 2015)

D@rkbytes, los tengo configurados a 2400bps, los monte sobre una placa pequeña soldados para evitar un poco de ruido, coloque un capa de 10nf entre los pines de alimentacion de estos (lo lei en un foro que tocaban el tema y tenian el mismo error) y nada aun... Según lei tambien, para que estos modulos funcionen correctamente es necesario utilizar codificacion manchester y estuve leyendo sobre el tema pero la verdad aun no se me ocurre como realizarla, manualmente es facil codificar pero el tema es hacer la funcion que lo haga XD 

Encontre este articulo que habla y ejemplifica sobre codificacion manchester, pero mi ingles es un poco nulo y me cuesta entender los ejemplos, me ayudas?

EDITADO:
Encontre un link de youtube donde una persona utiliza dos 16f84 mediante codificacion manchester...


----------



## D@rkbytes (Abr 4, 2015)

AlanB dijo:


> Encontré este articulo que habla y ejemplifica sobre codificación Manchester, pero mi inglés es un poco nulo y me cuesta entender los ejemplos. ¿Me ayudas?


OK. Tomando como base el documento que adjuntas y realizando algunos cambios, hice los programas.
Realicé las pruebas con dos 12F629 porque ya nada más tengo un 12F675.
Prácticamente son iguales, pero con la diferencia de que el 12F675 tiene ADC.

Ambos programas Tx y Rx funcionan físicamente conectados directamente.
Ya nos contarás que resultados obtienes con los módulos de R.F.

Adjunto el proyecto completo realizado con PIC C Compiler v5.044 y Proteus 7.10

Suerte.


----------



## AlanB (Abr 4, 2015)

D@rkbytes sos un GENIOOO!!! 

Ya no se mete ruido en el receptor y además enciende y apaga el led cuando quiero, la verdad sos un genio, ahora lo voy a retocar para que quede con las funciones que queria  Ni bien lo tenga terminado y funcionando subo el código por si a alguien le sirve!

Saludos, AlanB! 

PD: Si tenes tiempo, solo si tenes tiempo, me gustaria comprender bien el codigo realizado, o sea me gustaria que me lo expliques asi comprendo bien


----------



## D@rkbytes (Abr 4, 2015)

¿Qué partes del código de los programas son las que no entiendes?


----------



## AlanB (Abr 4, 2015)

Me gustaría comprender la codificación como la hace y bueno después es que las decodifica, todo el código sería jajajaja porque me intereso muchísimo el sistema de codificación


----------



## D@rkbytes (Abr 5, 2015)

OK. Para entender mejor la codificación y decodificación Manchester de los programas, lee el documento que adjuntaste.

Si no sabes inglés, puedes usar por ejemplo, el Traductor de Google de tu región.
Copia y pega  en el traductor las partes de texto que no comprendas. 

Leer también:  Codificación Manchester






Wikipedia.


Aquí están los programas comentados y con algunos cambios para su mejor comprensión.

Saludos.


----------



## AlanB (Abr 7, 2015)

D@rkbytes como va! 

Increiblemente, el codigo no funciona, tenia mis modulos rf defectuosos y lo que parecia que tomaba mis funciones no era mas que puro ruido en el receptor, hoy compre unos modulos nuevos y ademas me compre unos ht12e/d para hacer unas pruebas con los modulos y es ahi cuando me doy cuenta que los modulos no funcionaban, inmediatamente reemplace los modulos defectuosos por los nuevos y me doy con que el codigo no funciona 

Mañana probare reprogramar nuevamente los pics para ver si el error es de programacion y sino nuevamente a ponerme con el codigo...

Saludos!


----------



## D@rkbytes (Abr 19, 2015)

Hace unos días compré unos módulos de R.F pero no había tenido tiempo de hacer pruebas.
Y efectivamente comprobé que los programas no funcionaban correctamente.
Realicé algunos cambios y ahora ya funcionan perfectamente.

Éstos son los módulos que compré:  Muy económicos, por cierto.

Y estas son las características del emisor: (Del receptor *XY-MK-5V *no encontré información)
*FS1000A  433Mhz TX Module*


Wide input supply (2.5 V to 12V)
Easy to integrate (V+, GND and Data)
Device in deep sleep mode when Data pin is          grounded
Very small dimension


También compré un HT-12E y un HT12D para experimentar un poco. 

Adjunto los programas con los cambios y funcionando perfectamente.

Nota:
Los programas fueron probados con 2 PIC12F629 y también con 2 PIC12F675
El baudrate lo dejé en 2400 aunque los módulos que usé soportan hasta 9600 Bps.


----------



## AlanB (May 1, 2015)

Gracias D@rkbytes, tuve unos problemas personales razones por la cual me ausenté en estos días... Ya lo descargué para mañana hacer pruebas 

Muchas gracias como siempre, vi que comentaste todo el code  muchas gracias por eso tambien!

Saludos, AlanB!


----------



## AlanB (May 26, 2015)

Amigo D@rkbytes quedó funcionando a la perfección, al principio tuve problemas pero al reemplazar mis módulos rf nuevamente quedo totalmente funcional, seguramente se me dañaron con las pruebas o a lo mejor ya vinieron mal...

Gracias, AlanB!

PD: La verdad aprendí mucho con este proyecto


----------



## loisck (Feb 19, 2016)

hola para todos
Amigo D@rkbytes quisiera saber si me puedes ayudar para la comunicación entre el pic12f675 como RX
y un arduino mega 2560 con TX, a través de modulos RF, aprovechando que a proteus se le puede agregar esta libreria nueva


----------



## D@rkbytes (Feb 19, 2016)

Saludos.
Sobre este mismo tema se encuentra toda la información que necesitas.
No uso arduino, así que no me será posible ayudarte en ese aspecto.


----------



## loisck (Feb 22, 2016)

ok gracias, otra duda con respecto al pic 12f675, y modificando tu ultimo programa no puedo programar el pic para que me de salida en el pin_a3 o GP3 con el

 "set_tris_a(0xC7);" //  11000111 GP3, GP4 y GP5 como salidas.

ni tampoco #use rs232(baud = 2400, rcv = pin_a2
con otro que no sea el pin_a2... no funciona

port_a_pullups(0x04);    // activa pull-up del bit 2,  "00000100" = 4 en decimal.


----------



## D@rkbytes (Feb 22, 2016)

En el transmisor no hay problema si se usa cualquier pin como Tx, menos GP3 que es únicamente entrada.
Y el receptor no va a funcionar con otro pin, porque se está usando la interrupción externa por GP2.
En ambos casos esto vendría siendo usando el oscilador interno para poder usar GP4 y GP5 (OSC2, OSC1)

Si quieres que la recepción sea por otro pin, tienes que hacerlo por poleo usando "kbhit()" dentro del bucle principal.


----------



## Gerson strauss (Feb 22, 2016)

Yo hice ese proyecto y funciona muy bien. Use pic 12f675 TX y un entrenador con PIC16F88 como RX, aunque se puede usar también otro 12f675 como RX. El lenguaje es PROTON , pero no utilice ninguna interrupción.

Le puse antena de 16cm a los modulos de RF y el alcance a campo abierto es de unos 80 mts. Ahora intento enviar datos flotantes para hacer un termómetro inalambrico.

Saludos.


----------



## egyr (Jul 4, 2017)

Hola D@arkbytes, me he quedado gratamente sorprendido de lo bien que manejas la programación y lo claro y acertado que eres en tus respuestas.

He estado revisando la info de este proyecto del PIC12f675 para comunicación serial, pero la verdad me perdí en la ultima parte en la que envías el código con comentarios, la pregunta es porque en el modulo del transmisor usas 2 pines Pin_A4 y Pin_A5. Si para el Modulo solo necesitas 1 pin de entrada de datos.


----------



## D@rkbytes (Jul 4, 2017)

Saludos.
GP4 y GP5 (PIN_A4 y PIN_A5) respectivamente, son las entradas de los pulsadores.
Uno manda la instrucción para encender el LED (GP5) y el otro para apagarlo. (GP4)


----------



## egyr (Jul 6, 2017)

D@rkbytes, gracias por la respuesta ahora me queda claro, yo venia con la mente pensando en mi propio proyecto en el cual yo solo empleaba una entrada y envío de diferentes códigos ..

Yo, aun cuando he programado en "C", estoy empleando Para PIC, AVR y otros, el compilador de OshonSoft Compilador en Basic, el cual me parece muy poderoso y amigable, que genera codigo muy compacto.
Cuando termine mi proyecto lo compartiré en el foro..
UNa vez mas gracias..


----------



## wolfbitt (Nov 24, 2017)

Gerson strauss dijo:


> Yo hice ese proyecto y funciona muy bien. Use pic 12f675 TX y un entrenador con PIC16F88 como RX, aunque se puede usar también otro 12f675 como RX. El lenguaje es PROTON , pero no utilice ninguna interrupción.
> 
> Le puse antena de 16cm a los modulos de RF y el alcance a campo abierto es de unos 80 mts. Ahora intento enviar datos flotantes para hacer un termómetro inalambrico.
> 
> Saludos.



Hola amigos.. alguna novedad sobre el Termometro inalambrico que comenta el compañero Gerson
es justo lo que estoy necesitando
saludoos



Estoy trabajando en mi proyecto final para Mecatronica y este se trata de un sensor inalambrico por RF..!!
en el cual utilizo un LM35 , 2 PIC 16F877a , una pantalla LCD 16x2 y los modulos RF 418 MHz.


----------



## Gerson strauss (Nov 24, 2017)

wolfbitt dijo:


> Hola amigos.. alguna novedad sobre el Termometro inalambrico que comenta el compañero Gerson
> es justo lo que estoy necesitando
> saludoos
> 
> ...



¿Y puedes mostrar lo  que has hecho hasta ahora?.


----------



## wolfbitt (Nov 27, 2017)

Hola Gerson.. gracias por responder!!

El proyecto es algo simple. 

TRANSMISOR
Con un sensor LM35 mido la temperatura ambiente, este esta conectado a una entrada analogica del ADC del PIC 16F877a, luego envio los datos de manera serial al modulo RF TX. 

RECEPTOR
El modulo RF RX recibe la transmision, aqui el segundo PIC 16F877a recibe los datos y completa el acondicionado de las variables de lectura e imprime la temperatura sensada en una pantalla LCD 16x2. Tambien se incluye el control de un rango de trabajo manipulando 2 salidas del puerto B, las cuales se conectan y simulan con un LED ROJO y un LED AZUL para subir o bajar la temperatura segun lo requieran los limites definidos en el rango.

Hasta el momento he avanzando al punto de hacer funcionar el proyecto pero transmitiendo mediante un cable, al conectar los modulos RF la lectura toma valores aleatorios.

Segun entiendo esto se soluciona con la programacion adecuada de la transmision serial (lo que he hecho es muy basico) donde me estaria faltando implementar un encabezado para una lectura correcta del RX y un protocolo de comunicacion. En este punto seria donde necesito ayuda y alguno consejos ya que me ha costado un poco la codificacion de ellos. 

P/D. Es una condicion del Profesor realizar la programacion en Proton IDE

A continuacion dejo los programas que he elaborado e imagen del circuito en Proteus con los cuales he logrado que funcione la transmicion mediante un cable tanto en la simulacion como en la protoboard.

vengo trabajando hace un tiempo en el proyecto y aqui estoy algo estancado.. jeje
Desde ya agradezco cualquier ayuda ya que no soy experto en el tema.

Mi nombre es Alejandro.. Saludos amigos!!

TRANSMISOR


```
Device = 16F877A                'DESIGNAMOS EL PIC A USAR
Xtal = 4                        'CRYSTAL A USAR
    
        'PARAMETROS DEL ADC
    
Declare Adin_Res = 10           '10-BITS DE RESOLUCION.
Declare Adin_Tad = FRC          'RC OSC ELEGIDO
Declare Adin_Stime = 50         'TIEMPO DE MUESTREO CADA 50 uS

        'CONFIGURACION DEL PUERTO SE COMUNICACION SERIAL
        
Hserial_Baud = 2400         ' VELOCIDAD DE SISTEMA A 2400 BAUDIOS
Hserial_RCSTA = %10010000   ' HABILITAR LA RECEPCION CONTINUA
Hserial_TXSTA = %00100000   ' PERMITE TRANSMITIR Y MODO ASINCRONO 
Hserial_Clear = On          ' BORRA EL BUFFER ANTES DE RECIBIR

        'DEFINO PUERTOS 

TRISA.0 = 1                      'PIN A0 COMO ENTRADA
TRISC = 0                        'PUERTO C COMO SALIDA
TRISC.6 = 0                      'PIN C6 COMO SALIDA TX
ADCON1 = %10000000               'DEFINO LA ENTRADA ANALOGICA

Clear PORTA                     'LIMPIA EL PUERTO A
Clear PORTB                     'LIMPIA EL PUERTO B
Clear PORTC                     'LIMPIA EL PUERTO C
Clear PORTD                     'LIMPIA EL PUERTO D
Clear PORTE                     'LIMPIA EL PUERTO E

        'DECLARO VARIABLES Y ALIAS
        
Dim MEDICION As Word     

DelayMS 10

INICIO:
         
        MEDICION = ADIn 0       'LECTURA DE LA ENTRADA ANALOGICA 
        DelayMS 100
                     
        HSerOut [MEDICION]      'ENVIO DATOS    
        DelayMS 100
                
GoTo INICIO

End
```


RECEPTOR


```
Device = 16F877A                'DESIGNAMOS EL PIC A USAR
Xtal = 4                        'CRYSTAL A USAR
    
        'DECLARACION DEL LCD
        
Declare LCD_Type 0              'DECLARAR TIPO DE LCD ALFANUMERICO.
Declare LCD_DTPin PORTD.4       'DECLARAR EL CONTROL EN PINES D4; D5; D6; D7.
Declare LCD_RSPin PORTD.0       'DECLARAR RS EN PIN D0.
Declare LCD_ENPin PORTD.1       'DECLARAR E EN PIN D1.
Declare LCD_Interface 4         'INTERFAZ DE 4 LINEAS 
Declare LCD_Lines 2             '2 LINEAS DE ESCRITURA DEL LDC

        'CONFIGURACION DEL PUERTO SE COMUNICACION SERIAL

Hserial_Baud = 2400         ' VELOCIDAD DE SISTEMA A 2400 BAUDIOS
Hserial_RCSTA = %10010000   ' HABILITAR LA RECEPCION CONTINUA
Hserial_TXSTA = %00100000   ' PERMITE TRANSMITIR Y MODO ASINCRONO 
Hserial_Clear = On          ' BORRA EL BUFFER ANTES DE RECIBIR

         'DEFINO PUERTOS 

TRISB = 0                        'PUERTO B COMO SALIDAS
TRISD = 0                        'PUERTO D COMO SALIDAS
TRISC.7 = 1                      'PIN C.7 COMO ENTRADA RX

Clear PORTA                     'LIMPIA EL PUERTO A
Clear PORTB                     'LIMPIA EL PUERTO B
Clear PORTC                     'LIMPIA EL PUERTO C
Clear PORTD                     'LIMPIA EL PUERTO D
Clear PORTE                     'LIMPIA EL PUERTO E
        
        'DECLARO VARIABLES Y ALIAS

Dim MEDICION As Word        
Dim TEMP As Float 
 
Symbol BLUE = PORTB.2
Symbol RED = PORTB.1

Print 254,64,%00000110,%00001001,%00001001,%00000110,0,0 ,0,0   'DETERMINO EL SIMBOLO GRADOS   


Cls                                'LIMPIO LCD

        'TEXTO DE PRESENTACION 

      Print At 1,1,"    PROYECTO    "    'PRIMERA FILA (MAXIMO DE LETRAS 16)
      Print At 2,1,"  MECATRONICO   "    'SEGUNDA FILA (MAXIMO DE LETRAS 16)
      DelayMS 2000

      Cls                                
      DelayMS 500
      
      Print At 1,1,"   CONTROL DE   "
      Print At 2,1,"   TEMPERATURA  "
      DelayMS 2000

      Cls
      DelayMS 500
     
INICIO:
        HSerIn [MEDICION]                   'RECIBE DATOS RS 232
        
        TEMP = MEDICION * 5/1024            'ACONDICIONADO DE LAS VARIABLES
        TEMP = TEMP * 100

        Print At 1,1, "   TEMPERATURA  "    'IMPRIME TEXTO BASE
        Print At 2,1, "ACTUAL"

                    
        Print At 2,8,Dec1,TEMP,0            'IMPRIME VALOR ACONDICIONADO DE LA MEDICION
        Print "C" 
        
        If TEMP <= 25 Then                  'RANGO PARA EL CONTROL DE TEMPERATURA ENTRE 25 Y 30 GRADOS
        
            RED = 1  
            BLUE = 0
            
        End If
      
        If TEMP > 25 And TEMP < 30 Then
        
            RED = 0
            BLUE = 0
            
        End If
     
        If TEMP >= 30 Then
        
            RED = 0
            BLUE = 1
     
        End If 
        
        DelayMS 1000 
        
        
GoTo INICIO

End
```

--espero haber etiquetado bien los codigos jaja--


----------



## Gerson strauss (Nov 27, 2017)

Te falta definir los valores de los fusibles (fuses) en ambos programas.


----------



## wolfbitt (Nov 28, 2017)

Hola de nuevo Gerson..

Si, me faltaban los FUSES. Asique me puse a investigar y estudiar los mismos ya que mi conocimiento sobre ellos era muy pobre. Investigue en internet, revise la hoja de datos, el manual de proton y traduje algunos fragmentos, que estan en el PDF que adjunto abajo.!!

Los configure igual en ambos PIC de la siguiente manera.


```
Device = 16F877A                'DESIGNAMOS EL PIC A USAR
Xtal = 4                        'CRYSTAL A USAR

Config XT_OSC, WDT_OFF, PWRTE_ON, BODEN_OFF, LVP_OFF, CPD_OFF, DEBUG_OFF, CP_OFF 'DEFINIMOS FUSES
```

En la simulacion funciona bien pero sigo sin tener buenos resultados en el circuito fisico, la lectura varia mucho.

Mi interpretacion del defecto (que cito abajo) en el programa es correcto??


> Segun entiendo esto se soluciona con la programacion adecuada de la transmision serial (lo que he hecho es muy basico) donde me estaria faltando implementar un encabezado para una lectura correcta del RX y un protocolo de comunicacion. En este punto seria donde necesito ayuda y alguno consejos ya que me ha costado un poco la codificacion de ellos.


O deberia buscar solucionarlo desde otro aspecto?? 

Abajo adjunto un PDF con informacion basica sobre los FUSES (BITS DE CONFIGURACION) del PIC16F877a y su configuracion en PROTON IDE. Por si le sirve de ayuda a algun colega.!!

Desde ya Gracias por la ayuda brindada..!!


----------



## ricbevi (Nov 28, 2017)

Hay varias cosas....la temperatura no cambia tanto cada 200ms(salvo usos muy específicos pero yo no usaría el LM35 para eso habiendo sensores digitales como el DS18B20) por los que puedes tomar mas de una medición y enviar el valor sumado o hacer el promedio en emisor y enviar este.
Si  no quieres medir cualquier cosa, las conexiones entre el LM35 y el micro controlador debe estar lo mas cerca posible para evitar "antenas" que capten interferencias electromagnéticas de todo tipo.
Saludos.

Ric.


----------



## D@rkbytes (Nov 28, 2017)

wolfbitt dijo:


> En la simulación funciona bien pero sigo sin tener buenos resultados en el circuito físico, la lectura varia mucho.


Eso es por el ruido que recibe el módulo receptor.
Por eso durante el tema se ha hablado de usar una codificación y se trató el algoritmo Manchester.
Hace poco subí un ejemplo en PICBasic, el cual fácilmente podrás migrar a Proton Basic.
_*Manchester CODEC*_


----------



## Gerson strauss (Nov 30, 2017)

Lo que yo haria es:

1- Usar un amplificador operacional en modo seguidor de tensión, entre el LM35 y el PIC. 
2- En el programa del transmisor haria un promedio de las lecturas del ADC y toda la matemática, para enviar solo el resultado al receptor.
3- Para enviar usaría (ejemplo): *RSOut "wolfbitt",Dec MEDICION*   en donde wolfbitt seria la "codificación".
4- Para recibir usaría (ejemplo):  *RSIn Wait("wolfbitt"),Dec MEDICION*
5- Usar condensadores de desacoplo (100nf) en cada PIC, modulo de RF y LM35, lo mas cerca de la alimentación.

Así lo he hecho y siempre ha funcionado. ¡Buena suerte!.


----------



## wolfbitt (Dic 1, 2017)

Hola de nuevo, amigos. Aquí sigo en la búsqueda de hacer funcionar mi termómetro.

Muchas gracias a todos por sus consejos, gracias a cada uno de ellos voy avanzando un paso mas y aprendiendo muchísimo.

La precisión del proyecto no es muy importante ya que es de tipo didáctico, así que supongo que el LM35 funcionara bien.

En cuanto a la Codificación Manchester, he estado leyendo, aprendiendo sobre ella e incluso la implementé en uno de los ejemplos y funciona muy bien, luego la subiré.

Abajo adjunto un PDF que descargué de aquí mismo pero traducido.
Codificación Manchester usando RS232
Como verán, no se me da muy bien el inglés y debo traducir todo. jejeje.

También he implementado los condensadores de desacoplo.

Ahora me surge otra pregunta y es sobre el uso de Rsout y Rsin.

Según encontré y entiendo que estas funciones necesitan que el WATCHDOG esté activado para funcionar.

Entonces al definir los FUSES, el problema: Si lo activo WDT_ON el dispositivo se reinicia constantemente.
Pero si no activo el WDT_OFF, las directivas Rsout y Rsin no funcionan, no se comunican.   

¿Me podrían explicar el modo en el configurar estas directivas?

Como siempre, muchísimas gracias por su ayuda, amigos.

Saludos.


----------



## Gerson strauss (Dic 2, 2017)

wolfbitt dijo:


> Ahora me surge otra pregunta y es sobre el uso de Rsout y Rsin.
> 
> Según encontré y entiendo que estas funciones necesitan que el WATCHDOG esté activado para funcionar.
> 
> ...



En mi caso funciona bien sin el WDT_ON. Hay que hacer algunas declaraciones para que funcione correctamente. Consulta el manual de PROTON; es lo que yo hago.


----------



## ricbevi (Dic 2, 2017)

Necesitas tener el WDT_OFF  y no se para que usas el comando Rsin o Rsout(comunicación serie por software) si tienes un PIC con hardware para hacer Hrsin y Hrsout y ya estas usando los pines donde esta. 
Recuerda que la ayuda que trae el  "Proton" es tu mejor amiga!!!.
Saludos.

Ric.


----------



## wolfbitt (Dic 4, 2017)

Gracias por responder amigos..!!

He estado leyendo y estudiando sobre comunicacion serial por software y por hardware.. Con ello sigo en mi camino de aprendizaje..!! jeje
Desde luego siempre tengo en mano el manual de Proton y la hoja de datos de Pic.. Pero hay algunas cosas que me cuesta entenderlas, pero bueno, asi se aprende mas!!

Ahora queria contarles sobre algo muy extraño con mi trabajo..!!

Realice varias pruebas con distintos programas en los cuales incluyo Codificacion Manchester y encabezados en los envios!!

Al no incluir un encabezado las lecturas toman valores aleatorios, pero si lo hago la pantalla LCD se queda en blanco(no hay lectura), aqui es donde viene lo extraño para mi, cuando desconecto el emisor TX (lo des-energizo) en la pantalla LCD se muestra un valor exacto de temperatura ambiente, he realizado esto varias veces y corroborado con un multimetro..!!

P/D: las pruebas son en serie mediante un cable.

No comprendo porque se envia correctamente solo al "apagar" en emisor.
Las conclusiones que saco de esto son: 
- La configuracion y matematica del ADC es correcta, pues en el momento que se logra enviar se lee un valor totalmente valido de temperatura.
- La Codificacion Manchester es correcta tambien, la probe individualmente y funciona (si no lo fuese el valor de temperatura se veria modificado).
- El encabezado cumple su función de filtrado, evita las lecturas erroneas hasta que llega el valor correcto y luego muestra un valor valido de Temperatura.

Lo que no comprendo es porque solo sucede esto al apagar el circuito emisor.. pienso que es algo simple pero vital..!!     

He revisado toda mi programacion, Fuses, Declares de comunicacion Serial, comandos y directivas usadas. Pero aun sigo sin corregir ese defecto ni comprender porque sucede.

P/D: Supuse que podia estar dañado el Cristal pero lo remplace con uno de repuesto y nada..!!

Espero que alguien pueda brindarme algo de luz y orientarme hacia que aspecto enfocarme..!!

Como siempre Muchisimas Gracias por cualquier ayuda o consejo!!

Saludos Colegas


----------

