> Ale z tego czasem wynikaja inne pomysly albo inne rozwiazania.
> Np czemu nie moze byc zlacza ....

a się kolega uparł :)
No dobrze, może być złącze, które będzie w 100% szczelne (wodoodporne), do
tego
musi być odporne na wodę morską przy temperaturze do kilkudziesięciu st. C.
I tanie :)

> ... albo skoro ma byc tak latwo odlaczalny, to po co on tam w ogole
> jest - i moze wystarczy jeden na 10 sterownikow, a wiec najrozsadniej
> bedzie kupic gotowy TV zamiast robic samemu.

Musi być odłączalny na wypadek serwisu (użyszkodnik musi mieć taką możliwość
awaryjnie).
"panel LCD" + "reszta" to komplet i taki musi być. To jest projekt nie do
zabawy :)

do góry

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

Nie, wyświetlacz ma być wyjmowany tylko z powodu, żeby można go odesłać do
serwisu.
1 wyświetlacz - 1 urządzenie.

Ogólnie to co opisałeś, to jest dobra idea - zresztą dokładnie tak są
rozwiązane w większości systemy sterowania , które czasem (przy innych
okazjach)
zdarza mi się instalować - np. budynku inteligentnego. Tak, że koncepcja
jest idealna technicznie - gdyby nie cięcie kosztów :)
No, bo tak - ten ARM9, jak już go mam dać w ogóle do LCD, żeby była ładna
graficzka, i żeby to sobie wygodnie robić
za pomocą jakiegoś QT na przykład na linuxie, to - bardzo by było
uzasadnione również tak rozwiązać "główną" aplikację.
Innymi słowy - skoro już całe urządzenie ma tego ARM9 (bo gdyby nie to LCD i
latające obrazki, to by się obyło bez niego),
to byłoby bez sensu imho nie wykorzystać go do wszystkiego.

No i po drugie, chciałem go wykorzystać do innych ficzerów - WiFi, ethernet
itp. To musiałbym to wszystko przenieść do tego LCD.
A to już kłopocik się zaczyna robić, i pół laptopa :)

A nie mogę dać drugiego "w środku" - liczymy każdą złotówkę niestety.

Poza tym jeśli dam główny program razem z GUI, to jak użyszkodnik go
wyciągnie - to cały system zdechnie.
Chociaż - niby nie powinien wyciągać, dopóki mu się nie zepsuje :) Ale
użyszkodnicy bywają nieobliczalni.

No i dlatego zacząłem kombinować z tym przesyłem danych, żeby ARMa mieć w
środku.
No wiem, że to trochę wydaje się dziwaczne, ale w tym przypadku niestety to
by było najlepsze, oczywiście zakładając, że koszt takiego sprzęgu
to powiedzmy - 20E. Bo jak drożej, to się zaczyna robić bez sensu....

No kurcze wydawałoby się - prosta rzecz - przesłać trochę prostych danych,
tyle że szybko :)

do góry

W dniu 2011-03-20 02:31 sundayman napisał(a):

> Nie, wyświetlacz ma być wyjmowany tylko z powodu, żeby można go odesłać
> do serwisu.
> 1 wyświetlacz - 1 urządzenie.
[...]
> No kurcze wydawałoby się - prosta rzecz - przesłać trochę prostych
> danych, tyle że szybko :)

O sprzęgach optycznych już była mowa. Jeżeli z transferem zmieścisz się
w 1Gbps to do kupienia są gotowe nadajniki/odbiorniki światłowodowe.
Oczywiście i na 10Gbps (i więcej!) znajdziesz ale cena rośnie wykładniczo.

Pomyśl o rozdzieleniu programu na 2 procki: mocny (przy LCD) i słabszy
(w urządzeniu). W mocnym może śmigać np. Linux i grafika w QT, a słabszy
będzie mu tylko dostarczać proste zestawy danych i polecenia co
narysować. Oczywiście aby urządzenie działało sensownie po odłączeniu
modułu z LCD, właściwe "mięsko" programu (oprócz samego rysowania) musi
leżeć w słabszym procku.

