Interfaz VGA con PIC

Estoy buscando una forma de controlar una pantalla VGA con un PIC. Los componentes externos están bien, por lo que un chip VGA con I2C o SPI o algo así también está bien.

Requisitos:

  • Resolución: max 1024x768, sin mínimo
  • Idioma: C (compilador C18) o Jalv2
  • Solo texto, no se necesitan gráficos (pero estaría bien si también tuviera eso)
  • Un color es suficiente, por lo que la conversión DA está fuera del alcance de esta pregunta

En mi proyecto tengo un búfer de texto que quiero tener en una pantalla. Puede compararlo con el uso de una pantalla LCD para mostrar texto, pero ahora con VGA.

¿Que estás tratando de hacer? Un PIC no tiene ningún hardware de video, ni hay ningún hardware de video estándar de facto que se use con los PIC. Cualquier software será específico para una configuración de hardware en particular.
En mi proyecto, tendré un búfer de texto. Quiero ese texto en la pantalla. Quiero tener la opción de salida VGA en lugar de una pantalla LCD, para cuando quiera conectar el dispositivo a un proyector más o menos. Sé que es posible , pero eso es con ASM y quiero una biblioteca C/Jalv2. Pero como respuesta a su pregunta: quiero poner un búfer de texto en la pantalla.
El PIC correcto podría producir señales VGA con una codificación cuidadosa, pero eso no será fácil. ¿Qué hardware pretende proporcionar entre el PIC y la salida VGA?
De hecho, no pensé en eso, así que no hay restricciones dentro de lo razonable. También está bien si hay un chip VGA disponible. ¿Está ahí? (además, edité la publicación para dejar esto claro)
¿Un búfer de texto de qué dimensiones? ¿Puede dedicar la mayor parte de la potencia del procesador al mantenimiento de la pantalla? En la parte superior de mi cabeza, no estoy al tanto de los "chips VGA" autónomos, pero podría hacer un SPI autónomo o un esclavo de pantalla en serie con un FGPA pequeño o un segundo microcontrolador, ya sea uno con una frecuencia de reloj muy alta y /o DMA (quizás algunas de las partes de la corteza ARM) o uno diseñado para tareas extrañas como una hélice de paralaje. Si está de acuerdo con colores limitados, su interfaz eléctrica puede ser solo unas pocas resistencias.
Cambiaría las dimensiones a lo más grande que la solución pueda manejar, pero necesito al menos 60 caracteres horizontales y 16 verticales. Puedo dedicar la mayor parte de la potencia del controlador al mantenimiento de la pantalla. Esta pregunta está destinada a construir un esclavo I2C. No entiendo muy bien lo que quieres decir con FGPA.
¡+1 para la hélice Parallax! Microcontrolador realmente bueno y realmente poderoso, pero el proceso de desarrollo es un poco peculiar. En el lado negativo, cuesta alrededor de $7 y requiere EEPROM externa y cristal para VGA. Puede hacer bastantes colores usando solo resistencias para DAC.
Lo siento, olvidé mencionar que un color es suficiente. Edité la publicación y disculpe la confusión causada. @ChrisStratton, ¿por qué usaría una hélice de paralaje en lugar de un PIC?
Uno, simplemente descargar la ajetreada tarea de volver a pintar constantemente la pantalla para dejar su procesador principal libre para contemplar lo que debería estar en la pantalla. Dos, porque es más rápido, tiene múltiples núcleos y la gente ha hecho pantallas de video con él. Un FPGA brindaría aún más flexibilidad, pero tiene una curva de aprendizaje alta y es sustancialmente más costoso, incluidos los componentes de soporte.
Bien, puedes enviar eso como respuesta. ¿Tiene un enlace a algo que funcione con el paralaje que interactúa con una pantalla VGA? ¡Por favor comparte! Lo aceptaré a menos que haya mejores respuestas (usando un PIC, por ejemplo, que sería más barato).
@Camil Staps Eche un vistazo al código de Propeller Demo Board, por ejemplo. Funciona con teclado y mouse PS/2, muestra en salida compuesta y VGA, toma muestras de un micrófono y reproduce, todo al mismo tiempo. Otro lugar para buscar es el Intercambio de Objetos . Hay muchos objetos VGA disponibles de forma gratuita. También hay demostraciones de VGA que también vienen con el IDE.
Ooh, ese intercambio de objetos es algo muy bueno, ¡gracias por vincular! Ahora solo espero el paralaje como respuesta / una respuesta basada en PIC / otra respuesta.
Por mucho que me guste el chip Propeller (obtuve una de sus Placas de Desarrollo Profesional, cuando estaban en oferta por $100), si quieres usar el Propeller como un periférico para descargar el procesador principal, entonces el Propeller ganó No funciona muy bien sin la misma memoria adicional. Propeller tiene solo 32K de RAM global, y realmente necesita un búfer de cuadros completo: 1024x768 = 768K bytes para que el video se pueda actualizar continuamente.
¿Cómo llegas a 768Kbytes? Yo diría 1024 * 768 / (6*8) = 16384que 16,4 Kbytes, ya que usaría una fuente de 5x7. No necesitas un byte por píxel, ¿verdad? Además, el 1024x768 fue el máximo, menos también está bien.
@tcrosley: en realidad, no creo que esta aplicación requiera un búfer de cuadros. En su lugar, se puede utilizar un búfer de caracteres (64*16=1K) y realizar una trama de píxeles sobre la marcha mientras se escanea la pantalla. Esto sería comparable a ejecutar una pantalla de PC en modo de texto en lugar de modo de gráficos de mapa de bits. Agregue un poco de lógica de control del cursor y configúrelo para interactuar con la parte interactiva a través de un puerto serie o registros de buzón/fifos...
@ChrisStratton Tienes toda la razón, había olvidado que solo quiere hacer una prueba. Entonces Propeller parece una buena solución. Los chips cuestan solo $ 8 cada uno en cantidades individuales , y puede obtenerlos en un paquete DIP.
DarioG en los foros de Microchip.com creó un generador de video a partir de un DSPIC y publicó el proyecto para que otros lo usen. microchip.com/forums/m880978.aspx

