Siempre estoy buscando una adición de calidad a mi laboratorio que respetaría mi presupuesto estricto. Recientemente, me he encontrado presionando la barrera de Hertz con todos los demás proyectos que hago y, por lo tanto, deseé desesperadamente un alto alcance de ancho de banda. Desafortunadamente, solo recientemente tienen 70 MHz a 100 MHz se vuelven realmente asequibles, mientras que un nuevo osciloscopio de cuatro canales en el rango de 500 MHz a 1 GHz aún cuesta una fortuna para adquirir. Mi única opción fue encontrar un milagro absoluto en forma de un alcance de ancho de banda alto.
Parecía que los dioses de la mano me estaban sonriendo cuando encontré este basurero destinado a HP 54542C. Parecía estar en buena forma de hadas y era la cima canina en su día. Pero algo tenía que ser roto, ¿verdad? Seguro que la pantalla era claramente defectuosa e ilegible. ¿Quieres saber cómo lo arreglé? Cuatro letras: FPGA.
El problema
Una investigación poco profunda en este ámbito reveló una historia interesante. Este supuestamente era el primer alcance de gama alta de HP con una pantalla LCD y también fue el precursor de la serie de ámbitos de infiniium que continuaría directriz el mercado. Sin embargo, la LCD se sentía como una idea de último momento. El alcance tenía una variante de lo contrario similar con una pantalla CRT, y la versión que adquirí simplemente tenía los tractos digestivos CRT eliminados y una pantalla LCD de color instalada por HP. Esperaba que la LCD tuviera la culpa y no la conducción de ASIC, esto parecía una buena apuesta, ya que un grifo suave en algunos casos, ¿volvería a llevar la pantalla a la pantalla?
Comencé a investigar la causa raíz y comencé a apartar la pantalla LCD. Encontré que un líquido se había derramado por todas partes; Nada se había corroído, pero la limpieza y reinstalación no hicieron ninguna diferencia. Reuniendo el alcance con el basurero no era una opción, porque aparte de la pantalla LCD, el alcance se sentía como un tesoro absoluto. A pesar de que la Junta de Chauffeur de la LCD era completamente inútil ahora, provino de un momento en que la industria aún no se había movido al paso de PIN subatómico en los conectores de cable a bordo. Esto implicaba que podía soldar convenientemente en un televisor de cable de cinta con cinta convencional de 26 pines para eliminar todas las señales requeridas y comenzar el proceso de ingeniería inversa del protocolo en uso.
Ingeniería inversa Los protocolos LCD
Televisión por cable de cinta soldada en la parte superior del conector existente
El primer paso del proceso fue identificar las señales en el conector. Estaba atento al conjunto de señales más genéricas necesarias para conducir cualquier pantalla LCD. Esto debe incluir algunas señales estrictamente periódicas, un par de señales un tanto aleatorias y, por supuesto, el poder típico y el suelo. Las señales periódicas probablemente serían el reloj de píxeles y las señales de sincronización que marcarían el inicio de una nueva línea y marco; Por otro lado, las señales de aspecto aleatorio serían los datos de píxeles reales que se mostrarán. A juzgar por su edad, se esperaba un protocolo bastante fácil. Guiado por esta intuición Comencé a sondear el conector y pronto tuve las 25 señales descubiertas.
Solo encontré dos señales perforadas: una, una señal relativamente baja de 31.25 kHz cerrada en un sospechoso de 60 Hz, y la otra onda cuadrada de 25 MHz. El primero tenía que ser una señal de sincronización integrada. Los 60 Hz fueron un sorteo muerto, ya que correspondía a la tasa de cuadro nominal. La señal subyacente de 31.25 kHz debe corresponder a la tasa de línea horizontal dentro de un marco. Finalmente, la señal de 25 MHz tenía que ser el reloj para todo el sistema, de hecho, era el reloj de píxeles.
A continuación, tuve que darle sentido a las señales de aspecto aleatorio que evidentemente fueron los datos de píxeles. En primer lugar, la necesidad de un conector de 25 pines se aludió claramente a algún tipo de configuración de RGB paralelo. En total, encontré nueve señales de este tipo que se divide perfectamente por tres y envuelven que la pantalla LCD estaba usando nueve bits por píxel y tres bits por canal de color R, G y B respectivamente.
Ejemplo: plan de patio VGA
Averiguar el esquema y el pin-out fue parte del desafío. Posiblemente, mucho más esencial fue averiguar los tiempos de las señales en uso. Casi siempre, las señales de exhibición cruda tienen lo que se llaman “porches”. Estos pueden ser considerados como regiones dentro de cada cuadro donde no se pueden escribir los datos. Estos se originaron en los días de CRT, donde el haz físico de los electrones se tomó tiempo para barrer desde el extremo de una línea hacia el inicio del otro, o incluso desde la parte inferior de la pantalla hasta la parte superior. Aunque menos pronunciado en las pantallas electrónicas modernas, estas regiones aún existen porque el controlador LCD lleva tiempo procesando y arrastrando los datos entrantes.
Determinar los tiempos
Para extraer los tiempos, intenté correlacionar los datos de píxeles con las señales de sincronización. Estaba buscando a cualquier región donde los píxeles estuvieran constantemente sin garantizar.
Tiempos horizontales
Después de mirar los datos por un tiempo, estaba claro que la pantalla LCD estaba usando un esquema de patio simple y simple tanto en la parte horizontal como vertical de la señal de sincronización integrada. Esto fue fácil de identificar porque los píxeles se establecieron enya sea todo alto o todo bajo durante este período. Una vez que hubiera identificado estas regiones, usé los cursores para medir su duración y traducir ese tiempo a un número equivalente de píxeles.
Esta fue una pieza de información vital que garantizaría una reproducción estable y apropiada en el monitor VGA. El plan era alimentar estos valores como constantes en Verilog, y usar contadores para “Viajar” la lógica correspondiente para lograr las formas de onda requeridas.
Tiempos verticales
Por último, la resolución de LCDS tuvo que ser identificada ya que tendría que ejecutar el monitor de reemplazo en la misma configuración. Esto se hizo simplemente medir los diversos períodos activos y compararlos con otras señales, como el reloj de píxeles que tenía un período 40 NS. El tiempo activo horizontal se determinó que era alrededor de 25.7 EE. UU., Por lo tanto, constituye un total de 642.5 píxeles y de manera similar, el período activo vertical fue de 15.42 ms y con un período horizontal de 30 US, que corresponde a 481 líneas. Claramente, esta fue una pantalla convencional de 640 x 480 con una tasa de revitalización de 60 Hz.
Encontrar un sustituto capaz
El salvador de 8 pulgadas
Por lo tanto, la pantalla existente [resultó ser] bastante común al final, y un reemplazo parecía completamente plausible. Desafortunadamente, el tamaño fue un poco extraño; ¿Es fácil encontrar pantallas de siete pulgadas pero ocho? Aunque no pude encontrar ninguna caída de un precio bastante a un reemplazo en la web, el tamaño acaba de ser el mismo que utilizado por numerosos modernos instalaciones de LCD de mercado en automóviles. Estas son buenas pantallas de calidad “EYOYO” de bajo costo (£ 50) y aceptan literalmente todos los desarrollos de la entrada de video de todos los analógicos a VGA e incluso HDMI. También apoyan una resolución mucho más alta de 1024 * 768. Me sorprende que esta pantalla no es masivamente popular dentro de la comunidad de Raspberry Pi.
Finalmente, todo parecía estar haciendo clic. ¡No solo podría reemplazar la pantalla LCD con este monitor VGA, encajaría perfectamente cuando el alcance incluso tenía suficiente espacio para un CRT!
Así que exactamente, ¿cómo se lleva a cabo una conversión LCD a VGA? ¡Con un FPGA, por supuesto!
Conversión de señal
En este punto, la única cosa de pie entre mí y un alcance de 500 MHz en funcionamiento se convierte con éxito las señales LCD mencionadas anteriormente a VGA. Estaba claro que un procesamiento relativamente rápido solo se podía hacer en un FPGA, pero ¿cuál? Mi objetivo era, en algún momento, dejar el FPGA dentro del alcance con la pantalla, así que necesitaba algo pequeño y barato. Afortunadamente, ¡eBay parece tener un montón de estos viejos tableros de desarrollo basados en Altera Cyclone II para una mente alzada £ 10! Estos son de FPGA más bien capacitados, que tienen aproximadamente 4K elementos lógicos y óptimos para un proyecto de pequeña escala como este.
Una forma común en que se realizan estas conversiones de pantalla están usando buffers de marco. La idea es amortiguar un marco entero, llevar a cabo la conversión y escupirla en el otro extremo. Lamentablemente, esto requiere una RAM externa de tamaño respetable en la FPGA. Estos tableros de FPGA son notoriosos por no tener ningún RAM externo, por lo que este esquema estaba fuera de discusión. Después de un poco de pensamiento, me referí a la realización de que las señales LCD y VGA no eran tan diferentes después de todo. ¿Qué sucede si pudiera convertirlo de uno a otro de una línea de línea, y eludir la necesidad de un búfer de marco en absoluto?
Comparación: VGA vs LCD. Este diagrama se aplica tanto a los segmentos horizontales como verticales.
En resumen:
LCD tiene:
Un reloj de píxeles
Señales de sincronización combinadas
Solo patio delantero
Mientras que VGA tiene:
No hay pixel reloj
Señales de sincronización separadas
Patio delantero y trasero con un período de sincronización.
La señal de sincronización integrada.
Entrando en detalles de cómo funciona VGA está más allá del alcance de este artículo, pero lo arreglaré más tarde. Por ahora, si simplemente examinamos el sketch de sincronización, vemos que la única diferencia entre las dos señales es el número de ocurrencias y ubicaciones de los porches y la colocación de datos válidos.
El boceto hace que la conversión se vea fácil, pero solo es válida si los dos marcos están en sincronización completa. Para decirle a la FPGA para que comience a producir un marco LCD correspondiente sobre VGA, primero debemos identificar el inicio de un nuevo marco que proviene del conector LCD para que pudiéramos sincronizarlo. Esta es posiblemente la parte más difícil del proceso, ya que simplemente examinar los bordes de la señal de sincronización integrada de la pantalla LCD no es suficiente.
En su lugar, deberíamos medir el tiempo entre dos bordes y marcar la aparición de un nuevo marco. El resto es un conjunto relativamente sencillo de puertas lógicas que produce el diagrama de tiempo anterior. Por último, como la LCD no tiene un patio posterior o un pulso de sincronización, los datos de RGB entrantes deben estar equilibrados a tiempo usando un pequeño FIFO para que se alinee perfectamente donde el monitor VGA lo espera. Una vez que se completó la equipamiento de lo anterior en Verilog, procedí a lidiar con el hardware.
Configuración de hardware
La configuración de hardware
La configuración del hardware fue afortunadamente muy minimalista. HP no estaba utilizando del todo el LCD a su máximo potencial. Inspeccionando los trozos individuales de eEl canal ACH reveló una gran cantidad de redundancia: los diversos bits eran prácticamente siempre idénticos, lo que indica una utilización muy superficial de la paleta de colores completa de nueve bits. Esto no fue impactante, ya que HP estaba reutilizando principalmente a firmware de la versión CRT del alcance. Todo esto implicó que me salí con solo conectar el MSB de cada canal de color con prácticamente ninguna pérdida en la imagen final. Esto me ahorró incluso mucho más precioso memoria en el FPGA.
El problema más importante fue que la LCD estaba usando las señales de 5 V TTL. El FPGA puede aceptar en las mejores señales de 3.3 V, así que la conversión de nivel debía realizarse. Elegí aprovechar los diodos de sujeción de entrada en algunos de los buffers lógicos de la serie 74HC para llevar a cabo esta conversión. Esto tiende a destruir considerablemente los tiempos de subida / caída. Por ejemplo, el 74HC4050 incluso tiene resistencias polisilicon en serie con el diodo en el dado, desplazando la necesidad de una resistencia de series externa. Lo jugué seguro y agregué 1 kΩ de resistencias de la serie a la entrada de estos tampón y la salida fue alimentada en el FPGA. La salida de las salidas HSYNC y VSYNC de FPGA se engancharon directamente al monitor, mientras que las líneas RGB se vincularon a través de resistencias de 330 Ω.
Éxito
¡Éxito!
Después de domar el reloj de píxeles de 25 MHz para comportarse en una tabla de pan y conectar el FPGA al nuevo externo
¡El puerto VGA del monitor, el alcance fue devuelto a su gloria formal! Aunque todo funcionó perfectamente, esta configuración fue bastante propensa al ruido. Todo lo que necesito hacer ahora es hacer una PCB y otorgar al monitor VGA una residencia permanente dentro del alcance.
Entonces, ¿qué sigue te preguntas? Bueno, actualmente, la única forma de guardar las capturas de pantalla es a través de una unidad de disquete fechada. Pero, como ahora tenemos los datos LCD que pasan por un FPGA, ¿por qué no escribir eso a una tarjeta SD?