logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Obsługa grafiki na ATmega8A/ATmega16 z OpenGL - czy to możliwe?

lasek0110 05 Sty 2016 23:54 1311 9
  • #1 15304959
    lasek0110
    Poziom 11  
    Witam! Chciałbym poruszyć zagadnienie obsługi grafiki za pomocą mikrokontrolerów AVR, konkretnie ATmega8A lub ATmega16. Zamierzam zbudować układ złożony z dwóch kontrolerów połączonych na zasadzie master - slave. Kontroler "master" ma odpowiadać za przetwarzanie poleceń i generowanie odpowiednich przerwań, które z kolei obsługiwane są za pomocą drugiego kontrolera, a ten - za pomocą układów 74HC595 oraz PCF8574 - obsługuje wyświetlacz LCD. Czy takie rozwiązanie będzie w miarę wydajne, przy zastosowaniu zewnętrznego kwarcu 16 MHz? Czy też raczej pobawić się w dedykowane kontrolery? Poruszyłem temat OpenGL, gdyż jest to biblioteka niskopoziomowa. W związku z tym zastanawiam się, czy warto napisać port do tej biblioteki (przystosować ją do pracy na AVR), czy też zastosować własne rozwiązanie. A może istnieje już coś gotowego? W końcu po co wyważać otwarte drzwi. Przekopałem nieco forum i poczytałem na temat samych AVR-ów i biblioteki OpenGL, ale nawet na anglojęzycznych forach nie udało mi się znaleźć kogoś, kto już to robił. To ja słabo szukam, czy też nikt się jeszcze nie pochwalił?

    Pozdrawiam!
  • Pomocny post
    #2 15304985
    Konto nie istnieje
    Konto nie istnieje  
  • Pomocny post
    #3 15305094
    Konto nie istnieje
    Poziom 1  
  • Pomocny post
    #4 15305840
    tmf
    VIP Zasłużony dla elektroda
    Można się bawić w STMy i kombinowanie z grafiką, można kupić np. FT80x lub FT81x i mieć za parenaście złotych gotowy akcelerator graficzny, który realizuje wysokopoziomowe polecenia graficzne, w efekcie nawet 8-bitowy MCU będzie generował grafikę lepszą niż STM32Fxx...
    Oczywiście OpenGL jest poza zasięgiem nie tylko 8-bitowców, ale nawet wspomnianych STM32, krytyczny nie jest tu brak dzielenia, czy FPU, ale operacji wspierających obróbkę grafiki. Do tego przydają się operacje na macierzach, pakowania/rozpakowywania różnych formatów kodowania kolorów itd. Dla przykładu - jedna z prostszych operacji - alfablending, na 8-bitowcu i 32-bitowcu będzie wymagała tej samej liczby instrukcji, jedyna różnica będzie więc w szybkości zegara. Ale 180 MHz vs. 32 MHz nie czyni istotnej różnicy przy ilości operacji jakie są wymagane nawet dla rozdzielczości QVGA. Niektóre STMy mają pewne wsparcie w asemblerze, ale nie przebiją dedykowanych chipów typu FT8xx, czy nawet RA8875.
  • #6 15306331
    lasek0110
    Poziom 11  
    Dzięki wielkie za odpowiedzi! Nie spodziewałem się, że OpenGL może mieć aż tak duże wymagania. Czyli nie ma co się bawić w wymyślania koła od nowa, dobrze zrozumiałem? W sumie można spróbować zintegrować jakiś dedykowany układ z mikrokontrolerem. Tylko przytoczone STM'y bazują na architekturze ARM, nie będzie więc jakichś problemów z "dogadywaniem się" układów? Odnośnie wspomnianego "generowania przerwań" - miałem na myśli rozwiązanie rodem z DOSa - coś a'la 10h. Pozdrawiam!
  • #7 15306406
    tmf
    VIP Zasłużony dla elektroda
    Rozwiązanie na dwóch MCU, a tym bardziej AVR i ARM jest bez sensu. Nie napisałeś jaką matrycą chcesz sterować. Ja bym polecał FT80x lub FT81x - to są dedykowane koprocesory graficzne. Przejrzyj ich specyfikację, działają na zasadzie, że wysyłasz im listę poleceń i tyle., A polecenie to np. wyświetl obraz jpg z zadaną przezroczystością, wyświetl napis, odtwórz filmik itd. O tyle fajne, że nie trzeba własnoręcznie implementować niskopoziomowych funkcji graficznych.
  • #8 15308250
    TWl
    Poziom 21  
    Wygląda na to, że dla chcącego nic trudnego. Ktoś uruchomił Ubuntu na ATMega128, więc i OpenGLa się da :)

    http://hackaday.com/2012/03/28/building-the-worst-linux-pc-ever/

    System uruchamia się "tylko" kilka godzin (ale podobno jak już wstanie, to można pracować!)

    Jeśli chodzi o bardziej praktyczne rozwiązania: zamiast jakichś dziwnych pseudo-układów GPU (FT8xx), może po prostu użyj Raspberry Pi albo podobnego modułu - np. RPi0 ma wyjście HDMI, obsługuje OpenGL ES, współpracuje też z graficznymi ekranami via SPI. I do tego kosztuje (podobno) 5 dolarów.

    TWl
  • #9 15308880
    lasek0110
    Poziom 11  
    W zasadzie nie chodzi mi o proste rozwiązanie ;) Cały myk polega na tym, żeby jak najwięcej wiedzy nałykać przy próbie (może i szalonej i bez szans powodzenia) zbudowania takiego układziku. Bo przecież nie chodzi o to, żeby zajączka złapać ;)
  • #10 15308920
    Konto nie istnieje
    Konto nie istnieje  
REKLAMA