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.

do góry

In article <4d07db26$0$22793$65785112@news.neostrada.pl>, y...@m...com
says...
>
> 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.

Z monochromatycznych graficznych to HD61202 albo T6963.

P.

do góry

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

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ł

do góry

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

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

do góry

On 2010-12-15 19:48, Konop wrote:
> 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 ;)...

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.

do góry

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,

do góry

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

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

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.

do góry

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

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

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.

do góry

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.

do góry

>
> Jasssne, a widziałeś jak to działa w praktyce (albo chociaż w nieco
> lepszej jakości filmiku na YT)
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ł

do góry