Graficzne wyświetlacze LCD

Z monochromatycznych graficznych to HD61202 albo T6963.

P.

Tak dla ciekawości zobacz jaki fajny wyświetlacz zastosowany jest np. w takim "Kindle". Ma bardzo dużą rozdzielczość, znikomy pobór prądu i wszytko na nim widać nawet w pełnym słońcu. Tego typu urządzeń jest coraz więcej. Zapewne wkrótce pojawią się na Allegro jakieś uszkodzone egzemplarze, z których można będzie wymontować wyświetlacz.

Paweł

Ja z reguły staram się to robić tak - tworzę w pamięci bufor obrazu (1bit/pixel) i w nim tworzę sobie obraz, który potem wysyłam do LCD... W ten sposób właściwie masz tylko dwie funkcje, które są zależne od typu LCD - inicjalizacja i wysłanie bufora :). Jest tylko jedno małe "ale" - wyświetlacze monochromatyczne różnią się pod względem organizacji pamięci - w jednych 1 bajt danych tworzy fragment jednego wiersza, w innych - fragment jednej kolumny... przez co musisz mieć dwa rodzaje funckji do rysowania, pisania itp "w buforze", albo dodatkową funkcję do "odwracania" buforu ;)... No ale to są de facto dwa rodzaje i koniec, żadnych niespodzianek nie będzie ;)... Tak czy siak... pamiętaj o tym, żeby procek miał na tyle dużo ramu, aby zmieścił się bufor (X * Y / 8) - dla takiego małego 122x32, to jest 488 bajtów "straconych" na bufor...

Rozwiązuje to inaczej: pomiedzy CPU a wyswietlacz wkładam małego AVRa (czasem + szeregowy ram) który odwraca w locie obraz, służy jako framebuffer, albo jako generator synchronizacji do LCDków bez pamięci. Protokół zawsze ten sam: UART@1M + timeout na pierwszy bajt. 3 druty i wszystkie wyświetlacze zalatwione, jedynie w sofcie powiększam obraz ramki, organizacja zawsze ta sama. Dzieki temu mam jeden zestaw procedur graficznych a nie 5 i 5x więcej błedów.

Dziękuję wszystkim za porady. Chciałem jeszcze zapytać, czy tymi wyświetlaczami warto się zainteresować (w sensie łatwości programowania, standardowości)?

W dniu 2010-12-15 20:52 Sebastian Biały napisał(a):

Do osiągnięcia ostatniego celu wystarczy zunifikowana biblioteka graficzna rysująca w RAMie, obsługująca różne formaty pikseli. A pod konkretny model LCD tworzysz jedynie procedurki wypychające obrazek do wyświetlacza.

Zresztą najprościej idzie stosowanie wyświetlaczy TFT w nieco większych ARMach - jeżeli na pokładzie jest kontroler LCD (np. w AT91SAM9261) to cała zabawa jest bardzo prosta. Kwestia tylko tej biblioteki rysującej. Dla pełnego wypasu możesz nawet zrobić sobie port QT. :)

W dniu 2010-12-15 12:21 Paweł napisał(a):

Jasssne, a widziałeś jak to działa w praktyce (albo chociaż w nieco lepszej jakości filmiku na YT)? Koszmarny czas zmiany zawartości - wszystkie piksele robią się czarne, kilkaset ms później białe a kolejne kilkaset ms później pojawia się właściwy obraz. Nawet przy czytaniu książki potrafi wqrzać a co już mówić o pokazywaniu jakichkolwiek animacji. Dobre tylko do bardzo-wolno-zmiennych odczytów, np. pogody ściąganej z serwera co 15 minut. Chociaż to ostatnie i tak chętniej obejrzałbym na kolorowym LCD transrefleksyjnym (takim jak np. stosowane w starszych outdoorowych GPSach Garmin) - wspaniale widocznym bez podświetlania nawet w pełnym słońcu, a dodatkowo z możliwością podświetlenia gdy jest ciemno - co nie jest możliwe w wyświetlaczu Kindle.

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

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

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.

