Witam!
Przeglądając ostatnimi czasy w EdW 1/07, 12/06, 3/07 projekty związane z tworzeniem grafiki 3d ew. wyświetlanie obrazów generowanych na AVR na TV. Skoro można wyświetlać temperature i grać w Snake'a, to można także tworzyć proste bądź średnioskomplikowane animacje obiektów "trójwymiarowych" i zapisywać je np. na dysku twardym. Jedynym sensownym (moim zdaniem) rozwiązaniem jest pomysł pana Michała Wysockiego, tzn. stworzyć bufor na SRAMie, którego tablica odzwierciedlałaby ekran TV. Również przypadałyby 2 bity na każdy piksel (kolory biały, jasnoszary, ciemnoszary i czarny). Kwestia samego wyświetlania jest prosta (opisana w nr 12/06). Dla mnie problemem by było generowanie obrazu/następnej klatki. Na początku przyjąłem taki schemat: Wykożystałbym conajmniej trzy kostki: jeden µC do wyswietlania obrazu z bufora, kostkę SRAM jako bufor oraz drugi µC do rysowania obrazu i wpisania go do bufora(pamięci). tak jak nadmieniłem, wyświetlanie jest proste, gorzej z wpisywanie do bufora... Tu nasuwa się mi pytanie:
1. czy da się ustawić SRAM na rozdzielczość dwu bitową? Pytam, bo:
a) nie jestem "obcykany" w kostkach pamięci
b) znacznie uprościłoby to program( z rozdz. 8-bitową trzebaby kompresować 4 piksele do jednego bajtu-na początku normalka, ale spróbuj podać później współrzędne (nie twierdze, że to jest niemożliwe, ale dla mnie b. ciężkie do przerobienia na kod)
Rysowanie np. linii odbywałoby się tak jak w EdW 1/07 w Kursie C.
W fazie finalnej można by było dodać dysk twardy (np. 1GB) na zapisywanie naszych wypocin, ale to już nieco inny temat.
Aha, dlaczego nie chcę zastosować jednej kostki tak jak p. Michał? Sądzę, że mój układ będzie szybszy i nie będzie obciążony najdłuższym przerwaniem jakim jest wyświetlanie obrazu.
PS. Postaram się jak najszybciej zamieścić rysunki, by rozjaśniły mój (jak zwykle zagmatwany) pomysł.
PS2. Dane na temat obrazu byłyby wprowadzane za pomocą np. klawiatórki, z buzikami typu "Rysuj Linie" "rysuj Kwadrat" i podaniem wymiarów.
PS3. W miarę postępów (a będą one powolne) chciałbym zaimpletować silniczek 3d.
Proszę o komentarze, sugestie, pomysły...
SGI domowej roboty
-
ZbeeGin
Istnieją pamięci o różnej organizacji: 1-bit, 4-bit, 8-bit. Ale lepiej poświęcić nieco więcej kodu by skorzystać z pełnych 8-bitów bo przyśpiesza to dostęp do kolejnych pikslei. Dlaczego?GrzesiekG pisze:1. czy da się ustawić SRAM na rozdzielczość dwu bitową? Pytam, bo:
a) nie jestem "obcykany" w kostkach pamięci
1. Pobierając jednen bajt możesz bez straty czasu obrobić 4 piksele naraz. Wystarczy tylko potraktować bajt jako 4 pozycje 2 bitowe.
2. Operacje na jednym pikselu można wykonać z pomocą prostych i szybkich operacji ROL, ROR, AND i OR maskując sobie resztę pikseli.
3. Czas poswięcony na kolejne wczytywanie każdego piksela z pamięci zewnętrznej będzie na pewno dłuższy niż operacje AND i OR.
Ok, przykładowo. Jedna linia obrazowa ma 64 punkty. Linii obrazowych jest 128. Daje to nam:GrzesiekG pisze:ale spróbuj podać później współrzędne (nie twierdze, że to jest niemożliwe, ale dla mnie b. ciężkie do przerobienia na kod)
1 linia = (64 pkt * 2 bity) / 8 bitów = 16 bajtów
128 linii = 16 bajtów * 128 linii = 2KB na obraz
Jak dostać się do piksela numer 2 (x) w linii 8 (y)?
y * 16 + x div 4 = adres bajtu
x mod 4 = która ćwiartka bajtu (0, 1, 2, 3)
czyli
8 * 16 + 2 div 4 = 128 + 0 = 128 bajt
2 mod 4 = 2 czyli trzecia ćwiartka bo liczymy od zera!
Współrzędne liczymy od zera, zatem zakres X = (0..63), Y=(0..127)!!!
--------
Pomyśl także jak rozwiązać problem konfliktów na magistrali gdy do jednego bajtu pamięci będą w tym samym czasie chciały się dostać dwa układy...
Ostatnio zmieniony 01 sty 1970, 1:00 przez ZbeeGin, łącznie zmieniany 1 raz.
Miałem tego świadomość (chciałem zrobić tak by się nie narobić) i dziękuję. Co mam jednak robić, gdy interesujący mnie piksel (np. jest on wyliczony ze wzorów do wygenerowanej linii) jest drugą ćwiartką jakiegoś bajtu (np. 01xx1101)? Chodzi tu tylko o wspórzędną X, bo w dwuwymiarowej tablicy/buforze Y to po prostu numer wiersza. Mój pomysł: po prosu wyliczyć (na kartce papieru) przypadki, czyli jeśli X=1 to bierzemy pierwszy bajt i po prostu add xxb, jeśli X=3 to rol x2 i add xxb, jeśli x=10 to bierzemy 3 bajt i roll, add xxb itd. Oczywiście nie chcę tworzyć warunkowego monstrum, tylko matematyczny wzór i odpowiednie funkcje, to jest tylko pomysł.
Jeśli chodzi o dostęp do SRAM to mamy około 20 rejestrów ogólnego przeznaczenia do wykorzystania w µC wyświetlającym obraz (ewentualnie stworzyć w SRAMie µC lokalny bufor na powiedzmy jedną linię obrazu). Pod względem wyświetlania obrazu moduł wyświetlający miałby wyższy priorytet od modułu generującego tzn. "wyświetlacz" będzie miał jedną nóżkę podpiętą przez inwerter do int0 µC "tworzyciela" dając mu do zrozumienia, że może/nie może skorzystać z bufora obrazu. "Wyświetlacz" pobierałby powiedzmy 4 bajty (lub więcej, trzeba sprawdzić jak długo zejdzie z pobraniem danych), a kiedy później będzie zaję ty wyświetlaniem tego co ma da czas "tworzycielowi" na przesłanie nowej porcji tam gdzie trzeba. Oczywiście wszystko trzeba optymalizować itd.
Co Wy na to?
Jeśli chodzi o dostęp do SRAM to mamy około 20 rejestrów ogólnego przeznaczenia do wykorzystania w µC wyświetlającym obraz (ewentualnie stworzyć w SRAMie µC lokalny bufor na powiedzmy jedną linię obrazu). Pod względem wyświetlania obrazu moduł wyświetlający miałby wyższy priorytet od modułu generującego tzn. "wyświetlacz" będzie miał jedną nóżkę podpiętą przez inwerter do int0 µC "tworzyciela" dając mu do zrozumienia, że może/nie może skorzystać z bufora obrazu. "Wyświetlacz" pobierałby powiedzmy 4 bajty (lub więcej, trzeba sprawdzić jak długo zejdzie z pobraniem danych), a kiedy później będzie zaję ty wyświetlaniem tego co ma da czas "tworzycielowi" na przesłanie nowej porcji tam gdzie trzeba. Oczywiście wszystko trzeba optymalizować itd.
Co Wy na to?
-
ZbeeGin
-
ZbeeGin
