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.
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.
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. :)
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.
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.
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.
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:
formatting link
I działało dość fajnie i prosto. Mój kod do AVR do tego wyświetlacza:
formatting link
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.
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ą.
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.