Respuestas (2)

Si no es excesivo para su aplicación, puede agregar una interfaz ISA a su PIC y recoger una tarjeta de video vieja en alguna parte.

Sin embargo, supercat señala que no hay una PC para ejecutar el BIOS de video, por lo que probablemente esto no funcione.

Encontré una publicación en hackaday haciendo algo similar con un AVR que podría ser una buena fuente de inspiración.

¡Ooh genial! Ciertamente tengo que pensar en esto para futuros proyectos, ¡gracias por vincular y +1! Sin embargo, me temo que es una exageración para este proyecto ...
Bonito de hecho, se olvidó de todo eso. Creo que incluso puede haber tarjetas VGA que puedan funcionar solo con el ISA de 8 bits conectado; ciertamente hay tarjetas Hércules, EGA, etc. que podrían ser reprogramadas a los tiempos necesarios.
Una tarjeta VGA suficientemente anticuada debería funcionar con un bus de 8 bits, pero el requisito de E/S incluso para un bus de 8 bits será lo suficientemente grande como para que también se pueda acceder a un acceso de 16 bits. Sin embargo, un problema que se puede tener con las tarjetas VGA es averiguar qué secuencia de inicialización se requiere para una tarjeta en particular. Incluso las tarjetas que son "100% compatibles con VGA" a menudo tendrán que inicializarse de varias maneras no estándar antes de su uso. Dado que cada tarjeta VGA incluye una BIOS ROM, esto no es un problema cuando la tarjeta está conectada a una PC; la PC ejecutará el código en la ROM, que...
... realizar la inicialización adecuada para cualquier registro que no existiera en el VGA original. Sin embargo, a menos que planee escribir una biblioteca de emulación 8086 para su PIC, las rutinas de inicialización proporcionadas en la ROM pueden ser bastante inútiles.
@supercat, probablemente tengas razón, me olvidé del BIOS de video.
@PhilFrost: hay momentos en los que la interfaz con dispositivos de bus ISA puede funcionar bastante bien sin usar una cantidad de pines totalmente escandalosa (por ejemplo, si mal no recuerdo, un dispositivo de 8 bits que se asigna a 4 direcciones de E/S requeriría 8 bits para datos, 2 para dirección, /IORD y /IOWR. Doce bits.) Una tarjeta VGA de 8 bits requeriría como mínimo absoluto 8 datos, 17 direcciones, /IORD, /IOWR, /MEMRD, /MEMWR. Treinta bits. Tal vez uno podría omitir /IORD, y en algunos casos quizás /MEMRD, pero aun así, eso es mucho.
@supercat: muchos microcontroladores logran interactuar con dispositivos ISA de todos modos. Shift registros para la victoria.
@PhilFrost: cronometrar 32 bits para cada operación de visualización no parece una receta para la velocidad. Supongo que uno podría usar registros de desplazamiento para algunos bits mientras se mantienen los datos, los ocho bits de dirección inferiores y /MEMWR como puertos dedicados. El VGA podría establecer la cantidad de caracteres por fila virtual en 128 (independientemente de la cantidad de caracteres mostrados), por lo que ninguna fila cruzaría un límite de 256 bytes. Si uno solo fuera a usar texto, podría usar el modo de 16 bits pero usar un registro de desplazamiento para el bus de datos superior; eso agilizaría la escritura de muchos caracteres con el mismo color.

