Misterios con la Comunicación PIC- PC via RS232 (16F877)

[Tarumbar]

Bueno... resulta que etoy haciendo un "emulador" de LX200 (un protocolo y hardware que controla unas monturas de telescopio por PC a traves de unos sencillos comandos trasmitidos por el puerto serie.), y que en principio va bien .... con le programa de terminal. Me explico.

Usando la HiperTerminal o la termian del PicBasic, los comandos me van bien. Pero desde los programas comerciales que usan dicho protocolo, nmuchas veces, no huelen los comandos. Eso ocurre en conreto, cuando van dos o más commandos seguidos.... Para más inri, un ode dichos programas ,tiene un pseudo terminal para testear el puerto serie y resulta que mando un comando y no lo huele ... pero si despues del comando .. ENVIO CUALQUIER CARACTER responde al comando que en vie antes..... MISTERIOSO.....

Para inbvestigar, hice un programa eco (osea , lo que recibe, lo devuelve por el rs232)
y resulta que le envio un caracter y no me lo reenvia ... ahora escribo otro caracter .. y me envia el anteriro !!!!!! O_O ... Cosa rarra no ??

Alguno tiene idea que pasa ??

Posteo la configuracion del puerto serie q tengo en el pic :

8N1 a 9600 baudios

HSERIAL_BAUD = 9600         " Set baud rate to 9600
HSERIAL_RCSTA = %10010000      " Enable serial port and continuous receive
HSERIAL_TXSTA = %00100100      " Enable transmit and asynchronous mode - High Speed
HSERIAL_CLEAR = ON         " Optionally clear the buffer before receiving   


En el PC pongo el port a 9600 Baudios 8N1 y sin control de flujo.

PD: He usado HRSIN y HRSOUT y tambien probre con una rutina que usa los registros directamente ... y el mismo resultado...

[Artifox]

Bueno, no entiendo exactamente cual es el problema... Quien envia a quien?? supongo q PIC a PC... pues si es asi, de repente no te detecta bien cuando envias valores pequeños, por ejemplo 1, 2, ... 10 pues lee en la PC un caracter raro o un espacio en blanco, si es ese tu problema te recomendaria que a todos tus datos le agreges una constante osea si quieres enviar 1= const +1; la cual puede ser 10 osea envias al final 11....

No se si ese sea tu problema, pero en todo caso, explica un poco mejor como funciona tu programa...

[Tarumbar]

nono.....
La comunicaion es PC --> PIC .. y este responde...

Para más inri, hize un sencillo programa para investigar lo que pasa :

main:
   
HRSIN RSData
if RSData = ":" THEN
 HRSIN  RSData
  if RSData = "G" THEN " Interpreta los comandos G (get)         
          HRSIN  RSData      
       if RSData= "D"  THEN " Pregunta por la Declinación del telescopio

             if ModoFormato = 0 Then " Modo Corto                            
                 HRSOUT "+00:00#"     

             else " modo largo
                 HRSOUT "00*00:00#" " Contesta con 00*00:00# ya que no la sabemos
             endif
       endif      
   
       if RSData= "R"  THEN " Pregunta por la Ascension Recta del Telescopio            
             if ModoFormato = 0 Then " Modo Corto           
              HRSOUT "00*00:00#"           
         else " modo largo
            HRSOUT "00*00:00#" " Contesta con 00*00:00# ya que no la sabemos
           endif
        endif
  endif
endif

goto main   

Y hace esto :

Si en la terminal escribres un comando , letra a letra, te responde bien (es #:GD# y #:GR# ). Si escribes un comand ode un tiron (osea pegandolo del portapapeles) tambien lo ahce bien.
Ahora cuando escribes dos commandos seguidos del tiron (pegandolo desde el portapapeles) , solo me responde al primero.

Pero creo que ya se pq es. Caundo huele el primer comando, psa a ejecutar el HRSOUT y por l otanto, el tiempo en que lo esta ejecutando, como mucho puede recibir dos bytes de datos, con lo que se pierde el resto de datos y por eso no se entera del segundo comando.
La solución que se me planeta es , usar las interupciones prar recibir y mandar datos (o lamenos solo para mandar) en un buffer. Asi, podria trabajar en una pseduo multitarea y recibir y mandar datos al mismo tiempo.

Asi creo que podria solucionar almenos parte del problema.
Si alguien tiene una idea mejor o algun consejo...

[Artifox]

Ahhhhhhhhh si es de esa manera, lo mejor que puedes hacer es utilizando interrupciones, pues por software no es bueno recibiendo mucha data...
Bueno, por lo menos me alegro que ya sepas que hacer....

Nos vemos y un abrazo...

[RALF2]

Que tal mi pana tarumbar!
Que compilador estas utilizando, para hacer el programa, pic basic pro???
De que frecuencia es el cristal que le tienes conectado al pic?

Una cosa mas el hserin al recibir los datos tiene que irlos leyendo rapidamente, porque si recibe tres o mas datos consecutivos este se cuelga y una forma de resetearlo es agregando el define
DEFINE HSER_ CLROERR    1

Hay que tener en cuenta la velocidad del cristal para ver si este no introduce mucho error en el calculo del baud rate, por eso te pregunto por la velocidad del cristal que estas utilizando, ya que, dependiendo de la velocidad a la cual quieres transmitir los datos debes utilizar el cristal adecuado asi como la debida configuracion del registro txsta.

Saludos!