Problemas al envíar un caracter determinado al LCD

La pregunta, con esos datos, es imposible responderla. La comunicación con el LCD, sea a 8 ó a 4 bits, no debería verse afectada por el estado de los bits de datos, siempre que el firmware esté bien escrito, máxime teniendo en cuenta que es una comunicación síncrona.

Donde quizás sí podría afectar el que se recibieran varios bits seguidos iguales es en la comunicación con el PC. Al ser una comunicación asíncrona, si la emulación del puerto serie que haces con el 16F84 no va muy fina, puede que con determinadas combinaciones de los bits de datos, el firmware no lea bien el byte que le ha enviado el PC.

Como parece que el micro sí que envía bien los datos al PC, y ya tienes escrita la rutina de envío de esos datos, podrías hacer una prueba simple para ver si el problema está ahí. Simplemente con que el PIC devuelva al PC cada dato que reciba, como el típico eco de los modems, podrías asegurarte de que está interpretando bien lo que recibe por el puerto serie.

En cualquier caso, como te decía, es imposible responderte sin ver ni el firmware ni el hardware.

--

Saludos de Jose Manuel Garcia snipped-for-privacy@terra.es http://213.97.130.124

escribió en el mensaje news: snipped-for-privacy@b28g2000cwb.googlegroups.com... Hola a todos.

Resulta que tengo un PIC 16f84-A, un MAX232 y un LCD (PC1602-F) compatible con el Hitachi HD44780.

El programa que tengo puesto en el PIC envía un mensaje al ordenador por el puerto serie poniendo en el hyperterminal "Escriba su nombre". El usuario lo escribe y cada caracter que tecle el PIC lo reenvia al puerto serie de nuevo y lo muestra en el LCD (está configurado a 4 bits y usa retardos en vez del busy flag).

El problema es que todos los caracteres se visualizan bien en el LCD excepto 'p','P',' ','0' y '@', los cuales provocan que la pantalla se apague o muestre lineas. Cuando el usuario escribe otro caracter distinto de los anteriores se vuelve a mostrar el contenido otra vez incluyendo los carácteres problemáticos. Así, si el usuario escribe:

A p o l o

Cuando escribe la "p" desaparece el contenido y cuando escribo la "o" aparece "Apo" y a partir de ahí todo correcto.

Fijándome en la tabla CGROM de caracteres, veo que los 4 bits inferiores de los caracteres problemáticos son ceros. No se si ese será el problema junto con el bus de datos de 4bits. ¿Sabeis que puede ser y/o como se puede arreglar sin tener que modificar la configuración de los pines del LCD y del PIC?

Muchas gracias y perdón por el tocho.

escribió:.

Esos caracteres tienen en común que los cuatro bits inferiores son cero. Comprueba tu rutina de envio para ese caso particular.

'p' = 0x70 'P' = 0x50 ' ' = 0x20 '0' = 0x30 '@' = 0x40

Saludos Miguel Giménez

He cambiado el circuito para escribir simplemente una cadena "ABC DEF PIN @O0U" al LCD con un segundo de pausa detras de cada una y este es el resultado:

Lo que sorprende es que funcione bi=E9n con el resto de car=E1cteres y con esos 4 no

En el video,si que muestra la P. Si te das cuenta te ocurre de 3 bien y la cuarta mal. Yo revisaría la linea de datos a ver si tienes alguna pista suelto o cortocircuitada. un saludo

escribió en el mensaje news: snipped-for-privacy@h48g2000cwc.googlegroups.com... He cambiado el circuito para escribir simplemente una cadena "ABC DEF PIN @O0U" al LCD con un segundo de pausa detras de cada una y este es el resultado:

Lo que sorprende es que funcione bién con el resto de carácteres y con esos 4 no

Si, pero el problema es que escribo espacio y P, por lo que en ambos casos se muestran esas rayas, despu=E9s de escribir otra letra (en ese caso se escribe la I) ya se muestra todo como si nada hubiese pasado.

IFSG ha escrito:

inea

Por lo que se ve, el LCD recibe bien los caracteres, puesto que luego aparecen, pero justo antes o después de recibirlos hace cosas raras. Eso te está indicando que no es que haya un fallo en el envío de esos caracteres, sino algún tipo de "efecto secundario".

Lo que parece más probable es un fallo en el firmware del PIC. Parece como si además del carácter enviara algunas instrucciones de control que no afectan a la memoria de pantalla (después de eso los caracteres siguen ahí). ¿Seguro que alguna otra parte del programa no está cambiando los puertos usados para el LCD (especialmente los que uses para las señales E y RS del LCD)?

También podrías estar demasiado al límite en cuanto a velocidad de la comunicación. Podrías probar a relentizarlo todo, añadiendo retardos en la rutina de manejo del LCD.

Si estás seguro de que el firmware está bien, habría que mirar como trata el PIC esos puertos. Quizás ponga esos puertos en alta impedancia entre un carácter y otro. En esa situación, si no has previsto poner unas resistencias de pull-up, las entradas estarían recibiendo ruido, y a lo mejor en determinadas circunsatancias ese ruido se traduce en que haga esas cosas raras. Aunque parece poco probable, porque sería raro que por esa causa se comportara siempre igual.

Tampoco deberías descartar que fuera un fallo del propio módulo LCD (sobre todo si es marca pepito, y el chip controlador es marca nisupu, todo made in China).

Pues he probado con otro LCD y ya funciona, por lo que me imagino que el que tengo esta defectuoso de alguna manera.

Gracias a todos.

Pepitof ha escrito:

o te

eres,

omo

ah=ED).

tos

del

la

s en la

trata el

as

sobre

in

Debe tener un cortocircuito de ese bit que causa problemas con alguna otra se=F1al, dentro o fuera del chip. Podr=EDas echarle un vistazo a la placa controladora que no se vean cortos entre pines del chip u otros sitos por la t=EDpica gotita de esta=F1o que se escap=F3 durante el montaje en serie.

snipped-for-privacy@gmail.com ha escrito:

Eso te

cteres,

como

no

n ah=ED).

ertos

S del

e la

dos en la

mo trata el

un

lo

esas

sa

(sobre

de in