On 2010-12-15 22:03, Adam Dybkowski wrote:
>> Dzieki temu mam jeden zestaw procedur
>> graficznych a nie 5 i 5x więcej błedów.

> Do osiągnięcia ostatniego celu wystarczy zunifikowana biblioteka
> graficzna rysująca w RAMie, obsługująca różne formaty pikseli.

A więc 5x więcej błędów :)

> A pod
> konkretny model LCD tworzysz jedynie procedurki wypychające obrazek do
> wyświetlacza.

Może to być nietrywialne. Zacznijmy od tego że wypychanie moglo by się
odbywac za pomoca DMA. Tak robie to w ARMie. Problem konwersji zostawiam
komuś kto odbiera strumień. ARM dostaje poczatek i koniec framebuffera i
wypycha uartem liniowy framebuffer do "wyswietlacza".

Gdyby wyswietlacz składal się np. z dwóch połówek to zrobienie dma
zaczyna być mniej trywialne bo albo dma i popieprzona organizacja
framebuffera, albo konwerter i 2x więcej pamięci na framebuffer albo
rezygnacja z dma i ręczne wypychanie. Wiekszośc wyświetlaczy ma głupawą
koncepcję "pionowych" bajtów zamiast poziomych, to też mozna odwarcać w
locie. Czasem trafia się takie g. jak np. 12864 który ma w środku dwa
osobne wyswietlacze. Albo wyswietlacze bez kontrolera gdzie organizacja
ekranu przypomina ULE z ZX Spectrum (jedna linia logiczna zajmuje N
fizycznych w różnych miejscach). I tak dalej. Opanowanie wszystkich
kombinacji to masa supportu w software i sporo drutow w hardware.
Stosuje wartwę abstrakcji za pomocą AVRka i jest to całkiem fajne
rozwiązanie jesli musze szybko dostarczyć urzadzenie z np. większym
wyświetlaczem / innym wyświetlaczem. Przyznaje jednak że wypchnięcie
32bpp VGA za pomocą UARTa jest raczej nieosiągalne. Stosuje jednak
wyłacznie B&W i tam się sprawdza.

> Dla pełnego wypasu możesz nawet zrobić sobie port QT. :)

Oj, Qt to nie tylko grafika, ogólnie może być ciężko. Z drugiej strony
szukajac kiedyś sensownej bibliteki graficznej pisanej z myslą o uC
jakoś nie widze nic godnego uwagi.