Wydajne wyświetlanie prostego tekstu / grafiki na kolorowym wyświetlaczu LCD firmy ARM

12

Projektując urządzenie oparte na architekturze ARM, które powinno wyświetlać prostą grafikę na kolorowym wyświetlaczu LCD, jak najlepiej zająć się projektowaniem, aby umożliwić szybką aktualizację, najlepiej bez powiązania z konkretnym dostawcą ARM lub LCD? Mój obecny projekt wykorzystuje czarno-biały wyświetlacz, który może być błyskawicznie napędzany przez port SPI na PIC (przerysowanie złożonego wyświetlacza w 1/60 sekundy). Wygląda na to, że popularne kolorowe wyświetlacze LCD mają port SPI, ale nawet wypełnienie LCD 160x120 jednolitym kolorem zajęłoby 30 ms, a 320x240 zajęłoby 120 ms w najlepszym przypadku (zegar przesunięcia 10 MHz).

Jeśli można oszczędzić piny kontrolera, tryb równoległy może być lepszy, ale nie znam żadnych niezależnych od rodziny sposobów podłączania interfejsu równoległego bez konieczności posiadania trzech oddzielnych instrukcji przechowywania pamięci dla każdego piksela (jeden do ustawienia danych, jeden, aby ustawić wysoką częstotliwość wyjściową zegara, a drugi niską). Niektóre układy ARM mają interfejsy magistrali pamięci, ale te często chcą robić takie rzeczy, jak multipleksowanie adresu i danych, lub przypisywać wiele pinów do wysyłania nieistotnych bitów adresu (LCD potrzebowałby tylko jednego bitu adresu).

Patrząc na ILI9320 firmy ILITEK lub HD66789 firmy Renesas, jednym z podejść, które wydawałoby się interesujące, byłoby użycie CPLD do konwersji SPI na dane równoległe i włączenie trybu, który generowałby piksel na bit. Patrząc na arkusz danych Renesas, możliwe jest uzyskanie zapisu w pikselach na bit przy minimalnym sprzęcie (nie wymaga CPLD), dzięki czemu wszystkie bity danych portu równoległego śledzą pin danych szeregowych, używając trybu szeregowego do wszystkiego oprócz piksela zapisuje i przy użyciu funkcji porównywania / maskowania, tak aby piksele z zerami były przezroczyste, a piksele z zerami ustawiały wybrane bity w GRAM, lub piksele z zerami były przezroczyste, a piksele z zerami usuwałyby wybrane bity. Sekcja „funkcje” arkusza danych IKITEK sugeruje, że ma podobną funkcjonalność, ale mapy rejestru nie

Zakładając, że kod będzie głównie wyświetlał jednolity tekst i grafikę, idealnym podejściem wydaje się być użycie CPLD do połączenia portu SPI ARM z portem równoległym wyświetlacza i umożliwienia załadowania CPLD z kolorami pierwszego planu / tła. Byłoby to szczególnie miłe, gdyby ktoś miał sposób na pisanie „przezroczystych” pikseli. Biorąc pod uwagę czcionkę jako dwukolorową mapę bitową, można po prostu załadować dane czcionki bezpośrednio do portu SPI; pozwoliłoby to wyświetlać dane czcionek z prędkością jednego piksela co dwa zegary ARM. Z drugiej strony, CPLD wystarczający do obsługi takiego zadania sterowania wyświetlaczem kosztowałby około 2 USD.

Jaki jest najlepszy sposób na połączenie ARM z kolorowym wyświetlaczem LCD, jeśli celem jest przede wszystkim wyświetlanie jednolitego tekstu lub prostej (np. 16-kolorowej lub 64-kolorowej) grafiki?

Edytować

Zrobiłem wiele projektów wyświetlaczy LCD, z wieloma rodzajami wyświetlaczy LCD, w tym wyświetlaczami LCD w trybie znakowym, niestandardowymi segmentami multipleksowymi 3: 1 opartymi na segmentach, stosując własną metodę napędu, czarno-białe graficzne wyświetlacze LCD z wbudowanymi kontrolerami oraz czarno-białe -białe wyświetlacze LCD, dla których zaprojektowałem własny kontroler oparty na CPLD do współpracy z uniwersalnym DMA mikrokontrolera (zapewniającym nawet czteropoziomową skalę szarości). Jestem dumny z tego, że wyświetlacze są spakowane. Jeden z kontrolerów graficznych był trochę psem, który potrzebował około 1/10 sekundy na pełne odświeżenie ekranu nawet podczas zapisywania stałych danych, ale większość moich wyświetlaczy może renderować nawet dość złożony obraz w czasie krótszym niż 1/50 sekundy.