Tak Rzeczywiście nie nadaje się do pokazywania animacji. Jednak obrazy statyczne wg. mnie są w jakości chyba niemożliwej do osiągnięcia na innych typach wyświetlaczy. To rzeczywiście wygląda jak zadrukowana kartka papieru. Czas zmiany zawartości miliona pikseli to około 1 sek. W wielu zastosowaniach jest to do zaakceptowania. Najlepsze jest to, że można odłączyć zasilanie i nadal widać obraz.

Paweł

Kindle to czasami nie jest e-paper? Czyli ma wszystkie zalety papieru - lacznie z zapotrzebowaniem na latarke gdy jest ciemno.

Trzymając obraz w RAM-ie i chcąc wypisywać na LCD jakiś tekst, muszę mieć w programie matryce znaków (to może zając z 1kB

-- 16 linii na znak, 24 litery wielkie, 24 litery małe, 10 cyfr, z 8 znaków dodatkowych). Zależnie od procka, 1kB to może być mało albo dużo :)

Czy bywa tak, że same LCD posiadają w swojej pamięci matryce znaków?

R.

Użytkownik "Robbo" snipped-for-privacy@mmm.com napisał w wiadomości news:4d09e8e9$0$21007$ snipped-for-privacy@news.neostrada.pl...

T6963 ma na pewno. korzystam z takich LCD od jakiegos czasu i nie zamierzam sie przesiadać na nic innego :) chyba, ze kolor, ale to jeszcze chwilka ..

Dnia Wed, 15 Dec 2010 21:08:28 +0100 "Robbo" snipped-for-privacy@mmm.com napisał(a):

Ja z alfanumeryków przeszedłem na to:

Pozdrawiam,

Dzięki za ten przykład; już trochę lepiej to rozumiem.

R.

No tak, ale moim zdaniem TO JEST MAŁO! Bo powiedzmy sobie szczerze, jak chcesz zrobić jakąś grafikę, to i tak parę kB zajmą Ci "bitmapy" ;)... no chyba, że tylko prostokąt i kółko, to ok ;)... Ja tam wolę dopłacić parę zł do procka i dać więcej pamięci i tyle ;)...

Bywa! To się nazywa kontroler z generatorem znaków ;)... T6963 ma coś takiego na pokładzie ;)

Po pierwsze nie 5x, tylko 2x... a tak naprawdę, to kluczowe dla mnie są dwie funkcje - SetPixel (zapalająca pojedynczy piksel) i PutBmp (kopiująca bitmapę)... Reszta staje się uniwersalna ;)... Przynajmniej w takim zakresie, w jakim ja tych wyświetlaczy używam ;)... NA tej podstawie robię proste funkcje typu linia, kółko, prostokąt, oraz obrazki, animacje, teksty. Do tego piszę sobie odpowiednie narzędzia na PC, które odpowiednio konwertują mi plik PBM do tablicy w C i w ten sposób wrzucam to do proca. Jasne, w tych narzędziach też można się pomylić, no ale łatwiej się to pisze i debuguje, bo na PCie są większe możliwości ;)... Moim zdaniem różnica jest żadna - Ty piszesz soft na drugiego AVRka do obsługi wyświetlacza, a ja piszę dwie małe funkcje... i efekt jest ten sam ;)...

No dokładnie... Porównywanie takiego papieru elektronicznego do wyświetlacza LCD transfleksyjnego to jakieś nieporozumienie.

To wyświetlacz przeznaczony do czytania książek i do tego jest wyśmienity - np. aby wziąć go ze sobą na plażę przy zimnym piwku czy w ośnieżone góry i popijając gorącą czekoladę czytać lekturę :-)

Wszelkie iPody, iPady z błyszczącym wyświeltaczem wymiękają.

No ok, ale w ten sposób nie wykorzystujesz np. stronnicowania w wyświetlaczach LCD, i pewnie widać przerysowanie całego ekranu?

Double buffer to zadanie AVRka. Działa znakomicie, ram łatwo sztukuje za pare zł kostka po SPI, zazwyczaj prędkośc ma wystarczajacą do wyświetlaczy B&W.

Mam ostatnio projekt w którym ten AVR wyświetla klawiaturę ekranową (touch screen) "kompresując" obraz tak żeby zmieścil sie rysunek klawiatury na żądanie usera bez ingerencji ze strony softu w głównym CPU.