Problema Serin2 Serout2 con 18F4550

[fines98]

Buenas!

Tengo un problema en la comunicación entre el micro 18F4550 y la PC. Quiero enviar/recibir datos del micro al PC serialmente BaudRate 2400, 8N1, con un MAX232, pero siempre me da algun error. He utilizado Hyperterminal, el Serial Comunicator de MicroCode, Visual Basic y siempre el resultado es igual. He utilizado 300, 600, 1200.. hasta 9600 y tampoco cambia nada.
Cuando hago la simulación en Proteus con muchas variaciones que he probado siempre funciona correctamente, pero en físico me da problemas.

La parte del codigo que me da problemas es la sigiuente:

DEFINE OSC 4
DEFINE SER2_BITS 8             'He utilizaso Ser2_bits 9 y tampoco funciona.

INCLUDE "MODEDEFS.BAS"

PRUEBA VAR BYTE                'Con WORD es el mismo resultado

PINENVIA VAR PORTA.4
PINRECIBE VAR PORTA.5

INICIO:

SERIN2 PINRECIBE,396,[PRUEBA]           'Ya probe con los modos 16780, 33164 y 49548 y no funcionan.
LCDOUT $FE,1
LCDOUT $FE,2, "PRACT. NUM "
pause 100
LCDOUT $FE,$C0, "RECIBIDO ",#PRUEBA
PAUSE 1000
SEROUT2 PINENVIA,396,["OK"]

GOTO INICIO

