Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Europejski lider sprzedaży techniki i elektroniki.
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

ATmega128 - wyświetlanie brył 3D

ikko 06 Maj 2011 14:43 14232 42
  • ATmega128 - wyświetlanie brył 3D

    Witam.
    Jest to mój pierwszy post na tym wielkim forum. Chciałbym się pochwalić swoją konstrukcją, ponieważ nie wierzyłem, że uda mi się stworzyć coś, co będzie wyświetlało wirujący sześcian. To było raczej odległe marzenie zainspirowane nagraniami wideo znalezionymi w internecie jeszcze przez zakupem ATmegi.

    Cel:
    Chciałem wykorzystać nieco możliwości mikrokontrolera w innej aplikacji niż np. migacz LED.
    Założyłem, że skoro istnieją wirujące sześciany, to napiszę program obracający wszystkimi pięcioma bryłami platońskimi. Program realizuje to zadanie wyświetlając kolejno każdą z brył.

    Hardware:
    Mój "projekt" zbudowałem na mikrokontrolerze ATmega128 z dołączonym wyświetlaczem graficznym 240x128 opartym na sterowniku Toshiba T6963C.
    Schematu nie zamieszczam, ponieważ jest to tradycyjny interfejs AVR <-> GLDC.

    Software:
    Całość napisana jest w BASCOMie.
    Program zajmuje ok. 1000 linijek kodu i ok 25 KB pamięci Flash.

    Wyzwania, jakie mnie spotkały, to:
    -określenie współrzędnych kartezjańskich dla niektórych brył;
    -opanowanie przekształceń geometrycznych w 3D;
    -opanowanie projekcji perspektywicznej;
    -szukanie błędów w programie - znalazły się literówki;

    Link z nagraniem:

    Link




    ------------------------------------------------------------------------

    Projekt wyewoluował i znajduje się pod nowym adresem:
    https://www.elektroda.pl/rtvforum/topic2047647.html


    Fajne!
  • #2 06 Maj 2011 17:11
    aikax
    Poziom 8  

    Efekt byłby jeszcze lepszy, gdybyś dodał guziki do ręcznego obracania bryłą

  • #3 06 Maj 2011 17:18
    FastProject
    Poziom 28  

    Czy prędkość obracania można przyspieszyć?

  • #4 06 Maj 2011 17:39
    ^Rachel
    Poziom 21  

    Z tego co pamiętam we wzorach na obrót w 3 wymiarach występują funkcje trygonometryczne, jak sobie z nimi poradziłeś ?

  • #5 06 Maj 2011 17:44
    leonow32

    Poziom 29  

    Bardzo fajnie Ci to wyszło. Spróbuj dodać tekstury do tych brył. Jak bardzo skomplikowane modele możesz na tym pokazywać? Czy da się wyświetlić jakieś inne modele i skąd wziąłeś te bryły (tzn czy jakiegoś programu typu 3D Studio).

    Rozmiar programu wydaje mi się bardzo duży jak na 1000 linii kodu, chyba że to właśnie bryły tyle miejsca zajmują... Możesz zamieścić ten program?

  • #6 06 Maj 2011 17:55
    Urgon
    Poziom 36  

    AVE...

    Przypuszczam, iż autor rozsądnie modeluje bryły za pomocą układu współrzędnych i stosownych wzorów trygonometrycznych. Nie wyobrażam sobie tworzenia modeli dla tak "prostego" zadania. Ponadto konwersja tego by zajęła więcej czasu, niż stworzenie wszystkich potrzebnych wzorów przekształceń dla danego mikrokontrolera...

  • #7 06 Maj 2011 18:21
    pch
    Poziom 14  

    Rewelacja. Zawsze uważałem, że Bascom to świetne środowisko tylko nikomu nie chce się optymalizować programu stąd błędny wniosek, że generowany kod jest za wolny i za ciężki. Ja, swojego czasu, robiłem cuda na 8051 z softem pisanym w Bascomie.

    Pozdrawiam,
    PC

  • #8 06 Maj 2011 19:09
    tmf
    Moderator Mikrokontrolery Projektowanie

    No nie wiem, ATMega128 ma ok. 16MIPS, dla porównania to dla tak prostych obliczeń odpowiada mniej więcej mocy komputera 386SX (ktoś to jeszcze pamięta?). A na tym chodziły o wiele wypaśniejsze rzeczy. Ba, na ZX Spectrum osiągającym w porywach 0,2 MIPSa można było zrobić o wiele wypaśniejsze rzeczy.
    Niemniej autorowi gratuluję wybicia się poza standard i zrobienia czegoś ciekawszego. Z pewnością zdobyta wiedza zaoowocuje w kolejnych projektach.

  • #9 06 Maj 2011 19:50
    mklos1
    Poziom 25  

    MIPS'y MIPS'om nie równe, gdyż 386 był procesorem 32-bitowym, tak więc operacje na liczbach całkowitych są bardziej wydajne (386 miał zegar do 33MHz - z tego co pamiętam). Zaryzykowałbym stwierdzenie że był mniej więcej 8x bardziej wydajny przy wykonywaniu tych samych operacji.

  • #10 06 Maj 2011 20:00
    tmf
    Moderator Mikrokontrolery Projektowanie

    Miał różne zegary, pierwsze miały 16MHz. Zauważ, że specjalnie napisałem, że w tak prostych rzeczach to mniej więcej te MIPSy AVR i i386 są równoważne - rozdzielczość tego LCD powoduje, że operacje można wykonywać na liczbach 8-bitowych, w związku z tym 32-bitowy procesor nie ma jakiejś znaczącej przewagi.

  • #11 06 Maj 2011 20:33
    mklos1
    Poziom 25  

    Rozdzielczość wyświetlacza nie ma tu nic do rzeczy. Bryłę do wyświetlenia trzeba przecież przeliczyć. Oczywiście przy wymuszeniu 8-bitowych obliczeń na 32-bitowym procku spowoduje, że rzeczywiście wydajność będzie zbliżona, ale chyba nie o to chodzi... Idąc tym tropem procesor mógłby być i 1024-bitowy, przy operacjach na 8-bitach miałby tą samą wydajność... Naciąłem się kiedyś na bezmyślnym stosowaniu typów < 32-bity (np. char) na ARM'ach. Kompilator dorzuca dodatkowe instrukcje, które tak czy inaczej konwertują char do int, co w konsekwencji może spowodować drastyczny spadek wydajności.

  • #12 06 Maj 2011 20:52
    tmf
    Moderator Mikrokontrolery Projektowanie

    Oczywiście, że ma. Skoro mam 128x64 punkty to wszystkie obliczenia robię na liczbach 8-bitowych, a więc wydłużenie słowa procesora do 32-bitów nic nie przyśpiesza. No i o to właśnie chodzi - w takiej sytuacji nawet 32-bitowy procesor będzie miał wydajność zbliżoną do 8-bitowego. Co do kompilatora i typów 8-bitowych to zależy od architektury procesora, po prostu procesor może nie mieć instrukcji np. pobierających 8-bitów, albo nie umożliwiać wyrównywania danych do bajta, tylko np. do słowa lub podwójnego słowa. Tak ma m.in. ARM, AVR32 itd. Wtedy ograniczenie typu do 8-bitów nic lub niewiele daje, ale też nie szkodzi.

  • #13 06 Maj 2011 21:12
    szymon122
    Poziom 37  

    Coś pięknego :D
    Jaki jest dokładny symbol wyświetlacza i ile kosztuje?
    Czy skomplikowana jest obsługa tego sterownika?
    Ciekawe czy w C mniej by to wszystko zajmowało

  • #14 06 Maj 2011 21:12
    Urgon
    Poziom 36  

    AVE...

    Zapominacie też o jednej, bardzo ważnej rzeczy: procesory z rodziny 8x86 mają dużo bogatszą architekturę i więcej różnorodnych instrukcji podstawowych co czyni je bardziej wydajnymi od prostszych rdzeni ośmiobitowych. Kolega Ikko mógłby osiągnąć dużo lepszy efekt stosując dowolny procesor DSP, który jest przystosowany do wykonywania operacji na zbiorach danych, a współrzędne wierzchołków można traktować jako takie zbiory. Jednakże przy obliczeniach dla jednej bryły nie są tak wymagające, jak obliczenia do animowania wielu brył na raz lub jednej, złożonej bryły trójwymiarowej. Teksturowanie jest trudniejsze - nawet 16-bitowy SNES nie mógł robić innych tekstur niż jednolite kolory na swoich obiektach 3D...

  • #15 06 Maj 2011 21:48
    tmf
    Moderator Mikrokontrolery Projektowanie

    Podstawowa lista x86 jest uboga, w dodatku ma wyszczególniony akumulator i wiele instrukcji wynika z konieczności przesyłu danych z i do akumulatora w celu przeprowadzenia obliczeń. Przecież to nic innego jak nieco rozwinięta lista instrukcji 8088. To już nawet Z80 miał bogatszą listę. Z kolei AVR ma listę symetryczną, bez wyszczególnionego akumulatora i więcej rejestrów. Jedyne co ma x86 to div, czego nie ma AVR. Nie myl różnych trybów adresowania wynikających z pokręconej architektury x86 z kolejnymi łatami z użytecznymi instrukcjami.

  • #16 06 Maj 2011 22:08
    Urgon
    Poziom 36  

    AVE...

    386 ma już bogatą listę instrukcji w porównaniu do mikrokontrolera, o którym tu mówimy. To ma jedną zaletę: każde polecenie wysokiego poziomu jest rozbijane na mniejszą ilość instrukcji niskopoziomowych...

    Jednakże my mówimy tu o zupełnie różnych rodzinach procesorów o zupełnie różnych zastosowaniach. Nie widziałem, by ktoś na Atmelu czy PICu odpalał Windowsa. Są tylko jakieś porty DOS'a, lecz tylko do operacji na kartach SD/MMC. Nikt nie próbował robić portu CP/M...

  • #17 06 Maj 2011 22:23
    tmf
    Moderator Mikrokontrolery Projektowanie

    CP/M to na Z80 chodził. Ale nie róbmy tu zamieszania, bo co raz bardziej odbiegamy od tematu. Ja nie twierdzę, że AVR jest porównywalny do i386, a jedynie, że w tym konkretnym zastosowaniu moc obliczeniowa AVR będzie porównywalna do i386, ze względu na prostotę operacji. Swoją droga lista rozkazów i386 rozszerzyła się nieznacznie, tylko o instrukcje 32-bitowe (proste rozszerzenie rejestrów) i parę instrukcji związanych z nowymi trybami chronionymi. W przetwarzaniu danych niewiele się w tym procesorze zmieniło, jedynie dodali cache.

  • #18 06 Maj 2011 22:37
    wlw_wl
    Poziom 38  

    ^Rachel napisał:
    Z tego co pamiętam we wzorach na obrót w 3 wymiarach występują funkcje trygonometryczne, jak sobie z nimi poradziłeś ?

    Jak nie mamy mocy na obliczenia na bieżąco, to alternatywą jest ztablicowanie wartości sin i cos co powiedzmy 1°, narzutu obliczeniowego wtedy nie ma, ale trzeba poświęcić pamięć.
    Robiłem tak w grze FPP bodajże i działało to całkiem dobrze.

  • #19 06 Maj 2011 22:50
    xanio
    Poziom 27  

    CP/M to chodził na stacji dyskietek nawet (nie żartuję). AVR 8bit nie jest zbyt mocny ale wielu elektroników zdziwiłby jego potencjał, patrz np:
    http://www.youtube.com/watch?v=sNCqrylNY-0
    http://www.youtube.com/watch?v=sCN1bqRG-7o

    Windowsa niby jak odpalać skoro ma zamknięte źródło i jest kompilowany dla innej architektury? Poza tym, jakie aplikacje odpalałbyś na tym, skoro wszyskie są kompilowane dla x86? Zresztą, na 386 nie ma mowy o komfortowej pracy z jakimkolwiek windowsem nowszym niż 3.xx - a jaki jest sens portowania takiego quasi-systemu?
    Proste zapytanie p. Google i zaraz wiemy, że jednak jakieś systemy na avr powstają:
    http://en.wikibooks.org/wiki/Embedded_Systems/Atmel_AVR/Operating_systems_and_task_managers

    Dodano po 4 [minuty]:

    wlw_wl napisał:

    Jak nie mamy mocy na obliczenia na bieżąco, to alternatywą jest ztablicowanie wartości sin i cos co powiedzmy 1°, narzutu obliczeniowego wtedy nie ma, ale trzeba poświęcić pamięć.
    Robiłem tak w grze FPP bodajże i działało to całkiem dobrze.


    Nawet na mocniejszych platformach (486, pentium) funkcje trygonometryczne się tablicowało. Przy takich rozdzielczościach błąd jest pomijalny.

  • #20 06 Maj 2011 23:04
    Urgon
    Poziom 36  

    AVE...

    Xanio, CP/M chodził na stacjach dyskietek wyposażonych w procesor Z80 lub jego podróbki...
    Co do systemów operacyjnych na mikrokontrolery, to są one ograniczone funkcjonalnie tylko do dzielenia czasu procesora na zadania. Te same funkcje można realizować i bez nich, często nawet szybciej...

  • #21 06 Maj 2011 23:19
    xanio
    Poziom 27  

    Ja bym nie powiedział, że takie np Contiki to jest tylko do dzielenia czasu procesora.
    Fakt, stacje dyskietek miały procesor Z80. Wcześniej nie wiem czemu ale przeczytałem u przedpiścy, że chodziły na ZX.

  • #22 07 Maj 2011 00:53
    zdebel
    Poziom 14  

    Urgon napisał:

    Teksturowanie jest trudniejsze - nawet 16-bitowy SNES nie mógł robić innych tekstur niż jednolite kolory na swoich obiektach 3D...


    Bezedura!
    Wolfenstein 3D!

  • #23 07 Maj 2011 01:25
    Urgon
    Poziom 36  

    AVE...

    Nie B.Z.D.Ura, tylko fakt. SNES nie był w stanie tworzyć ruchomych obiektów 3D z oteksturowaniem. Dlatego gra Star Fox choć miała grafikę opartą o bryły, to bez tekstur jako takich, a i tylko dlatego, iż użyto dodatkowego koprocesora do akceleracji grafiki wbudowanego w kartridż...

    Wolfenstein 3D był tak naprawdę 2.5D i używał techniki zwanej Raycastingiem do tworzenia efektów trójwymiarowości. Do tego wersja SNES była bardzo zubożona - przeciwnicy nie mogli się obracać przez co wyglądali jak wycinanki...

  • #24 07 Maj 2011 02:43
    ikko
    Poziom 11  

    aikax napisał:
    Efekt byłby jeszcze lepszy, gdybyś dodał guziki do ręcznego obracania bryłą

    Istnieje możliwość ręcznego obracania bryłą względem dowolnej osi w czasie rzeczywistym. Działa też skalowanie i przesunięcia. Można sterować z terminala lub przyciskami. Program to umożliwia choć nie widać tego na nagraniu. Działa jakby w trybie auto dla celów pokazowych.


    Daro_Elektronik napisał:
    Czy prędkość obracania można przyspieszyć?

    Można zwiększyć FPS lub kąt obrotu na "klatkę". W programie umieściłem pętle opóźniające całość średnio o ok 30% by przy najbardziej złożonych bryłach zniwelować migotanie. Bez tych opóźnień najprostsze bryły obracały się prawie 3 razy szybciej.
    Wartość FPS spada wraz ze wzrostem złożoności bryły (ilości wierzchołków do przeliczenia). Można też zrezygnować z perspektywy (projekcja izometryczna jest szybsza).



    ^Rachel napisał:
    Z tego co pamiętam we wzorach na obrót w 3 wymiarach występują funkcje trygonometryczne, jak sobie z nimi poradziłeś ?

    Wykorzystałem je :) Zacząłem od prostszych obrotów 2D względem określonego punktu. Potem już było trochę prościej.
    Przy 3D by obliczyć nowe współrzędne dla pojedyńczego wierzchołka, Atmega wykonuje ok 60 obliczeń na liczbach zmiennoprzecinkowych (typu Single) na cykl (klatkę).


    leonow32 napisał:
    Jak bardzo skomplikowane modele możesz na tym pokazywać?

    Myślę, że głównym ograniczeniem jest pojemność pamięci ram. Program teoretycznie działa z dowolnie skomplikowaną bryłą. Jedynie obroty spadną w przypadku bardziej złożonych brył.


    leonow32 napisał:
    Czy da się wyświetlić jakieś inne modele i skąd wziąłeś te bryły (tzn czy jakiegoś programu typu 3D Studio).

    Można wyświetlić inne modele gdy są podane ich współrzędne wierzchołków.
    Były one przy starcie wygenerowane przez mikrokontroler. Bryły budowałem z odcinków metodą obrotów. To była raczej przyjemna część.
    Np. by stworzyć kwadrat bierzemy odcinek AB i obracamy pkt A względem pkt B o 90 stopni otrzymując pkt C.. itd.
    Brałem też pod uwagę zwykłe przepisanie współrzędnych z jakiegoś programu 3D i późniejsze przeskalowanie.


    szymon122 napisał:
    Jaki jest dokładny symbol wyświetlacza i ile kosztuje?
    Czy skomplikowana jest obsługa tego sterownika?
    Ciekawe czy w C mniej by to wszystko zajmowało

    Wyświetlacz to: LGMFD240128A6PFLW .. z Maritexu.
    Posiada on raczej popularny sterownik T6963C. Bascom go obsługuje więc nie miałem z nim kłopotów.
    W C nie pisałem więc nie mam porównania ale ten program nie był szczególnie optymalizowany.

  • #25 07 Maj 2011 08:37
    JohnM
    Poziom 9  

    A tej pamięci gdzieś będzie 1024 bajty,zamiast liczyć funkcje sin i cos pobiera się wartości w radianach

  • #26 07 Maj 2011 11:09
    leonow32

    Poziom 29  

    Jeżeli brakuje Ci pamięci to możesz ją dołożyć. ATmega128 obsługuje nawet 64kB zewnętrznej pamięci RAM. Kup dwa scalaki 62256-50, latch 74HC573 i bramkę not 74HC04. Koszt razem ok 15zł. Interfejs jest bardzo prosty i nie wymaga od strony programistycznej żadnych wygibasów, ot parę poleceń i pamięć zewnętrzna działa tak samo jak wewnętrzna.

    Mógłbyś jednak zamiast obliczania funkcji trygonometrycznych liczb zmiennoprzecinkowych dać tablice jak wlw_wl radzi. To zdecydowanie podniesie wydajność! I staraj się nie stosować zmiennoprzecinkowych jeżeli nie jest to niezbędne.

  • #27 07 Maj 2011 11:38
    Urgon
    Poziom 36  

    AVE...

    Możesz także wygenerować tablice w fazie inicjacji, zapisać je do zewnętrznego ramu i tylko się do nich odnosić w miarę potrzeby...
    Technika generowania tablic i danych w fazie uruchamiania i odwoływania się do nich potem jest wykorzystana w grze Kkrieger, która zajmuje 96kB w formie pliku wykonywalnego, lecz po uruchomieniu zapełnia około 300-500MB w pamięci RAM...

  • #28 07 Maj 2011 12:26
    kred
    Poziom 19  

    Urgon napisał:
    AVE...

    386 ma już bogatą listę instrukcji w porównaniu do mikrokontrolera, o którym tu mówimy. To ma jedną zaletę: każde polecenie wysokiego poziomu jest rozbijane na mniejszą ilość instrukcji niskopoziomowych...

    Jednakże my mówimy tu o zupełnie różnych rodzinach procesorów o zupełnie różnych zastosowaniach. Nie widziałem, by ktoś na Atmelu czy PICu odpalał Windowsa. Są tylko jakieś porty DOS'a, lecz tylko do operacji na kartach SD/MMC. Nikt nie próbował robić portu CP/M...

    Jak to nikt nie odpalił CP/M na AVR? A to: http://spritesmods.com/?art=avrcpm&f=had ? :)

  • #29 07 Maj 2011 20:56
    ikko
    Poziom 11  

    leonow32 napisał:
    Jeżeli brakuje Ci pamięci to możesz ją dołożyć.

    Posiadam pamięć BS62LV1027 czyli.. sram 128kB -55ns którą dołożę niebawem.
    Wiem, że sprzętowo mój AVR tylko 64 kB zaadresuje więc jej połowa będzie odpoczywać.
    Na razie nie jest ona niezbędna ale do większych modeli wewnętrzne 4kB nie wystarczy.

    leonow32 napisał:
    Mógłbyś jednak zamiast obliczania funkcji trygonometrycznych liczb zmiennoprzecinkowych dać tablice jak wlw_wl radzi. To zdecydowanie podniesie wydajność! I staraj się nie stosować zmiennoprzecinkowych jeżeli nie jest to niezbędne.

    Dziękuję za radę :). Skorzystam z tych tablic trygonometrycznych i porównam wydajność. Pomoże to na pewno przy obracaniu modeli bardziej rozbudowanych. Wykorzystuję teraz skok 1° więc tablice ciężkie nie będą.

  • #30 07 Maj 2011 21:01
    Urgon
    Poziom 36  

    AVE...

    Jest na pewno jakaś sztuczka programistyczna, która pozwalałaby Ci wybierać jedną lub drugą połówkę pamięci. W starym podręczniku do elektroniki cyfrowej widziałem coś takiego pod hasłem "układ stronicowania"...

    @Kred...
    Dzięki za link. Faktycznie port CP/M jest na AVR. Niezbyt wydajny jednak. Możnaby zastąpić oryginalną kość pamięci RAM kością FRAM i umieścić w niej system na stałe. Lub nawet użyć pamięci (E)EPROM tak samo, jak to robiono w komputerach ośmiobitowych...

TME logo Szukaj w ofercie
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME
TME Logo