Limitaciones de la USART con cristales "lentos"

[pollastre]

Buenas a todos,

como parte de un proyecto, tengo un PIC16F648A comunicandose con dos puetos serie, pertenecientes a dos dispositivos diferentes. Uno de ellos funciona a 4800bauds, y el otro a 115200 .  (la línea RX del PIC está multiplexada para permitir "escuchar" alternativamente a los dos dispositivos según el momento que sea).

Con el primer dispositivo, el de 4800, no tengo problema ninguno para recibir informacion en mi USART (este dispositivo solo me permite recibir, no admite que se le envíen datos).

Con el de 115200 sin embargo no he conseguido echarlo a andar (por cierto que este dispositivo sí admite tanto recepción como transmisión). La duda que me surge es si quizás es demasiado pedir una comunicacion a 115k usando un cristal de 4Mhz, no sé si el PIC irá algo "justo". Desde luego el datasheet da a entender que lo soporta, aunque eso sí, casi al límite ( SPBRG = .1 , mode = HIGH ) .

Para intentar ver un poco mejor el tema, he "pinchado" las lineas RX y TX, sacandolas a traves de un max232 y un db9 para poder "espiar" con el hiperterminal lo que se va transmitiendo ( RX_db9--->PIC_TX,  TX_db9--->PIC_RX)  .

Hecho esto, intento transmitir una pequeña cadena de texto a través del TX del PIC, y efectivamente aparece texto en el hiperterminal, pero completamente desfigurado, ningun caracter coincide ni por asomo con la cadena que envié desde el PIC.

Entonces, esto podría ser....

1)  la USART mal inicializada... me extraña porque ya vengo de conseguir que funcione perfectamente en el caso del otro dispositivo, el de 4800bauds
2)  cristal de 4Mhz demasiado "justo" para comunicarse a 115k ? Quizás deberia probar con uno de 16Mhz ?


muchas gracias por vuestras opiniones,

Pollastre

[maunix]

pollastre , ¿cómo has logrado los 115200 con un cristal de 4Mhz?

En comunicaciones rápidas, un error de < 5% o 3% es totalmente aceptable y no debiera acarrearte problemas.  El punto es que con ese clock no me dan los cálculos para 115200 o similar.

Generalizar no es bueno y pensar en que un XTAL de baja frecuencia no permite un baudeaje rápido, es erróneo.  Todo depende la aplicación y del "data rate" que quieras usar.  Paso a explicar.

Con un pic a 4Mhz puedes hacer comunicaciones a 250.000bps! El tema es que tu pic estará muy forzado cuando quiera 'leer' datos a esa velocidad.  Para transmitir no es tan así porque mandas un dato y tu software sigue lo que estaba haciendo (o no) y luego mandas otro dato y así sucesivamente.

La recepción es más complicada porque uno "no sabe cuando vendrá".

Con esto espero haber aclarado que un XTAL lento no significa que el Módulo Usart tenga limitaciones, sino que las limitaciones suelen estar en el PIC para procesar todo ese flujo de datos.

[pollastre]

Hola Maunix,

pues los 115k2 los he configurado segun el datasheet ( DS40044D, pagina 76 ), donde muestra varios de los modos de configuracion de la USART para el 16f648A, en concreto hay uno que es el que me interesa :

BRGH = 1  ( high speed )
Baud Rate = 115200
Error = 8.507%
SPBRG = 0x01


el caso es que el puerto serie del otro integrado está fijado a 115k2 , y no puedo reducirlo. Y de momento no tengo demasiada suerte en que se "hablen" correctamente....

Pollastre

[maunix]

Hola Maunix,

pues los 115k2 los he configurado segun el datasheet ( DS40044D, pagina 76 ), donde muestra varios de los modos de configuracion de la USART para el 16f648A, en concreto hay uno que es el que me interesa :

BRGH = 1  ( high speed )
Baud Rate = 115200
Error = 8.507%
SPBRG = 0x01


el caso es que el puerto serie del otro integrado está fijado a 115k2 , y no puedo reducirlo. Y de momento no tengo demasiada suerte en que se "hablen" correctamente....

Pollastre

Un 8,5% de error es algo significativo.  Todo depende también de la 'tolerancia' que tenga el otro extremo a estas cosas.

Un módulo usart en modo asíncrono trabaja con muestreos a 16 o 64 veces la velocidad del baudeaje.  Esto hace que no siempre se tome una muestra "correctamente".