Lo que recibe siempre se repite cada 7 u 8 letras aproximadamente.
Si el envio al micro "A", muestra en la LCD 12.
B muestra 48, C muestra 60, D muestra 192, E muestra 204. F muestra 240, G muestra 252, H muestra 0. Y luego se repite.
Siempre recibe estos numeros: 12 48 60 192 204 240 252 0 y nuevamente 12 48 60 192 204 240 252 0, etc, etc, etc...
Con las minusculas es lo mismo.
Si en SERIN2 utilizo DEC, HEX, STR muestra caracteres variados sin sentido.
Para SEROUT2 es lo mismo. Envio "OK" o cualquier variable y llegan simbolos como { ´ : ' [ y cosas por el estilo.
Con Serin, Serout, Hserin y Hserout tampoco funcionan.

Ya no se que más probar, velocidades distintas, pines distintos, modos distintos, etc... y nada. Cambie el Cristal, el Micro, el MAX232, el Cable serial, en otra PC y nada de nada.

Necesito ayuda urgente por favor!!!!!!!!

[otto_79]

tengo el mismo problema, cuando recibo los datos del dispositivo a la pc, los caracteres estan bien, ahora cuando quiero recibir los datos del dispositivo al pic "16f877" y desde alli al lcd me muestra caracteres que nada que ver. imagino es una opcion de configurcion o como guardamos el frame en el strig.
si llegas a obtener alguna info por favor avisame yo hare lo mismo.
saludos...

[septiembre_negro]

Pues nunca e tenido este problema si el pic y el otro dispositivo están configurados igual
Baut paridad, formato de datos
Mas bien el problema creo que esta en el formato en que se envían los datos si el pic los manda en hexadecimal o acii y el dispositivo espera decimales pues esta clara la falla.
Otra pudiera ser la capa física si se reciben caracteres sin sentido es muy probable que se este induciendo ruido.
Desde mi humilde experiencia estos son los problemas que e tenido
Los dos dispositivos no están configurados correctamente
El formato de los datos es diferente
Ruido en la capa física
Suerte

[fines98]

Despues de muchas horas de pruebas, revisar el hardware montones de veces (incluso hice la prueba con otro PIC en otro protoboard) y leer muchísimos ejemplos, foros, etc... no he logrado conseguir ningun error.

Pero este fin de semana, me puse a engañar al micro un poco con el código y logré recibir/enviar algunos caracteres correctamente (pero no todos). Parece que es un error de velocidades y sincronización.
Lo conseguí asi:
Define OSC 8, pero usando un cristal de 4 MHz.

Ya que tengo que compilar con MPSAM por ser un 18F, no puedo colocar esto al principio del código:
@Device XT_OSC
y segun al archivo 18F4550.inc, el asume un oscilador HS (High Speed, osea HS_OSC). Tendría que modificar ese archivo, para ver si logro hacer funcionar correctamente la transmisión serial, pero creo que primero buscaré otro cristal de 8, 12 o 20 MHz, para hacer las pruebas.

Alguno a usado el 18F4450, un cristal de 4 MHz y lograr usar Serin2/Serout2 con éxito?

Gracias por los comentarios

[septiembre_negro]

Despues de muchas horas de pruebas, revisar el hardware montones de veces (incluso hice la prueba con otro PIC en otro protoboard) y leer muchísimos ejemplos, foros, etc... no he logrado conseguir ningun error.

Pero este fin de semana, me puse a engañar al micro un poco con el código y logré recibir/enviar algunos caracteres correctamente (pero no todos). Parece que es un error de velocidades y sincronización.
Lo conseguí asi:
Define OSC 8, pero usando un cristal de 4 MHz.

Ya que tengo que compilar con MPSAM por ser un 18F, no puedo colocar esto al principio del código:
@Device XT_OSC
y segun al archivo 18F4550.inc, el asume un oscilador HS (High Speed, osea HS_OSC). Tendría que modificar ese archivo, para ver si logro hacer funcionar correctamente la transmisión serial, pero creo que primero buscaré otro cristal de 8, 12 o 20 MHz, para hacer las pruebas.

Alguno a usado el 18F4450, un cristal de 4 MHz y lograr usar Serin2/Serout2 con éxito?

Gracias por los comentarios

Si en su momento utilice varios pic de la familia 18fxx sin problemas,
Por lo que comentas de engañar al pic  poniendo Define OSC 8, pero usando un cristal de 4 MHz.
No creo que ese sea tu problema aunque en apariencia lo resuelvas
Ya que como te menciono e  practicado con estos pic sin tener que hacer lo que comentas para establecer una comunicación serial exitosa

[fines98]

Todavia no he podido solucionar el problema!!!!! Necesito ayuda URGENTE, POR FAVOR!!

Ya use cristales de 8, 12 y 20 MHz, pero sigue enviando y recibiendo lo mismo. Probando baudrates desde 300, 1200, 2400... hasta 9600 y siempre es lo mismo. Con el osciloscopio comprobe que la PC esta enviando los valores correctos al micro, el MAX232 hace la conversion correcta, pero al enviar por ejemplo A = 65, I = 73, Q = 81, todos los interpreta como el valor 12. La B, J, R los interpreta como 48, y asi sigue...

Por lo menos hice la prueba entre 2 18F4550 (PIC a PIC), configurando serout2 y serin2 (Driven, Inverted, Parity None), absolutamente todos los valores que envio llegan correctamente.

Osea que ya he descartado muchas cosas. Pero el problema esta al usar el MAX232, y usar el modo (Driven, True, Parity none), que el micro no esta recibiendo los valores correctos. Hice las pruebas con las resistencias de 1k y 22k como dice el manual (sin MAX232) y nuevamente el mismo error.

Alguien tiene idea que puede estar pasando? Por que se comunican correctamente entre pic y pic, pero no PC-PIC?
Muchas Gracias!

[fines98]

Hoy hice otra prueba para seguir descartando, y definitivamente el problema es como el PIC envia y recibe en modo "true".
Conecté 2 PC, pero no directamente entre sus puertos, sino cada uno a través de un MAX232 (PC-MAX232---><---MAX232-PC) y se comunicaron sin ningun problema (lo que confirma lo que vi en el osciloscopio).
Entre PIC-PIC se comunican perfectamente (modo iverted), y los MAX232 estan funcionando bien, es decir el problema definitivamente es la interpretacion del PIC de los valores que le estan llegando en modo "true".

Alguien sabe que otros registros debo configurar el 18F4550 para comunicación serial???? Además de los TRIS, ADCON1... algun otro?
Por favor, necesito ayuda urgente!!!!
Gracias....

[xambatronic]

Hola.

Hace unos días me pelee con los puertos serie, y como tu tuve problemas diversos y la única forma de solucionarlos no es con el osciloscopio (" Yo por lo menos no veo ni pijota ") , yo utilice un analizador digital.

Te adjunto una dirección de uno que para mi va muy bien y el precio es correcto 129 €.

http://www.saleae.com/logic/

Espero te sirva.

[psicowifi]

no soy experto en el 18f4550 pero estoy iniciandome en ese pic y creo que el problema esta en la declaracion del OSC.
yo uso un cristal de 20 Mhz en el pic y defino asi

DEFINE PIC18F4550
DEFINE OSC 48

a mi asi me funciona todo bien
si hacen la prueba y dejan el cristal de 20 MHZ y el el lugar de DEFINE OSC 48 ponen 20, veran como se altera notablemente la velocidad de funcionamiento. esto lo pueden ver apagando y prendiendo un led con PAUSE 1000 veran que con DEFINE 20 en lugar de DEFINE 48 el led apaga y prende mas rapido fuera de tiempo y si lo ponen en DEFINE 48 pues el led lo hace a 1 segundo de intervalo cada apagado y encendido.
para mi ese es el problema no se si estare errado... alguien corrija no sea que me equivoque.
por eso no funciona bien el serin2 y el serout2

[ASTROCAR]

Hola buenos dias, oye voy por parte para ver si logro ayudarte un poco hermano en principio el pic18f4550 tiene un solo USART, es decir un solo modulo hard serial y noto en tu codigo que estas usando SERIN2 que es para el 2do modulo o hardware serial de tenerlo el pic.

fines98:Pregunta
Alguien sabe que otros registros debo configurar el 18F4550 para comunicación serial???? Además de los TRIS, ADCON1... algun otro?

Comentario:Astrocar
Ahora mi otra incognita es por la sintaxis que usas estas haciendo comunicacion serial por simulacion y no por hardware USART por tal razon no deberias configurar registros de modulo serial como haces referencia en unos de los post.

Saludos y aclaremos eso para luego ver los detalles de tu problema.
Atten.
Alexander Santana.
Venezuela-Barcelona.

[psicowifi]

yo como comente antes estoy en lo mismo con el 4550 y te cuento algo...
yo uso un cristal de 20Mhz y configuro asi.
define pic18f4550
define osc 48

y la salida serial funciona perfectamente sin problemas
ten e cuenta de configurar el divisor de 96 mhz antes de programar y depende de la frecencia que quieras pon el divosor
ejemplo yo tengo uso el divosor de 96 mhz la seleccion que dice diveide /2 esto pone el pic a trabajar a 48 mhz.
comente antes que si es define osc lo pones mal el pic trabaja mas rapido o diferente lo explique en el post pasado yo tu hago eso
pongo un cristal de 20 mhz ejemplo y despues el define osc 48 y el divisor de 96 mhz entre dos y listo te funciona como es
me di cuenta que el define osc siempre tiene que estar a corde cn el divisor ejemplo
si pones el divisor a dividir entre dos 96 Mhz /2 =48 Mhz que es lo que debes poner en define osc.
Si estoy errado que alguien me corrija..
yo tengo un problema similar pero sacando el serial por varios pines pero si lo saco por uno solo que no es el UART me funciona bien.
saludos

[KonKong]

Yo se que es tarde la respuesta pero al que le suceda este problema es muy posible que sea problema con el tiempo de oscilacion. Ya que los pic 18fxxx tienen un PLL que eso cambia los tiempos de oscilacion.

Coloquen esto en el archivo 18f4550.INC que esta en la carpeta C:/PBP

__CONFIG _CONFIG1L, _PLLDIV_5_1L & _CPUDIV_OSC1_PLL2_1L & _USBDIV_2_1L
       __CONFIG _CONFIG1H, _FOSC_HS_1H & _FCMEN_ON_1H & _IESO_ON_1H
       __CONFIG _CONFIG2H, _WDT_ON_2H & _WDTPS_512_2H
       __CONFIG _CONFIG3H, _PBADEN_OFF_3H & _MCLRE_ON_3H & _CCP2MX_ON_3H & _LPT1OSC_ON_3H
       __CONFIG _CONFIG4L, _LVP_OFF_4L & _ICPRT_OFF_4L & _XINST_OFF_4L & _STVREN_OFF_4L & _DEBUG_OFF_4L
       __Config _CONFIG5L, _CP0_OFF_5L & _CP1_OFF_5L & _CP2_OFF_5L & _CP3_OFF_5L
       __Config _CONFIG5H, _CPD_OFF_5H & _CPB_OFF_5H
       __Config _CONFIG6L, _WRT0_OFF_6L & _WRT1_OFF_6L & _WRT2_OFF_6L & _WRT3_OFF_6L
       __Config _CONFIG6H, _WRTB_OFF_6H & _WRTC_OFF_6H & _WRTD_OFF_6H
       __Config _CONFIG7L, _EBTR0_OFF_7L & _EBTR1_OFF_7L & _EBTR2_OFF_7L & _EBTR3_OFF_7L
       __Config _CONFIG7H, _EBTRB_OFF_7H
Y prueben a ver... Lo digo porque tuve un problema parecido y lo que hice fue programar 2 micros a que prendieran y apagaran una led por 500ms y resulta que uno iba mas rapido que el otro, y así lo resolví.