Wiele projektów, które wykonuję, są zasilane bateryjnie, więc aktualny pobór jest problemem. Kontroler wyświetlania oparty na DMA działał dobrze, ale był to projekt zasilany liniowo. Uważam, że jedynym sposobem na uzyskanie rozsądnego poboru prądu z graficznego wyświetlacza LCD jest użycie kontrolera, który łączy bufor wyświetlacza i sterowniki kolumn. Wysyłanie dużej ilości wyświetlania między układami w każdej klatce zmarnowałoby dużo energii, nawet na pojedynczym wyświetlaczu bit-na-piksel; na kolorowym wyświetlaczu z szesnastoma bitami na piksel byłoby znacznie gorzej.

Zacząłem tylko patrzeć na kolorowe arkusze danych LCD; wiele wyświetlaczy wydaje się używać kontrolera podobnego do ILITEK ILI9320, chociaż wszystkie arkusze danych, które znalazłem dla kontrolerów opartych na tym ogólnym projekcie, zostały oznaczone jako „wstępne”. Niektórzy jak ILITEK jeden twierdzą, że mają funkcje maskowania i przejrzystości, ale nie wymieniają żadnych rejestrów; Nie wiem, czy prawdziwe układy mają takie funkcje, ale „wstępne” arkusze danych nie uwzględniły ich, czy też pominęły te funkcje, ale zapomniały o nich wspomnieć. Jeżeli w praktyce wszystkie takie układy mają funkcje przezroczystości, rozsądne wydaje się ich zaprojektowanie; jeśli nie, nie.

