RTV forum PL | NewsGroups PL

Innowacyjne metody bezprzewodowej transmisji dla 6-7 calowego LCD z MCU

bezprzewodowa komunikacja z LCD.

NOWY TEMAT

elektroda NewsGroups Forum Index - Elektronika Polska - Innowacyjne metody bezprzewodowej transmisji dla 6-7 calowego LCD z MCU

Goto page 1, 2  Next

sundayman
Guest

Fri Mar 18, 2011 4:52 pm   



Takie mam zadanie nietrywialne :)

Otóż , mamy LCD rzędu 6-7 cali. Ten wyświetlacz ma pracować w jakimś
wbudowanym sterowniku.
Na razie nie wiem, czym to bedzie sterowane - albo jakiś lepszy MCU z
wbudowanym interfejsem dla LCD, a może
jakiś ARM9 (np. samsung S3C2440) - coś w tym rodzaju.

I teraz - jakie by tu cudo wymyśleć, coby można było oddzielić ten LCD od
systemu ?
Chodzi o potrzebę fizycznej izolacji, a nie galwanicznej - ale w sumie efekt
ten sam :)

Czyli - zasilanie moge dać transformatorkiem - w obudowie modułu z LCD dać
uzwojenie wtórne, w obudowie "głównej" pierwotne.
Ale jak tu oddzielić wizję ? Żeby tak jeszcze zachować szybkość transmisji.
Ostatecznie mogę rozważać np. LCD z wejściem RGB,
tyle że dodatkow muszę taką konwersję zrobić po stronie MCU. A tu każda
złotówka się liczy...

Macie jakieś genialne pomysły ?
Odległość żadna - chodzi o to, żeby się dało wyjąć z obudowy głównej obudowę
z LCD. Czyli normalna praca polega na tym, że się "wtyka" moduł z LCD i
gitara.
Oczywiście - żadne złącza nie wchodzą w grę Smile

J.F.
Guest

Fri Mar 18, 2011 5:54 pm   



On Fri, 18 Mar 2011 16:52:41 +0100, sundayman wrote:
Quote:
Takie mam zadanie nietrywialne :)

Chodzi o potrzebę fizycznej izolacji, a nie galwanicznej - ale w sumie efekt
ten sam Smile

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.

sundayman
Guest

Fri Mar 18, 2011 7:20 pm   



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 Smile

Paweł
Guest

Fri Mar 18, 2011 7:23 pm   



Quote:
Czyli - zasilanie moge dać transformatorkiem - w obudowie modułu z LCD dać
uzwojenie wtórne, w obudowie "głównej" pierwotne.
Ale jak tu oddzielić wizję ? Żeby tak jeszcze zachować szybkość transmisji.
Są transformatorki do CCTV służące do galwanicznej separacji.


Paweł

sundayman
Guest

Fri Mar 18, 2011 11:19 pm   



Quote:
Ale w jakim celu ?
O rany, a co za różnica Smile

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.

Adam Dybkowski
Guest

Fri Mar 18, 2011 11:42 pm   



W dniu 2011-03-18 16:52 sundayman napisał(a):

Quote:
Otóż , mamy LCD rzędu 6-7 cali. Ten wyświetlacz ma pracować w jakimś
wbudowanym sterowniku.
Na razie nie wiem, czym to bedzie sterowane - albo jakiś lepszy MCU z
wbudowanym interfejsem dla LCD, a może
jakiś ARM9 (np. samsung S3C2440) - coś w tym rodzaju.

I teraz - jakie by tu cudo wymyśleć, coby można było oddzielić ten LCD od
systemu ?

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

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

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

sundayman
Guest

Sat Mar 19, 2011 1:13 am   



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

sundayman
Guest

Sat Mar 19, 2011 1:50 am   



A może zrobić sprzętowy deserialiser ?
Tylko na czym, bo jak mam jakiś przeciętny LCD z interfejsem RGB (np. coś
takiego
http://www.ampdisplay.com/product_specs/7.0%20Digital-specs/ADI_7.0_AM800480E2-TMQW-01H-pre.pdf)

no to potrzebuję przesłać dla typowej szybkości CLK 40MHz dane z szybkością
720Mbit.
Możemy powiedzmy wykorzystać 4 kanały : CLK,R,G,B to mamy wtedy 240Mbit.

Sporawo. W co to wpuścić ???

J.F.
Guest

Sat Mar 19, 2011 2:29 am   



On Fri, 18 Mar 2011 23:19:26 +0100, sundayman wrote:
Quote:
Ale w jakim celu ?
O rany, a co za różnica Smile No tak musi być.

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

Quote:
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ę.

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

Quote:
Pomyślałem o optycznej transmisji - via diody nadawcze i odbiorcze IR. Można
ich dać ileś tam (taki "interfejs zrobić")

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

J.

Adam Dybkowski
Guest

Sat Mar 19, 2011 10:33 am   



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

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

sundayman
Guest

Sun Mar 20, 2011 2:05 am   



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

a się kolega uparł Smile
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 :)

Quote:
... 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 Smile

sundayman
Guest

Sun Mar 20, 2011 2:31 am   



Quote:
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 Smile
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 Smile 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 Smile

Adam Dybkowski
Guest

Sun Mar 20, 2011 10:43 am   



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

Quote:
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 Smile

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.

sundayman
Guest

Sun Mar 20, 2011 4:28 pm   



Quote:
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 Smile
No ale - albo zrobię w cenie akceptowalnej, albo nie zrobię wcale (zrobi
ktoś inny) - a jak łatwo się domyśleć, wolę to pierwsze Smile
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 Smile

Marcin Wasilewski
Guest

Sun Mar 20, 2011 4:33 pm   



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

Quote:
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ł.

Goto page 1, 2  Next

elektroda NewsGroups Forum Index - Elektronika Polska - Innowacyjne metody bezprzewodowej transmisji dla 6-7 calowego LCD z MCU

NOWY TEMAT

Regulamin - Zasady uzytkowania Polityka prywatnosci Kontakt RTV map News map