Generovani VGA signalu

Literaturu? To snad nie. Potrebujes specifikaciu. Uplny zaklad je napr.
http://www.javiervalcarce.eu/wiki/VGA_Video_Signal _Format_and_Timing_Specifications

elektricky tam je na RGB signaloch tusim 0.7Vpp do 75ohm zataze, takze musis mat nejake budice (uplne staci 3x NPN tranzistor v zapojeni emitorovy sledovac do 75ohm odporu), a zrejme aj nejaky dalsi HW ptz uC asi nebude zvladat takto rychlo generovat pixely (pixel clock je od 25MHz vyse, zavisi od rozlisenia. T.j. potrebujes robit minimalne 25milionov D/A prevodov za sekundu, a to este krat 3, lebo R,G,B)
P.S. sync signaly su normalna 5V alebo 3,3V logika

este P.S. ak by si chcel len nejake zakladne farby (t.j. len digitalne RGB signaly) a ne celu farebnu skalu, a len nejake velmi nizke rozlisenie alebo zakladne obrazce, tak to bude zvladat generovat aj samotny uC, t.j. potom nepotrebujes dodatocny HW ako framebuffer a D/A prevodniky atd.

ano pouze barevne pruhy nic sloziteho o elektronickou stranku se starat nemusim to uz mam jenom mi jde ciste o program a potrebuju se naucit ty zaklady coz jsou vstupni signaly zapis dat apod..

U VGA nie su ziadne vstupni signaly a ani ziaden zapis dat. Je to analogove RGB + digitalny H a V synchro.

ano spatne jsem to rekl, potrebuju jenom vedet zaklady se zbytkem mi poradi ve skole jenom se potrebuju od neceho odrazit

Tak zaklady mas na tom linku co som dal, viac vpodstate clovek ani nepotrebuje. Takze mozes zacat uvazovat jak urobis ten 32kHz Vsync a 60Hz Hsync(na to staci odpocitat si urcity pocet Vsyncov), a ako medzi nimi budes menit nejake tie R,G,B, vystupy uC.

neco takoveho jsem mel na mysli diky az budu mit to zapojeni hotove tak to sem hodim jestli by jste se nekdo na to nemrkli. zatim dekuju moc

tak tady je to schema

Sice mám zkušenosti s PIC16F, PIC18F a hlavně STM32F procesory, ne s ATMegama, ale vidím tam pár věcí, které by mohly působit potíže.

1) PIC16F a PIC18F pokud vím nemají na MCLR resp. NRST pinu pull-up, STM32F ano. Nevím, jak to je u Atmelů, ale na Na !RESET bych pro jistotu dal pull-up.
2) To samé u těch tlačítek - jestli má ATMega pullupy na vstupech přímo v procesoru, je to takto v pořádku, jinak ke každému tlačítku přidat pull-up rezistor (nějakých 10k třeba)-
3) K čemu má sloužit X4? Vypadá to jako nějaký analogový vstup - v tom případě ho připojit na AD vstup. Zvážil bych alespoň jednoduchou ochranu zenerkou nebo dvěma diodami. Kromě toho tam nevidím, že bys tam někde dával nějakej offset - pokud budeš chtít měřit i záporná napětí, budeš muset zvednout ten signál třeba o 2,5 V. Nejsnáž to uděláš tak,že vytvoříš jednoduchý odporový dělič.
4) K budoucímu návrhu desky - USB konektor co nejblíže procesoru, D+ a D- vést celou cestu od konektoru k procesoru stále u sebe a dbát na to, aby měly oba stejnou délku (aby se nestalo že třeba D- bude mít délku 17mm a D+ 21mm, zkoušel jsem si s tím hrát a nevím jak u pomalých USB u atmelů a PICů, ale u STM32F4 a OTG HS to už pak dost blbne).
5) Paralelně k napájení dej nějaký 1uF nebo 2uF kondenzátor a co nejblíže uC ještě k tomu 100nF nějaký 1nF.
6) Na ochranu USB sběrnice se mi osvědčil následující obvod: http://cz.farnell.com/on-semiconductor/nuf2221w1t2 g/ic-filter-usb-esd-protect-sot363/dp/2101235 . Má v sobě všechno krásně integrované a je sám o sobě malinkatej.

edit: 7) Nějak si ochraň i ty digitální výstupy, který vedou k VGA konektoru. Nikdy nevíš, co se kam dostane za bordel.

zdroj jeste doreseny nemam ano to je pravda on ten pripravek bude slouzit jenom na naprogramovani jednou to ukazu pri obhajobe a pak to bdue nekde lezet takze tam proto neni tolik ochran. ma to slouzit jenom na zobrazeni barevnych pruhu na monitoru

