Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Wyświetlacz LCD od s65 jako ekran TV

jarkem 17 Aug 2010 15:40 4079 17
Tespol
  • #1
    jarkem
    Level 16  
    Witam! Myślę nad pewnym urządzeniem i zastanawiam się czy można coś zrobić żeby ekranem TV był wyświetlacz LCD np od Siemensa S65 lub nokii, ewentualnie aparatów cyfrowych... Szybkość wyświetlania (bo pewnie po drodze musiałby być procesor) nie musi być porywająca... Do wykorzystania są wyjścia EURO i S-video... Jakieś linki lub pomoc mile wskazana...
  • Tespol
  • #2
    tomek_programista
    Level 19  
    Też miałem taki pomysł: Mini TV i LCD z Sony Ericsson k550i
    Znalazłem nawet oscyloskop z ekranem od Siemensa S65.
    Wystarczyło tylko napisać procedurę wyświetlania pikseli na ekranie.
    Ale to było ponad moją wiedzę.
  • #3
    tmf
    Moderator of Microcontroller designs
    Zacznij najpierw od digitalizacji sygnału z S-Video, odzyskania z niego sygnałów synchronizacji i sygnału wizji. Jeśli cię to nie zatrzyma to reszta jest raczej prosta - napisanie procedur, które z sygnału o rozdzielczości PAL zrobią obraz o rozdzielczości natywnej dla LCD. Właściwie całość ci załatwia układ typu BT878 i podobne ze starych kart TV. Są też LCD, które oprócz wejścia cyfrowego mają także wejścia analogowe z których wyświetlają obraz w programowo określonym okienku. Wtedy trzebaby tylko odzyskać sygnały synchronizacji.
  • Tespol
  • #4
    nsvinc
    Level 35  
    bez paniki :]

    Wystarczy poszukać na stronie Analog Devices kości, do której podłączasz
    analogowy sygnał wizji, a wypluwa z drugiej strony juz gotowe, odfiltrowane
    informacje cyfrowe, ktore można sobie wziąć i użyć. Jestem pewny, że
    takie scalaki mają bo widziałem, tylko oznaczeń nie pamiętam.
    Analog przysyła sample...

    tmf wrote:
    Właściwie całość ci załatwia układ typu BT878 i podobne ze starych kart TV.

    No to łup...
    Mam dziwne wrażenie, że z podstawową obsługą BT8x8 być może
    poradzi sobie ARM7, a być może nie.... Sądzę, że autor tematu
    raczej nie miał na myśli użycia procesora innego niż AVR....

    trzeba zauważyć, że obojętnie czy BT8x8 przeskaluje obraz do chcianej
    rozdzielczości, czy nie - procesor musi być na tyle szybki, żeby zdążyć
    odebrać każdy piksel, i przenieść go na matrycę.
    Wyświetlacze od starych komórek odpadają - >15fps nie wydoisz, a i to
    nie jest pewniak.
    Dobrym początkiem na taką zabawę byłby chociażby taki STM32, i
    dobra matryca z kontrolerem przystosowanym do odbierania
    piksli w czasie "prawie" rzeczywistym...
  • #5
    tmf
    Moderator of Microcontroller designs
    Wydoli spokojnie, BT878 steruje się po I2C, po skonfigurowaniu wypluwa gołe dane cyfrowe, które po dodaniu zegara nadają się do bezpośredniego wysłania do LCD. Zresztą jeśli skalowanie będzie sprzętowe, to i AVR bez problemu wydoli, co więcej, niektóre rodziny przy takim transferze będą się nudzić. A LCD z S65 wydoli znacznie więcej niż 15FPSów, SPI dla niego można taktować >10MHz, pomijając pare bajtów wymaganych do wysłania komendy zapisu mamy 46464 bajtów na ramkę, czyli bez problemu 25 FPS wyciągniemy.
  • #6
    nsvinc
    Level 35  
    Być może. Jeden z Kolegów na tym forum robił doświadczenia z takimi
    wyświetlaczami - no i właśnie stąd wywnioskowałem fpsy tego wyświetlacza.

    Ehh...znowu bedzie potyczka...

    Dla 640x480 przy 60fps wychodzi transfer do wyświetlacza na poziomie
    36 864 000 bajtów na sekunde, zakladajac 64k kolorow....
    Ciezko wymagac takiej wydajnosci pracujac z 16DMIPSowym AVRkiem
    Nawet w tej chwili mocny CM3 generuje zegar SPI o fmax nie wiekszym
    niż 36MHz...Co daje 36megabitów na sekunde...MAŁO....

    Co z tego, ze steruje się go przez I2C...Liczy sie nie sam config, a
    przepustowość magistrali niosącej obraz.

    Pamietaj o tym, że wyswietlacz od S65 nie połyka rozkazów z częstotliwością
    zegara. On ma swoje delaye, na ktore bedziesz czekać albo w przerwaniu, albo delayem.
    Ten kontroler niestety nie wydoli po prostu. Jest topic, gdzie rozmawiałem
    z jednym z Kolegów na temat tego wyświetlacza - i między innymi dlatego
    nigdy nie położyłem go do układów.

    Być może najnowsza XMEGA sobie poradzi, korzystając z udogodnien DMA.
    Ale nawet soft w asmie nie wydoli po prostu gdy zmusisz procesor
    do przerzucania informacji (tj wykorzystanie procka jako klej), gdy ma on
    po prostu za mało MIPSów...

    Wiem z doświadczenia, że nawet CM3 niestety traci "punkty" gdy chcę napisać
    w niskim C aplikację okienkową - nie wyrabia się....
    I tu znacznie zyskuje CR4F :) Radzę Koledze zamowić z TI sample tego układu -
    just beautiful....:D
    '
    A, chcialem dodać - nieistotne jest, czym konfigurujesz kość zajmującą
    się przetwarzaniem obrazu. Zdaje się, że głowice FM na kartach TV z scalakami
    BT8x8 też były sterowane po I2C.... Pomijając zawodność I2C - nawet dla
    poczatkujacego programisty jest to zerowy poziom trudności zapisać i odczytać
    bajt po I2C. Gorzej z danymi obrazu...

    Gotowe informacje dla wyświetlacza? OK, ale CO Z OSD?. Myśmy
    przyszłościowo...Przecież nie położysz dodatkowego wyświetlacza
    2x16 na którym wyświetlisz aktualną częstotliwość dostrojenia odbiornika...
    Lepiej pokazać to przez OSD, no a tutaj wracamy do tematu wymaganych MIPSów...

    --------
    PS.
    ->tmf
    Jak ja sie lubie z tobą kłócić :)
  • #7
    jarkem
    Level 16  
    Zainteresował mnie fakt gotowych układów Z Analog Device, choć muszę trochę poszukać zanim znajdę poprawny dział produktów... Pamiętać należy że obraz nie musi być bardzo szybko wyświetlany lub w nie wiadomo jakiej rozdzielczości... Ma tylko wyświetlać na małym ekranie LCD to co pojawia się na Euro/S-video... Coś na typ okna podglądowego... Pozdrawiam...
  • #8
    nsvinc
    Level 35  
    Obojętnie jaki mały jest wyświetlacz - zegar piksla jest wyznacznikiem
    płynności obrazu. Nawet na podglądzie 5fps będzie wyglądać dosyć
    pokracznie. A nie radzę przeskalowywać 720p PAL na np. 120p, bo zamiast
    uroczej laski zapowiadającej wiadomości zobaczysz pasztet w tym smutne
    efekty ditheringu i mory....
  • #9
    tmf
    Moderator of Microcontroller designs
    Tylko pamiętaj, że od początku była mowa o LCD o niskiej rozdzielczości, S65 ma 176*132 punkty i AVR spokojnie wydala z przerzucaniem do niego danych. Jeśli z kolei chce mieć LCD o wyższej rozdzielczości to najprościej dobrać taki z wejściem analogowym, można je podłączyć bezpośrednio do zregenerowanego sygnału video i dodać tylko synchronizację.
    BTW o jakim opóźnieniu dla komend mówisz w przypadku LCD z S65? Nie ma żadnych opóźnień, tylko przy inicjalizacji jest wymagane odczekanie pomiędzy włączeniem LCD a dalszymi komendami. Wysłanie pełnej ramki wymaga tylko 8 dodatkowych bajtów.
  • #10
    nsvinc
    Level 35  
    AVR wydoli pod jednym warunkiem. Że strumień bitów po SPI będzie szedł
    przez DMA (którym standardowa ATMega nie dysponuje...), a nie zapisem do rejestru z obstawą while-ów czekających
    na "transfer complete" i całą resztę tego typu flag. Popatrz ile czasu
    stracisz na kręcenie się w pętlach, czekających na flagi...

    696960 16bitowych słów danych przy 64k koloru i 30fps. 1393920 bajtów
    trzeba wysłać co sekundę. Co daje nam zegar SPI rzędu 11151350Hz.
    nie wliczam 8 bajtow overhead

    Czy naprawde w AVRkach SPI chodzi z pełną prędkością zegara rdzenia?
    Pomijając prędkość SPI - sprawdzmy ile masz instrukcji rdzenia między
    kolejnymi zapisami do shift-registra modułu SPI, zakładając idalny (uwaga na skoki...) przelicznik
    1DMIPS/MHz przy 16MHz zegarze...:
    16000000/1393920 = 11,48 jedenascie z kawałkiem instrukcji. wlicz w to pętle czekające na flagi,
    no i sam zapis. Ciężko...A gdzie reszta maina, i gdzie przerwania??....

    Co do LCD z wejsciem analogowym - do zdobycia, chocby w maritexie - ale
    mało który poważny producent takie wyświetlacze robi. W obecnych
    czasach obstawia się na cyfrówkę.

    Poza tym, myślę że taki BT8x8 raczej nie będzie wiedział jak prawidłowo
    wysyłać obraz analogowo do takiego "chińczyka" z maritexu. Mogą
    być rozjazdy.
  • #11
    tmf
    Moderator of Microcontroller designs
    Od tyłu - BT878 + zegar wyśle dane cyfrowo do LCD, który ma tylko wejścia synchronizacji i wejścia RGB, np. 6 bitów/kanał. Niektóre sterowniki do LCD komórkowych też oferują wejścia, za pomocą których bezpośrednio można wyświetlić bitstream. LCD z analogowym wejściem są bardzo popularne - cały sprzęt TV do samochodu działa na takich LCD. Do kupienia praktycznie wszędzie.
    Co do twoich wyliczeń - są OKDR, bo od początku jest mowa o małym LCD, a nie LCD o rozdzielczości VGA. Dla S65 mamy 132*176 pixeli, to nam daje 46464 bajtów/ramkę, chcemy 25 ramek (nie wiem skąd dla PAL wziąłeś owe 30fps), to nam daje 1161600 bajtów/s. 9292800 bps na SPI. Czyli jesteśmy ciągle w specyfikacji LCD. Żeby ATMega miała taki zegar na SPI jej zegar musi być 2xszybszy, czyli ok. 18MHz, nie ma problemu bo nowe mają zegary do 20MHz. Procesor wykona 16 instrukcji pomiędzy bajtami. Nie jest to może dużo, ale wystarczy. Tym bardziej, że w sygnale PAL mamy przecież blank time pomiędzy liniami, oraz pomiędzy ramkami, w którym to mamy całkiem sporo czasu na ew. inne obliczenia. Zresztą nie specjalnie widzę jakie to jeszcze operacje miałby procesor w międzyczasie wykonywać. A jak nie wierzysz do czego zdolna jest ATMega to zobacz projekt uzebox - http://belogic.com/uzebox/. Tu nie tylko generuje obraz TV ale jeszcze ma czas grać muzykę i można sobie poszpilać w oldschoolowe gierki.
  • #12
    nsvinc
    Level 35  
    Zakładając disasemblację gotowego telewizorka samochodowego i
    zdobycie wyświetlacza w ten sposób...no ok :] Nie pomyślałem tymi
    kategoriami...

    Obliczenia potwierdzam :] Faktycznie wziąłem pod rozważania złą
    rozdzielczość.

    Uzebox...No chciałoby się do czegoś przyczepić, ale nie ma do czego :]
    Jedyne co trochę rzuca się w oczy, to hardcorowo podkrecony
    procesor no i tragicznie mało kolorów. Pozostałość - impressive.

    Tak patrzę sobie w datasheeta BT878, i widzę, że nie wypluje on gotowych
    danych na wyświetlacz. Zauważ, że scalak
    nie ma kontrolera LCD, i nie ustawisz w nim parametrow
    rdzennie ważnych dla wyświetlacza (front porch, back porch, VSYNC width itp...)
    Więc nie da się podłączyć standardowego LCDka z wejsciami parallel-RGB pod BT878 bez zastosowania kleju.
    Pomijając już chęci podłączenia takiego wyświetlaczyka od s65 do biednego
    BT878...

    Twoje obliczenia pokazały, że nie ma co się obawiać o wysyłanie danych
    na wyświetlacz. Robiąc to w czasie rzeczywistym, cieszymy sie 16stoma
    wolnymi instrukcjami co piksel. No a teraz z pełną konsenwencją wypada
    jednak troche tych zegarów zmarnować :]
    Oprocz wysłania danych na wyświetlacz, mamy jeszcze do odebrania piksle
    z BT878. Mamy zegar piksla, co który trzeba wyrwać 16 bitów koloru - dla
    ATMegi dwa porty - 3 instrukcje (nie mam najmniejszej pewnosci, szacuje).
    Więc zadania i oszacowane zegary:
    1) co zbocze wejść w przerwanie: 4
    2) wyrwać 16 bitów danych z portów: 3
    3) Sprawdzić ifami co to za dane (czy koniec ramki itp itd...): 6
    4) Zapisać do data registra SPI pierwszy bajt: 1
    5) Zbuforować drugi bajt: 1
    6) Inkrementować jakieś liczniki / inne zmienne kontrolno-pomocnicze: 4
    7) Ustawić flage dla przerwania SPI: 1
    8) Wyjść z przerwania: 2

    Dodatkowo koniecznością jest przerwanie SPI, w ktorym
    podejmie się decyzja czy wysłać drugi, zbuforowany bajt, czy uznać
    koniec transmisji piksla:
    1) Wejść do przerwania: 4
    2) if sprawdzający flagę czy wysłac drugi bajt: 2
    2a) jesli powyzsze, zapisać do data registra SPI drugi bajt: 1
    3) Uwalic flage: 1
    4) Wyjść z przerwania: 2

    Widzisz, ciasno. Uzebox nie musi nic odbierać (i to jeszcze po
    cudzym zegarze), więc ma czas.

    W powyższym przykładzie rozpisałem tylko algorytm klejący BT878 z wyświetlaczem. A gdzie parę instrukcji na podstawowe zmiany
    konfiguracji po I2C, o nawet najprostszym OSD nie wspominając?...
  • #13
    tmf
    Moderator of Microcontroller designs
    LCD z analogowym wejściem z niczego nie trzeba wypruwać. Bez problemu można je kupić za ułamek ceny normalnego LCD.
    Co do reszty, napisałeś się, poświęciłeś czas, zamiast zajrzeć do dokumentaci BT878. On ma SPI out mode, w którym po SPI wypluwa dane o obrazie. Wykorzystując ten tryb CPU musi tylko inicjalizować transfer do LCD (raz na ramkę), gołe dane idą bezpośrednio z BT do LCD po SPI. Procesor się nudzi, jal chce może sobie OSD nakładać (z drugiej strony istnieją do tego specjalne chipy).
  • #14
    nsvinc
    Level 35  
    No ok - ma SPI output (nie zauważyłem :P). Jak widzisz rozwiązanie inicjalizacji transferu do LCD, bez czynnego udziału procesora w tym
    transferze? Skad procesor ma wiedzieć, gdzie zaczyna się ramka? Ma liczyć
    zegary? Zauważ, że BT878 generuje zegar, więc przy próbie
    wysłania inita do wyświetlacza procesor musi zbramkować zegar z BT878,
    uaktywnić swój, i wysłać dane. Bramkowanie zegara z BT == zgubione piksle.
    A zegar z BT idzie cały czas, i nie powinno się go ot tak wstrzymywać lub
    bramkować.

    Co do OSD - chipy istnieją do wszystkiego. Mozna sobie takiego
    chipa wylutować, ale dokumentacje do ASICów kładzionych w wiekszości
    sprzętów są niedostępne (bo i po co...). Nie przeczę, że ktoś kiedyś
    wyprodukował kość do OSD, do której wchodzi spi, wychodzi spi, a osd
    jest wysyłane przez jeszcze jedno spi :]. Ale skąd taką kość wziąć?

    Procesor nie może po prostu nakładać OSD. Albo liczy zegary, w odpowiednich
    miejscach przełącza transfer z wyswietlacza na swoje SPI (i odłącza
    od wyświetlacza), buforuje piksel, modyfikuje mu kolor i wysyła do wyświetlacza a potem jakimś cudem próbuje ponownie zsynchronizować
    transfer do wyświetlacza z zegarem wychodzącym z BT878, albo
    bierze czynny udział w przerzucaniu piksli
    . Ale wtedy masz w przerwaniu ify,
    które wyłapują interesujące piksle i zmieniają im kolor.
    A wtedy zaczyna brakować czasu...
  • #15
    tmf
    Moderator of Microcontroller designs
    Oprócz prostego sygnału szeregowego masz także na GPIO wyprowadzony komplet sygnałów synchronizacji - synchro ramki i linii. Pomiędzy liniami w PAL są odstępy, po 64us o ile pamiętam, w tym czasie nie ma transmisji i procesor może wysłać komendę do LCD. Oczywiście trzeba rozwiązać problem sumowania zegara na SPI, ale tu mała bramka logiczna sprawę rozwiązuje. Co do OSD - sygnał synchronizacji linii możesz podać jako sygnał taktujący timer, w sprzętowym przerwaniu timera compare match robisz śledzenie kolejnych pixeli (tu też można wykorzystać kolejny timer) i nakładasz własny sygnał MOSI - wymagana kolejna bramka. Czyli wersja full wypas to dodatkowe 2 braki, chociażby pojedyncze w SOT23.
  • #16
    nsvinc
    Level 35  
    To rozwiązanie to jest "half wypas" :] Według moich założeń napis jest
    nałożony na obraz na podstawie oryginalnego koloru piksli pod napisem -
    będzie działał alpha-blending. W twoim rozwiązaniu nie.

    W datasheecie BT878 nie znalazłem, żeby napisali, że zegar kiedykolwiek
    zanika. Zdaje się że nie, bo to, że obraz przez eter idzie z przerwami
    miedzy ramkami/liniami/czyms innym, nie świadczy o tym, że w ten sam sposób
    dane są wypluwane przez SPI. BT878 dekoduje wchodzący obraz i pakuje
    to do FIFO. Zawartość tego FIFO wychodzi po SPI. Zawartość FIFO nie
    zawsze nadaje się do wyświetlenia. O tym mówią bity jednego z rejestrów
    statusowych - trzeba je czytać.
    Z tego wynika, że zegar z BT878 raczy nie zanikać, nawet gdy fizycznie
    w danym momencie piksle nie idą przez eter.

    Zauważ kolejny problem, że PAL definiuje interleaving jak i dual-scan.
    W BT878 nigdzie nie widzę pamięci ramki, więc dane wychodzą
    z niego w poplątany, PAL-owy sposób. W efekcie czego trzeba inicjalizować
    pozycję na wyświetlaczu co linię, i jeszcze trzeba wiedzieć na którą
    linię zmienić
    . Trzeba je liczyć.
  • #17
    jarkem
    Level 16  
    Tak czytam i... nie mogę wyjść z podziwu, że Polska ma tak zdolnych ludzi... Pełen szacunek dla Was i Waszej wiedzy... OSD mi nie potrzebne, chce tylko mieć podgląd co się pojawia na wyjściu wideo na jakimś małym LCD, więc myślałem o tym S65... Będę próbował na podstawie Waszych informacji coś złożyć... Pozdrawiam...
  • #18
    tmf
    Moderator of Microcontroller designs
    jarkem - my sobie tak luźno dywagujemy. Ty po prostu kup sobie LCD z wejściem analogowym i dołóż do tego układ odtwarzający synchronizację.
    nsvinc - nie będę się sprzeczał czy w blank time idzie zegar z SPI czy nie, bo nie chce mi się aż tak zagłębiać do dokumentacji :) Nawet jeśli idzie to skoro jak ustaliliśmy i tak musiałbym zrobić przełączanie zegara SPI pomiędzy BT a AVR, to tak naprawdę nic to nie zmienia. Początek linii dostaje w formie przerwania (to mi wypluwa BT), kiedy idzie pierwszy użyteczny pixel obrazu wiem (bo to wynika ze standardu PAL), zaprzęgam timer i wtedy przełączam na zegar z BT. Sam BT dekoduje obraz - można ustawić mu, który z półobrazów chcesz czytać. Zauważ, że przy naszej marnej rozdzielczości po prostu wywalenie drugiego półobrazu nic nie pogorszy. Ale można bez problemu przełączyć go, żeby robił progressive scan. Prawdę mówiąc zastosowanie alfa blendingu do OSD, jeszcze przy tak niskiej rozdzielczości to przegięcie.
    A jeśli te wszystkie działania by nie pomogły, to nie ma problemu, żeby znaleźć LCD, który ma oprócz kontrolera dodatkowe sprzętowe wejście do kontrolera do wyświetlania obrazu, na nie się podaje zwykle cyfrowo sygnał + impulsy synchronizacji (frame, nowa linia + dotclock). Chyba wszystkie kontrolery ILIxxxx to mają, z tym, że w komórkach to nie jest zazwyczaj wyprowadzone. Ale modele gdzie masz osobno gołą matrycę i osobno kontroler dają dostęp do tych pinów.