TODOPIC
Microcontroladores PIC => Lenguaje C para microcontroladores PIC => Mensaje iniciado por: J1M en 18 de Febrero de 2008, 20:17:17
-
Hola!
Os pongo en situación, he hecho un pequeño trasto mediante el cuál:
- Conecto el PC al PIC mediante Bluetooth.
- Conecto el PC al PIC mediante USB CDC
Qué hago?
- Abro los puertos COM de Bluetooth y USB CDC con el hyperterminal.
- Escribo un dato en el COM del BlueTooth y el PIC automáticamente lo envía, mediante una interrupción, al COM del USB.
El código que hace eso: (un extracto de un programa más grande)
#INT_RDA
void rda_isr(void)
{
temp=0;
temp=fgetc(blue);
printf(usb_cdc_putc,"%c",temp);
}
La variable 'temp' es un char. Y 'blue' es el string para el COM del Bluetooth, ya que tengo por ahí también un 485.
El problema es que obtengo esto:
(http://img90.imageshack.us/img90/4218/dudawf6.jpg)
Hasta donde he llegado al analizar el problema:
Puedo enviar un carácter como máximo 2 veces, la tercera vez que lo envío pasa lo que se ve en la imagen, y a continuación ocurre una de cada dos veces. Me he imaginado que era un problema con los bits... y este es el código binario de los caracteres ascii:
q: 01110001
±: 11110001
Como veis la diferencia entre ambos caracteres es un bit, y no que falte, sino que se añade. Eso me ocurre siempre y con cualquier carácter. Se os ocurre cual puede ser el problema?
Gracias y un saludo!
-
algo asi me paso tambien a mi, y era cuestion de tiempos, parece que la PC no soportaba que le mandara el carcater muy rapido asi es que puse un tertado entre los caracteres y ajuste el tiempo a lo minimo necesario para que no me robe mucho tiempo y se soluciono el problema, puedes hacer la prueba enviando un caracter-retardo-caracter-retardo y asi ajustar el retardo necesario, para despejarnos las dudas :mrgreen:
-
no creo sea problema de tiempos pero vamos. Los caracteres los introduzco a mano, por lo que el retardo en principio es grande. He probado a dejar el dedo pulsado y a introducir uno cada ~3segs.. y nada ;)
-
Bueno, eso de 921600 8N1 suena un poco surrealista. Has probado a configurar envio, recepcion y pic a 9600-8N1? Si ahi tampoco te funciona...
-
Hola manex, gracias por la respuesta. No lo he probado, ese 921600 es la velocidad del USB CDC, en principio con eso no hay problema. Todas las comunicaciones que he probado con USB CDC suelen estar así. Con respecto al Bluetooth no está a 9600 sino a 128000. Pero en cualquier caso, aun 'sincronizados', pasa lo mismo :S
saludos!
-
Una de las prácticas que mejor me ha resultado para identificar una falla es aislarla y dejarla solita, pa'que no le eche la culpa a más nadie :wink:
1.- Prueba lo siguiente, haz un programa que envíe solamente un carácter desde el pic al COM del USB cada 1 seg. y verifica que lo haga bien.
2.- Luego desde el Blue, envía el caracter 'q' (por ejemplo) y que el pic identifique que es el caracter 'q' que recibió y te mande de regreso un '1' (true) y si recibe cualquier otro caracter que te mande un '0' (false) :wink:
Esas son las ideas que se me vienen en este momento a la mente.
Saludos.
---- Editado ----
También puedes probar ingresando manualmente la configuración del hyper en el caso del Blue, por si acaso eso de que te detecte automaticamente la conexión presente algún problemita.
-
Hola Amigos
No creo que sea tu problema, pero a mi me paso algo parecido y tal vez le sirva a alguien mas:
Me he encontrado muchas veces con pics que tienen muy mala estabilidad en su clock interno, por ejemplo luego de luchar una semana para comunicar un 628 con rs232, me hacia exactamente lo mismo que a vos, cambie la configuracion a XT y salio andando perfecto sin tocar ni una linea de codigo, fue hace un año, pero todavia el recuerdo me causa acidez.
Luego probe con otro 628 que tenia y andaba bien con clock interno, lo someti a altas temperaturas (lo puse sobre mi IBM de 19 pulgadas) y comenzo a hacer la misma falla que el otro.
Luego en otros proyectos con otros modelos, me paso lo mismo, es decir, tenia problemas de sincronismo por culpo del clock interno.
Espero evitarle una ulcera a alguien...
-
J1m, que modulo BT estas usando?
si no es mucha molestia, que medidas tiene y donde lo compraste?
-
No se si digo una burrada pero :
Los Pic 18Fxx5x con tienen un bug de hardware al usar rs232 y usb
El amigo Modulay conoce bien el problema .
-
Gracias a todos por las respuestas, finalmente he solucionado el problema aplicando una máscara por software :)
Viciony, este es el módulo:
http://www.sparkfun.com/commerce/product_info.php?products_id=8550
En que consiste el problema Sisco?? Pq estoy haciendo algún que otro diseño mezclando esos dos puertos y me han vuelto casi loco el tema de las interrupciones, se machacan las unas a las otras y como no lo hagas de una manera muy determinada eso no quiere funcionar!
saludos!!
-
creo que es Silicon Errata , osea chungo
http://ww1.microchip.com/downloads/en/DeviceDoc/80335a.pdf
Haver le doy toque a Modulay pasarse por aqui que tuvo pelea tambien.
-
El bug está en el bloque de salida de la usart.Consiste en que el bit más significativo a veces es transmitido de forma errónea.
Apartado 6 del pdf:
http://ww1.microchip.com/downloads/en/DeviceDoc/80287c.pdf (http://ww1.microchip.com/downloads/en/DeviceDoc/80287c.pdf)
SOLUCION: No parece que la haya...cambiar de micro en todo caso
-
Gracias por las respuestas :)
Entonces el problema del 'bit' rebelde viene de esto? Ya que efectivamente tengo el BlueTooth conectado a la usart para poder 'jugar' con las interrupciones del RDA. Me quedo más tranquilo, entonces...
Esto de los Errores en el Silicio, lo arreglan dependiendo la serie, o el lote? o una vez lo detectan lo advierten pero...ahí queda?
un saludo!
-
Hola J!M, con las pocas pruebas que he hecho con el usb_cdc y 485, al mandar un cadena de 6 caracteres, desde la pc, leía el caracter 5 desde el pic, que era el que contenía el comando para realizar determinada acción, el detalle era que no me hacía nada, entonces o que hice, fue que desplegara en el lcd lo que iba recibiendo pero en forma binaria, ahi me fijé que mandaba entre caracter y caracter el caracter null, lo que hice fue que al guardar los caracteres uno por uno no le hiciera caso a dicho caracter, y solucioné el problema, no se si eso es lo que te sucedía o si era la aplicación que utilizaba desde el pc la que mandaba el null :mrgreen:.
Saludos amigo, y también recién comienzo con el usb_cdc, entre mas seamos tendremos mas posibilidades de dominar a la bestia. :mrgreen:
Saludos.
Ganbatte kudasai.
-
Gracias por las respuestas :)
Entonces el problema del 'bit' rebelde viene de esto? Ya que efectivamente tengo el BlueTooth conectado a la usart para poder 'jugar' con las interrupciones del RDA. Me quedo más tranquilo, entonces...
Esto de los Errores en el Silicio, lo arreglan dependiendo la serie, o el lote? o una vez lo detectan lo advierten pero...ahí queda?
un saludo!
Según he entendido,el problema que tienes es con un bit en la recepción de la usart (y posterior transmisión por usb) y no en la transmisión,que es donde se supone que está el bug de silicio según el pdf que puse....por lo que en principio no parece que sea lo que te provoca el fallo...
Hay unos cuanto modelos más afectados por este bug,como el 18F452 o el 18F4620...y la verdad no se si corregirán el/los defectos para seguir produciendo dichos modelos (cosa que dudo) o los dejarán aparcados para dar paso a modelos nuevos.
Huichoman,en la Errata Rev. A3 he leído acerca de otro bug de la usart que describe lo que comentas,pero también,curiosamente, en sentido inverso,o sea en la transmisión...apartado 19:
http://ww1.microchip.com/downloads/en/DeviceDoc/80220g.pdf (http://ww1.microchip.com/downloads/en/DeviceDoc/80220g.pdf)
-
Gracias por la respuesta Modulay.
El cacharrito en cuestión ya está funcionando donde debe, el USB era para debug hasta no tener terminado el 'otro lado del 485'... he eliminado la máscara para solucionar el bug y esto funciona bien sin el usb, por lo que el problema parece estar en el envío de datos del PIC al PC por USB... ya que como digo, si sustituyo el USB por el 485 todo funciona de lujo...
saludos
-
Hola J1M, ahora mismo estoy tratando de comunicar un 18F2525, un 18f2550 con rs485. Y el 2550 a la pc mediate usb_cdc.
Yo iré contando los avances y tropiezos :mrgreen:.
Saludos.
GAMBARIMASU
-
Según parece sólo fallan los de Revision ID = 0100.
Habrá que chequear este dato cuando necesitemos usarlo. Yo sin saberlo he montado uno y hasta ahora no me ha dado guerra.