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
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,,,
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?
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ć (;
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.
No niestety przewidywania się sprawdziły, są jakieś linie, ale nie wygląda to tak jak ma wyglądać 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?
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.
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".
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.
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 (;
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.
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.
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.
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?
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.
defrag07 napisał:
A co tego co chcę uzyskać, to możliwość wyświetlania znaków, ale to najpierw zdolność rysowania pojedynczych pikseli
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.
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.
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ę.
I co za różnica czy delay przyjmuje liczby całkowite czy też nie ?
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ę.