PIC MCU y pantalla LCD 16x2 - comportamiento extraño

Tengo una pantalla LCD 16x2 conectada a un PIC32MX470F512L. En PIC32, configuro los 6 pines que se usan para interactuar con la pantalla LCD como salidas de drenaje abierto en pines tolerantes a 5 V, tengo un pull-up de 4,7 K en cada línea (DB4-DB7, EN y RS), como muestra el esquema del hardware.

Una puesta en marcha del PIC hay al menos 4 segundos (inicialización de otro hardware conectado al PIC) antes de que el PIC interactúe con la pantalla LCD. Para la inicialización de la pantalla LCD envío:

0x02; /* enviar para la inicialización de 4 bits de LCD */

0x28; /* 2 líneas, matriz 5*7 en modo de 4 bits */

0x0C; /* Mostrar en cursor apagado*/

0x06; /* Incrementar el cursor (desplazar el cursor a la derecha)*/

0x01; /* Borrar pantalla de visualización*/

Mi reloj para escribir en los pines de la pantalla LCD es lento. Cuando escribo en LCD, configuro los niveles lógicos de los pines DB4-DB7 y RS (comando/datos) de acuerdo con lo que se va a escribir, espero al menos 1 ms, pongo EN (reloj LCD) a 1, espero al menos 1 ms, ponga EN a 0, espere al menos 1 ms antes de poner EN a 1 nuevamente (el comienzo del siguiente carácter/comando)

Hice un firmware donde el PIC escribe "PRUEBA SIMPLE" en la segunda línea de la pantalla LCD después de su inicialización.

El comportamiento es:

(1) Programo el PIC y cuando comienza el código, se muestra la cadena "PRUEBA SIMPLE" en la pantalla LCD (imagen adjunta)

(2) Programo el PIC nuevamente y cuando inicia el código, no muestra la cadena de la segunda línea ("PRUEBA SIMPLE"), y la pantalla LCD de la primera línea está llena de puntos (imagen adjunta) Este es el ciclo: ( 1), (2), (1), (2), (1), (2)...

En cada reinicio del PIC, después de cada reprogramación (sin cambiar nada en el código), los resultados son 1,2,1,2... Reiniciar el PIC a través de SoftReset() da el mismo bucle. Una vez funciona, una vez no funciona, en bucle. ¿Cuál puede ser la razón de esto, siempre debería funcionar ...

ingrese la descripción de la imagen aquí

ingrese la descripción de la imagen aquí

ingrese la descripción de la imagen aquí

No tengo el código aquí, pero hay una "secuencia" (si mal no recuerdo: de tres bytes) que debe enviar para asegurarse de que la interfaz tenga 4 bits de ancho. La secuencia se ha desarrollado de forma que funcione si la interfaz se inicia en modo de 4 u 8 bits.

Respuestas (1)

Encontré la solución. Necesito enviar los comandos 0x33 y 0x32 antes de los comandos enumerados en la publicación original. Ahora siempre funciona

Compartir lo que hacen esos comandos sería útil para otros.