Jak szybciej komunikować się z LCD-TFT? cz. 1

Witajcie,
Zapewne większość z was używała w swoich projektach LCD-TFT lub zamierza ich użyć. I pewnie każdy, kto użył takie LCD początkowo walczył z problemami podobnymi do opisanych w poniższym poradniku. Jak napisać program, żeby LCD szybciej tworzył obraz? Dlaczego tak wolno to działa? Jak to zrobić lepiej? Mam nadzieję, że poniższy mini-poradnik odpowie na część tych pytań i pozwoli osobom początkującym uniknąć typowych błędów. W dalszej części, planuję opisać nieco bardziej zaawansowane metody przyśpieszenia transmisji danych i tworzenia dynamiczniejszej grafiki.
Zapraszam do oglądania:

No i oczywiście do komentowania. Jakie Wy napotkaliście problemy? Co warto omówić i pokazać?
Dajcie znać.
Do tej pory opublikowane części:
część 1. Komunikacja z kontrolerem TFT po SPI
część 2. Komunikacja w trybie 16-bitowym po SPI
część 3. Jeszcze o różnych implementacjach SPI
część 4. Interfejs równoległy
część 5. Nietypowe funkcje kontrolerów
część 6. Kontroler z akceleracją RA8875 - wstęp
część 7. Kontroler z akceleracją RA8875 – funkcje podstawowe
część 8. Kontroler z akceleracją RA8875 – funkcje zaawansowane
część 9. Overclocking kontrolera matrycy LCD-TFT – RA8875

Zdaje się że pomyliłeś bitowość koloru z bitami interfejsu.
Interfejs (równoległy) 8/16/18, kolory 12/16/18 bit.
Nie kojarzę 8b koloru w popularnych LCD.

Stare AVRy SBI/CBI nie miały?

@piotrgo 8-bitową głębię koloru ma m.in. RA8875.

Trochę nie ta kategoria i dostępność. Fonty, akceleracja 2D, ADC, klawiatura,...
Indeksowany kolor (1b/4b/8b) by się przydał w tych tańszych wyświetlaczach.

A co z softwarowym spi w starych avr (to co dodałem)?

piotr_go wrote:

Trochę nie ta kategoria. Fonty, akceleracja 2D, ADC, klawiatura,...
Indeksowany kolor (1b/4b/8b) by się przydał w tych tańszych wyświetlaczach.

RA jest tani, ale zwykle jest łączony z lepszymi matrycami TFT i finalnie jest trochę droższy. Ale i tak warto - wyższa rozdzielczość, często dostępne w wersji z pojemnościowym touch panelem, no i dodatki o których wspomniałeś, a o których będzie w kolejnych częściach.

piotr_go wrote:

A co z softwarowym spi w starych avr (to co dodałem)?

Trzeba uważać, bo na niektórych AVR niektóre porty są poza zasięgiem SBI/CBI. Druga sprawa - tu akurat chodziło tylko o zilustrowanie problemu, jak wspominałem kod można napisać optymalniej, ale CBI/SBI modyfikują na raz tylko jeden bit. Rejestry SET/CLR/TGL umożliwiają modyfikację 0-8 bitów na raz, co umożliwia optymalizację, jeśli np. SCK/MOSI/CS są na jednym porcie.
Niemniej nawet jeśli się optymalnie napisze soft-SPI, to i tak będzie wolniejszy, dużo wolniejszy, w stosunku do hardware-SPI - przy hardware SPI zyskujemy za darmo co najmniej 16 taktów na obliczenia.

Wszystko ma wady i zalety. Nauka optymalnego pisania kodu na wolniejszych MCU daje pewne doświadczenie jak przyśpieszyć kod na bardziej potężnych układach (z racji skali, więcej ograniczeń widać na słabszych układach).
Parę lat temu pierwszy silnik 3D napisałem na ATMEGA16(8) z wyświetlaczem 220x180px 8bit po sprzętowym SPI bez buforowania ramki w pamięci:


Później spróbowałem przenieść to samo na STM32F4 z obniżonym zegarem, ale komunikacja nadal po SPI bez buforowania (grafika w rogu to obliczany fraktal):