tak jsem nejak postoupil a mam dotaz jestli mi na to casovani bude stacit

<util/delay.h>

nekde jsem cetl ze to pujde ale bude obraz zvlneny nekde ze to nepujde vubec ? jak to teda je ?

Na casovanie by si mal snad pouzit HW timer/counter (ktore su v kazdom uC) a nie nejake dementne kniznice na delay. To by si uz snad mal vediet aj sam ked robis diplomku.

Ja osobne by som bud nastavil casovac na HW generovanie HSYNC frekvencie (nastavis to ako periodicke PWM a priamo na HSYNC vystup), a potom pixely generoval tak ze by som v slucke cital hodnotu casovaca a pri urcitej hodnote zmenil RGB vystupy. Sucasne by som pocital pocet HSYNC a po patricnom pocte by som generoval VSYNC. Trvanie VSYNC je presny pocet HSYNC.

Druha moznost je nastavit si HW casovac na generovanie IRQ pre kazdy pixel, za predpokladu ze uC bezi na dostatocnej frekvencii aby to stihal. A v IRQ handleri generoval R,G,B, stavy a po urcitom pocte pixelov (v IRQ handleri si ratas pocet pixelov) generoval HSYNC, a po urcitom pocte HSYNCov generoval VSYNC.
Generovat R,G,B, stavy musis velmi optimalne (co najmenej instrukcii), ptz pixel clock je spravidla dost vysoky (ked chces len pruhy tak to mas trochu ulahcene ale na optimalnost treba mysliet).

Tymito uvahami si mal zacat uplne na zaciatku, az potom sa robi schema napr. aby si vystup HSYNC dal na spravny vystup ktory moze byt PWM apod.

Tieto dve metody su podla mna normalne (ta druha je lepsia - presnejsia). Cokolvek ostatne by bolo podla mna totoalna polonefukcna sracka a keby som bol Prof. tak by som nejake delaye neakceptoval.

BTW. za predpokladu ze sa pixel clock blizi uC clocku, napr. ak je pixel clock vyssi jak desatina uC clocku, tak vyssieuvedene sposoby su problem (uC to nestiha), tak je akceptovatelne aj casovanie poctom vykonanych instrukcii. uC vykonava instrukcie v pevne stanovenom pocte clock cyklov, je to v datasheete (pocet cyklov moze zavisiet od instrukcie). Takze ak urobis vystup R,G,B, tak ze je vzdy na stejny pocet instrukcii t.j. stejny pocet clock cyklov (t.j. nemas tam ziadne if a skoky ktore by zaviseli od hodnot farieb, ale mas predpripravene hodnoty kdesi v RAM, a len ich ladujes na vystup, pomocou indexu do nejakeho pola) tak potom je to casovanie vykonanymi instrukciami velmi presne a je pouzitelne. Nic sa potom nebude vlnit.
Ak su tie tvoje delaye deterministicke (trvaju vzdy presny pocet cyklov) tak mozes pouzit aj delaye, ale za normalnych okolnosti su delaye v tomto pripade samozrejme len na skodu, ptz predpokald bol predsa ze uC nestiha.
No a predpoklad v tomto pripade je aj ten ze vsetky IRQ musia byt zakazane samozrejme, inac to casovanie nebude presne a pixely budu skakat po obrazovke sem a tam.

Menit data v RAM (ak chces animaciu apod) si mozes potom pocas HSYNC a VSYNC, tam sa da pouzit potom HW casovac a robit nieco ine pocas sync signalov.

animaci nepotrebuju. jenom barevne pruhy zatim je pro mne dulezite co musim stihnout do 12 prosince aby monitor zjistil ze v ze ma zobrazovat ve VGA tj trefit tu Frekvenci +/- 60Hz takze v case pro zapis RGB dat necham momentalne prazdny. jde o to ze jsem pres ty Citace/casovace nebyl moc zbehly ale asi mas pravdu bude to treba dostudovat.
zitra se pustim do toho at mam aspon uz nejaky nastrel zatim diky za tvuj cas

Ono vpodstate na VGA bude najlepsie pouzit ten posledny sposob, ptz ten prvy by bol nepresny (triaslo by sa to horizontalne) a to s IRQ nepotrebujes nutne robit, kludne tam prdni ten tvoj delay, mas argument ten ze u VGA si na limite s frekvenciou a teda casovanie robis poctom instrukcnych cyklov.

Frekvencia nemusi byt uplne presna, monitory nemaju problem s odchykou. Vyrataj si to priblizne. Hlavne dbaj na to aby tvoje instrukcie boli deterministicke pri kazdom priebehu, t.j. napr. ber hodnoty z pola, ziadne if else podla farby alebo co (if podla horizontalnej polohy je ok). Potom sa nebude nic vlnit ptz instrukcia uC trva vzdy presny pocet cyklov, nemeni sa to.