Es probable que el circuito requerido para agregar una pantalla VGA a un PIC exceda el costo y la complejidad de usar un chip diferente que podría proporcionar una pantalla y también hacer lo que fuera que iba a hacer el PIC, o usar algo como una Raspberry. Pi para proporcionar la pantalla y hacer que se comunique con el PIC a través de un UART o algo similar (creo que Raspberry PI tiene al menos un UART entre sus pines de E/S).

Si su meta es construirse un subsistema VGA para que pueda aprender cómo funcionan estas cosas, una interfaz VGA a 640x480 requiere la capacidad de registrar alrededor de 32 millones de píxeles por segundo. Eso va a estar un poco más allá de las capacidades de un PIC "sin asistencia"; probablemente no tendría que agregar mucho hardware a un PIC para permitirle generar texto si no le importara que la pantalla acaparara el procesador durante la mayor parte de cada cuadro, pero es probable que el PIC no tenga tiempo para nada . demás; cada línea de escaneo requeriría que ejecutara una secuencia de 160 instrucciones algo así como:

movf  POSTINC0,w,c
movwf PORTC,c

comenzando en el ciclo correcto y funcionando sin interrupción [el hardware tomaría ciegamente los datos de caracteres de PORTC en el momento en que se suponía que debían estar allí, los alimentaría a través de una ROM con forma de carácter y los cargaría en un registro de desplazamiento].

Si hiciera algo así, podría ser posible que un PIC de 32MHz genere texto de 80x25 usando algo así como una ROM rápida (25ns) de 32Kx8 para contener formas de caracteres y serializarlos, un contador de 3 bits para registrar los píxeles de cada carácter , y algunas puertas misceláneas; uno probablemente podría usar uno de los módulos PWM de PIC para manejar la sincronización horizontal. Este enfoque proporcionaría una matriz de mosaicos de 80x25, cada uno de los cuales podría tener cualquiera de las 256 formas; cada forma sería de 8x16 píxeles, y cualquier combinación de 256 colores [para simplificar, imagine que los colores probablemente serían RRRGGGBB o algo así]. Si uno tuviera problemas para encontrar una ROM de 32Kx8 lo suficientemente rápida, podría usar una RAM de 32Kx8 rápida en su lugar y proporcionar un mecanismo para alimentar datos en el inicio del sistema.

Pero Raspberry Pi no hace VGA.
@AndrejaKo: Ah, está bien. Si necesita VGA en particular, es probable que todavía haya otras computadoras de placa única que podrían hacer el trabajo por menos del costo de diseñar una solución personalizada. Sin embargo, seguir la ruta PIC puede ser educativo. La cantidad de circuitos no debería ser irrazonable, y probablemente aún pueda encontrar todo lo que necesita en piezas de orificio pasante fáciles de soldar a mano. Por cierto, agregar algunos contadores, una RAM fuera del chip y un poco de lógica adhesiva haría posible que el video se genere continuamente sin la participación del PIC, con la advertencia de que el PIC...
... tendría que cronometrar adecuadamente sus escrituras de visualización para asegurarse de que coincidieran con las horas en que los datos de visualización estaban disponibles; agregar un poco más de circuitos podría aliviar ese requisito.
Interfaz VGA con PIC
RespuestasAquíPolítica de privacidad1y, 0v