Generar Señal de Video con PIC

Antes de nada quiero "quejarme" del termino NTSC, si no se utiliza la modulacion de color no se puede llamar NTSC sino señal de blanco y negro (sincronismo + luminancia).
La diferencia esta en la complejidad, mucho se hablo,pero creo que el unico que lo consiguio fue con la gama SX, una especie de pic tuneados a 50Mhz.



Por impresionante esta "DEMO" con SONIDO guapisimo.
Hay algunos puntos que me hacen sospechar parece tener mucha resolucion...?

El sonido y la preimagen las generan en los tiempos muertos del refresco.

Lo que me tiene intrigado es la entrada MOSI (canal serie).

En su dia pense que era una señal interesante(SPI/I2C), le tiras el dato y va saliendo bit a bit como si fuera un registro de desplazamiento, esto permitira ganar 7ciclos libres y ganar velocidad

Creo que es interesante estudiar si es factible utilizar el spi para enviar información a la pantalla mediante interrupciones.


Otra forma de plantearlo seria utilizando una memoria RAM y un contador tipo 74hct4040, pero esto ya se complica un poco
 
Soy yo el que sigue llamando NTSC a la señal de video, eso lo hago para dejar claro que la imágen se ve en un televisor compatible con el estándar NTSC, debería usar el termino RS170 pero NTSC suena más claro :LOL:
 
tiopepe123 dijo:
Antes de nada quiero "quejarme" del termino NTSC, si no se utiliza la modulacion de color no se puede llamar NTSC sino señal de blanco y negro (sincronismo + luminancia).
La diferencia esta en la complejidad, mucho se hablo,pero creo que el unico que lo consiguio fue con la gama SX, una especie de pic tuneados a 50Mhz.



Por impresionante esta "DEMO" con SONIDO guapisimo.
Hay algunos puntos que me hacen sospechar parece tener mucha resolucion...?

El sonido y la preimagen las generan en los tiempos muertos del refresco.

Lo que me tiene intrigado es la entrada MOSI (canal serie).

En su dia pense que era una señal interesante(SPI/I2C), le tiras el dato y va saliendo bit a bit como si fuera un registro de desplazamiento, esto permitira ganar 7ciclos libres y ganar velocidad

Creo que es interesante estudiar si es factible utilizar el spi para enviar información a la pantalla mediante interrupciones.


Otra forma de plantearlo seria utilizando una memoria RAM y un contador tipo 74hct4040, pero esto ya se complica un poco

Sigo diciendo que si no quieres limitaciones, usen el PIC32, se nota que nadie por el momento sabe manejarlo y menos en ASM. Tiene 80 MHz, nadie se puede quejar. Quizás aumente ya que antes eran de 72MHz y ahora 80.
 
Estoy implementando algo parecido pero en PAL y a 20MHz.

Las líneas horizontales y sincro horizontal ya se ven perfectas, el problema es que no tengo idea de cómo hacer el sincronismo vertical. Ya busqué en internet y no logro entender cuándo hay que mandar los pulsos, de que tamaño son, de que niveles, etc.

Alguien me podría ayudar ?

Gracias,
Gonzalo
 
Autocita:

pic-man dijo:
La resolución vertical la hice gracias a un diagrama de la página de PIC Breakout, consiste en pulsos de sincronización alternados que duran 9 líneas horizontales:
- Primero pulsos de sincronización cortos: 30us de Negro seguidos de 2us de Sincronización. Se repite 3 veces.
- Luego pulsos de sincronización largos: 30us de Sincronización seguidos de 2us de Negro. Se repite 3 veces
- Por último pulsos de sincronización cortos de nuevo: 30us de Negro seguidos de 2us de Sincronización. Se repite 3 veces.

Con eso se logra la sincronización vertical!

Es decir ocupas generar una señal que sea:
30us de Negro -- 2us de Sync -- 30us de Negro -- 2us de Sync -- 30us de Negro -- 2us de Sync
30us de Sync -- 2us de Negro -- 30us de Sync -- 2us de Negro -- 30us de Sync -- 2 us de Negro
30us de Negro -- 2us de Sync -- 30us de Negro -- 2us de Sync -- 30us de Negro -- 2us de Sync