... takze urob to s tymi delaymi, bude to ok. Ser na to co som pisal v tej predpredoslej reakcii, to som sa trochu unahlil s usudkom

Este nieco, tie RGB by si mal nastavit naraz, vsetky 3 vystupy jednym pristupom na I/O register. Lebo keby si ich menil postupne po jednom tak budes vidiet postupne farebne prechody pri zmene farby.

dekuju zatim za tvou pomoc velmi si mi pomohl precetl jsem si cely ten clanek a po par konzulatci s ucitelem mam v tom sice jasno ale mam jeste par dotazu

1.Zacnina se s HSYNC to vim ale nevim jestli po zapisu posledniho radku je nejaka jina prodleva nez ta bezna mezi radky
2.Nekde jsem se jeste docetl ze pry sice rozliseni je 640*480 ale jsou tam tzv skryte pixely ktere se sice nevykreslujou ale musim je do programu zapsat (klidne jako prazdne misto)
3. do VSYNC zapisuju data Log. 0

mohl by jsi mi jeste s temi 2. problemy pomoct ?
dekuju moc za tvuj cas

vsetko to mas nakreslene aj s presnymi hodnotami (zaujima ta C a E u riadku, a Q a S u VSYNC) na tom linku co som dal uplne v prvej odpovedi.

... hodnoty v ms si prepocitaj na pocet pixelov resp. riadkov podla rozlisenia napr. z prveho stlpca, z toho sa zas nestriela.

P.S: sync rob obe negativne (t.j. aktivne v log.0) ptz robis relativne pomale rozlisenie (frekvenciou ekvivalent 640x480 60Hz apod).

takze 1. nastrel programu bych mel
problem je v tom ze 3-5 pixelu jsou posunuty to bude nejspis kvuli doby na zpracovani instrukci (?) .

#include <avr/io.h>
#define F_CPU 20000000 // 20 MHz
#include <util/delay.h>

// PB4 = VSYNC

uint16_t x=0  ;   //Promenna x (8 bit cislo) 

int main()
{
	DDRB = (1<<PB4) + (1<<PB2);
	PORTB = (1<<PB4) + (1<<PB2);
	DDRC = 0b00000111;	

	while(1)
	{
		// viditelná oblast
		x = 480;
		while(x--)
		{
			// vykreslení jednoho řádku
			PORTB = (1<<PB4) + (0<<PB2);	
			_delay_us(3.8);
			PORTB = (1<<PB4) + (1<<PB2);	
			_delay_us(1.9);

			PORTC=0b00000111;
			_delay_us(20);
			PORTC=0b00000101;
			_delay_us(5.4);
			PORTC=0b00000000;


			_delay_us(0.6);


		}

		// neviditelné řádky
		x=10;
		while(x--)
		{
			// vykreslení jednoho řádku
			PORTB = (1<<PB4) + (0<<PB2);	
			_delay_us(3.8);
			PORTB = (1<<PB4) + (1<<PB2);	
			_delay_us(1.9);

			_delay_us(25.4);

			_delay_us(0.6);

		}

		// vertikální synchronizace
		x=2;
		PORTB = (0<<PB4) + (1<<PB2);
		while(x--)
		{
			// vykreslení jednoho řádku
			PORTB = (0<<PB4) + (0<<PB2);	
			_delay_us(3.8);
			PORTB = (0<<PB4) + (1<<PB2);	
			_delay_us(1.9);
			
			_delay_us(25.4);

			_delay_us(0.6);
		
		}

		// neviditelné řádky
		x=33;
		while(x--)
		{
			// vykreslení jednoho řádku

nechapem co mas kde jak posunute ale to ze musis ratat s dobou vykonavania kazdej instrukcie som uz pisal vyssie.

lamu si hlavu nad posledni veci a nemam tuseni jak udelat vodorovny pruh nema nekdo nejaky tip ?

Vidím céčko, tak zkusím tipnout.. Pomocí počítadla řádků? Že bys počítal řádky a třeba dal podmínku, že když je to řádek > 100 a < 150, tak to bude vykreslovat jinak barevné řádky.

ale jo tipnul si spravne stacilo X=480 rozdelit po dvou na 240 a v kazdem zmenit barvu diky moc.

jeste jedna posledni vec ze to obcas problikne ale to jenom na mojem monitoru doma kdyz to skusim jinde funguje to normalne.muzu to nejak ovlivnit nebo je to kvuli elektroniky monitoru a nepresnosti mojeho signalu ? (doba trvani prikazu a nepresne casovani)