Poza tym nie pisz, że szkoda Ci 50 zł na dobry procek, gdy projektujesz
urządzenie odporne na skrajne warunki (woda morska i kilkadziesiąt st.
C). Sama obudowa do tego urządzenia będzie pewnie kosztować 10x tyle.

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

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

do góry

> Poza tym nie pisz, że szkoda Ci 50 zł na dobry procek, gdy projektujesz
> urządzenie odporne na skrajne warunki (woda morska i kilkadziesiąt st. C).
> Sama obudowa do tego urządzenia będzie pewnie kosztować 10x tyle.

Panie kolego, mnie to nie szkoda, tylko klientowi, który ma węża boa w
kieszeni.
Obudowa to w tym przypadku nie mój problem, będzie robiona z tworzywa (na
wtrysku), tak że jednostkowo wyjdzie niedrogo.
A całość ma niezbyt duży budżet ,też uważam , że za mały jak na te wymogi :)
No ale - albo zrobię w cenie akceptowalnej, albo nie zrobię wcale (zrobi
ktoś inny) - a jak łatwo się domyśleć, wolę to pierwsze :)
Zawsze najłatwiej powiedzieć, że "się nie da i proszę spadać na drzewo", no
ale nic z tego nie będę mieć wtedy.

Cóż, na razie przyjąłem wersję taką, że procek przy LCD będzie obsługiwał
cały soft, natomiast w środku dam
naprawdę prosty MCU, który mi fizycznie obsłuży peryferia, i będzie się toto
komunikowało via RS.

Ewentualne WiFi dam też przy LCD, jakoś tam się zmieści. Z ethernetu chyba
zrezygnuję po prostu.
No i postaram się, żeby wyjęcie tego modułu z LCD było proste, ale nie aż
tak, żeby to zrobić "przypadkiem".
Jak to się mówi "wyżej d... nie podskoczę" :)

No i tyle.
Dzięki serdeczne za uwagi i pomoc :)

do góry

Użytkownik "sundayman" <s...@p...onet.pl> napisał w wiadomości
news:im0sf6$gj$1@news.onet.pl...

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

Wg mnie jednostka sterująca i rysująca GUI powinna być przy tym LCD, a w
głównym urządzeniu tylko moduł wykonawczy. W ten sposób pomiędzy
touchpanelem a urządzeniem głównym masz do przesyłania jedynie niewielkie
sekwencje sterujące, które bez problemu (i ze sporym zapasem) przepuścisz
przez byle transciver za 15 zł.

do góry

Użytkownik "sundayman" <s...@p...onet.pl> napisał w wiadomości
news:im3lcg$5k4$1@news.onet.pl...

> A to już kłopocik się zaczyna robić, i pół laptopa :)
> A nie mogę dać drugiego "w środku" - liczymy każdą złotówkę niestety.
> Poza tym jeśli dam główny program razem z GUI, to jak użyszkodnik go
> wyciągnie - to cały system zdechnie.

A tor analogowy z modulatorem i demodulatorem to możesz dać? To jest
dopiero koszt.
Pamiętaj, że nadmierna oszczędność się mści, a podzespoły analogowe służące
do obsługi tej transmisji mogą być droższe niż ten drugi procek.
Jedyne sensowne podejście to transmisja cyfrowa, czy to rozkazów, czy
strumienia bitowego z obrazem, gdyż za jej pomocą możesz w strumień wplatać
dane sterujące itp.
Tak czy siak, bez drugiego procka się nie obędziesz.

do góry

On Sun, 20 Mar 2011 16:33:36 +0100, Marcin Wasilewski wrote:
>Wg mnie jednostka sterująca i rysująca GUI powinna być przy tym LCD, a w
>głównym urządzeniu tylko moduł wykonawczy. W ten sposób pomiędzy
>touchpanelem a urządzeniem głównym masz do przesyłania jedynie niewielkie
>sekwencje sterujące, które bez problemu (i ze sporym zapasem) przepuścisz
>przez byle transciver za 15 zł.

w zaleznosci od wymogow moze rowniez nie byc problemem przepuscic po
prostu strumien video. Za to ulatwia sie troche konstrukcja
oprogramowania .. albo i utrudnia :-)

J.

do góry