En tu caso, es difícil baticinar cual sea la causa porque el otro lado no lo controlas tú.  Lo que sí te puedo asegurar es que si de ambos lados pones 2 pics con misma configuración de usart, se comunicarán bien por más que sea 125.000 bps (el valor no estadard al que se comunicará el módulo usart con la configuración que has elegido).

En tu caso, yo cambiaría el cristal por uno que te permita un baudeaje más próximo a los 115200 y luego a partir de ahí comenzar las pruebas.

Tal vez también tengas algún bug en el software, y si programas por ejemplo en C puede que pierdas bytes porque no le das tiempo al PIC a que procese todo, ya que el código en C para los 16F dista de ser lo óptimo que pudieras lograr con ensamblador y si por ejemplo, usas interrupciones o bien tu bucle de lectura de usart es largo, bueno, de seguro perderás bytes.

Entonces, aumentar el clock te puede beneficiar en estas cuestiones.  Si conoces bien los "timings" de tu aplicación podrás comprender bien qué sucede.

Saludos

[pollastre]

la verdad, y ahora que repaso los distintos "error rates" en el datasheet con más calma, parece claro que un 8,5% puede ser suficiente para confundir a un terminal remoto (sobre todo si éste es sensible y está bien calibrado a 115k2).

Tambien deberia ser significativo, que el hiperterminal - configurado a 115200 - muestra esos "caracteres sucios" cuando la línea está pinchada directamente del TX del PIC  ( pic_TX -> max232 -> pc_RX ). Si al hiperterminal llega "ruido", parece claro que el PIC con el cristal de 4 Mhz no es capaz de "hablar" correctamente a 115k2... al menos no lo suficiente para el PC, desde luego, y parece claro que para el dispositivo en el otro extremo tampoco !

Asi que en primer lugar me voy a "agenciar" un cristal de 20Mhz, o incluso uno de 16 que me deja en torno al 3%, y ya posteo los resultados mañana.

gracias por las sugerencias!

pollastre,

[maunix]

Coincido, creo que cuando pasan los problemas hay que buscar y "separar" la causa.  Para ello se debe ir probando parte por parte para así poder determinar la razón del problema.

Tal vez consigas los 115200 clavados y el hiperterminal te los siga mostrando mal, tal vez por un firmware no del todo depurado o tal vez porque el buffer de usart de la PC se llene ante que el hiperterminal pueda mostrar los datos.

Saludos

[pollastre]

bueno, pues creo que el tema está resuelto ya. Dos cosas he descubierto (de momento)

la primera es que un 8,5% de error rate parece haberse demostrado que es, efectivamente, "demasiê" para el body. He probado a bajar el PIC a 4800 bauds y a "escuchar" con la linea pinchada y el max232, y ahora efectivamente el PIC saca los caracteres que tendria que sacar, sin problema ninguno, aparecen en el hyperterminal perfectamente hablando y escuchando a 4800  (con un cristal de 4Mhz se puede hablar a 4800 con un error mínimo).

Asi pues, en primer lugar, a comprar cristal de 16 o 20Mhz para poder aproximar mejor los 115k2 en el pic.

Pero es que luego, al poder "espiar" ya lo que el pic transmitia, me ha permitido enterarme de rebote de otro problema, este ya en mi codigo. Al ser tan lenta la transmision (4800 baudios hace que entre char y char transmitido al pic le de tiempo de tomarse un café, copa y puro), cuando desactivo TXEN justo tras cargar el ultimo caracter en TXREG, todavía está en el TSR el penultimo caracter del string a transmitir, y en TXREG el ultimo, pero como he desactivado TXEN antes de que suceda la proxima transmision, se quedan colgados sin transmitir esos dos caracteres  en TSR y en TXREG    vamos,  que me "como" los dos ultimos caracteres, por lo que le he añadido una pequeña subrutina que comprueba, antes de desactivar TXEN, que se cumple que PIR<TXIF> = 0 y TXSTA<TMRT>=0 , a fin de que ambos queden vacios y no me deje en el camino los dos ultimos caracteres de la string.

desde luego que cada dia me gustan mas los PICbichos estos....

[maunix]

pollastre me alegro que hayas solucionado el problema y como habrás observado, lo resolviste luego de "separar" los problemas llevando la solución por partes a cosas "conocidas" o "manejables".

Lo del TXEN realmente te iba a fallar con cualquier baudeaje, y es a esto a lo que me refería con que no por cambiar el CLOCK lo ibas a solucionar si el problema era de firmware.

Te felicito y me pone muy contento de que lo hayas podido echar a andar, al menos a un bajo baudeaje, ya luego lo harás andar más rápido con el nuevo clock.

Saludos