Jakie graficzne wyświetlacze LCD 122x32 z programowaniem w C dla ATmega wybrać?

Tue Dec 14, 2010 10:01 pm   

Witam,

Do tej pory podłączałem do mikrokontrolerów ATmega
znakowe wyświetlacze LCD zgodne z HD44780.
Teraz chciałem nauczyć się programowania graficznego,
monochromatycznego wyświetlacza LCD
(na początek np. 122x32 piksele).
O ile w przypadku wyświetlaczy znakowych powszechnym
standardem jest HD44780, to nie wiem, jak wygląda sprawa
jakichś powszechny standardów w przypadku wyświetlacza
graficznego. Chciałem się Was poradzić w tej kwestii.
Jaki wyświetlacz wybrać, aby był to popularny standard,
abym nie miał problemów z nabyciem wyświetlaczy o różnych
rozdzielczościach, aby były dostępne przykłady programowania
w C dla WinAVR. Z góry dziękuję za pomoc.

R.

Wed Dec 15, 2010 11:52 am   

In article <4d07db26$0$22793$65785112@news.neostrada.pl>, yyy@mmm.com
says...

Z monochromatycznych graficznych to HD61202 albo T6963.

P.

Wed Dec 15, 2010 12:21 pm   

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ł

Wed Dec 15, 2010 7:48 pm   

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 / - dla takiego małego 122x32, to jest 488
bajtów "straconych" na bufor...

--
Pozdrawiam
Konop

Wed Dec 15, 2010 8:52 pm   

On 2010-12-15 19:48, Konop wrote:

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.

Wed Dec 15, 2010 9:08 pm   

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


http://allegro.pl/art-nowe-lcd-192x64-f-y-g-led-piny-z-boku-i1334771306.html
http://allegro.pl/art-nowe-lcd-graficzne-122x32-rozm-2x16-k-white-i1334187490.html
http://allegro.pl/art-nowe-lcd-graficzne-122x32-rozm-2x16-white-blue-i1334187469.html
http://allegro.pl/art-nowe-lcd-128x64-m-z-podsw-led-k-white-i1334188090.html

Pozdrawiam,

Wed Dec 15, 2010 10:03 pm   

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. :)

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

Wed Dec 15, 2010 10:07 pm   

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.

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

Wed Dec 15, 2010 10:54 pm   

On 2010-12-15 22:03, Adam Dybkowski wrote:

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
32bpp VGA za pomocą UARTa jest raczej nieosiągalne. Stosuje jednak
wyłacznie B&W i tam się sprawdza.


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.

Wed Dec 15, 2010 11:18 pm   

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ł

Thu Dec 16, 2010 12:04 am   

On 15/12/2010 21:07, Adam Dybkowski wrote:


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


--
Jerry1111

Thu Dec 16, 2010 11:24 am   

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.

Thu Dec 16, 2010 1:43 pm   

Użytkownik "Robbo" <yyy@mmm.com> napisał w wiadomości
news:4d09e8e9$0$21007$65785112@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 ..

@

Thu Dec 16, 2010 1:44 pm   

Dnia Wed, 15 Dec 2010 21:08:28 +0100
"Robbo" <yyy@mmm.com> napisał(a):


Ja z alfanumeryków przeszedłem na to:
http://seguro.pl/sklep/?zobacz=2477&producent
I działało dość fajnie i prosto. Mój kod do
AVR do tego wyświetlacza: http://temp.thera.be/LCD.cc

Wada taka, że raczej jest drogie. Ale może coś na jego kontrolerze
znajdziesz tanio. Programowałem też jakiś wyświetlacz wyciągany ze
starych nokii, ale fatalnie się go lutuje.

Pozdrawiam,
--
Tomasz bla Fortuna
jid: bla(at)af.gliwice.pl
pgp: 0x90746E79 @ pgp.mit.edu
www: http://bla.thera.be

Thu Dec 16, 2010 2:41 pm   

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

R.