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.

[LCD TFT] [AVR/ARM] [C] kilka pytań

dd1515 27 Apr 2012 16:24 7201 48
Texa Poland
  • #1
    dd1515
    Level 9  
    Witam,
    Posiadam taki wyświetlacz tft http://www.jhdlcd.com.cn/productshow.asp?ciid=97 i mam kilka pytań odnośnie jego sterowania/podłączenia do mikrokontrolera.
    1. Czy AVR da radę go wysterować ?
    2. W jaki sposób zacząć pracę z takim wyświetlaczem, co powinienem wiedzieć na początek o sterowaniu takiego wyświetlacza (inicjalizacja, przesyłanie danych) ?
    3. Panel dotykowy lepiej sterować bezpośrednio przez mikrokontroler czy inny scalak, np. AD7843 ?
    4. Z noty katalogowej wynika, że zasilanie podświetlenia to 16V. Jak najlepiej rozwiązać ten problem ?


    Nota katalogowa wyświetlacza:
    http://www.jhdlcd.com.cn/Upload/tbPdf/2011-12-7_10_50_31.pdf
    Nota katalogowa sterownika:
    http://www.allshore.com/pdf/HimaxHX8257.pdf
  • Texa Poland
  • #2
    tmf
    Moderator of Microcontroller designs
    1. Z zewnętrzną pamięcią SRAM XMEGA dałaby radę, zwykły AVR - nawet jakby to właściwie nic innego by nie robił.
    2. On wymaga generowania V i HSync oraz na bieżąco wysyłania danych RGB, jest prawie bezużyteczny.
    3. Obojętne, obsługa touch panela jest tak prosta że równie dobrze możesz to zrobić na aDC procesora. Wyjdzie taniej.
    4. Przetwornica.

    Weź pod uwagę, że ten LCD ma tylko trochę rozwinięty sterownik matrycy, ale nie ma swojej pamięci ani układu generującego obraz z VARAM. Stąd też musisz albo doać zewnętrzny sterownik, albo to zrealizować programowo. Ze względu na dużą rozdzielczość w grę wchodzą procesory XMEGA lub większe (ARM, UC3, 32-bitowe PICe).
  • #3
    gaskoin
    Level 38  
    Niektóre ARMy mają wbudowany kontroler takich matryc, jedyne co musisz robić to uzupełniać jakiś bufor i tyle.
  • #4
    dd1515
    Level 9  
    Dzięki za odpowiedź. Taki ARM w jakiej może być cenie ? Jeżeli w granicach 50-100zł to uważam, że bardziej opłaca się kupić trochę droższy wyświetlacz z lepszym sterownikiem i wtedy nawet tańszy ARM da radę. A co do V i HSYNC w nocie jest napisane, że zewrzeć z masą jeżeli nie jest używane, czyli jakoś można to "obejść" ? ;)
  • #5
    gaskoin
    Level 38  
    Zależy ile sztuk planujesz kupić, jak jedną to cena około 28 zł, sterowanie dotykiem jest w kontrolerze LCD więc też jest załatwione sprzętowo. Jak zależy Ci tylko na sterowaniu wyświetlaczem, to imho lepiej to zrobić na jakimś CPLD/FPGA. Ceny bardziej sensownych od 15 zł.
  • Texa Poland
  • #6
    tmf
    Moderator of Microcontroller designs
    gaskoin: ale zapominasz, że do realizacji bufora obrazu dla tego LCD potrzeba prawie 400 kB RAM, chyba żaden ARM tyle na pokładzie nie ma, czyli potrzeba zastosować zewnętrzną pamięć co pociąga dalsze koszty (kilka złotych pamięć + trochę więcej za PCB) i komplikuje układ. Na końcu otrzymamy coś co działa, za cenę gotowego porządnego modułu LCD - no może nie do końca, bo moduły o tych rozmiarach trochę kosztują.
  • #7
    dd1515
    Level 9  
    Wolałbym to zrobić na ARM skoro mam możliwość. Zamierzam do tego jeszcze później podłączyć kartę SD i inne pierdoły. Pewnie będę miał trochę problemów z obsługą tego wyświetlacza ale to już nie w tym temacie. Mógłbyś podać nazwę tego procka ?
  • #8
    gaskoin
    Level 38  
    tmf wrote:
    gaskoin: ale zapominasz, że do realizacji bufora obrazu dla tego LCD potrzeba prawie 400 kB RAM, chyba żaden ARM tyle na pokładzie nie ma, czyli potrzeba zastosować zewnętrzną pamięć co pociąga dalsze koszty (kilka złotych pamięć + trochę więcej za PCB) i komplikuje układ. Na końcu otrzymamy coś co działa, za cenę gotowego porządnego modułu LCD - no może nie do końca, bo moduły o tych rozmiarach trochę kosztują.


    Nie zapominam, piszę tylko na temat uC, to co jest w tle, czyli kondensatory, rezystory, zewnętrzny SRAM pomijam :) Choć kolega tmf ma rację - trzeba dość sporo pamięci.

    STM32F100RCT6D - 17 zł w farnelu za 1 sztukę, jeśli ma czegoś za mało to możesz szukać innych z 256kb flasha i więcej (takie mają fsmc). Pamięci są różne, od 25zł do prawie 90zł za kość. Można poszukać procesora z kontrolerem DRAM i kupić pamięć trochę taniej, ale to już sam musisz sobie zorganizować poszukiwania.
  • #10
    tmf
    Moderator of Microcontroller designs
    Czas dostępu 55ns jest na granicy. Ponieważ potrzebujesz 24-bitową szyną danych musisz wykorzystać 3 takie pamięci, albo jedną umożliwiającą odczyt 3 bajtów w jednym cyklu, ale wtedy potrzebujesz pamięć o czasie dostępu 10-12ns, a nie 55. Poza tym kwestia czy użyty procesor wspiera taki tryb. Tak więc najpierw wybierz procesor, poczytaj o jego interfejsie pamięci zewnętrznej i pod to wybierz odpowiednią kość pamięci. Swoją drogą robiłeś kiedyś coś takiego? Bo jeśli nie robiłeś do tej pory takich projektów to szansa na powodzenie jest mała.
  • #11
    gaskoin
    Level 38  
    Ciągnięcie magistrali do pamięci nie należy do zbyt przyjemnych rzeczy. Czym więcej ich kolega dołoży tym większa masakra :) STM mają szynę adresową do 26bit i danych do 16bit.
  • #12
    tmf
    Moderator of Microcontroller designs
    gaskoin wrote:
    Ciągnięcie magistrali do pamięci nie należy do zbyt przyjemnych rzeczy. Czym więcej ich kolega dołoży tym większa masakra :) STM mają szynę adresową do 26bit i danych do 16bit.


    Prawdę mówiąc to całkiem koszmarne zajęcie :)
    Czyli może mieć 2 takie kości, 16 bitów odczyta na raz, potrzebuje 24, więc dwa odczyty potrzebne - chyba, żeby zrezygnować z 24-bitowej głębi, 16-bitowa też jest ok jak na prosty LCD. EBI w STM może pracować wolniej niż procesor? Czy się wait staty wrzuca? No i jakaś multipleksacja danych/adresów by się przydała, żeby nie wykorzystać od razu połowy pinów IO.
  • #13
    gaskoin
    Level 38  
    Kości może być więcej, masz przecież jeszcze linie sterujące.

    Może pracować na innej częstotliwości niż procesor. Jest kilka szyn zegarowych do których są podłączone różne peryferia, można im nadać dość swobodnie preskaler. Jednak FSMC pracuje na głównej szynie do której są potem podpięte inne dzielniki, więc zwalniając tę szynę zwolnimy też resztę. Może trochę pokrętnie wyjaśnione, najlepiej wyjaśni to rysunek. Na czerwono jest zaznaczone gdzie jest zegar do FSMC. Zegar ten jest potem jeszcze dzielony (lub nie) dla innych peryferiów.
    [LCD TFT] [AVR/ARM] [C] kilka pytań

    Tak jest w STM, podejrzewam, że u innych producentów niewiele to odbiega. Polecam się przyjrzeć bliżej układom z rdzeniem ARM, ponieważ to co podaję może nie być najlepszym wyborem. Być może inni producenci mają coś ciekawszego do zaoferowania pod kątem obsługi pamięci (wiem, że np NXP ma Cortexy z obsługą SDRAMu).



    I nie znam odpowiedzi na pytanie kolegi czy można pogodzić obsługę LCD z RAMem. Obawiam się, że może to być problemem, ale lepiej się wczytać w notę. LCD obsługuje się właściwie jak pamięć (szyny adresowe + danych) więc do tego celu używa się tego samego peryferium. Ale może ST to jakoś rozwiązało, w końcu peryferia jakie mają w swoich układach są dosyć wypasione pod każdym względem.
  • #14
    tmf
    Moderator of Microcontroller designs
    SDRAM nie polecam, ostatnio się na to naciąłem. Raz, że nie jest szybszy niż SRAM (piszę o tych normalnych taktowanych 133 MHz), ale co gorsze czas dostępu zależy od tego czy przekraczasz stronę pamięci (musisz wysłać komendy precharge) i od nakładających się cykli odświeżania. W dodatku trzeba dobrze przeanalizować kontroler SDRAM procesora, bo można się naciąć - szczególnie jeśli ktoś myśli, że uzyska przepustowość rzędu 1 bajta/takt (czyli teoretyczną dla SDRAM). IMHO przy pojemnościach rzędu 100-500 kB SRAM jest górą, SDRAM jeśli ktoś potrzebuje grube MB pamięci.
  • #15
    User removed account
    User removed account  
  • #16
    gaskoin
    Level 38  
    480*272*16 = 2088960 = 261120 bajtów = 255kB gdzieś ten obraz trzeba trzymać.
    Dla 24 bit koloru będzie to koło 380kB.

    Paczki owszem można trzymać na SD, ale nie wiem jaka będzie prędkość, a kolega chciał zrobić kontroler do matrycy, więc sensowniejsze byłoby wyświetlanie większej ilości obrazów w ciągu sekundy niż 1 :)

    No i drugi minus takiego rozwiązania - trzeba dodać jakieś cuda żeby działać na obrazie. W rozwiązaniu proponowanym, można się do niego odwołać jak do tablicy w języku C.
  • #17
    tmf
    Moderator of Microcontroller designs
    oloam wrote:
    Mam pytanie. Dlaczego uparliscie sie na na bufor obrazu 400kb i podlaczanie dodatkowej pamieci? Przeciez wysylane dane mozna podzielic na paczki (chociazby przy odczytywaniu danych z karty sd - 512bajtow). Ja spokojnie obsluzylem tft 320x240 z szyna 16bit (5r6g5b) na atmedze8 (predkosc byla ok 1 klatka na sekunde) i nie potrzebowalem do tego 150kb (tyle zajmuje pelna ramka) pamieci podrecznej.


    Ano uparliśmy się z powodów o których pisze kolega powyżej, a dodatkowo dlatego, że ten LCD nie ma VRAM, a oczekuje danych o kolejnych pixelach z jakąśtam minimalną prędkością- typowo dla takich LCD jest to pixel clock 7MHz min. Jeśli mu wsuwasz wolniej to mu skracasz żywot - pewnie pochodną zegara pixeli są inne timingi, w tym do sterowania samym kryształem. A że prąd stały mu szkodzi to z odświeżaniem zjechać nie można. Co innego jeśli masz LCD z kontrolerem, który wrzuca dane z własnego VRAM, wtedy sobie możesz robić nawet 1 pixel/s i problemu nie ma, bo kontroler na matrycę wrzuca dane jak należy.
  • #18
    User removed account
    User removed account  
  • #20
    User removed account
    User removed account  
  • #21
    Freddie Chopin
    MCUs specialist
    Do LCD bez sterownika (czyli bez pamięci) dane T-R-Z-E-B-A wrzucać na bieżąco - dla każdej klatki, każdej linii i każdego piksela. Kilkadziesiąt klatek na sekundę, kilkaset linii na klatkę, kilkaset pikseli na linię. One mają iść właśnie tak szybko.

    50 (fps) * 480 (linii) * 272 (pikseli) * 3 (bajty) = 20MBps. Mega-BAJTÓW, a nie bitów.

    Wyciągnij na ARMie tyle z karty SD - powodzenia. Z magistralą czteroprzewodową musiałoby to mieć 40MHz i to oczywiście przy wesołym założeniu, że nic nigdy nie będziesz chciał do tej karty zapisać i że ona się cudownie sama będzie adresować i obsługiwać.

    4\/3!!
  • #22
    User removed account
    User removed account  
  • #23
    Freddie Chopin
    MCUs specialist
    No a ty w kółko swoje. Czy ty w ogóle czytasz co się pisze do Ciebie? Do takiego LCD dane trzeba wrzucać z określoną prędkością, wynoszącą 50 klatek na sekundę - kropka. Jeśli masz problem ze zrozumieniem wymagań sprzętowych, to ja już nic na to nie poradzę.

    Kup sobie ten wyświetlacz i zapodaj na niego 10 klatek na sekundę i napisz nam jak szybko padł.

    4\/3!!
  • #24
    tmf
    Moderator of Microcontroller designs
    oloam wrote:
    tmf wrote:
    oloam wrote:
    Mam pytanie. Dlaczego uparliscie sie na na bufor obrazu 400kb i podlaczanie dodatkowej pamieci? Przeciez wysylane dane mozna podzielic na paczki (chociazby przy odczytywaniu danych z karty sd - 512bajtow). Ja spokojnie obsluzylem tft 320x240 z szyna 16bit (5r6g5b) na atmedze8 (predkosc byla ok 1 klatka na sekunde) i nie potrzebowalem do tego 150kb (tyle zajmuje pelna ramka) pamieci podrecznej.


    Ano uparliśmy się z powodów o których pisze kolega powyżej, a dodatkowo dlatego, że ten LCD nie ma VRAM, a oczekuje danych o kolejnych pixelach z jakąśtam minimalną prędkością- typowo dla takich LCD jest to pixel clock 7MHz min. Jeśli mu wsuwasz wolniej to mu skracasz żywot - pewnie pochodną zegara pixeli są inne timingi, w tym do sterowania samym kryształem. A że prąd stały mu szkodzi to z odświeżaniem zjechać nie można. Co innego jeśli masz LCD z kontrolerem, który wrzuca dane z własnego VRAM, wtedy sobie możesz robić nawet 1 pixel/s i problemu nie ma, bo kontroler na matrycę wrzuca dane jak należy.


    Moze jestem w bledzie ale wg mnie to o czym piszesz w tym kontrolerze pelni uklad TCON - przez niego ida dane zarowno w trybie rownoleglym jak i szeregowym. Co wiecej w trybie szeregowym max predkosc szyny spi wynosi 20Mhz czyli mozna i wolniej, a TCON bierze na siebie reszte.


    Ten jego tryb "szeregowy" to tryb w którym wsuwa 8 bitów (cały bajt) na raz, w przeciwieństiwe do trybu równoległewgo w którym mu zapodajesz na raz 24 bity (3 bajty). Tak jak pisze Freddie Chopin, w tym trybie "szeregowym" przy CLK=20 MHz zapodajesz mu 20 Megabajtów na sekundę. Możesz wolniej, ale tylko ciut wolniej, bo zniszczysz LCD. Ten kontroler ma bufor tylko jednej linii, w efekcie musisz mu np. 50 razy na sekundę wysyłać po kolei 272 linie. Jest to niemałe wyzwanie dla procesora.
  • #25
    User removed account
    User removed account  
  • #26
    tymon_x
    Level 30  
    oloam wrote:
    Gdzie jest napisane w datasheet, ze trzeba wrzucac 50 klatek na sekunde ? Jak to sie ma do magistrali szeregowej, ktorej maksymalna predkosc dla tego kontrolera wynosi 20Mhz (wyciagniesz 50fps?) ? Rozumiem, ze jak ty cos napiszesz ,to tak ma byc i kropka. Co w takim razie z dokumentacja ? Jakis dziwny jestes, odpowiadajac powinienes podac jakies zrodla twojej wiedzy, bo nie jest nim napewno datasheet hx. Dlaczego mialby pasc skoro sterowaniem zajmuje sie TCON kontrolera? Kup mi ten wyswietlacz , jak padnie oddam ci pieniadze.

    I z tego powodu co piszą koledzy wyżej, producent wyświetlacza nie wyprowadził pinów dla transmisji po SPI. Ta dokumentacja jest licha, te wszystkie matryce pochodzą z jednego źródła (Tajwan). I to od nich zależy jak dopracują dokumentację. Widać jej jakość (chamski skan przebiegów i80 ?). Mam ten wyświetlacz, ale od Formik Electronics, jak mnie pamięć nie myli jego DotClock (czy PixelClock) wynosi jakieś 5-12MHz.

    Matryca TFT != Sterownik != Kontroler
  • #27
    tmf
    Moderator of Microcontroller designs
    oloam wrote:
    Freddie Chopin wrote:
    No a ty w kółko swoje. Czy ty w ogóle czytasz co się pisze do Ciebie? Do takiego LCD dane trzeba wrzucać z określoną prędkością, wynoszącą 50 klatek na sekundę - kropka. Jeśli masz problem ze zrozumieniem wymagań sprzętowych, to ja już nic na to nie poradzę.

    Kup sobie ten wyświetlacz i zapodaj na niego 10 klatek na sekundę i napisz nam jak szybko padł.

    4\/3!!


    Gdzie jest napisane w datasheet, ze trzeba wrzucac 50 klatek na sekunde ? Jak to sie ma do magistrali szeregowej, ktorej maksymalna predkosc dla tego kontrolera wynosi 20Mhz (wyciagniesz 50fps?) ? Rozumiem, ze jak ty cos napiszesz ,to tak ma byc i kropka. Co w takim razie z dokumentacja ? Jakis dziwny jestes, odpowiadajac powinienes podac jakies zrodla twojej wiedzy, bo nie jest nim napewno datasheet hx. Dlaczego mialby pasc skoro sterowaniem zajmuje sie TCON kontrolera? Kup mi ten wyswietlacz , jak padnie oddam ci pieniadze.


    A gdzie ty u niego widzisz magistralę szeregową? Już ci pisałem, że tryb szeregowy służy do wrzucania danych po 8 bitów na raz, a nie po 24 bity na raz jak to jest w trybie równoległym. Jego interfejs SPI służy z kolei do realizacji dostępu do rejestrów kontrolnych sterownika matrycy, a nie do wrzucania danych o obrazie.
    Kolejna sprawa - to co ci piszemy wnika z naszego doświadczenia z tego typu matrycami. Ta akurat ma notę badziewną, ściągnij sobie notę do praktycznie identycznego LCD montowanego w Sony PSX i będziesz miał napisane jaki jest minimalny pixelclock.
    I zrozum w końcu, że jak nie ma VRAM to choćbyś się skichał, to LCD obrazu nie wyświetli bo nie ma skąd brać danych o obrazie. Stąd też musisz mu je na bieżąco podsyłać z częstotliwością wynikającą z minimalnego pixelclock. Typowo to jest 7-12 MHz.
  • #28
    User removed account
    User removed account  
  • #30
    tmf
    Moderator of Microcontroller designs
    Ale ty czytasz co się do ciebie pisze? Interfejs SPI tego kontrolera służy dla realizacji dostępu do rejestrów wewnętrznych, a nie do przesyłania danych o obrazie!
    Już 3 raz ci to piszę - mylisz interfejs SPI z trybem "szeregowym" w którym przesyłany jest na raz cały bajt. W tym trybie możesz przesłać do 20 Mbajtów, a nie Mbitów na sekundę danych o obrazie.