-
21. Data: 2010-12-16 18:26:10
Temat: Re: Graficzne wyświetlacze LCD
Od: "Pszemol" <P...@P...com>
"Sebastian Biały" <h...@p...onet.pl> wrote in message
news:iedje8$uab$1@news.onet.pl...
> 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 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 :-)
-
22. Data: 2010-12-17 22:38:09
Temat: Re: Graficzne wyświetlacze LCD
Od: Adam Dybkowski <a...@4...pl>
W dniu 2010-12-16 18:48 Sebastian Biały napisał(a):
>> 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.
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.
-
23. Data: 2010-12-17 23:37:15
Temat: Re: Graficzne wyświetlacze LCD
Od: Sebastian Biały <h...@p...onet.pl>
On 2010-12-17 23:38, Adam Dybkowski wrote:
> 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.
-
24. Data: 2010-12-19 23:47:08
Temat: Re: Graficzne wyświetlacze LCD
Od: Adam Dybkowski <a...@4...pl>
W dniu 2010-12-18 00:37 Sebastian Biały napisał(a):
>> 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.
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.
-
25. Data: 2010-12-20 07:43:55
Temat: Re: Graficzne wyświetlacze LCD
Od: Sebastian Biały <h...@p...onet.pl>
On 2010-12-20 00:47, Adam Dybkowski wrote:
> 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.
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.