Esa parte fue la que mas tiempo me llevó porque tambien yo buscaba información pero en ningún lado lo veía claro.
 
La idea de generacion de las sincronias es muy simple... simplemente se ponen contadores en cascada para ir contando los tiempos requeridos de sincronia horizontal y vertical

para cada pulso de sincronia horzontal esperas 64uS, y para cada vertical 14mS, durante el tiempo de sincronia la señal de video debe estar en un cero logico (que es el nivel de voltaje requerido para sincronia), para un negro la señal es de 0.3V y para un blanco de 1V

El proyecto que hice tiene unos 8 años y mis documentos se han ido perdiendo con el paso del tiempo... pero si tengo el codigo que use en un PIC16F84 a 4MHz, se los dejo para que entre todos lo estudiemos y veamos que demonios quise hacer por que el diagrama del circuito lo tengo extraviado, recuerdo que el pic daba salida en 2 pines.. uno para sincronia y otro para señal.. ambos pines se "sumaban" por medio de 2 transistores para poder generar la señal compuesta

Código:
	LIST p=16F84
	#include P16F84.inc
	
SGEN	EQU	H'0C'		;REGISTRO DE ESTADO
CONT	EQU	H'10'		;CONTADOR GENERAL
CONTV	EQU	H'11'		;CONTADOR VERTICAL
CONTH	EQU H'12'		;CONTADOR HORIZONTAL

CONTS	EQU H'13'		;CONTADOR SEGUNDOS

BAND	EQU 7			;BIT DE BANDERA

SINC	EQU 0			;BIT DE SINCRONIA
INF		EQU 1			;BIT DE INFORMACION



		ORG H'0000'

		BSF 	STATUS,RP0		;PAGINA 1
		MOVLW	B'00000000'		;
		MOVWF	OPTION_REG		;CONFIGURA OPTION
		MOVLW	B'00000000'		;
		MOVWF	TRISA			;CONFIGURA PUERTO A
		MOVLW	B'00000000'		;
		MOVWF	TRISB			;CONFIGURA PUERTO B
		BCF		STATUS,RP0		;PAGINA 0

;++++++++++ FIGURA 1 +++++++++++++++

		MOVLW	D'170'			;CONTADOR SEGUNDOS
		MOVWF	CONTS			;
FIG1	MOVLW	D'229'			;CONTADOR 14mS
		MOVWF	CONTV			;
HOR1	MOVLW	D'18'			;CONTADOR 64uS
		MOVWF	CONTH			;
		
		NOP						;
		NOP						;
		BSF		PORTB,SINC		;PULSO SINCRONIA
		NOP						;
		NOP						;
		BCF		PORTB,SINC		;

SAL1	DECFSZ	CONTH,F			;64uS?
		GOTO	SAL1			;NO, CONTINUA ESPERANDO

		DECFSZ	CONTV,F			;14mS?
		GOTO	HOR1			;NO, GENERA SINC HORIZONTAL

		MOVLW	D'166'			;SI, GENERA PULSO 2mS
		MOVWF	CONTH			;
		MOVLW	D'03'			;
		MOVWF	CONTV			;

		BSF		PORTB,SINC		;PULSO EN ALTO

SAL2	DECFSZ	CONTH,F			;RETARDO DE 2mS
		GOTO	SAL2			;
		DECFSZ	CONTV,F			;
		GOTO	SAL2			;
		
		DECFSZ	CONTS,F			;TIEMPO DE PANTALLA TERMINADO?
		GOTO	FIG1			;NO, VUELVE A GENERAR FIG 1


;++++++++++ FIGURA 2 +++++++++++++++

		MOVLW	D'170'			;CONTADOR SEGUNDOS
		MOVWF	CONTS			;
FIG2	MOVLW	D'229'			;CONTADOR 14mS
		MOVWF	CONTV			;
HOR2	MOVLW	D'10'			;CONTADOR 32uS
		MOVWF	CONTH			;
		
		NOP						;
		NOP						;
		BSF		PORTB,SINC		;PULSO SINCRONIA
		NOP						;
		NOP						;
		BCF		PORTB,SINC		;

