UART PIC

[superprp]

¿porque me deja de enviar la UART cuando le recibe muchos datos??? alguien sabe a que puede ser debido o como solucionarlo?
el bit de OERR se me activa y lo borro por software, no entiendo porque se activa ya que en la rutina de atencion a la interrupcion leo el dato y salgo y trabajo a 20MIPS no debería saltar ya que no desborda (no se porq otra razon se puede activar este bit) aun así funciona bien, excepto algunos momentos que pierde algun bit o byte, ¿ideas?

[issac_itd]

Hola que tal

soy nuevo pero espero poder ayudarte

que pic estas usando???

a 20 MIPS (millones de instrucciones por segundo) correcto??

osea que usas un PIC de 80 MHz??

y pues el bit OERR puede ponerse a 1 logico debido a varias razones

una de ellas puede ser que el PIC no alcanza a leer la informacion que le llega al registro RCREG (en mi caso que uso el PIC 16f877A) que le estas mandando

necesitaria saber tambien si trabajas en asincrono o sincrono

[superprp]

en modo asíncrono, el microcontrolador usado es el dsPIC30F4013, y está funcionando a 80Mhz como bien dices con un reloj de 10Mhz y un PLL x8

[superprp]

Otra cosa curiosa que me pasa es que envio con el PIC por la UART un 0xaa (10101010) y algunas veces me muestra en el PC un 0x8a, es decir, me cambia un bit, el quinto, si envío un 0x30, algunas veces se me muestra un 0x20, es decir, me cambia el cuarto bit, y lo mas curioso de todo es que enviando un 0xff o un 0x00 lo envia perfectamente todas las veces. De código no es porque la configuración es la misma que he usado otras veces y está perfectamente, la placa que toy usando es diferente a la que he probado otras veces (identica pero tengo dos iguales) puede ser tema del microcontrolador? o del max232?

[Javicho]

A cuantos baudios comunicas? prueba con 9600 baudios es una buena velocidad, para evitar ese tipo de errores deberias enviar/recibir usando el bit de paridad, para así bajar las posibilidades de error en la transacción de los datos.

Javicho.

[superprp]

57600, pero en principio no debería dar tantos problemas... no?

[Javicho]

57600, pero en principio no debería dar tantos problemas... no?

57600 es mucha velocidad, tambien me ha pasado eso, a menos que lo mandes con el bit de paridad como te comente en el post anterior, bajale a 9600baudios y si aun asi tienes problemas trata de filtrar mejor tu fuente de alimentación o apantalla el cable que usas para conectar con la PC para aminorar el ruido, tambien prueba con un cable mas corto.

Javicho

[superprp]

Pues tengo que subir la velocidad a 115.000 por lo menos, porque los paquetes que tengo que enviar y recibir son de 80 bytes y se reciben y se envian y con una periocidad de 3 paquetes de estos cada segundo aprox.

[Javicho]

Si son 3 paquetes de 80bytes ... entonces hablamos de 240bytes por enviar, a 9600baudios 1 byte (con bit de inicio y stop) te toma en enviarlo 1.04mS para los 240bytes todo te demoraria tan solo 249.6mS que esta lejos de 1seg.

Cuando tengo que enviar/recibir a esas velocidades implemento un software y gestiono la transacción por tramas de 32bytes o hasta 64bytes máximo con paridad y checksum asi los datos llegan muy bien y al final hago la verificación (si es que el sistema lo permite).

Javicho.

[superprp]

a ésto se puede deber también la pérdida de paquetes de vez en cuando???? espero que se solucione así y poniendo un reloj de 14.7456 para clavar la velocidad al valor entero del PIC para los diferentes baudrate

[Javicho]

a ésto se puede deber también la pérdida de paquetes de vez en cuando????

Tanto como pérdida de paquetes no, mas bien como adulteración de los datos si, y es muy frecuente a esas velocidades.

Javicho.

[superprp]

¿a que se puede deber que enviando unos cuantos bytes seguidos (160bytes al segundo) deje de recibirme la UART del pic pero sin embargo siga enviando por el pin de TX el pic? ¿alguna forma para asegurarme de que nunca deje de funcionar?

[Javicho]

Hola

Seguramente tu buffer de recepción se ha llenado y hay unos bits de error que han bloqueado la recepción, para que puedas seguir recibiendo mas datos debes limpiar por soft estos bits, leelo en el datasheet está todo.

Para que asegures deberias recibir los datos por interrupción y sales rapidamente antes que vaya a alllegar otro dato.

Como el USART es full duplex puedes enviar y recibir al mismo tiempo, la parte de transmisión no se pelea con el de recepción, son como 2 bloques separados, pero igual antes de transmitir un byte debes asegurar que el byte anterior ya se transmitió para eso hay un flag que te indica cuando el buffer de transmisión esta vacio y listo para recibir tu nuevo dato a enviar.

Te recomiendo que leas un poco mas el USART y varias veces, no se que pic estas usando creo que un dspic no se que tan detallado esté ahi porque tal vez microchip no detalle mucho estas cosas asumiendo que uno ya ha pasado por otros pics mas pequeños en donde si se detallan bien, en todo caso puedes leer el datasheet del pic16F628A ahi está muy bien explicado todo y te sacará todas tus duduas.

Que te vaya bien.

Javicho.

[superprp]

Tengo activa la interrupción por RX, y funciona perfectamente, pero cuando envio bytes hacía el PIC, no se debido a que, imagino que porque cuando le envio datos son una burrada de datos, sobre 160bytes por segundo, éste me deja de interrumpir por RX, compruebo los bits de FERR y de OERR en el main y los reseteo si saltan, también compruebo el flag de interrupción por si se activa y no puede atenderla que lo borre para que pueda interrumpir de nuevo la siguiente vez, por lo que no se la razón por la cual deja de interrumpirme en la recepción

[Javicho]

Solo la recepción es el problema o el PIC en general se queda bloqueado? tal vez hay un proceso que hace que el pic se bloquee por otro lado y desactiva la interrupción, tal vez en algún momento en el tratamiento de interrupciones te demores mas de la cuenta y llegaron muchos datos y el bufer se llenó, prueba leyendo 3 veces el registro RCREG para vaciar bien el buffer de recpción y continuar recibiendo a parte de haber borrado los flags señalizadores.

Porque no implementas un contador de bytes recibidos asi veras en que momento sucede este bloqueo de recepción de mas datos, fijate si siempre se bloquea con el contador en el mismo valor. Prueba enviando este contador a la pc para que visualizes dicho valor.

Javicho.