bezprzewodowa komunikacja z LCD.

Ale w jakim celu ?

Mozesz wstawic wifi, a wizja na netbooku. Przez x-windows, VNC czy RDP. I nie bedziesz ograniczony co do odleglosci - moze nawet przez modem sie da.

Mozesz wstawic modulator TV i dac normalny telewizorek.

J.

Wifi to odpada, ¿adnych netbooków itp.

Pomys³ z przesy³em radiowym ju¿ prêdzej - jakkolwiek nie mogê tam daæ "ca³ego" TV ( i sensu nie ma , tak¿e ekonomicznego) , ew. mo¿e panel z wej¶ciem RGB + modu³ video. Chocia¿ obawiam siê o jako¶æ obrazu , ale mo¿e niepotrzebnie...

No, ale mo¿e jakie¶ inne koncepcje ? Przypominam, ¿e odlego¶æ "stykowa" czyli prawie ¿adna. No, tyle ¿e bez styków :)

Są transformatorki do CCTV służące do galwanicznej separacji.

Paweł

O rany, a co za ró¿nica :) No tak musi byæ. Pomys³ z transmisj± wizji per radio jest niez³y, tyle ¿e wymaga dodatkowego dekodera wizji do rgb. Oraz - co gorsza jakiego¶ uk³adu "generatora wizji" w czê¶ci g³ównej. Nie wiem na ile tanio mo¿na to wykonaæ, bior±c pod uwagê, ¿e musi siê to daæ potem pod³±czyæ np. do ARM9 tak, ¿eby OS (powiedzmy android) móg³ to potem obs³u¿yæ normalnie (bêd± wykorzystywane "zaawansowane" metody generowania grafiki). Czyli ¿adne tam wynalazki z specjalizowanym systemem generowania obrazu (w rodzaju "generator wizji na mcu").

Oczywi¶cie nie u¿y³ bym do odbioru ca³ego "TV", ale jaki¶ fragment toru, bo ma to byæ ekonomicznie te¿ , a liczymy ka¿d± z³otówkê. No i zastanawiam siê nad tym, na ile to popsuje mi jako¶æ obrazu, ale mo¿e niewiele... No, to jest jaki¶ pomys³ w ka¿dym razie.

A co¶ innego ? Pomy¶la³em o optycznej transmisji - via diody nadawcze i odbiorcze IR. Mo¿na ich daæ ile¶ tam (taki "interfejs zrobiæ"), mo¿e to byæ dwustronne - co jest o tyle istotne, ¿e musi byæ komunikacja "od lcd" - bo musi mieæ touch panel.

W dniu 2011-03-18 16:52 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 ?

A mo¿e zrobiæ sprzêtowy deserialiser ? Tylko na czym, bo jak mam jaki¶ przeciêtny LCD z interfejsem RGB (np. co¶ takiego

Sporawo. W co to wpu¶ciæ ???

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

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

Dokladnie, sa np tranceivery do swiatlowodow, ale dzialaja tez bez wlokien - wystarczy zblizyc.

J.

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

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

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 :)

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 :)

Nie, wy¶wietlacz ma byæ wyjmowany tylko z powodu, ¿eby mo¿na go odes³aæ do serwisu.

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 :)

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

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.

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 :)

U¿ytkownik "sundayman" snipped-for-privacy@poczta.onet.pl> napisa³ w wiadomo¶ci news:im0sf6$gj$ snipped-for-privacy@news.onet.pl...

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

U¿ytkownik "sundayman" snipped-for-privacy@poczta.onet.pl> napisa³ w wiadomo¶ci news:im3lcg$5k4$ snipped-for-privacy@news.onet.pl...

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.

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.