Retardo en la comunicacion serial asincrona

[carmalcoz]

Saludos

estoy trabajando la comunicacion serial asincrona en un pic 16f877 usando el modulo USART con que cuenta este pic. La velocidad es de 9600 bps y el cristal es de 20 MHz.
la transmision es de 8 bytes por frame y espero confirmacion del pc si recibio bien estos datos.
Cuando monte el diseño en protoboard funciono bien pero ahora que lo pase a pcb debo meter un retardo de 2 ms
en la transmision entre byte y byte de lo contrario el pc no recibe todos los datos.

Es esto normal? o que puedo hacer. Un amigo me propuso que pidiera confirmacion del pc despues de cada byte, es necesario hacer esto?

Gracias de antemano por la ayuda que me puedan dar.

[Sispic]

Hola Carmalcoz .

Lo que no entiendo el por que al pasarlo a pcb debes meter un retardo de 2 ms si antes no hacia falta ..ummm.

Quiza ayas modificado la configuracion del usart del pic con respecto al cristal o del pc en algun valor .

Prueva a bajarle el tamaño del buffer de recepcion del pc para que atienda mas rapido .

Tambien te aconsejo que mandes un byte de cksum para grupo de datos que mandes , asi el pc sabra si los datos que recive son correctos y biceversa.

Algo tendras mal ya que 2 ms es vastante .
Suerte.

[RGL]

Este verano tuve que trabajar conectando una placa mía con PIC, con otra de otra persona con un winbond (arquitectura 8051). Esta comunicación la hacíamos con una red RS485 (que de cara al micro viene a ser lo mismo que la puerta serie salvo que hay que controlar el sentido de la comunicación, lo hacíamos en Half Duplex).

Bien, cuando yo hacía pruebas con dos Pic, aquello iba sin retardos ni nada y transmitía y recibía de vicio, pero cuando conecté mi placa con la windbond,  yo si leia bien pero la otra no recibía mas que el prime carácter, los demás los perdía. Poniendo un retardo de unos 5 milisegundos todo funcionaba bien.

Lo que no me cuadra bien es que con a misma herramienta el mismo circuito se comporte de manera diferente. No encuentro explicación para eso. Pero de de tener que poner un pequeño retardo es algo normal, además yo diría que es conveniente, pues tendrás más tolerancia  a los diferentes PC que puedas conectar tu PIC.

Saludos
Ricky

[carmalcoz]

Saludos y muchas gracias por atender mi duda. La verdad debo hacer una aclaracion, y es que en el ProtoBoard igualmente necesitaba el retardo en la comunicacion. Yo pense que era problema del mismo protoboard y las altas frecuencias.
Asumi que una vez mi circuito montado en un pcb me evitaria ese problema, pero no.
Los registros para la comunicacion estan bien configurados (TXSTA, SPBRG) para 20Mhz y 9.6Kbps en velocidad. Aplico el retardo y la comunicaion funciona pero sin el se pierden uno o dos bytes de la trama
-> [Head][D0][D1][D2][D3][D4][CRC][CRC]
Sin embargo, mi codigo PIC no hace la transmision por interrupcion TXIE sino por polling de la bandera TXIF, sera que eso? sera que la frecuencia del cristal es muy grande? sera, como dice RGL, es valido utilizar esos retardos? pero que pasa si cambia la longitud del cable o la temperatura ambiente cambia?  
Nuevamente gracias de antemano por su ayuda.  

[jorgeansuini]

Buenas:

Alguna vez hice un probador de enlaces serie y realmente era el puerto del PC el que no recibia la trama del mensaje completa,por lo que tuve que agregar un pequeño retardo entre caracteres, lo que es bastante normal .-
Aqui me parece que pasa lo mismo, no es problema del pic sino de la recepción, quizás del soft de comunicaciones que tenes en el pc, pero te repito, es normal dejar un pequeño espacio entre la transmisión de caracteres, inplusive en picbasic hay un define con esta función.-

Saludos
Jorge

[carmalcoz]

Saludos amigos, halle una solucion muy practica, en lugar de estar chequeando la bandera TXIF chequeo la bandera TRMT que se pone en 1 cuando se ha desocupado el registro TSR, es decir, cuando ya el cable "esta libre" y no hay necesidad de ningun retardo.

Gracias por los consejos y quedamos pendientes

[_Canito_]

Hola a todos.

Yo tuve el mismo problema al diseñar una interfase RS232.

Después de mucho investigar descubri que era problema de la PC. En realidad de VB, creo en C esto no ocurre.

Independientemente de la velocidad de cristal del micro, la PC "perdia" 1 byte cada 3 enviados.

Lo solucione aumentando el buffer de recepción, por lo menos al doble de la cantidad de datos a enviar.

Espero que te sirva.

un saludo
Canito