TODOPIC
Microcontroladores PIC => Todo en microcontroladores PIC => Mensaje iniciado por: superprp en 28 de Julio de 2008, 05:35:57
-
¿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?
-
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
-
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
-
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?
-
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.
-
57600, pero en principio no debería dar tantos problemas... no?
-
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
-
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.
-
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.
-
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
-
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.
-
¿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?
-
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.
-
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
-
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.
-
Solo sucede en la recepción, en ésta tengo un while para leer datos mentras haya, ya que no creo que me lleguen datos mas rápidos de lo que tardo en leerlo. Uso dos indices, uno para leer datos y los guardo en un vector, y otro para enviar los datos.
Cuando llegan gran cantidad de bytes me deja de funcionar y el resto de interrupciones sigue funcionando, teniendo todas las interrupciones la mima prioridad, incluso dandole más prioridad a la recepción, alguna vez me a petado, pero ahora tb alguna vez, en lugar de la recepción deja de atenderme otras interrupciones como la del convertidor AD.
En las rutinas de interrupcion tengo el minimo código para que emplee el menor tiempo posible para que no intente atender a dos interrupciones a la vez, ya que si no una se la dejará sin atender y entonces ya deja de funcionar (creo que es lo que me está pasando, pero no lo entiendo porque a 20MIPS debería sobrarle tiempo para todo
-
No queda otra que hacer una busqueda exhaustiva del error, para ello debes probar muchas cosas hasta las que creas obvias pero igual pruebalas, con esto me refiero a lo siguiente por ejemplo dices que estas trabajando a 20MIPS, quizás por alguna razón por ahi tu pic esta trabajando a 10MIPS o quizas menos y por ello cuando sales de la interrupción llegaron mas datos, hazle un test simple con un led para que verifiques tu velocidad, otro punto seria por ejemplo verificar que la recepción de datos trabaja bien para ello desactiva todo lo demas y asi sucesivamente anda probando cada cosa si no tienes osciloscopio prueba con prender un led al pasar por puntos criticos en tu programa y al salir de la RSI lo apagas por ahi derepente el led se queda prendido y no se paga eso quiere decir que nunca salió del RSI entonces asi te vas dando cuenta por donde esta el problema ... es tedioso hacer esto pero es muy eficaz.
Javicho.
-
Tengo unas dudas sobre el funcionamiento de las UART, te comento:
Cuado tu pones putUART1(buffer); esto envia el vector buffer por el puerto serie, pero si el vector tiene 4 posiciones, y son de tipo char, quiere decir que envias 4 bytes, esto como se hace? se envian un byte y hasta que no se envien todos no sigue ejecutando instrucciones? lo pone en algun registro de envio y sigue realizando tareas el pic y eso se va enviando? como va exactamente?
Es que además de dejar de recibir datos cuando me llegan muchos a la vez, tengo un problema constante y es la pérdida de bytes, ya que el pic hace de puente (tiene dos UART) y lo que recibe por un sitio lo manda por el otro, extrañamente de los 80 bytes que le envio solo el 60% de las veces llega el mensaje completo, siempre se pierde un byte, y no siempre es el mismo
-
Bueno aun no he usado los dsPICs, pero hasta los PIC18 he visto que se mantiene la misma filosofia en cuanto al USART se refiere, es decir, antes de enviar un byte debes verificar que el buffer de transmisión está vacio, si mandas 4 bytes uno tras otro el buffer se va a llenar y no vas a poder enviar mas bytes, se bloquea.
Igual pasa con la recepción, si no lees a tiempo el buffer se llena y no recibe mas bytes, tambien se bloquea, por eso para evitar esto hay flags tanto para recibir como para transmitir que te indican en que momento puedes enviar el siguiente byte.
Intuyo que esta filosofia debe mantenerse aun en los dsPICs.
Javicho.
-
Hola gente me meto un poco, la filosofia del manejo de la UART sea el micro que sea es atravez de colas circulares, como te comentaron antes, cuando vos envias a transmitir un "string" o un buffer, se deberian copiar estos datos a la cola circular de transmicion y se activa la interrupcion correspondiente. Ahora cuando se genera una interrupción por registro de transmicion vacio, la funcion de bajo nivel verifica que exista algo para transmitir y lo pone en el registro de transmicion. Para darse cuenta cuanto tiene que transmitir usa dos indices uno llamdo Head ( cabeza ) y otro Tail ( cola ) la idea es que cuando son iguales es que se transmitio todo. La función que manda a transmitor ( puts ) incrementa el indice Head y el handler de interrupcion maneja el Tail.
Con respecto a la recepcion la idea es la misma, salvo que normalmente la interrupcion maneja el indice Head y la funcion que lee maneja el Tail. La condición de error Overrun es que entro otro caracter en el registor de recepcion antes de que el anterior haya sido leido, en ese caso como te comentaron tenes que tener en cuenta la velocidad en la que lees y el baud rate al que trabajas.
La explicación se refiere a una UART generica que se aplica a cualquier micro.
Saludos !
-
y cuando una UART deja de funcionar (ya sea porque deja de atender interrupciones, o porque hay algun flag de error activo) como puede hacer que funcione de nuevo? que bits son los indispensables que hay que volver a activar o borrar para que vuelva a funcionar?
Además, yo entiendo que la función putUART ya controla el envio de bits, yo simplemente los pongo y ésta función debe enviarlos todo, lo que no se es si ésta función puede llegar a saturarse (no creo, porque tampoco mando tantos bits, solo es al recibirlos)
-
Que tal amigos, estoy trabajando con el uart de un pic 16f877a, en este pic recibo una cadena de caracteres y de esta cadena necesito identificar ciertos caracteres que se encuentran por la mitad de la cadena, estoy programando con serin y serout pero esto funciona para un caracter y no se como guardar caractreres seguidos, alguien ha programado esto?, les agradesco mucho su ayuda...
Saludos
-
¿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?
El bit ese se podría activar o bien por ruido al encender el PIC o bien por algún desfasaje en los baudeajes (y cuando hablo de desfasaje hablo de más de un 5 o 10%).
Quisiera saber cómo es que borras el bit de OERR, tal vez allí tengas el problema.
Además revisa si tienes ruido en el canal de comunicación, cómo es el vínculo físico? es decir usas un cable? si es así es muy largo? es mallado?
Saludos
-
Que tal amigos, estoy trabajando con el uart de un pic 16f877a, en este pic recibo una cadena de caracteres y de esta cadena necesito identificar ciertos caracteres que se encuentran por la mitad de la cadena, estoy programando con serin y serout pero esto funciona para un caracter y no se como guardar caractreres seguidos, alguien ha programado esto?, les agradesco mucho su ayuda...
kdtguerrag por lo que comentas de Serin y Serout asumo que estas usando algún basic ¿no?
No he usado el basic para PICs, pero la idea general de cómo se resuelve en C, aplica para cualquier lenguaje ya que el problema no está en el lenguaje sino en que el PIC tiene un buffer pequeño para la usart de 2 bytes, del cual leerás uno por vez.
La idea es la siguiente, creas un arreglo o cadena en memoria y le vas agregando caracteres en la posición indicada por un contador.
Por ejemplo, te paso un pequeño listado de pasos, en ningún lenguaje en particular.
1. Contador = 0; Cadena = ""
2. Recibes un caracter
3. Cadena = Cadena + caracter
contador = contador+1
4. Recibes un caracter
5. Cadena = Cadena + caracter
contador = contador+1
...
...
y así sucesivamente , lo deverás hacer hasta que contador llegue a un valor límite que le impongas (tampoco puede ser muy grande ya que el pic tiene memoria limitada).
Tal vez en el foro de Basic haya alguien que tenga una solución específica para el problema, si te pasas por allí con la pregunta de seguro encontrarás una respuesta más puntual. :)
Saludos