Graficzne wyświetlacze LCD

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Polish to

Threaded View
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.


Re: Graficzne wyświetlacze LCD
says...
Quoted text here. Click to load it

Z monochromatycznych graficznych to HD61202 albo T6963.

P.

Re: Graficzne wyświetlacze LCD
Quoted text here. Click to load it

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ł


Re: Graficzne wyświetlacze LCD
W dniu 2010-12-15 12:21 Paweł napisał(a):

Quoted text here. Click to load it

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 /

We've slightly trimmed the long signature. Click to see the full one.
Re: Graficzne wyświetlacze LCD

Quoted text here. Click to load it
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ł





Re: Graficzne wyświetlacze LCD

Quoted text here. Click to load it

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


--
Jerry1111

Re: Graficzne wyświetlacze LCD
Quoted text here. Click to load it

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ą.


Re: Graficzne wyświetlacze LCD
Quoted text here. Click to load it

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

--
  Pozdrawiam
  Konop

Re: Graficzne wyświetlacze LCD
Quoted text here. Click to load it

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.

Re: Graficzne wyświetlacze LCD
W dniu 2010-12-15 20:52 Sebastian Biały napisał(a):

Quoted text here. Click to load it

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 /

We've slightly trimmed the long signature. Click to see the full one.
Re: Graficzne wyświetlacze LCD
Quoted text here. Click to load it


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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Re: Graficzne wyświetlacze LCD
Quoted text here. Click to load it

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

--
  Pozdrawiam
  Konop

Re: Graficzne wyświetlacze LCD
Quoted text here. Click to load it

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


Re: Graficzne wyświetlacze LCD
Quoted text here. Click to load it

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.

Re: Graficzne wyświetlacze LCD
Quoted text here. Click to load it

No to prze byk z Ciebie...
Myślałeś już może aby opublikować ten projekt LCD/AVR na sourceforge?

Jestem pewny ze zrobisz sie slawny :-)

Re: Graficzne wyświetlacze LCD
W dniu 2010-12-16 18:48 Sebastian Biały napisał(a):

Quoted text here. Click to load it

Sorry no ale to chore rozwiązanie raczej. Zamiast wziąć nieco większego
procka głównego wolisz dołożyć pośredniczącego AVRa oraz pamięć na SPI?
Pierwszy z brzegu ARM z 256KB Flasha i 64KB RAMu kosztuje ze 30 zł. A
zapewne wystarczyłby i mniejszy.

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

We've slightly trimmed the long signature. Click to see the full one.
Re: Graficzne wyświetlacze LCD
Quoted text here. Click to load it

Pamięć na SPI to ostateczność, np popędzanie wyświetlacza bez własnego
RAM. Zazwyczaj wystarczy translator bez zewnętrznej pamięci.

Quoted text here. Click to load it

Stosuje w tym celu rownież AT91SAM7S32 (jak jeszcze tani był), jednak
jego cena to niestety równiez druk dwustronny bez którego ciężko.
Ogólnie stosuje co jest, to przecież nie ma znaczenia. Na 5 sterowników
do graficznych LCD mam 3 na gołych AVR, jeden na AVR + SPI RAM i jeden
na SAM7S32 i wszystkie mają ten sam protokół mimo że to kompletnie inne LCD.

Re: Graficzne wyświetlacze LCD
W dniu 2010-12-18 00:37 Sebastian Biały napisał(a):

Quoted text here. Click to load it

A teraz weź soft do obsługi konkretnego typu wyświetlacza i wstaw w
główny procesor. Odpadnie pośredniczący AVR a płytka wyjdzie mniejsza.

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

We've slightly trimmed the long signature. Click to see the full one.
Re: Graficzne wyświetlacze LCD
Quoted text here. Click to load it

Nie. Obciązy procesor konwersjami (przeciez układ bajtów zazwyczaj w LCD
jest *popieprzony*) i może przeszkodzić w uzyciu DMA. Wygeneruje mi 4
wesje *głównej* płytki (bo magistrala równoległa, bo I2C, bo SPI, bo h.
wie co jeszcze ktoś wymyślił) albo wygeneruje kobylastą złaczkę z której
uzywama w danej chwili 4 druty. Wymusi stosowanie interfejsu do
touchscreena i jakiejś przelotki (a tak touchscreenem zajmuje się
"sterownik" LCD bądx nawet emuluje go myszką na PS/2), jest bardzo
trudne dla LCD bez RAMu chyba ze się weźmie procek ze sterownikiem LCD
(wybór juz nie jest kolorowy), uniemożliwia przesunicie LCD dalej od
głównego strownika, wymaga dodatkowych portów do klawiatury (a tak
akurat klawiaturą zajmuje się AVRek w LCD). Itd.

IMHO nie ma dla mnie żadnych zysków ze sterowania LCD bezpośrednio.
CHYBA że byłby to I2C z liniową organizacją ekranu i własną pamiecią.
Ale nawet wtedy jeśli na rynku pojawi się 2x tańszy LCD ale z debilna
magistralą to jestem w plecy bo trzeba przerabiać projekt główny. A tak
mam stabilny projekt główny i przerabiam małą duperelę za kilka zł.

Nikogo nie namawiam na takie zastosowanie. Ja po prostu mam bardzo
specyficzne zastosowanie. Jednak nawet amatrosko lepiej mieć
zdroworozsadkową organizację ekranu i magistralę niż pomysły wymagające
gimnastyki hardware i software których celem jest maskowanie niedorobek.

Re: Graficzne wyświetlacze LCD
Quoted text here. Click to load it

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.


Site Timeline