Ostatni jaki zrobiłem to STM32F3 z komunikacją równoległą do wyświetlacza 800x480px 16bit (interfejs równoległy sprzętowy MCU):


W ostatnim przykładzie także brakuje buforowania w pamięci RAM co drastycznie obniżyło możliwości. Obraz musi byś rysowany bezpośrednio na ekranie, co w niektórych przypadkach skutkuje przeplotami, migotaniem czy drastycznym spadkiem klatek.
Wąskim gardłem tutaj jest szyna komunikacyjna MCU<->sterownik LCD.
Biblioteki graficzne pisane samodzielnie, zoptymalizowane pod MCU.

Moim zdaniem, próba optymalizacji kodu na słabszych MCU daje pewne doświadczenie jak optymalniej pisać kody.
Teraz oczywiście zastosował bym np. NXP i.MX RT czy STM32H7 + szyba zewnętrzna pamięć RAM, ale doświadczenie jest bezcenne.

Podoba mi się pokazany proces optymalizacji, takie podejście nie tylko przyda się przy LCD ale innych peryferiach i innych magistralach.

Co chciałbym jeszcze zobaczyć?

1. DMA.

2. Porównanie z interfejsem równoległym.

3. Porównanie różnych trybów kolorów.

4. Wpływ komunikacji z LCD (częstości odświeżania obrazu) na pobór mocy (czy ma to w ogóle jakiś wpływ czy i tak wszystko zjada podświetlanie)

5. Sztuczki LCD (być może coś pomyliłem ale kojarzę komendy scrolowania a może też skalowania, które mogą odciążyć CPU a LCD przyjmując komendy modyfikuje wyświetlany obraz)

6. Jako eksperyment i ciekawostkę sprawdzenie o ile można "podkręcić" komunikację z LCD względem specyfikacji bez pojawienia się błędów komunikacji.

TechEkspert wrote:

2. Porównanie z interfejsem równoległym.

Uzyskanie 60FPS nie jest problemem. Może się pojawić natomiast inny - "tearing", gdy wyświetlacz jest odświeżany w innym kierunku niż wysyłka danych. Można to co prawda zsynchronizować, ale w przypadku poniżej wymagało by to wymiany LCD.
Tearing ukośny (widoczny przez kilka sekund od 1:00):

@adimistrzu Kiedyś oglądałem twoje filmiki i nie powiem, zainspierowały mnie do podjęcia tematu TFT.
@techekspert To chciałbym pokazać w kolejnych odcinkach. Co do podkręcania - nie jestem fanem, ale oczywiście jeśli chodzi o aspekt edukacyjny to dlaczego nie. Nie wgryzałem się dokładnie w wewnętrzną budowę sterowników, ale z opisów wynika, że częstotliwość taktowania magistral jest pochodną częstotliwości wewnętrznego oscylatora lub Dot Clock. Także pewną możliwością podkręcenia transmisji jest przeprogramowanie sterownika tak, aby odświeżał matrycę LCD z większą szybkością (tu limitem są też parametry matrycy).
Dla przykładu bawiłem się w podkręcanie rzeczonego RA8875 - jest to wygodne bo ma programowalne PLL i dzielniki, więc można łatwo poszaleć. Nominalnie ten chip potrzebuje taktowania 60 MHz, bez zająknięcia przechodził 100 MHz (chyba nawet ponad 120 MHz, muszę odszukać notatki). Więc jakieś pole manewru jest. Niemniej unikałbym takiej zabawy w finalnym układzie, lepiej zmienić interfejs na równoległy - o tym też w kolejnych odsłonach wspomnę. No i przede wszystkim lepie poprawnie napisać kod, bo tu zyski potrafią być naprawdę ogromne.

Microchip miał jakiś myk na wykorzystanie PWM, ale to się tyczyły ekranów Vsync/Hsync