SAL3	DECFSZ	CONTH,F			;32uS?
		GOTO	SAL3			;NO, CONTINUA ESPERANDO

		BSF		PORTB,INF		;DIBUJA LINEA
		BCF		PORTB,INF		;

		MOVLW	D'07'			;RESTO DE LA ESPERA
		MOVWF	CONTH			;
		
SAL4	DECFSZ	CONTH,F			;32uS?
		GOTO	SAL4			;NO, CONTINUA ESPERANDO

		DECFSZ	CONTV,F			;14mS?
		GOTO	HOR2			;NO, GENERA SINC HORIZONTAL

		MOVLW	D'166'			;SI, GENERA PULSO 2mS
		MOVWF	CONTH			;
		MOVLW	D'03'			;
		MOVWF	CONTV			;

		BSF		PORTB,SINC		;PULSO EN ALTO

SAL5	DECFSZ	CONTH,F			;RETARDO DE 2mS
		GOTO	SAL5			;
		DECFSZ	CONTV,F			;
		GOTO	SAL5			;
		
		DECFSZ	CONTS,F			;TIEMPO DE PANTALLA TERMINADO?
		GOTO	FIG2			;NO, VUELVE A GENERAR FIG 1

		GOTO	FIG1			;REPITE SECUENCIA
								;HASTA EL CANSANCIO
	
		END

Como pueden observar el codigo esta hecho para compensar incluso los saltos del pic asi que si quieren usar este codigo en un pic mas rapido van a tener que recalcular todos los contadores y los nops que vean

Aqui se generan 2 pantallas... la primera es completamente negra y dura unos 3 segundos, la segunda es una raya (o mejor dicho barra) en el centro de la pantalla y tambien dura 3 segundos... despues se repite la secuencia....
 
Gracias, lo había leído, pero pensé que era solo para ntsc. ops:

Por otro lado, hice un código que se podría poner en las scanlines y me da que con 20MHz se pueden hacer 231 pixeles y los pixeles múltiplos de nueve son iguales a los de la izquierda.

Voy a ver si implemento VSYNC y hago alguna animación sencilla.

En tu video, los cuadrados se ven separados, es por algo en particular? o es a propósito?

Saludos,
Gonzalo
 

Adjuntos

  • palimagen_154.txt
    3.7 KB · Visitas: 65
gzaloprgm me equivoqué con la sincronía, ahora que veo mi codigo me doy cuenta que estoy equivocado, la cosa es asi:

- Primero se ocupan pulsos de sincronía cortos: 30 us Negro, luego 2 us Sync, 30 us Negro y otra vez 2 us Sync, con eso logras los 64us que dura una línea horizontal, eso lo debes repetir 3 veces, es decir 192us
- Luego van los pulsos de sincronia largos: 30us de Sync, luego 2 us Negro, 30us Sync y de nuevo 2 us de Negro, de nuevo son 64us y repites esos pulsos 3 veces para tener 192us
- Al final se vuelven a necesitar pulsos de sincronía cortos: 30 us Negro, luego 2 us Sync, 30 us Negro y otra vez 2 us Sync, con eso logras los 64us que dura una línea horizontal, eso lo debes repetir 3 veces, es decir 192us

Así hago yo la sincronización vertical. Es distinto al tiempo que dice Chico3001 pero segun lo que yo he investigado la sincronía vertical debe durar el tiempo de 9 líneas horizontales, 576us, el tiempo que dura la sincronización que yo digo.

-- Edito --
Tengo entendido que el tiempo de sincronia es igual para PAL así que no debes tener ningún problema.

Y sobre tu pregunta de la línea negra entre cada cuadro, ¿era para mi?, si es así las líneas negras aparecen para que se vea bien definido cada cuadro, son intensiónales y escritas directamente en el código.
 
Sí, era para tí. Gracias por la explicación.

Chico3001, estás seguro que son cada 14ms los períodos de sinc. vertical?

(14 milliseconds) / (64 microseconds) = 218.75 (?)
el ,75 es lo que me intriga.

