Jak generować czarno-biały sygnał wideo za pomocą mikrokontrolera?

Question

Chciałbym móc za pomocą uC wyświetlać obraz na telewizorze, czytałem różne artykuły, aczkolwiek nie dużo z tego rozumiem(często sprowadzały się np do wyświetlenia pasów, a co ze znakami?), mógłby mi to ktoś wytłumaczyć w miarę prostymi słowami? Obraz nie musi być kolorowy, czarno-biały wydaje mi się że będzie łatwiej obsłużyć.
Będę bardzo wdzięczny za pomoc :wink:

tymon_x · Accepted Answer

TV Terminal Atmega8 Generate Video Signal Na obrazkach to lepiej widać (;

tymon_x · Accepted Answer

Pionowe linie V-sync do szczęścia nie potrzebują (; Na temat dokładnych timming'ów i ramek, skorzystaj z tego:
PAL video timing specification
Video Signal Measurement
Monochrome Composite Video
Przygodę z assemblerem można zacząć od tego:
Kurs asemblera dla AVR w przykładach PL
Liczne przykłady asm
www.atmel.com
W ten sposób łatwo uzyskasz dokładność do 0.1us i będziesz miał pełną kontrolę na sygnałem.

Promuję tematy:
05.02.2017 uTest - framework C++ do testów jednostkowych dla urządzeń wbudowanych

KaW · Answer

Trzeba poszukać struktury sygnału VIDEO.Najprosciej to bedzie znależć jakąś
gre WIDEO .Były takie -wkładało się do nich "gre'.
W układzie tej gry jest układ scalony zawierający modulator i wydajacy na zewnątrz sygnał /treść/.
Przy łucie szczęscia mozna kupić jakaś gre stara.To tak w bardzo dużym skrócie,,,

Mam na sprzedaż:
15.03.2008 Para BD139B/140B
15.03.2008 Para tranz. BD249C/250C
15.03.2008 Para tranz. KD503
15.03.2008 Para tranzystorowa 2N5303

defrag07 · Answer

Zgodnie z tym żeby zapalić dany piksel muszę ustawić odpowiednio pin VIDEO na 1 na czas 52us/768? dobrze rozumiem czy niekoniecznie?

tmf · Answer

Generalnie tak. Z tym, że musisz ciągle generować pełen sygnał video. W linkach tymona masz elegancko wszystko wyjaśnione.

defrag07 · Answer

Z linków oczywiście coś skorzystałem, tylko z tym moim angielskim różnie bywa, a o asemblerze już nie wspominając, ale ogólnie dzięki za zainteresowanie, postaram się coś sklecić, w razie czego będę pisał, tylko jeszcze jedna wątpliwość, ten generowany sygnał mam podłączyć przez przejściówkę czincz(ten zółty) do euro w telewizorze?

Konto nie istnieje · Answer

Dowolnie.

defrag07 · Answer

OK, nabazgrałem coś, prosiłbym o sprawdzenie i skorygowanie:


#define F_CPU 1000000
#include <avr/io.h>
#include <util/delay.h>
int main(void)
{
	DDRB=0x3;
	PORTB=0x0;
	//pb0 450 om
	//pb1 900 om
	while(1)
	{
		PORTB=0x0;
		_delay_us(4);
		PORTB=0x2;
		_delay_us(8);
		PORTB=0x1;//szary
		_delay_us(5);
		PORTB=0x2;//czarny
		_delay_us(18.5);
		PORTB=0x3;//biały
		_delay_us(5);
		PORTB=0x2;//czarny
		_delay_us(18.5);
		PORTB=0x1;//szary
		_delay_us(5);
	}
}

tymon_x · Answer

Najlepiej puścić na TV i sprawdzić (; Nie bez powodu ludzie piszą w assemblerze, bo w tedy mają najlepszy timming. Jeśli nie pójdzie (nie złapie synchronizacji), lub się rozjedzie, wiedz że przy zegarze 10MHz masz 100ns na cykl. Zapis w assemblerze do portów IO, to dwie instrukcje (LDI, OUT), czyli dwa cykle zegarowe, co daje 0.2us. Przy siedmiu zapisach (PORTB) daje 7*0.2us=1.4us dodatkowe. Nie wiem jak z dokładnością funkcji _delay_us(); sprawdź w deassemblerze. Do tego skok rjmp, czyli pętla while() 2 dodatkowe cykle. Tak na przyszłość, żebyś wiedział co nie będzie grało, jak obraz będzie migotać (;

Promuję tematy:
05.02.2017 uTest - framework C++ do testów jednostkowych dla urządzeń wbudowanych

tmf · Answer

defrag07 - poczytaj najpierw jak wygląda sygnał video - jak ten twój przykład ma działać, skoro nie ma tam np. impulsów synchronizacji. Poza tym porzuć C, nawet nie chodzi o szybkość, chociaż to też, ile o determinizm. W C nie masz zbyt wielkiej kontroli nad tym co wygeneruje kompilator, a tu się liczy każda instrukcja.

tymon_x · Answer

Chyba mi się zdaje, ale synchronizacje oparł na tym:
Jak generować czarno-biały sygnał wideo za pomocą mikrokontrolera?

U umieścił to w takim kodzie:

 PORTB=0x0; 
_delay_us(4);

Tak poza tym da się wszytko napisać w C, tylko trzeba myśleć niskopoziomowo (; Można zastosować zawsze wstawki asm, tak dla pewności.

Promuję tematy:
05.02.2017 uTest - framework C++ do testów jednostkowych dla urządzeń wbudowanych

tmf · Answer

Nawet jeśli, to H-Sync ma trwać 4,7us, potrzebujemy forward blanking time, line blanking, no i przede wszystkim V-sync.

defrag07 · Answer

No niestety przewidywania się sprawdziły, są jakieś linie, ale nie wygląda to tak jak ma wyglądać :cry:

Coraz bardziej zastanawiam się nad asemblerem, tylko w zasadzie czas na naukę zaczyna się kończyć, bo przyjdzie szkoła i nie będzie go za wiele. Moglibyście z doświadczenia napisać ile mniej więcej trzeba czasu bym nauczył się asemblera w takim stopniu bym mógł rozwiązać ten problem, oraz w miarę sprawnie posługiwać się pętlami, instrukcjami warunkowymi, funkcjami, operacje na portach, UART, SPI, timery?

Aktualizacja

Pozmieniałem troszkę:


#define F_CPU 10000000
#include <avr/io.h>
#include <util/delay_basic.h>
int main(void)
{
	DDRB=0x3;
	PORTB=0x0;
	//pb0 450 om
	//pb1 900 om
	while(1)
	{
		PORTB=0x0;//h-sync
		_delay_loop_2(45);
		PORTB=0x2;//back porch
		_delay_loop_2(55);
		PORTB=0x1;//szary
		_delay_loop_2(38);
		PORTB=0x2;//czarny
		_delay_loop_2(198);
		PORTB=0x3;//biały
		_delay_loop_2(38);
		PORTB=0x2;//czarny
		_delay_loop_2(198);
		PORTB=0x1;//szary
		_delay_loop_2(38);
		PORTB=0x2;//front porch
		_delay_loop_2(12);
	}
}

Uzyskałem coś takiego:

Jest to w miarę do przyjęcia?

tmf · Answer

To zależy, jeśli znasz jakikolwiek assembler to jest to kwestia paru dni. Jeśli dobrze znasz język programowania wyższego rzędu, np. C, to jest to kwestia 2-3 tygodni. Jeśli nie umiesz programować to jest to kwestia roku i więcej. Wartości absolutne mogą się zmienić w zależności od twoich zdolności, proporcje będą mniej więcej zachowane.
BTW, w necie masz pełno gotowców jak generować obraz video, spróbuj uruchomić któryś z nich i postarać się zrozumieć o co chodzi.
tymon_x - jak nie dasz V-sync to wszystko ci będzie latać. Nie zapominaj, że tor wyświetlania jest analogowy i info na temat początku ramki jest niezbędne.

Dodano po 1 [minuty]:

Obraz jest do przyjęcia, o ile to coś jest wyświetlane stabilnie. Jeśli ci się linie przesuwają to niedobrze.

Promuję tematy:
18.08.2023 Przerwania UART - co warto wiedzieć, aby je efektywnie wykorzystywać
07.08.2023 UART i kontrola przepływu danych dla początkujących i nie tylko
29.07.2023 AY-3-8910 – układ stary, ale ciągle jary – budujemy odtwarzacz starych melodyjek
18.06.2023 Układy BMP280/BME280 – proste przetworniki ciśnienia, temperatury i wilgotności
31.05.2023 Wyświetlacze OLED RGB: parametry elektryczne, interfejs i kod inicjujący kontroler

tymon_x · Answer

Myślałeś, że o tym nie wiem (; Pewnie, że będzie latać, ale jak widać z synchronizacją poziomą szybko mu poszło, do dalszego zapoznawania się z tematem podesłałem mu odpowiednie linki. A to już blisko, do utrzymania stabilnego, statycznego obrazka (;

EDIT.
Jakbyś chciał lekturę na ten temat, polecam: "Mikrokontrolery AVR ATtiny w praktyce". Może to assembler na Attiny, ale to prawie to samo, z małymi wyjątkami. Na stronie BTC znajdziesz przykładowe programy "listingi".

Promuję tematy:
05.02.2017 uTest - framework C++ do testów jednostkowych dla urządzeń wbudowanych

tmf · Answer

Tylko trochę bez sensu jest pisanie programu od tyłu. A twoje zdanie "Pionowe linie V-sync do szczęścia nie potrzebują (;" można raczej zrozumieć, że V-sync jest niepotrzebne
Lepiej zacząć konstruować poprawną ramkę, począwszy od V-sync, co da przynajmniej jednolity, stabilny obraz. A potem do tego dokładać kolejne elementy - H-sync i dopiero na końcu bawić się w pixele.

tymon_x · Answer

Ojj tam przesadzasz, szybko i łatwo wygenerował obraz? Wygenerował, może bez stabilizacji, ale wygenerował. Zainteresuje się, zapozna się z tematem i może niedługo coś światu zaprezentuje (; Sam bym od początku do końca tak zrobił jak mówisz, ale czasem lepiej układać coś z klocków niż lepić z gliny od razu zamek (;

Promuję tematy:
05.02.2017 uTest - framework C++ do testów jednostkowych dla urządzeń wbudowanych

Konto nie istnieje · Answer

Ale to Ty powinieneś wiedzieć czy jest do przyjęcia. Przecież to Twój temat i to Ty najlepiej wiesz co chcesz uzyskać. Jak chciałeś uzyskać takie paski jakie uzyskałeś, to jest do przyjęcia. Jak nie, to nie.

ktrot · Answer

Nie dostałeś pasów pionowych tak jak zamierzałeś, bo pętla while ze wszystkim co jest w środku nie trwa 64us. Nie musi być idealnie 64us z nie wiadomo jaką dokładnością - generator w odbiorniku dopasuje się do niewielkiej odchyłki. U ciebie kłopot mógł być z delay_us(18.5) - nie wiem co kompilator z tym robi czy zamienia float 18.5 na int 18 czy bierze 2 bajty z tego float 18.5 i traktuje to jako int. Aby uzyskać pionowe pasy jak oczekiwałeś możesz dopasować pętlę while aby trwała 64us (dokładając np puste instrukcje jak: a=1 lub dokładniej asemblerowe #asm("nop") ). Najlepiej jednak by było wszystko co jest w pętli while wrzucić do przerwania timera wywoływanego co 64us. Poczytaj o tym.
Nie potrzeba asemblera, żeby zrobic prostą grafikę na tv. Rozdzielczość ok 60x250 da się zrobić w C.

tmf · Answer

ktrot - argumentem delay jest double. Więc 18.5 zostanie przeliczone na ilość cykli i wszystko będzie ok. Z pewnością nie trzeba pisać własnych pętli, tym bardziej, że forma pętli opóźniającej którą podałeś nie zadziała.

defrag07 · Answer

Zgadzam się z _delay_us to miałem lewa stronę w zasadzie do 1/3 szaro białą, a reszta czarna, więc _delay_us oprócz odczekiwania, tak na mój głupi rozum musi marnować kilka cykli na jakieś swoje widzi mi się, aczkolwiek spodziewałem się pasów pionowych. Z timerem też myślałem tylko muszę się zastanowić bo i tak i tak muszę jakoś przerwy stosować, a znowu jak bym użył if dla sprawdzenia czy już wykonać, to znowu pewnie stracę parę cykli i coś nie wyjdzie, no chyba że wywołałbym if troszkę wcześniej z uwzględnieniem cykli zmarnowanych. Być może się mylę, więc proszę o poprawę w razie czego, o "nop" też myślałem, ale troszkę by tego wyszło, ktrot a robiłeś już taką grafikę, byłbyś w stanie podrzucić jakiś prosty kodzik?
A co tego co chcę uzyskać, to możliwość wyświetlania znaków, ale to najpierw zdolność rysowania pojedynczych pikseli
A jeszcze takie pytanie to całe h sync i v sync to dopiero prowadzi do powstanie piksela, coś w stylu x i y, bo ja mam już mały mętlik w głowie?

tymon_x · Answer

V-sync - synchronizacja pionowa (vertical), obraz nie lata góra/dół. H-sync - synchronizacja pozioma (horizontal), obraz nie lata na boki. Obie dobrze dobrane czasowo, sprawiają że obraz nie pływa po ekranie, czyli jest w jednym stabilnym miejscu przez stały czas. Najprościej, punkt (0,0) piksela jest tam gdzie powinien być i nie biega sobie po ekranie (;. Generalnie pierwsza linia pikseli (n, 0) występuje po pierwszym V-sync i H-sync, każda kolejna linia po H-sync (n, m), natomiast następny zestaw V-sync i H-sync zapowiada koleją klatkę i proces się powtarza. Jest typowe dla kineskopowych TV/Monitorów, bo dzięki temu sterujesz działem elektronowym i Twój elektron (piksel) trafia tam, gdzie Ty chcesz. Trochę teorii: Na przykładzie CRT Jak już pisał, można to napisać w C, postaraj się uzyskać pełną ramkę na podstawie tych informacji co Ci przesłałem. Będziesz miał w tedy tzw. basic-of-basic żeby przenieść to na assembler. Przesadzasz, jak się chce można wszystko: Example 1 Example 2 (NTSC)

Nawigator · Answer

Na dobry początek może być taki projekt: Sprawdzony i dobrze opisany. Oraz to - AVR Video Generator with an AVR Mega163: N.

defrag07 · Answer

Coś mi się rozjaśniło, czyli ja tylko robię to kolejne hsync, a brak mi v sync, czyli trzeba mi jeszcze te linie określane jako 1-23, 311-318 i te przy końcówce, bo w nich jest to całe v sync.

tmf · Answer

Póki co to brak ci i V i h-sync. Długość impulsu synchronizacji poziomej jest ściśle określona, to co ty generujesz niespecjalnie jest rozpoznawane jako h-sync, gdyby było nie miałbyś poszarpanych poziomych pasków tylko pionowe. Długość linii też jest ściśle określona - tu znowu nie trzymasz timingów. Także zacznij najpierw od dokładnego przeczytania literatury, do której dostałeś linki, bo inaczej nic ci z tego nie wyjdzie.

ktrot · Answer

Tak na prędce skleciłem układ i napisałem programik.

Pętla while programu:


while(1)
{
PORTD=0; delay_us(6);
PORTD=2; delay_us(12);

PORTD=1; delay_us(6);
PORTD=2; delay_us(6);
PORTD=0; delay_us(6);
PORTD=1; delay_us(6);
PORTD=2; delay_us(6);
PORTD=0; delay_us(6);
PORTD=1; delay_us(6);
PORTD=2; delay_us(6);
}

Ani impulsy synchronizacji (u mnie np Hsync ma 6us), ani długpść linii nie są szczególnie wymagające - trzeba je zachować "mniej więcej" - nie podam ci w jakich granicach bo to zależy od odbiornika. Nie uruchamiaj tego programu pod Winavr bo napisałem to pod innym kompilatorem - m.in delay_us() przyjmuje tylko wartości int jako argument. Pokazuję tylko, że można te pasy wygenerować w C i to bez timera. Niemniej namawiam cię na użycie timera - bez niego ciężko zrobić najprostszą grafikę.

gaskoin · Answer

sorry, że się przyczepię: 18 maja? jakim ? I co za różnica czy delay przyjmuje liczby całkowite czy też nie ?

ktrot · Answer

Data w aparacie nie ustawiona. Choćby taka, że float czy double zamiast int zmienia timingi, ponadto inny kompilator generuje inny kod (dłuższy lub krótszy) co w efekcie może spowodować wystarczające zmiany aby zerwać synchronizację.

gaskoin · Answer

niby w jaki sposób ? Skoro wszystko jest liczone na etapie kompilacji a nie w procesorze dlatego pytam jakiego kompilatora używasz

Jak generować czarno-biały sygnał wideo za pomocą mikrokontrolera?

Jak wygenerować stabilny czarno-biały sygnał wideo z mikrokontrolera, żeby wyświetlać na telewizorze znaki lub prostą grafikę?

Post #1

Post #2

Post #3

Post #4

Post #5

Post #6

Post #7

Post #8

Post #9

Post #10

Post #11

Post #12

Post #13

Post #14

Post #15

Post #16

Post #17

Post #18

Post #19

Post #20

Post #21

Post #22

Post #23

Post #24

Post #25

Post #26

Post #27

Post #28

Post #29

Post #30

Podsumowanie tematu