NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Jakie graficzne wyświetlacze LCD 122x32 z programowaniem w C dla ATmega wybrać?
Konop
Guest
Guest
Thu Dec 16, 2010 4:10 pm
Quote:
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
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
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
...
Quote:
Czy bywa tak, że same LCD posiadają w swojej pamięci matryce znaków?
Bywa! To się nazywa kontroler z generatorem znaków
... T6963 ma coś
takiego na pokładzie ;)
--
Pozdrawiam
Konop
Konop
Guest
Guest
Thu Dec 16, 2010 4:15 pm
Quote:
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.
(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.
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
Pszemol
Guest
Guest
Thu Dec 16, 2010 5:14 pm
"Jerry1111" <jerry1111alwaysattackedbyspam@wp.pl.pl.wp> wrote in message
news:iebhis$v06$2@news.onet.pl...
Quote:
On 15/12/2010 21:07, Adam Dybkowski wrote:
a dodatkowo z możliwością podświetlenia
gdy jest ciemno - co nie jest możliwe w wyświetlaczu Kindle.
Kindle to czasami nie jest e-paper? Czyli ma wszystkie zalety papieru -
lacznie z zapotrzebowaniem na latarke gdy jest ciemno.
a dodatkowo z możliwością podświetlenia
gdy jest ciemno - co nie jest możliwe w wyświetlaczu Kindle.
Kindle to czasami nie jest e-paper? Czyli ma wszystkie zalety papieru -
lacznie z zapotrzebowaniem na latarke gdy jest ciemno.
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ą.
Pszemol
Guest
Guest
Thu Dec 16, 2010 5:16 pm
"Sebastian Biały" <heby@poczta.onet.pl> wrote in message
news:ieb69g$mfp$1@news.onet.pl...
Quote:
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.
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.
No ok, ale w ten sposób nie wykorzystujesz np. stronnicowania
w wyświetlaczach LCD, i pewnie widać przerysowanie całego ekranu?
Sebastian Biały
Guest
Guest
Thu Dec 16, 2010 6:48 pm
On 2010-12-16 17:16, Pszemol wrote:
Quote:
No ok, ale w ten sposób nie wykorzystujesz np. stronnicowania
w wyświetlaczach LCD, i pewnie widać przerysowanie całego ekranu?
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.
Pszemol
Guest
Guest
Thu Dec 16, 2010 7:26 pm
"Sebastian Biały" <heby@poczta.onet.pl> wrote in message
news:iedje8$uab$1@news.onet.pl...
Quote:
On 2010-12-16 17:16, Pszemol wrote:
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.
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.
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
Adam Dybkowski
Guest
Guest
Fri Dec 17, 2010 11:38 pm
W dniu 2010-12-16 18:48 Sebastian Biały napisał(a):
Quote:
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.
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.
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/
Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.
Sebastian Biały
Guest
Guest
Sat Dec 18, 2010 12:37 am
On 2010-12-17 23:38, Adam Dybkowski wrote:
Quote:
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?
procka głównego wolisz dołożyć pośredniczącego AVRa oraz pamięć na SPI?
Pamięć na SPI to ostateczność, np popędzanie wyświetlacza bez własnego
RAM. Zazwyczaj wystarczy translator bez zewnętrznej pamięci.
Quote:
Pierwszy z brzegu ARM z 256KB Flasha i 64KB RAMu kosztuje ze 30 zł. A
zapewne wystarczyłby i mniejszy.
zapewne wystarczyłby i mniejszy.
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.
Adam Dybkowski
Guest
Guest
Mon Dec 20, 2010 12:47 am
W dniu 2010-12-18 00:37 Sebastian Biały napisał(a):
Quote:
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?
Pamięć na SPI to ostateczność, np popędzanie wyświetlacza bez własnego
RAM. Zazwyczaj wystarczy translator bez zewnętrznej pamięci.
Pierwszy z brzegu ARM z 256KB Flasha i 64KB RAMu kosztuje ze 30 zł. A
zapewne wystarczyłby i mniejszy.
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.
procka głównego wolisz dołożyć pośredniczącego AVRa oraz pamięć na SPI?
Pamięć na SPI to ostateczność, np popędzanie wyświetlacza bez własnego
RAM. Zazwyczaj wystarczy translator bez zewnętrznej pamięci.
Pierwszy z brzegu ARM z 256KB Flasha i 64KB RAMu kosztuje ze 30 zł. A
zapewne wystarczyłby i mniejszy.
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.
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/
Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.
Sebastian Biały
Guest
Guest
Mon Dec 20, 2010 8:43 am
On 2010-12-20 00:47, Adam Dybkowski wrote:
Quote:
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.
główny procesor. Odpadnie pośredniczący AVR a płytka wyjdzie mniejsza.
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.
elektroda NewsGroups Forum Index - Elektronika Polska - Jakie graficzne wyświetlacze LCD 122x32 z programowaniem w C dla ATmega wybrać?