Además, no debería dar 625lineas /2 ?

Estoy cada ves más confuso con esto

Saludos,
Gonzalo
 
El programa funciona.. fue mi proyecto de fin de carrera en la materia de TV... pero la verdad lo hice hace 8 años y se fue extraviando la documentacion del proyecto y solo me quedo el programa, por lo que la verdad no se si sea correcto o solo jalo "de chiripa" como decimos en mexico

Recuerdo que tenia problemas casi al final de la pantalla donde se empezaba a perder un poco la sincronia horizontal y la linea se comenzaba a desviar al inicio de la pantalla... pero nunca pude averiguar si era debido a inconsistencias en el cristal o por que haya tenido errores al generar alguna sincronia

Estoy reanalizando el programa para ver el por que de los 14mS, pero se me ocurren 2 ideas.. una que el comentario este errado y sea un contador de numero de horizontales que se estan generando (que es lo mas probable) y otra que el restante del tiempo sea parte del todo el codigo sumado...

Mientras te dejo esta pagina que es donde me estoy basando en revisar los calculos...

http://www.desi.iteso.mx/telecom/siscom/tv/información/senal_de_video.html
 
En ese enlace dice lo siguiente:

* El intervalo de tiempo correspondiente al retroceso vertical tiene una duración de 9 líneas horizontales.
* Las 3 primeras líneas forman una zona denominada como de igualación, las 3 líneas centrales son en sí el pulso de sincronía y las últimas 3 líneas horizontales forman otra vez una zona de igualación.
* En todo el intervalo de retroceso vertical los pulsos de sincronía se producen al doble de la frecuencia: 31,468.5 Hz.
* En las zonas de igualación los pulsos de sincronía son invertidos en su forma

Es lo mismo que había leido yo en otra parte, la sincronía vertical tiene una duración de 9 líneas horizontales asi que la duración no puede ser de 14ms sino de 576us como dije en el post anterior., que bueno es encontrar información en español, y de una universidad, que respalde lo que leí.

Gracias por el enlace Chico3001, ya lo guardé para futuras referencias.
 
mmm eso explica muchas cosas... en mi programa mantengo el pulso en cero durante 2mS posiblemente por eso se pierde la linea al final de la pantalla....

Mucho cuidado... si tu vez en el esquema el pulso de sincronia vertical es un tren de pulsos horizontales de ciertas medidas... y todo ese rango de pulsos mide 9 pulsos horizontales...
 
Si, las medidas deben corresponder con las que puse en los mensajes anteriores, es decir 30us y 2us alternando entre Negro y Sync, primero el tiempo equivalente a 3 lineas horizontales en donde la señal de 2us es la Sync, luego 3 líneas horizontales donde los 30us correspondan a Sync y de nuevo 3 línes horizontales donde Sync dure 2us, alternando las señales asi hasta que se completen las 9 líneas horizontales.
 
Entonces la forma es esta?

  • Lineas impares (64us * 305) = 19,520 ms

    Pulsos cortos lineas impares (32us * 6)
    Pulsos largos (32us * 5)
    Pulsos cortos lineas impares (32us * 5) En total, 8 líneas de vsync = 0,512ms

    Lineas pares (64us * 305) = 19,520 ms

    Pulsos cortos lineas pares (32us * 5)
    Pulsos largos (32us * 5)
    Pulsos cortos lineas pares (32us * 4) En total, 7 líneas de vsync = 0,448ms
TOTAL=40ms = 1/25 (25 FPS)!

Alguien corríjame si me equivoco, son las 3:30 de la mañana :LOL:

Es el sincro vertical para PAL!

http://en.wikipedia.org/wiki/Vertical_synchronization_pulse
http://web.archive.org/web/20070325...projects/video/pic/vinformación_vsync_big.png

Mañana armo el código y me fijo si funciona bien.

Saludos,
Gonzalo
 
META, el pic32 sera muy potente pero parece que no gusta, mira que llevan tiempo intentando promocionarlo y no les funciona, pasate por el foro de microchip y compara los dspic con el pic32 y no hay brillo por algo sera.

