W dniu 2011-03-19 01:13 sundayman napisał(a):

>> Zserializuj sygnały idące do twojego sterownika LCD i przepuść traktem
>> optycznym. Jeżeli na wyświetlaczu dużo się nie dzieje (np. odświeżasz
>> max 10 ekranów na sekundę przy pikselu 565 i rozdzielczości 800x480)
>> to nie jest wymagana jakaś ekstremalna przepływność. Po drugiej
>> stronie masz już swój procek podczepiony do LCD (np. ten ARM9), niech
>> zajmuje się przy okazji deserializacją.
>
> no niezupełnie. Znaczy - nie chciałem PRZY lcd dawać arma, bo potrzebuję
> jego "peryferiów" w części głównej.
> Ale - ew. do obsługi samego LCD mogę ew. dać jakiegoś najtańszego ,
> który się nada.
> Tylko teraz tak, odswiezanie 10/s moze byc mało...tam mają być
> "animacje" w GUI , więc chociaż tak z 15-20 chyba powinno być.
>
> Policzmy, ile tego trzeba.Załóżmy ten 800x480, 15 ramek, 5/6/5 bit/kolor
> to daje... 88 Mbit ? A dla 20 ramek 107 Mbit mi wychodzi.
> No to zdeserialozować to na jakimś FPGA to pewnie spokojnie, ale na MCU ?
>
> Jak to kolega widzi ?

Musisz do tego podejść całkiem z innej strony: jeżeli masz "głupi" LCD
(bez wbudowanego kontrolera) to i tak potrzebujesz ARMa z wbudowanym
kontrolerem LCD. Mały to już i tak nie będzie. Dlaczego więc by nie
włożyć w niego większości operacji, które w GUI muszą być realizowane?
Bitmapy, przyciski, okienka itd. Jeżeli ten wyświetlacz ma być jeden,
wkładany na zmianę do wielu urządzeń - to tym bardziej do niego trzeba
przerzucić jak najwięcej kodu a oszczędzić kasę na prockach w wielu
urządzeniach. Trywialnym sprzęgiem optycznym doprowadzisz z/do niego
UART, przez który właściwe urządzenie niech zleca tylko proste operacje
- wypisanie ciągu znaków, pokazanie bitmapy o nazwie "abc.png" w
określonym miejscu ekranu, pokazanie przycisku itd. Wtedy rzeczywiście
kawałek sprzętu przy LCD się rozbuduje (większy procek, jakiś Flash na
bitmapy) ale procki w wielu urządzeniach nie będą tego musiały umieć.

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

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.