Swoją drogą, megaherce na magistrali to limit, który szybko przestaje mieć znaczenie- wystarczy wyświetlić coś bardziej skomplikowanego. Nic z tego że obraz rysuje się w ułamku sekundy, skoro jego wyliczenia trwa na tyle długo że widać już laga. 8 bitów i brak RAM poszaleć nie pozwala. 3D ADI'ego i tak nieźle wygląda, przy okazjimógł byś coś napisać jak "czyściłeś" ekran pod nową klatkę, bo raczej całego ekranu nie rysowałeś?

@figamiga w ostatniej wersji działa to tak:
Obiekt jest odczytywany z pamięci uSD (format STL) i jest przepisywany do struktury w nieco łatwiejszy do obróbki format (struktura w każdej pozycji ma informacje na temat 3 wierzchołków poligonu oraz ich lokalizacji XYZ). Dalej poszukiwane są najdalej wysunięte wierzchołki dla X, Y i Z i w ten sposób znamy objętość obiektu i jego wymiary, pomaga to w późniejszym skalowaniu obiektu aby mieścił się na ekranie.
Kolejne kroki to już matematyka związana z perspektywą, macierz obrotu itd.

Jeśli chodzi o czyszczenie, to znamy rozmiar obecnego narysowanego obiektu (czyli najdalsze wierzchołki) więc wiemy jaki prostokątny obiekt narysować aby wyczyścić tylko taki kawałek jaki nas interesuje do przerysowania.
Ale najpierw są robione wszystkie obliczenia związane z obrotem a na sam koniec dokonywane rysowanie prostokąta w celu wyczyszczenia ekranu a następnie od razu rysowanie nowego obiektu. Skraca to czas pomiędzy wyczyszczonym obrazem a nowym obiektem, więc wydaje nam się że trwa to krócej. (na ekranie czas jaki jest wyświetlony obiekt to czas obróbek matematycznych)
Samo rysowanie trwa najdłużej, ponieważ np. przy linii po skosie 80% transferu na linii danych to adresacja pixel'a, Lepiej było by buforować obraz w pamięci RAM a następnie przesłać go w postaci strumienia danych rysowania prostokąta do wyświetlacza, ale niestety nie miałem tyle miejsca.
Dlatego pojawia się to migotanie.

Kiedyś napisałem pracę na ten temat, mogę poszukać jej gdzieś i wkleić fragmenty które mogą być interesujące.

figa_miga wrote:

Swoją drogą, megaherce na magistrali to limit, który szybko przestaje mieć znaczenie- wystarczy wyświetlić coś bardziej skomplikowanego. Nic z tego że obraz rysuje się w ułamku sekundy, skoro jego wyliczenia trwa na tyle długo że widać już laga. 8 bitów i brak RAM poszaleć nie pozwala.

To prawda, ale nie to jest celem tej części. Można odwrócić sytuację - na nic dużo RAM i mocy obliczeniowej, jeśli implementacja transferu będzie do kitu. O tym jest właśnie ta część poradnika.

ADI-mistrzu wrote:

Ale najpierw są robione wszystkie obliczenia związane z obrotem a na sam koniec dokonywane rysowanie prostokąta w celu wyczyszczenia ekranu a następnie od razu rysowanie nowego obiektu.

Tu widzę możliwość optymalizacji polegającej na ponownym wyświetleniu obiektu, tym razem w kolorze tła. Biorąc pod uwagę, że liczba zmienianych pikseli jest niewielka, może się to opłacać. Chyba, że... mamy np. DMA i kasowanie ekranu robimy równolegle do obliczeń i tworzenia nowego obrazu. Chyba, że... możemy sobie pozwolić na przeplatanie tych operacji.

ADI-mistrzu wrote:

Samo rysowanie trwa najdłużej, ponieważ np. przy linii po skosie 80% transferu na linii danych to adresacja pixel'a,