Uno de los problemas de los pic cuando generamos imagenes son los saltos que hacen saltar la pipeline y se saltan pasos intermedios y eso no se puede solucionar con un nop al ser medios ciclos.


El error que sale en la parte inferior puede ser un problema de post ecualizacion, no tiene exactamente la misma duracion la pantalla par respecto la impar.
 
p0 equ 0x20
p1 equ 0x21
p2 equ 0x22
p3 equ 0x23
p4 equ 0x24
p5 equ 0x25
p6 equ 0x26
p7 equ 0x27
p8 equ 0x28
p9 equ 0x29
p10 equ 0x2A
p11 equ 0x2B
p12 equ 0x2C
p13 equ 0x2D
p14 equ 0x2E
p15 equ 0x2F
p16 equ 0x30
p17 equ 0x31
p18 equ 0x32
p19 equ 0x33
p20 equ 0x34
p21 equ 0x35
p22 equ 0x36
p23 equ 0x37
p24 equ 0x38
p25 equ 0x39
p26 equ 0x3A
p27 equ 0x3B
p28 equ 0x3C

movfw p0
movwf porta
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
movfw p1
movwf porta
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
movfw p2
movwf porta
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
movfw p3
movwf porta
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
movfw p4
movwf porta
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
movfw p5
movwf porta
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
movfw p6
movwf porta
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
movfw p7
movwf porta
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
movfw p8
movwf porta
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
movfw p9
movwf porta
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
movfw p10
movwf porta
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
movfw p11
movwf porta
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
movfw p12
movwf porta
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
movfw p13
movwf porta
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
movfw p14
movwf porta
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
movfw p15
movwf porta
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
movfw p16
movwf porta
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
movfw p17
movwf porta
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
movfw p18
movwf porta
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
movfw p19
movwf porta
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
movfw p20
movwf porta
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
movfw p21
movwf porta
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
movfw p22
movwf porta
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
movfw p23
movwf porta
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
movfw p24
movwf porta
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
movfw p25
movwf porta
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
movfw p26
movwf porta
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
movfw p27
movwf porta
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
movfw p28
movwf porta
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1
rlf porta, 1 ; (9*29)-1 instrucciones / 260 instrucciones = 52us / (8*29)-1 pix. = 231 pixeles
; 260 WORDS ROM / 29 BYTES RAM
 
tiopepe123 dijo:
META, el pic32 sera muy potente pero parece que no gusta, mira que llevan tiempo intentando promocionarlo y no les funciona, pasate por el foro de microchip y compara los dspic con el pic32 y no hay brillo por algo sera.

Uno de los problemas de los pic cuando generamos imagenes son los saltos que hacen saltar la pipeline y se saltan pasos intermedios y eso no se puede solucionar con un nop al ser medios ciclos.


El error que sale en la parte inferior puede ser un problema de post ecualizacion, no tiene exactamente la misma duracion la pantalla par respecto la impar.

Entonces estás diciendo que los PIC32 son una basurilla. ME daré el salto al foro de Microchip a ver http://forum.microchip.com/

¿Tanto que por ahí decían que es muy bueno y7 potente con sus 80MHz y al final no sirve para nada?

Pues salió en noviembre del 2007 que recuerdo que decían que es genial y que no se que historias... Si no vende, entonces a ver que harán, porque los de 8 Bits se venden como rosca. La verdad es que siempre encuentro muy poca información sobre ellos y en otros foros lo han comprado y les encanta, eso si, menuda maraña de cables.

Pues Microchip que tanto presume de ellos, vamos a ver que harán, porque el 16F sea mejor que el PIC32 para TV como que sorprende.

Bueno, pues, a probar un 16F88 a TV, que tiene más memoria.

PD: Aún así, tengo ganas de ver proyectos de esos PIC32 que nunca se lo he visto a nadie y la programación tanto en ASM como en nivel alto.

EDIT:
Bueno, para lo que se quieres registrar y sacar más información sobre PIC32...

http://www.mypic32.com/

No sabía que había una Web de ellos mismos sólo con sus PIC32.
 
Atrás
Arriba