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.