I to jest niestety sedno problemu w tym przypadku. Optycznie sytuację mogłoby poprawić podwójne buforowanie, ale niestety większość kontrolerów nie ma na to wystarczająco pamięci.
Czyli dramatycznie sytuację poprawiłoby tworzenie całego obrazu w RAM MCU, a potem kopiowanie do kontrolera LCD całego bloku. Ale to wymaga o wiele większego procka, a jeśli już za takowy sie bierzemy, to lepiej zrobić kolejny mały krok i użyć MCU, który ma możliwość bezpośredniego sterowania matrycy TFT.
Konkluzja z tego taka - przed rozpoczęciem projektu zawsze warto poświęcić trochę czasu na przemyślenia i identyfikację potencjalnych problemów. Bo może się okazać, że początkowe założenia uniemożliwiają realizację projektu. Przekonanie się o tym, kiedy mamy już zaawansowany prototyp jest raczej bolesne.

@tmf próbowałem
Rysowanie obiektu w kolorze tła zajmuje więcej czasu, ze względu na ciągłą adresację (więcej danych jest zawierających adres niż dane). to Działa tylko w niektórych sytuacjach.
Odnośnie DMA, zadziała jeśli mamy gotowy obraz w pamięci RAM, jeśli musimy go rysować na wyświetlaczu to niema jak tego zrobić. Obliczamy np. linię i musimy ją rysować po skonie na wyświetlaczu, co oznacza że praktycznie każdy piksel musi być oddzielnie adresowany, a to DMA nie zrobi (z tego co wiem).

W wolnej chwili może napiszę tutaj jakiś krótki opis mojego "projektu" silnika 3D czy w jaki sposób opracowałem menu, może komuś się przyda.
Generalnie projekt powstawał bardzo od zera, czyli założyłem że nie będę korzystał z żadnej wiedzy elementarnej czy sprawdzał jak się to robi, chciałem sam dojść do tego, jak wygenerować obraz 3D (czyli perspektywa, głębia, obrót figur itd.), dzięki temu wiem na czym to się dokładnie opiera i dlaczego działa tak a nie inaczej.

No to napisz, chętnie poczytam, oczywiście z przykładami

ADI-mistrzu wrote:

Odnośnie DMA, zadziała jeśli mamy gotowy obraz w pamięci RAM, jeśli musimy go rysować na wyświetlaczu to niema jak tego zrobić. Obliczamy np. linię i musimy ją rysować po skonie na wyświetlaczu, co oznacza że praktycznie każdy piksel musi być oddzielnie adresowany, a to DMA nie zrobi (z tego co wiem).

Myślałem raczej o takiej sytuacji, że przez DMA przesyłasz blok kasujący obraz, a w trakcie transferu DMA robisz obliczenia dla kolejnej ramki. Jak je skończysz to akurat masz gotowe dane do wyświetlenia. I też można je spróbować wysłąć na raz za pomocą DMA. Chociaż ze względu na preplatanie komend i danych nie będzie to proste. W każdym razie ciekawy temat (i efektowny).

tmf wrote:

yślałem raczej o takiej sytuacji, że przez DMA przesyłasz blok kasujący obraz, a w trakcie transferu DMA robisz obliczenia dla kolejnej ramki.

Ramka nie koniecznie musi być duża może to być np linia pozioma lub pionowa. Wtedy najperw rysujesz tę linię w pamięci, następnie odpalasz DMA, a wym czasie rysujesz w drugim buforze kolejną linie pionową itd itd. Nie ma migotania i da się zrobić nawet na niewielkim procku. Jedynie minimalnie bardziej złożoe rysowanie bo rysujesz tylko na jednej linii - ale to jest dość trywialne do realizacji.

zupabiskupa wrote:

Wtedy najperw rysujesz tę linię w pamięci, następnie odpalasz DMA, a wym czasie rysujesz w drugim buforze kolejną linie pionową itd itd. Nie ma migotania i da się zrobić nawet na niewielkim procku.

Jest tylko mały problem - większość, a właściwie wszystkie popularne kontrolery TFT nie ma wystarczającej ilości pamięci aby zrobić double buffering, w efekcie musisz rysować na aktywnej części VRAM, co wiąże się niestety z paskudnymi efektami wizualnymi. Sytuację może nieco poprawić obecność sygnału TE (lub bitu TE w rejestrach kontrolera), ale też tylko wtedy jeśli czas kreślenia obrazu nie przekracza zbytnio czasu tworzenia ramki.