Cuando se diseña un dispositivo basado en ARM que debería mostrar gráficos simples en una pantalla LCD en color, ¿cómo debería uno mejor diseñar cosas para permitir actualizaciones rápidas, preferiblemente sin estar vinculado a un proveedor particular de ARM o LCD? Mi proyecto actual utiliza una pantalla en blanco y negro que puede ser impulsada a la velocidad de la luz por un puerto SPI en un PIC (redibujando una pantalla compleja en 1/60 de segundo). Parece que las pantallas LCD en color comunes tienen un puerto SPI, pero incluso llenar una pantalla LCD de 160x120 con un color sólido tomaría 30 ms, y una 320x240 tomaría el mejor caso de 120 ms (reloj de cambio de 10MHz).
Si uno pudiera ahorrar los pines del controlador, el modo paralelo podría ser mejor, pero no conozco ningún medio independiente de la familia para conectar la interfaz paralela sin requerir tres instrucciones de almacenamiento de memoria separadas para cada píxel (una para configurar los datos, uno para configurar la salida del reloj alto y otro para marcarlo bajo). Algunos chips ARM tienen interfaces de bus de memoria, pero a menudo quieren hacer cosas como direcciones multiplex y datos, o comprometer muchos pines para generar bits de direcciones irrelevantes (la LCD solo necesitaría un bit de dirección).
Mirando el ILI9320 de ILITEK, o el HD66789 de Renesas, un enfoque que parecería interesante sería usar un CPLD para convertir SPI en datos paralelos e incluir un modo que generaría un píxel por bit. Mirando la hoja de datos de Renesas, es posible obtener escrituras de píxel por bit con un hardware mínimo (no se requiere CPLD) haciendo que todos los bits de datos de puerto paralelo rastreen el pin de datos en serie, utilizando el modo en serie para todo menos píxeles escribe y utiliza las funciones de comparación / máscara para que los píxeles de todos los ceros sean transparentes y los píxeles de todos establezcan los bits seleccionados en GRAM, o los píxeles de todos sean transparentes y los píxeles de todos los ceros borren los bits seleccionados. La sección "características" de la hoja de datos IKITEK sugiere que tiene una funcionalidad similar, pero los mapas de registro no '
Suponiendo que el código muestre principalmente texto y gráficos en color sólido, el enfoque ideal parece ser utilizar un CPLD para conectar el puerto SPI del ARM con el puerto paralelo de la pantalla y permitir que el CPLD se cargue con colores de primer plano / fondo. Esto sería especialmente bueno si uno tuviera un medio para escribir píxeles "transparentes". Dada una fuente como un mapa de bits de dos colores, uno podría simplemente cargar los datos de la fuente directamente en el puerto SPI; esto permitiría que los datos de fuente se muestren a una velocidad de un píxel cada dos relojes ARM. Por otro lado, un CPLD suficiente para manejar dicha tarea de control de visualización costaría alrededor de $ 2.
¿Cuál es la mejor manera de interconectar un ARM con una pantalla LCD en color, si el objetivo es principalmente mostrar texto en color sólido o gráficos simples (por ejemplo, 16 colores o 64 colores)?
Editar
He realizado muchos proyectos de pantallas LCD, con muchos tipos de pantallas LCD, incluidas pantallas LCD de modo de caracteres, 3: 1 personalizado basado en segmentos multiplexados utilizando mi propio método de manejo, pantallas LCD gráficas en blanco y negro con controladores integrados y pantallas en blanco y negro -Pantallas LCD blancas para las que diseñé mi propio controlador basado en CPLD para interactuar con el DMA de uso general de un microcontrolador (incluso en escala de grises de cuatro niveles). Me enorgullezco de hacer exhibiciones rápidas. Uno de los controladores gráficos era un perro que requería aproximadamente 1/10 de segundo para una actualización de pantalla completa incluso cuando escribía datos constantes, pero la mayoría de mis pantallas pueden mostrar incluso una imagen bastante compleja en menos de 1/50 de segundo.
Muchos de los proyectos que hago funcionan con baterías, por lo que el consumo actual es un problema. El controlador de pantalla basado en DMA que hice funcionó bien, pero fue para un proyecto de línea. Creo que la única forma de obtener un consumo de corriente razonable de una pantalla LCD gráfica es usar un controlador que combine el búfer de pantalla y los controladores de columna. El envío de una gran cantidad de pantallas entre chips en cada cuadro desperdiciaría mucha energía incluso en una sola pantalla de bit por píxel; en una pantalla a color con dieciséis bits por píxel, sería mucho peor.
Solo he comenzado a mirar hojas de datos LCD en color; muchas pantallas parecen usar un controlador similar al ILITEK ILI9320, aunque todas las hojas de datos que he encontrado para los controladores basados en ese diseño general han sido marcadas como "preliminares". Algunos como el ILITEK one afirman tener características de enmascaramiento y transparencia, pero no enumeran ningún registro para ellos; No sé si los chips reales tienen tales características, pero las hojas de datos "preliminares" no las incluyeron, o si omitieron las características pero olvidaron mencionarlas. Si en la práctica todos estos chips tienen características de transparencia, parecería razonable diseñarlos para ellos; si no, no
Esperaría que para la mayoría de los proyectos una pantalla típica consistiera en texto colocado arbitrariamente en un número moderado de fuentes de color sólido de tamaño arbitrario. Las fuentes probablemente se almacenarían como datos de bit por píxel. Usando un Cortex-M3, si quisiera escribir la pantalla con datos paralelos, el "bucle interno" del código para escribir dos píxeles probablemente terminaría como:
rol r0, r0, # 2; Obtenga un bit en C, el otro en N itcs strhcs r1, [r3, # DATA_OFS]; Escribir datos strhcc r2, [r3, # DATA_OFS]; Escribir datos strb r4, [r3, # CLOCK_SET_OFS]; Ajuste el reloj alto strb r4, [r3, # CLOCK_CLR_OFS]; Establecer reloj bajo itmi strhmi r1, [r3, # DATA_OFS]; Escribir datos strhpl r2, [r3, # DATA_OFS]; Escribir datos strb r4, [r3, # CLOCK_SET_OFS]; Ajuste el reloj alto strb r4, [r3, # CLOCK_CLR_OFS]; Establecer reloj bajo
No es exactamente lo más rápido del mundo. Sería útil eliminar las escrituras en las instrucciones de establecer / borrar el reloj. Supongo que no hay una buena manera independiente de la arquitectura para eliminar ambas escrituras del reloj, pero puede haber una forma bastante común que permita eliminar una (por ejemplo, muchos chips pueden tener un contador / PWM que se podría hacer que impulse una salida brevemente en respuesta a una sola operación de almacenamiento de memoria).
Usar el puerto SPI y agregar hardware para registrar un píxel por bit aceleraría enormemente el acceso a la pantalla. Si utiliza una pantalla sin enmascaramiento y transparencia, el CPLD debería incluir un contador de direcciones y, para cada píxel, una palabra de datos de píxel o un comando de establecer dirección para la siguiente posición del píxel (para lo cual necesitaría un contador ) Por el contrario, si una pantalla tuviera enmascaramiento y transparencia, todo lo que tendría que hacer sería que el CPLD admitiera un modo en el que después de haber registrado 16 bits, cada bit adicional registraría una palabra de datos en la pantalla con el LSB rastreando el pin SDI (puede que ni siquiera sea necesario usar un CPLD, solo unos pocos chips lógicos normales). Establecería el color de transparencia en el color que quiero escribir pero con el LSB invertido.
No quiero crear un diseño hermoso que se base en el enmascaramiento y la transparencia y luego descubrir que las únicas pantallas con tales características tienen un tiempo de espera de 30 semanas. Por otro lado, si tales pantallas son aptas y están ampliamente disponibles en muchos proveedores, no quiero dejar que la paranoia sobre la disponibilidad me lleve a usar un diseño inferior.