Spodziewałbym się, że w przypadku większości projektów typowy ekran składałby się z arbitralnie umieszczanego tekstu w umiarkowanej liczbie czcionek jednokolorowych o dowolnym rozmiarze. Czcionki najprawdopodobniej byłyby przechowywane jako dane bit-per-pixel. Używając Cortex-M3, gdybym chciał napisać ekran z danymi równoległymi, „wewnętrzna pętla” kodu do zapisu dwóch pikseli prawdopodobnie skończyłaby się tak:

  rol r0, r0, # 2; Zdobądź jeden bit w C, drugi w N
  itcs
  strhcs r1, [r3, # DATA_OFS]; Napisz dane
  strhcc r2, [r3, # DATA_OFS]; Napisz dane
  strb r4, [r3, # CLOCK_SET_OFS]; Ustaw wysoki zegar
  strb r4, [r3, # CLOCK_CLR_OFS]; Ustaw niski czas
  itmi
  strhmi r1, [r3, # DATA_OFS]; Napisz dane
  strhpl r2, [r3, # DATA_OFS]; Napisz dane
  strb r4, [r3, # CLOCK_SET_OFS]; Ustaw wysoki zegar
  strb r4, [r3, # CLOCK_CLR_OFS]; Ustaw niski czas

Niezupełnie najszybsza rzecz na świecie. Pomocne byłoby wyeliminowanie zapisów do instrukcji ustawiania / czyszczenia zegara. Domyślam się, że nie ma dobrego niezależnego od architektury sposobu na wyeliminowanie obu zapisów zegara, ale może istnieć dość powszechny sposób, który pozwoliłby na wyeliminowanie jednego (np. Wiele układów może mieć licznik / PWM, który można by impulsować wyjściem krótko w odpowiedzi na operację pojedynczego magazynu pamięci).

Korzystanie z portu SPI i dodawanie sprzętu do taktowania o jeden piksel na bit znacznie przyspieszy dostęp do wyświetlania. Jeśli używasz wyświetlacza bez maskowania i przezroczystości, CPLD musiałby zawierać licznik adresów, a dla każdego piksela albo taktować słowo danych piksela, albo też polecenie ustawiania adresu dla pozycji następnego piksela (dla którego potrzebowałby licznika ). Z drugiej strony, jeśli ekran miałby maskowanie i przezroczystość, wszystko, co musiałbym zrobić, to mieć tryb CPLD obsługujący tryb, w którym po taktowaniu w 16 bitach, każdy dodatkowy bit taktowałby słowo danych na wyświetlaczu za pomocą LSB śledzące pin SDI (może nie być nawet konieczne użycie CPLD - tylko kilka normalnych układów logicznych). Ustawiłbym kolor przezroczystości na kolor, który chcę napisać, ale z odwróconym LSB.

Nie chcę wymyślać pięknego projektu, który opiera się na maskowaniu i przejrzystości, a potem odkrywam, że jedyne wyświetlacze z takimi funkcjami mają 30-tygodniowy czas realizacji. Z drugiej strony, jeśli takie wyświetlacze są i są powszechnie dostępne od wielu dostawców, nie chcę, aby paranoja związana z dostępnością skłoniła mnie do zastosowania gorszego projektu.

supercat
źródło
1
Brak odpowiedzi, ponieważ twoje wymagania obejmują niepowiązanie z konkretnym dostawcą ARM, ale rodzina mikrokontrolerów LPC LH754xx zawiera zintegrowany sterownik LCD.
Kevin Vermeer
@reemrevnivek: Istnieje wiele układów ARM z małymi sterownikami LCD; Nie wyobrażam sobie, aby jakikolwiek układ posiadający sterownik odpowiedni do wyświetlaczy graficznych o użytecznym rozmiarze pojawił się w pakiecie, który byłby użyteczny w czymkolwiek innym niż scenariusz „układ na szkle”. Układ może mieć kontroler, ale wyświetlacz LCD z kontrolerem typu chip-on-glass wydaje się bardziej energooszczędny i łatwiejszy w obsłudze. Sprawdzę jednak chip, o którym wspomniałeś - może być interesujący.
supercat
@ supercat - Mam na myśli wyświetlacze LCD z interfejsem RGB: zegar pikseli, synchronizacja klatek i linie kontrolne synchronizacji linii z równoległą pikselową magistralą danych. Czy spodziewasz się używać wyświetlacza sterowanego COG?
Kevin Vermeer
1
@reemrevnivek: Tak myślałem. Wydają się być dość powszechne, ponieważ są używane w wielu przenośnych urządzeniach zasilanych bateryjnie, takich jak telefony komórkowe. Wyświetlacz COG z wbudowanym kontrolerem będzie znacznie bardziej energooszczędny niż ten, który wymaga ciągłego taktowania danych RGB.
supercat
@reemrevnivek: Właśnie zaktualizowałem swoje pytanie bardziej szczegółowo.
supercat

Odpowiedzi:

7

Problem z użyciem mikrokontrolera do sterowania wyświetlaczem LCD polega na tym, że wyświetlacz LCD wymaga stałej uwagi. Można to złagodzić za pomocą CPLD sterowanego przez SPI (oczywiście przy użyciu DMA), ale wtedy napotykasz inny problem: kolorowe wyświetlacze LCD wymagają dużodanych. 320x240 w czerni i bieli ma margines 9,6 KB, ale przy 24-bitowym kolorze i nagle musisz dostarczyć 230 KB danych w 1/60 sekundy. (Nie zapominaj jednak, że możesz uzyskać 4-bitowe, 16-kolorowe sterowanie po prostu przez powiązanie niskich 20 bitów z jednym ustawieniem). 24-bitowy bufor ramki nie mieści się już we wbudowanej pamięci RAM większości mikrokontrolerów i prawdopodobnie nie masz czasu na odczyt z zewnętrznego układu pamięci RAM, wyrejestrowanie danych i wykonywanie innych operacji. Próba zrobienia tego z CPLD (lub FPGA) i układem pamięci RAM znacznie przewyższa cenę 2 USD, która spowodowała, że ​​zadawałeś sobie pytania.

Tradycyjnym rozwiązaniem łączenia mikrokontrolera z kolorowym wyświetlaczem LCD jest kontroler wyświetlacza, taki jak SSD1963. Oto bardzo prosty schemat blokowy:

MCU do pamięci RAM i rejestrów, a następnie do interfejsu LCD

Równoległe wejście do dużego bufora ramki RAM (Tłumaczenie: Ponad 2 $) połączone z konfigurowalnym rejestrem równoległym interfejsem LCD. Wejście równoległe jest zwykle kompatybilne z interfejsem magistrali pamięci.

Rynek kolorowych ekranów LCD nie zawsze jest łatwy do znalezienia w Internecie, zwykle będąc domeną producentów OEM, a reszta kupuje wyświetlacze od firm, które integrują kontroler z wyświetlaczem. Najlepszym zasobem, jaki znalazłem, jest Crystal Fontz, a konkretnie ta strona na temat wyboru graficznych wyświetlaczy LCD . Przewiń w dół do kontrolerów, które zawierają następujące opcje (uwaga: nie wszystkie są kontrolerami kolorów):

  • Epson S1D13521B01 E Atrament Arkusz (1 moduł)
  • Epson S1D13700 (11 modułów)
  • Kompatybilny z Epson SED1520 (8 modułów)
  • Kompatybilny z Himax HX8345 (1 moduł)
  • Kompatybilny z ILITek ILI9325 (3 moduły)
  • Kompatybilny z KS0107 / KS0108 (26 modułów)
  • Novatek NT7534 (14 modułów)
  • Orise Technology OTM2201A (1 moduł)
  • Orise Technology SPFD5420A (1 moduł)
  • RAiO RA8835 (1 moduł)
  • Sanyo LC7981 (13 modułów)
  • Sino Wealth SH1101A (2 moduły)
  • Sitronix ST7920 (29 modułów)
  • Solomon SSD1303 (1 moduł)
  • Solomon SSD1305 (9 modułów)
  • Solomon SSD1325 (2 moduły)
  • Solomon SSD1332 (1 moduł)
  • Solomon SSD2119 (2 moduły)
  • ST STV8105 (1 moduł)
  • Toshiba T6963 (23 moduły)
Kevin Vermeer
źródło
@reemrevnivek: Myślałem o kolorowych wyświetlaczach LCD z wbudowanymi kontrolerami. Wydają się dość powszechne, ale te, które widziałem, ogólnie oczekują, że procesor będzie taktował się wieloma bitami na piksel, mimo że częstym scenariuszem wyświetlania jest wyświetlanie jednolitego tekstu. Kiedyś za pomocą CPLD zaimplementowałem 4-poziomowy kontroler LCD w skali szarości oparty na DMA i działał bardzo dobrze, ale było to urządzenie zasilane liniowo.
supercat
1
@ supercat - Bardzo niewiele kontrolerów LCD oczekuje od procesora taktowania wielu bitów na piksel w każdej ramce. Na ogół oczekują, że zrobi to dedykowany sprzęt graficzny . Zasadniczo, kiedy dojdziesz do dość dużych (tj.> 128 * 128) wyświetlaczy RGB, moc obliczeniowa wymagana do wygenerowania obrazu dla ekranu jest wystarczająco duża, aby dedykowany procesor graficzny (nawet jeśli jest zintegrowany z MCU) prawie zawsze obecny.
Connor Wolf,
1
@supercat - Ale to, co opisujesz, wyspecjalizowany CPLD, który wykonuje ASCII do konwersji rastrowych, jest w zasadzie (niestandardowym) specjalistycznym sprzętem graficznym . Mówię w zasadzie, nie wymyślaj od nowa koła, i prawdopodobnie łatwiej i bardziej opłacalnie jest kupić MCU z wbudowanym interfejsem wideo, a następnie sam go zaprojektować.
Connor Wolf,
1
W każdym razie, jeśli naprawdę chcesz zbudować własny, powiedziałbym, że użyj dwóch dwuportowych układów SRAM i użyj jednego portu do wysyłania sygnału do wyświetlacza LCD, a drugiego do MCU. Pozwala to MCU zmieniać zawartość pamięci z dowolną żądaną prędkością, a wyświetlacz LCD może działać z częstotliwością odświeżania.
Connor Wolf,
1
@ Fałszywa nazwa: konwersja rastra nie byłaby ASCII. Zasadniczo byłaby to konwersja bit-na-piksel na multibit-na-piksel. Myślę, że nie rozumiesz, na co patrzę. Nie szukam wyświetlaczy, które mają tylko sterowniki , ale takie, które zawierają sterowniki i kontrolery , więc muszą być podawane dane tylko wtedy, gdy zmieniają się rzeczy na ekranie.
supercat