Elektroda.pl
Elektroda.pl
X
AM TechnologiesAM Technologies
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Atmega1284p [C] - Bezpośredni dostęp do RAM - generowanie obrazu VGA

27 Kwi 2013 18:51 4557 24
  • Poziom 9  
    Witam.
    Realizuję prosty projekt generatora wideo na VGA opartego o Atmegę1284p - obraz jest generowany z pamięci RAM dosyć chałupniczą metodą: aby osiągnąć rozdzielczość 53x240 pikseli (!) tworzę 53 tablice (rozdzielczość pozioma) uint8 o rozmiarze 240 wpisów (rozdzielczość pionowa) a następnie ustawiam PORTC po kolei każdą tablicą o indeksie linii. Przykład:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Oczywiście aby uzyskać 240 linii w 480 liniowym standardzie dubluję każdą linię.
    Jak można się domyślić, problem jest z rozdzielczością poziomą.. obsługa tablicy i zmiennej oznaczającej numer linii jest powolna - dramatycznie obniża ona rozdzielczość obrazu - z około 500 cykli procesora udaje mi się wycisnąć jedynie 53 piksele (po "podkręceniu" timingów VGA - np. redukcji czasu synchronizacji poziomej udaje mi się wyciągnąć 56 pikseli, jednak oczywiście metoda pobierania pikseli z RAM jest tak samo powolna).
    Próbowałem z bezpośrednim (a może robię coś nie tak?) dostępem do RAM poprzez funkcję
    Kod: c
    Zaloguj się, aby zobaczyć kod
    gdzie ADRES jest fragmentem adresu dla danego piksela, jednak wyszło na to samo.

    Więc, przechodząc do sedna - w jaki sposób można wydajniej pobierać dane z pamięci RAM?

    Wszystkie zmienne są typu volatile uint8_t.
    Używam procesora Atmega1284p z kwarcem 20MHz. Obraz VGA generowany jest w przerwaniach. Ja sam jestem bardziej początkującym programistą atmeg, jednak wydaje mi się, że podstawy znam (kilka małych projektów w C mam za sobą) ;-) .

    PS. Używam wewnętrznego RAM'u (16 KB) - obraz 53x240 zajmuje znaczną część pamięci, jednak nie potrzebuję 240 linii obrazu - z rozdzielczości 120x120 będę całkowicie zadowolony.

    Dziękuję za pomoc i pozdrawiam :-)
    nkp123
  • AM TechnologiesAM Technologies
  • Pomocny post
    Poziom 1  
  • Poziom 9  
    Dziękuję bardzo za odpowiedź :-).
    1. Potrzebuję mieć możliwość podłączenia dowolnego wyświetlacza - telewizora, monitora. Projekt z wyświetlaczem LCD zintegrowanym z projektem odpada.
    2. Jakby się uparł, mogę wziąć bardziej nowoczesny mikrokontroler, jednak chciałbym, aby był on w technologii przewlekanej oraz aby był w rozsądnej (<40zł) cenie. No i aby to było coś w stylu Atmega/AtXmega (z naciskiem na to pierwsze).
    3. Nie mam żadnego doświadczenia w obsłudze zewnętrznego RAM, jednak jeżeli była by ona wykonalna dla osoby dosyć początkującej, to chętnie bym skorzystał :-) . Jakie by były koszty takiego rozwiązania?

    Jeżeli chodzi o asemblera - nie mam żadnego doświadczenia z nim. Mogę prosić o wytłumaczenie zasady działania tego kodu, oraz w jaki sposób wykorzystać go w kodzie, gdzie przerwanie jest wywoływane co linię obrazu oraz mamy zmienną odpowiadająca za numer linii (chociaż.. pobranie zmiennej też zajmuje czas...)?

    No i przemyślenia... trochę się zabrałem za tego typu projekt zbyt wcześnie, jednak jeżeli mam już jakieś efekty (53x240 pikseli z możliwością dowolnej modyfikacji każdego piksela podczas wolnego czasu procesora oraz wykonywania dowolnego kodu (z małym jitterem na obrazie z powodu mniej dokładnych czasów przerwań)) to może warto by było osiągnąć cele, oczywiście w miarę możliwości? :)

    PS. Kombinowałem z większym naciągnięciem standardu VGA (np. zmniejszeniu częstotliwości H i V, aby dać więcej czasu procesorowi na rysowanie pikseli), jednak moje próby spełzły na niczym. No ale to jednak logiczne, że monitory działają według standardów, a nie tak, jak chce osoba pisząca program na uC ;-) .
  • Pomocny post
    Poziom 27  
    Programowe generowanie sygnału video w jakimkolwiek standardzie jest zadaniem krytycznym czasowo, dlatego bez asemblera niewiele zwojujesz. Nawet w asemblerze trudno uzyskać więcej niż 100 punktów w linii. Zresztą zerknij na:
    Rejestrator przebiegów cyfrowych - przystawka do TV z EP 10/1999
    Rejestrator przebiegów analogowych - przystawka do TV z EP 3, 4/2000
  • AM TechnologiesAM Technologies
  • Pomocny post
    Specjalista - Mikrokontrolery
    Takich projektów znajdziesz w sieci min. kilkanaście - jest z czego kopiować, więc po co wyważać otwarte drwi?
  • Poziom 9  
    Cóż.. Wszyscy macie racje - z tego wynika, że czas zacząć powoli ogarniać asemblera ;-)
    W sieci można znaleźć projekty, wiem - jednak chciałem skonstruować coś od podstaw - nawet nie jako coś specjalnego - ma działać, mieć podstawową użyteczność i nauczyć mnie zarówno podstaw generowania sygnału VGA jak i innych ciekawych rzeczy (męczenie się z uC po błędnym ustawieniu Fusebitów - bezcenne :-) ).

    Dziękuję bardzo wszystkim za pomoc!
  • Pomocny post
    Poziom 1  
  • Poziom 9  
    Zastanowię się, co dalej zrobić jeżeli chodzi o wybranie typu procesora. W obecnej chwili i tak z powodu nauki mam ograniczone możliwości bawienia się mikrokontrolerami, jednak w przyszłości dokonam wyboru i zobaczę, jakie będą tego efekty :-) .
    Generator VGA zostawię w takim stanie, jaki jest obecnie - w ramach nauki i taka rozdzielczość będzie satysfakcjonująca :-) .
  • Poziom 43  
    Podstawowym problemem jest to że wybierasz pixele z tablic ustawionych "pionowo".
    Działało by to znaczenie szybciej jak byś pakował pixele do tablic "poziomych"
    Tzn. takich gdzie każda tablica miała by powiedzmy 53 pixele i tych tablic było by 240.
    Wtedy te tablice o 53 pixelach jako że działało by to szybciej mogły by mieć więcej niż 53 pixele.
    Na moje oko spokojnie ze 240 pixeli też by mogły mieć.
  • Pomocny post
    Moderator Mikrokontrolery Projektowanie
    Tomasz Gumny napisał:
    Programowe generowanie sygnału video w jakimkolwiek standardzie jest zadaniem krytycznym czasowo, dlatego bez asemblera niewiele zwojujesz. Nawet w asemblerze trudno uzyskać więcej niż 100 punktów w linii. Zresztą zerknij na:
    Rejestrator przebiegów cyfrowych - przystawka do TV z EP 10/1999
    Rejestrator przebiegów analogowych - przystawka do TV z EP 3, 4/2000


    Nie jest to prawdą. Należy poprawnie wykorzystać zasoby sprzętowe procesora, a wtedy wszystkie krytyczne czasowo rzeczy nie robi CPU, w efekcie będzie to działać nawet w Bascomie.
    Przede wszystkim ważna jest synchronizacja - to można załatwić timerami, szczególnie łatwe to jest w przypadku XMEGA. Kolejna sprawa - piksele. Dla obrazu mono sprawę załatwia SPI. Dla obrazu kolorowego przydaje się procek z DMA + zewnętrzny zatrzask - znowu XMEGA jest tu górą, aczkolwiek bez większych problemów można to zrealizować na zwykłej ATMedze.
    Co do XMEGA serii A1 - ułatwieniem jest w tym przypadku posiadany przez nią interfejs EBI, jednak zdecydowanie w tym rozwiązaniu nie polecam jego użycia z SDRAM - jest zbyt wolny. Z SRAM będzie działać to ok.
    Natomiast nie trzeba stosować zewnętrznej pamięci, XMEGA mają do 32 kB wewnętrznej pamięci SRAM, co wystarcza do wygenerowania obrazu w rozdzielczości 320 na 200, 4bpp. Dla obrazu mono, albo trybów alfanumerycznych wystarcza znacznie mniej. Dla XMEGA generowanie obrazu mono lub trybu monochromatycznego nie obciąża procesora więcej niż w 10-30%. Więc żadne zaawansowane sztuczki nie są potrzebne, a tym bardziej assembler. Jedyną rzeczą do której jest wymagany to króciutka wstawka w assemblerze w celu eliminacjai jitteru obsługi przerwania.
  • Poziom 9  
    Marek_Skalski napisał:
    edit:
    Nie skupiaj się na asemblerze. Warto mieć pojęcia co i jak, ale nie warto dzisiaj pisać w nim całych programów. To nie te czasy, kiedy ze sprzętu wyciskało się 110% możliwości (jak np. wychodzenie poza ramki albo FLI w VIC/C64). Jak brakuje pamięci, sprzętu albo mips'ów, to bierzesz inny kontroler, zmieniasz kilka linii albo całą architekturę+hardware i ma działać.[...]

    Rozumiem - będzie to trzeba również przemyśleć ;-) .


    atom1477 napisał:
    Podstawowym problemem jest to że wybierasz pixele z tablic ustawionych "pionowo".
    Działało by to znaczenie szybciej jak byś pakował pixele do tablic "poziomych"
    Tzn. takich gdzie każda tablica miała by powiedzmy 53 pixele i tych tablic było by 240.
    Wtedy te tablice o 53 pixelach jako że działało by to szybciej mogły by mieć więcej niż 53 pixele.
    Na moje oko spokojnie ze 240 pixeli też by mogły mieć.

    Nie potrafię sobie wyobrazić, jakby mogła działać obsługa rysowania w tablicach tak zorientowanych. Wtedy indeksem tablicy byłby numer linii, który muszę co piksel inkrementować - w moim rozwiązaniu licznik inkrementuję co linię - a linii generowanych jest znacznie mniej niż pikseli, więc mniej czasu względem rysowania tracę na inkrementację zmiennej.

    tmf napisał:
    Nie jest to prawdą. Należy poprawnie wykorzystać zasoby sprzętowe procesora, a wtedy wszystkie krytyczne czasowo rzeczy nie robi CPU, w efekcie będzie to działać nawet w Bascomie.
    Przede wszystkim ważna jest synchronizacja - to można załatwić timerami, szczególnie łatwe to jest w przypadku XMEGA. Kolejna sprawa - piksele. Dla obrazu mono sprawę załatwia SPI.

    Hmm. O SPI nie pomyślałem - cenna uwaga.
  • Moderator Mikrokontrolery Projektowanie
    Przede wszystkim zastosuj tablicę dwuwymiarową i adresuj ją tak jak radzi kolega atom. Spokojnie w mono uzyskasz 320 na 200 pikseli, a i 640 na 200 nie jest wielkim problemem (poza ilością pamięci potrzebną na bufor ramki). Jeśli rozważasz XMEGA to śmiało idź w tym kierunku - powiem ci tyle, że obsługa VGA na XMEGA to dosłownie kilkanaście linii kodu w c. Można wziąć jeszcze bardziej wypasiony MCU, ale podstawowa idea generowania obrazu będzie identyczna jak w XMEGA.
  • Poziom 1  
  • Poziom 27  
    tmf napisał:
    Tomasz Gumny napisał:
    Programowe generowanie sygnału video w jakimkolwiek standardzie jest zadaniem krytycznym czasowo, dlatego bez asemblera niewiele zwojujesz. Nawet w asemblerze trudno uzyskać więcej niż 100 punktów w linii.
    Nie jest to prawdą. Należy poprawnie wykorzystać zasoby sprzętowe procesora, a wtedy wszystkie krytyczne czasowo rzeczy nie robi CPU, w efekcie będzie to działać nawet w Bascomie.
    Wejście w procedurę obsługi przerwania zajmuje 4 takty zegara, wyjście z niej to kolejne 4 takty. Odczyt wewnętrznej pamięci RAM to 2 takty a wystawienie czegokolwiek na porcie - 1 takt. W sumie daje to 11 taktów, czyli 0.55µs przy zegarze 20MHz. Zakładając, że czas rysowania linii trwa 52µs już zjechaliśmy do 94 punktów a wypadałoby jeszcze coś do tej pamięci wpisać...
    Udał mi się uzyskać 120 punktów przy 10MHz, ale wymagało to utworzenia bufora jednej linii o krótkim czasie dostępu (z rejestrów procesora). Zawartość RAM jest doń przepisywana w czasie co drugiej linii i powrotu plamki (dokładnie nie pamiętam).
  • Poziom 9  
    Tomaszu, ja wchodzę w przerwanie raz na linię, a do pamięci video wpisuję zawartość poza przerwaniem.
  • Moderator Mikrokontrolery Projektowanie
    Marek_Skalski napisał:

    Xmega niby jest super, ale jeżeli chcesz puścić dane przez port SPI (max. 8MHz, więc teoretycznie 200pxl), to nie masz bufora i pojawia się kwestia stabilizacji obrazu. Bufor ma tylko USART w trybie SPI, ale on pracuje z prędkością do 4MHz (100pxl/linię).
    Możesz użyć DMA do transferu danych na port, z którego uzyskasz kolory, ale...
    Prędkość DMA zależy od clk_PER. Z pomocą PLL możesz ustawić na 26MHz lub 24MHz (standard VGA przewiduje zegar ~25MHz). Ale to oznacza obraz ok. 640x480. I ponownie ten sam problem - jak rozpakujesz dane dla większej ilości kolorów? Gdzie je zmieścisz, w 32kB? Nie dasz rady, bo przesyłasz całe bajty a nie pojedyncze bity (3, 4, 6 czy inne kombinacje jak 565). Każdy piksel (mono czy kolor) to 1 bajt i koniec. Dla 480 (240) linii z 32kB uzyskasz max. 68 (136) pikseli w linii przy może 256 kolorach. Warto?
    No i jeszcze ta jedna fajna rzecz z DMA... to nie jest stabilne. Jeżeli w programie jest dużo przesyłania danych, są odczyty i zapisy do SRAM poza DMA (np.CPU albo inny kanał DMA), to DMA się zatrzymuje na te 2 czy 3 cykle. Efekt będzie bardzo brzydki na ekranie. I raczej tego nie unikniesz jeżeli chcesz wyświetlać coś innego niż statyczny obraz.
    Dlatego ja będę odradzał używanie xmegi do takiego zadania. Szkoda Twojego czasu i pracy, ponieważ albo się zniechęcisz i wszystko wrzucisz do szuflady, albo i tak zmienisz platformę.


    Twoje wyliczenia są błędne. Zarówno SPI, jak i USART w trybie SPI (zalecane rozwiązanie) w XMEGA mogą nadawać z częstotliwością CLKper/2, czyli 16 MHz. Jest to więcej niż potrzeba. Dla obrazu mono nie trzeba robić żadnych synchronizacji zapisu, bo to załatwia sam interfejs. Dla obrazu kolorowego, dla synchronizacji, a właściwie likwidacji jitteru związanego z DMA można zastosować zewnętrzny zatrzask, w którym przepisywanie stanu następuje przez zbocze sygnału generowanego przez timer (pixelclock). W ten sposób z łatwością można uzyskać obraz do 8bpp.
    A jakie można osiągnąć na XMEGA efekty to proponuję spojrzeć na to demo:
    https://www.youtube.com/watch?v=CXFOTpM2Jn4
    Tu jest całkowicie programowo generowany kolorowy obraz NTSC. Informacja o kolorze też jest generowana programowo. Jak widać czasu starcza nie tylko na generowanie obrazu, ale także na całkiem niezłe animacje.
    IMHO można użyć np. ARMa, ale to nam tylko zwiększy rozdzielczość, bo problemy z jakimi się będziemy borykać będą identyczne jak dla XMEGA.

    Dodano po 3 [minuty]:

    Tomasz Gumny napisał:
    tmf napisał:
    Tomasz Gumny napisał:
    Programowe generowanie sygnału video w jakimkolwiek standardzie jest zadaniem krytycznym czasowo, dlatego bez asemblera niewiele zwojujesz. Nawet w asemblerze trudno uzyskać więcej niż 100 punktów w linii.
    Nie jest to prawdą. Należy poprawnie wykorzystać zasoby sprzętowe procesora, a wtedy wszystkie krytyczne czasowo rzeczy nie robi CPU, w efekcie będzie to działać nawet w Bascomie.
    Wejście w procedurę obsługi przerwania zajmuje 4 takty zegara, wyjście z niej to kolejne 4 takty. Odczyt wewnętrznej pamięci RAM to 2 takty a wystawienie czegokolwiek na porcie - 1 takt. W sumie daje to 11 taktów, czyli 0.55µs przy zegarze 20MHz. Zakładając, że czas rysowania linii trwa 52µs już zjechaliśmy do 94 punktów a wypadałoby jeszcze coś do tej pamięci wpisać...
    Udał mi się uzyskać 120 punktów przy 10MHz, ale wymagało to utworzenia bufora jednej linii o krótkim czasie dostępu (z rejestrów procesora). Zawartość RAM jest doń przepisywana w czasie co drugiej linii i powrotu plamki (dokładnie nie pamiętam).


    Tylko napisz o jakim procesorze mowa i czy obraz jest mono czy kolorowy. Dla obrazu mono generowanego przez USART w trybie SPI mamy 16 taktów na 8 pikseli/1 bajt, a to aż nadto. Zakładając istnienie 1 poziomowego bufora mamy do dyspozycji 32 takty. Jeśli myślisz o kolorach i ATMega (nie XMEGA) to proponuję zerknąć na projekt UZEBOX:
    http://belogic.com/uzebox/index.asp
    Jak widać nie tylko się da, ale wychodzi to całkiem nieźle. Oczywiście dla obrazu TV mamy dwa razy więcej czasu, co ułatwia zadanie.

    Dodano po 5 [minuty]:

    Aby nie toczyć dyskusji o niczym, proponuję, aby autor określił wymagania, np. rozdzielczość, głębię kolorów i możliwość użycia elementów zewnętrznych, np. dodatkowej pamięci SRAM bo to może znacznie determinować proponowane rozwiązania.
    Warto też zauważyć, że ARMy z co najmniej 128 kB pamięci SRAM na pokładzie występują w obudowach BGA lub LQFP100-144, w efekcie ich użycie w projekcie amatorskim może być czysto teoretyczne.
  • Poziom 27  
    tmf napisał:
    [...] Jeśli myślisz o kolorach i ATMega (nie XMEGA) to proponuję zerknąć na projekt UZEBOX
    Czy nadal piszemy o tworzeniu sygnału na drodze programowej?
  • Poziom 1  
  • Moderator Mikrokontrolery Projektowanie
    Tomasz Gumny napisał:
    tmf napisał:
    [...] Jeśli myślisz o kolorach i ATMega (nie XMEGA) to proponuję zerknąć na projekt UZEBOX
    Czy nadal piszemy o tworzeniu sygnału na drodze programowej?


    W UZEBOX masz obraz generowany programowo.
  • Poziom 43  
    nkp123 napisał:
    atom1477 napisał:
    Podstawowym problemem jest to że wybierasz pixele z tablic ustawionych "pionowo".
    Działało by to znaczenie szybciej jak byś pakował pixele do tablic "poziomych"
    Tzn. takich gdzie każda tablica miała by powiedzmy 53 pixele i tych tablic było by 240.
    Wtedy te tablice o 53 pixelach jako że działało by to szybciej mogły by mieć więcej niż 53 pixele.
    Na moje oko spokojnie ze 240 pixeli też by mogły mieć.

    Nie potrafię sobie wyobrazić, jakby mogła działać obsługa rysowania w tablicach tak zorientowanych. Wtedy indeksem tablicy byłby numer linii, który muszę co piksel inkrementować - w moim rozwiązaniu licznik inkrementuję co linię - a linii generowanych jest znacznie mniej niż pikseli, więc mniej czasu względem rysowania tracę na inkrementację zmiennej.

    Chyba numer pixela a nie linii?
    Jak by nie było jest to lepsze rozwiązanie.
    Bo tak się składa że inkrementowanie indexu jest prostsze niż zmienianie tablicy.
    Bo zmiana tablicy wymaga pobrania adresu początku tablicy i dodania aktualnego indexu. Ten index nie jest więc inkrementowany ale musi być dodawany.
    Z kolei przy inkrementowaniu wskaźnika z jednej tablicy nic nie trzeba ciągle pobierać i dodawać.
    Zamiast 2 operacji (pobieranie i dodawanie) mamy więc 1 (inkrementowanie).
    Pozatym w assemblerze jest instrukcja która automatycznie inkrementuje wskaźnik podczas pobierania wartości z tablicy. Zatem można uznać że inkrementowanie to jest 0 (zero) operacji.
    A 0 to na pewno mniej niż 2 czy 1.
  • Moderator Mikrokontrolery Projektowanie
    Marek_Skalski napisał:
    Ale nie podoba mi się twierdzenie o eliminacji wpływu opóźnienia DMA przez zewnętrzny rejestr. DMA pracuje z interwałem clk_PER i jeżeli się zatrzyma, to na całkowitą liczbę cykli, co oznacza przesunięcie w całych pikselach (widać to na podlinkowanym filmie) i moim zdaniem tylko FIFO taktowany stabilnym zegarem może to anulować. Przy okazji można szybciej taktować całość. Ale jeżeli FIFO, to lepiej już prosty FPGA, który będzie zwykłym automatem do obsługi pamięci video i sygnału vga, widzianym jako urządzenie i/o na szynie danych.

    Cytat:
    Warto też zauważyć, że ARMy z co najmniej 128 kB pamięci SRAM na pokładzie występują w obudowach BGA lub LQFP100-144, w efekcie ich użycie w projekcie amatorskim może być czysto teoretyczne.

    Uważam się za amatora, płytki zamawiam (ponieważ sam nigdy nie zrobię porządnej metalizacji otworów, solder maski czy opisów), nie mam super sprzętu i bez problemu korzystam z LQFP100 (xmega128a1u, pic24ep256mu810) i przymierzam się do LQFP144 albo 208, więc większe obudowy to nie jest czysta teoria.

    Ciekawy jestem jakie wymagania postawi aplikacji autor tematu?


    Zauważ, że PIXELCLOCK ma niższą częstotliwość niż CLKPER, dla obrazu VGA bedzie to 25.175 MHz dla 640 pikseli i połowa z tego dla 320 pikseli. W efekcie mamy ok. 32/12.5, czyli ok. 2.5. Wygodnie byłoby nieco przetaktować XMEGA, aby mieć stosunek np. 1:3, zegar 37,8 MHz jest akceptowalny. Dzięki temu zewnętrzny zatrzask umożliwia nam likwidację jitteru DMA sięgającego aż 3 cykli CLKper (to najdłuższa atomowo wykonywana instrukcja). Rozumiem jednak, że pomysł z overclockingiem może się nie podobać, więc nawet przy stosunku 1:2 mamy możliwość likwidacji jitteru równego 2 cykli CLKper, co dla XMEGA jest wystarczające. Dodam jeszcze, że nie piszę o teorii, bo taki układ złożyłem i przetestowałem, działa ok. Ubiegając ewentualne pytania, tego typu przykłady będą w drugiej części książki o XMEGA.
    Jest jeszcze kwestia, którą poruszyłeś - zewnętrznego FIFO. Nie będę odkrywczy jeśli powiem, że wystarczy zastosować zewnętrzną pamięć RAM SPI (8 pinowy chip w cenie paru zł) w trybie sequential read. Wtedy MCU generuje tylko sygnal SCK, może to robić np. timerem, pamięci tego typu mają sygnał HOLD, dzięki czemu całe generowanie obrazu odbywa się sprzętowo i MCU jest zajęty w 0,0% :) Wymagany jest tylko reload adresu licznika pamięci co ramkę, co jest pomijalnym obciążeniem. A jeśli mono to za mało to podpowiem, że są pamięci RAM z tzw. pattern generator, gdzie można sobie na tej samej zasadzie stworzyć wyjście z 2bpp, 4 bpp, 8 bpp i 16 bpp. Wszystko w jednej małej kostce, bez FPGA, czy innych większych i droższych elementów.
    Co do wykorzystania elementów w LQFP i BGA - z BGA nie miałem jeszcze do czynienia, LQFP lutuję transformatorówką i jest ok. Problem jednak leży w tym, że dla LQFP144 na 2 warstwach robi się ciasno, a 4 warstwy to spore koszty. No i nie wszyscy są tak odważni - nie zapominaj, że na tym forum ciągle panuje pewien (nieuzasadniony) strach przez SMD, stąd popularność jak sądzę ATMega8 dostępnej w obudowie DIL.
  • Poziom 27  
    tmf napisał:
    W UZEBOX masz obraz generowany programowo.
    ... ale już podnośnymi kolorów zajmuje się AD725. To może tworzenie ramki oddajmy w ręce... tfu! piny MC6845, I8275 lub podobnych - wszak dane wpisywać do nich będzie program. Gwoli sprawiedliwości da się wygenerować zespolony sygnał wideo z kolorami na drodze czysto programowej, ale to raczej w postaci kilku pasów niż grafiki.
  • Moderator Mikrokontrolery Projektowanie
    Tomasz Gumny napisał:
    tmf napisał:
    W UZEBOX masz obraz generowany programowo.
    ... ale już podnośnymi kolorów zajmuje się AD725. To może tworzenie ramki oddajmy w ręce... tfu! piny MC6845, I8275 lub podobnych - wszak dane wpisywać do nich będzie program. Gwoli sprawiedliwości da się wygenerować zespolony sygnał wideo z kolorami na drodze czysto programowej, ale to raczej w postaci kilku pasów niż grafiki.


    Jeśli generujesz w PAL to coś musi wygenerować color burst, ale może to też zrobić procesor. A że mocy starczy nie tylko na paski, to pokazuje demo, do którego link już zamieściłem:
    https://www.youtube.com/watch?v=CXFOTpM2Jn4
    Tu masz całkowicie programowo robiony sygnał w standardzie NTSC.
    Ale pytający chciał to użyć dla sygnału VGA - tu AD725 nie jest potrzebny, bo mamy na wejściu monitora oddzielne sygnały RGB.
  • Poziom 9  
    Witam ponownie,
    Byłem pewien, że napisałem tutaj moje rozwiązanie już wcześniej, więc nie zaglądałem do tego tematu a tu pojawia mi się e-mail z propozycją napisania rozwiązania.. więc opiszę je.

    Ogólnie skorzystałem z porady Kolegi atom - odwołuję się do tablicy w sposób [y][x] - czyli mam tablicę (pikseli poziomych) tablic pionowych.
    Dało mi to możliwość zasemblerowania krytycznego miejsca w programie - wczytywania danych z miejsca w ramie i wypluwania danych na PORTC. Robię to ustawiając w rejestrze adres:
    Kod: c
    Zaloguj się, aby zobaczyć kod


    i wypluwaniem danych na port z inkrementacją wskaźnika o jeden:
    Kod: c
    Zaloguj się, aby zobaczyć kod


    czyli po prostu skorzystałem z porady Kolegi Marek_Skalski przy czym nie robię pętli a kopiuję ten kod tyle razy ile chcę mieć pikseli w poziomie - to nie jest dużym problemem, zwiększa mi rozmiar programu ale nieznacznie. Udało mi się tą metodą przy minimalnym odbieganiu od standardu VGA osiągnąć teoretycznie 130x240 (przy 8-mio bitowym wyjściu oczywiście) pikseli teoretycznie przy czym z powodu ograniczonej pamięci zdecydowałem się na kwadratowe 120x120.

    Tak jak wspominałem obraz modyfikuję w czasie vertical blank oraz (dla większej ilości cykli dla programu głównego kiedy nie przeszkadzają mi artefakty) w horizontal blank.

    Wymagania aplikacji były właśnie w okolicach 120x120 przy 256 kolorach i dostatecznej ilości wolnych cykli procesora. Zrobiłem proste biblioteki do rysowania różnych rzeczy na ekranie, napisałem grę Tetris i teraz cały projekt czeka na jakieś konkretniejsze zastosowanie.

    Zdjęcia dodane.
    Ogólnie występuje jeszcze jeden problem związany z działaniem głównego programu w okresie horizontal blank - niektóre instrukcje trwają więcej niż jeden cykl procesora co czasem opóźnia wejście w przerwanie i powoduje pewne szarpanie linii co widać w pliku P1170838.jpg - odpowiednia optymalizacja kodu zmniejsza znacząco ten efekt, ale jednak szukałem prostszego sposobu na redukcje szarpania i niezbyt go znalazłem.

    Zastanawiam się czy nie dodać efektów mojej pracy do działu DIY - chociaż, czy warto?

    W każdym razie spóźnione wielkie dzięki dla Kolegów, którzy pomogli mi w osiągnięciu celu jakim był własny generator wideo... chociaż to już jest coś więcej.

    Pozdrawiam,
    nkp123
  • Moderator Mikrokontrolery Projektowanie
    Efekty fajne, w międzyczasie pojawiły się też moje przykłady na XMEGA do generowania sygnału TV/VGA, do 320x240x8bpp. Można je pobrać wraz z innymi przykładami do mojej książki stąd:
    http://helion.pl/przyklady/avrukp.zip
    Znajdziesz tam m.in. przykład pokazujący eliminację jitteru związanego z tym że część instrukcji jest wykonywana w czasie dwóch i więcej taktów, co powoduje przesunięcie generowanej linii.