Sterowanie wyświetlaczem TFT - część 1

[Elvis 1416]

Wyświetlacze stosowane w urządzeniach elektronicznych przeszły ogromną ewolucję. Można ją łatwo prześledzić chociażby na przykładzie telefonów komórkowych. Pierwsze modele miały monochromatyczne, często tekstowe wyświetlacze. W latach 90. ubiegłego wieku popularne były już wyświetlacze graficzne (oraz gra w węża). W kolejnych latach wyświetlacze monochromatyczne zostały prawie zupełnie wyparte przez modele z kolorową, aktywną matrycą, czyli popularne TFT.

Spis treści:

• Sterowanie wyświetlaczem TFT - część 1 - wstęp, podstawowe informacje
• Sterowanie wyświetlaczem TFT - część 2 - analiza problemu
• Sterowanie wyświetlaczem TFT - część 3 - testy prędkości na STM32
• Sterowanie wyświetlaczem TFT - część 4 - własny program
• Sterowanie wyświetlaczem TFT - część 5 - optymalizacja programu

W przypadku urządzeń wbudowanych, wiele nowości dociera ze znacznym opóźnieniem. Podczas kursu Arduino wykorzystany został alfanumeryczny wyświetlacz 2x16 znaków, kursy STM32 F1 oraz STM32 F4 wykorzystywały graficzne, ale nadal monochromatyczne wyświetlacze (chociaż F4 o wiele nowocześniejszy OLED). Celem niniejszego artykułu jest pokazanie jak można we własnym projekcie wykorzystać kolorowy wyświetlacz TFT. Będzie to okazja do pokazania zarówno wad, jaki i zalet tego typu wyświetlaczy oraz podstawowych technik optymalizacji.

Ten wpis brał udział konkursie na najlepszy artykuł o elektronice lub programowaniu. Sprawdź wyniki oraz listę wszystkich prac »
Partnerem tej edycji konkursu (marzec 2020) był popularny producent obwodów drukowanych, firma PCBWay.

Wybór wyświetlacza

Jednym z dość istotnych powodów powolnego wzrostu zainteresowania wyświetlaczami TFT była ich dość wysoka cena (w szczególności w porównaniu ze starszymi modelami monochromatycznymi). Obecnie ceny wyświetlaczy TFT bardzo spadły i model o niewielkiej przekątnej można kupić za podobną cenę do starszych urządzeń.

Jako przykład użyję wyświetlacza o przekątnej 1.8 cala i rozdzielczości 160 na 128 pikseli firmy WaveShare. Dokumentację wyświetlacza, użytego sterownika oraz przykładowe programy znajdziemy na stronie producenta: https://www.waveshare.com/wiki/1.8inch_LCD_Module

Również z tej strony pochodzi zdjęcie modułu wyświetlacza:

Jak widzimy na zdjęciu jest to kompletny moduł. Na stronie producenta znajdziemy zarówno instrukcję obsługi, jak i schemat, jednak jest on tak prosty, że raczej niezbyt interesujący. To na co powinniśmy zwrócić uwagę to opis wyprowadzeń:

Kolejny ważny parametr to model kontrolera, czyli ST7735S oraz jego dokumentacja. Wszystkie wspomniane dokumenty warto oczywiście przeczytać. Ale jeśli nie mamy akurat czasu na czytanie nieco ponad 200 stron, powinniśmy chociaż pamiętać gdzie szukać informacji.

Podłączenie wyświetlacza

Czas wybrać mikrokontroler i podłączyć do niego wyświetlacz. Przykłady dostarczone przez WaveShare są przeznaczone dla Arduino UNO, STM32F103, Raspberry Pi oraz Jetson Nano. Sensowność podłączania tak małego wyświetlacza do potężnego komputera jakim jest Raspberry Pi (o Jetson Nano nawet nie wspominając) jest mocno dyskusyjna więc ograniczę się do Arduino oraz STM32.

Na początek Arduino UNO, bo to chyba najlepiej znana wszystkim platforma. Oczywiście wiele osób pewnie stwierdzi, że układ atmega328 jest o wiele za słaby na sterowanie kolorowych wyświetlaczem, ale skoro producent dostarczył gotowe przykłady warto chociaż spróbować.

Sam interfejs jest opisywany jako SPI, ale szybkie spojrzenie na listę wyprowadzeń może nieco zaskoczyć. Po pierwsze używane są nieco inne nazwy, po drugie komunikacja jest jednokierunkowa (można tylko wysyłać dane do wyświetlacza), a po trzecie wreszcie jest sporo linii, które nie są obecne w standardowym interfejsie SPI.

Musimy również zadbać o zasilanie układu z napięcia 3.3V oraz konwersję napięć sterujących - Arduino UNO używa sygnałów o napięciu 5V, co może uszkodzić wyświetlacz TFT. Do podłączenia użyłem modułu opartego o układ 74LVC245, można to zrobić taniej, lepiej itd. ale akurat miałem taki moduł pod ręką.

Krótki opis wyprowadzeń wyświetlacza:

• 3V3, GND - zasilanie
• DIN - linia danych, podłączamy do MOSI interfejsu SPI
• CLK - zegar interfejsu SPI
• CS - odpowiada linii CS interfejsu SPI
• DC - informuje o rodzaju przesyłanych danych, stan niski oznacza komendę sterującą, a wysoki dane
• RST - stan niski resetuje sterownik wyświetlacza
• BL - sterowanie podświetlaniem

Podłączenie do Arduino UNO jest dość proste, linie interfejsu SPI, czyli DIN i CLK należy podłączyć do pinów zapewniających dostęp do sprzętowego modułu SPI, pozostałe linie są sterowane programowo (chociaż BL można podłączyć do wyjścia PWM, aby uzyskać sterowanie jasnością podświetlenia).

W programie przykładowym użyte wyprowadzenia są zdefiniowane w pliku o nazwie DEV_config.h, powinniśmy więc ustawić je odpowiednio do wybranego sposobu podłączenia. U mnie ten kod wygląda następująco:

//GPIO config
//LCD
#define LCD_CS 7
#define LCD_CS_0		digitalWrite(LCD_CS, LOW)
#define LCD_CS_1		digitalWrite(LCD_CS, HIGH)

#define LCD_RST 5
#define LCD_RST_0		digitalWrite(LCD_RST, LOW)
#define LCD_RST_1		digitalWrite(LCD_RST, HIGH)

#define LCD_DC 6
#define LCD_DC_0		digitalWrite(LCD_DC, LOW)
#define LCD_DC_1		digitalWrite(LCD_DC, HIGH)

#define LCD_BL 4
#define LCD_BL_0    digitalWrite(LCD_DC, LOW)
#define LCD_BL_1    digitalWrite(LCD_DC, HIGH)

#define SPI_Write_Byte(__DATA)   SPI.transfer(__DATA)

Pierwsze uruchomienie

Czas skompilować i uruchomić program przykładowy. Po drobnych poprawkach oraz ustawieniu wybranych pinów powinno udać się program skompilować. Warto zwrócić uwagę na ilość użytej pamięci:

Jak widzimy wykorzystane zostało raptem 9348 bajtów pamięci Flash (28%) oraz 453 bajtów pamięci RAM (22%). To bardzo mało i jak później się przekonamy to jeden z powodów "niedoskonałości" tego rozwiązania.

Ale na razie czas zaprogramować Arduino i podłączyć zasilanie:

 

Dobra wiadomość jest taka że działa - i to w wysokiej rozdzielczości (160x128) oraz w kolorze... Zła jest taka, że może "niezbyt szybko" działa.

Zanim stwierdzimy, że wyświetlacz do niczego się nie nadaje, warto nieco dokładniej przyjrzeć się przyczynom takich, a nie innych osiągów. Dzięki temu może uda się działanie programu nieco poprawić.

Czas rysowania zawartości ekranu

Pomiary "na oko" to niezbyt doskonała metoda, nieco lepiej dodać wywołanie millis() przed rozpoczęciem i po zakończeniu rysowania ekranu. Różnica między zwróconymi czasami pozwoli nam oszacować jak szybko (albo wolno) działa pierwszy program. Przy okazji możemy jeszcze sprawdzić ile zajmuje skasowanie zawartości ekranu.

Nowy program w pętli rysuje i kasuje zawartość ekranu:

 

Wyniki pomiarów to ok. 1240 ms dla rysowania oraz 96 ms dla kasowania zawartości. "Not great, not terrible" chciałoby się powiedzieć...

Prosta animacja

Wyświetlanie ekranu demonstracyjnego jest oczywiście interesujące, ale może warto sprawdzić jak ekran zachowa się w nieco bardziej pasjonującym zastosowaniu. Zacznijmy od odbijającej się piłeczki, taki wstęp do napisania gry w "ponga".

Pierwsze podejście jest mocno uproszczone - w pętli głównej kasujemy zawartość ekranu, obliczamy pozycję piłki i rysujemy:

 

Jak widzimy tempo gry jest raczej spokojne, a miganie irytujące. Warto jeszcze przetestować ile czasu zajmuje naszemu programowi rysowanie:

Wyszło trochę ponad 100ms, to nieco więcej niż czas samego kasowania ekranu, więc jak łatwo się domyślić właśnie ta czynność zajmuje najwięcej czasu.

Optymalizacja

Skoro już wiemy, że najwięcej czasu zajmuje kasowanie ekranu, to może zamiast kasować wszystko warto usuwać jedynie poprzednią pozycję "piłki" i rysować nową. Taki program działa już znacznie lepiej:

 

Porównajmy jeszcze czasy rysowania:

Jak widzimy skasowanie i narysowanie piłeczki zajmuje o wiele mniej czasu.

Nieco jednak uprzedzając dalsze części, spróbujmy jeszcze zamiast okrągłej piłki użyć kwadratowej. Może nie brzmi to zachęcająco, ale efekt robi wrażenie:

Podsumowanie

To co zobaczyliśmy to pierwsze możliwości optymalizacji. Nawet jeśli odrysowanie całego ekranu zajmuje mnóstwo czasu, możemy uzyskać o wiele lepsze efekty zmieniając sposób rysowania. To jedna z metod optymalizacji - nie jedyna i w kolejnej części postaram się opisać dlaczego rysowanie działa tak wolno i o ile możemy poprawić wydajność.

Spis treści:

• Sterowanie wyświetlaczem TFT - część 1 - wstęp, podstawowe informacje
• Sterowanie wyświetlaczem TFT - część 2 - analiza problemu
• Sterowanie wyświetlaczem TFT - część 3 - testy prędkości na STM32
• Sterowanie wyświetlaczem TFT - część 4 - własny program
• Sterowanie wyświetlaczem TFT - część 5 - optymalizacja programu

[Treker 2990]

@Elvis świetny artykuł, czekamy na kolejne części! Jak rozumiem mamy tutaj pierwszą pracę, która będzie zgłoszona do naszego konkursu na artykuł - super!

[jas123 82]

Super artykuł , mam podobny wyświetlacz tylko nie wiem jak go podłączyć bo mam trochę inne oznaczenia albo w ogóle coś innego. Piny służą do tego samego czy mój wyświetlacz działa na innej zasadzie?

Zdjęcie:

[Treker 2990]

@jas123 wygląda na to, że Twój wyświetlacz również może komunikować się przez SPI (jest to nawet napisane na płytce). Musisz sprawdzić jaki jest tam sterownik

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[jas123 82]

Na stronie sprzedającego jest napisane że sterownik to ST7735

[OloOlo 0]

Cześć wszystkim  Mam pytanie, czy do Raspberry PI można podłączyć więcej wyświetlaczy podobnych do tego jaki opisał w swoim artykule Elvis? Mam na myśli 3 lub nawet 4, na każdy chciałbym wyświetlić coś innego. Z góry dziękuję za odpowiedź.

Edytowano 8 lutego przez OloOlo

[H1M4W4R1 370]

@OloOlo witaj na forum

Tak, możesz podłączyć więcej wyświetlaczy. Z tego co się orientuję RPi ma bodajże 5 czy 6 magistrali SPI. Do każdej z nich możesz podłączyć wyświetlacze. Równie dobrze możesz podłączyć wszystkie do jednej magistrali i wybierać, do którego mają trafiać dane (CS = low).

Polecam ten artykuł. Wprawdzie jest dostosowany pod MCU ATMega, aczkolwiek jest w nim sporo podstawowej wiedzy o magistrali. 

Podłączanie wyświetlaczy pod tą samą magistralę wpływa negatywnie na maksymalną prędkość odświeżania obrazu. To najważniejsza kwestia różniąca dwie wymienione powyżej możliwości.

[SOYER 298]

Ja się przymierzam do tego, komunikacja po uart, projektowanie w osobnym programie, zobaczymy co mi z tego wyjdzie.

Jaką maksymalna długość przewodów do uart?

[wn2001 309]

@SOYER Jeśli chodzi o długość przewodów do UART, sprawa nie jest jednoznaczna (https://forum.allaboutcircuits.com/threads/maximum-length-for-ttl-uart-between-two-boards.160562/) - zależy od wielu czynników: baudrate'u; jakości kabla czy środowiska, w którym ma pracować Twoja aplikacja (domowe/przemysłowe). Na zdjęciu widzę, że producent dołącza do niektórych zestawów dedykowany przewód - i nie ma on więcej niż kilkanaście cm. Jeśli chciałbyś sterować wyświetlaczem z znacznie większych odległości, musisz pomyśleć o Arduino (lub innej płytce) blisko wyświetlacza, która to będzie dopiero realizować "długodystansową komunikację" - np. różnicowym RS-485 (nie wchodząc w szczegóły, co oznacza "różnicowy", może pracować on w środowisku dużych zakłóceń elektromagnetycznych)

Rozumiem, że chcesz zapłacić nieco więcej za moduł, który niejako "samowystarczalny", a jedynie komunikuje się np. z Arduino (oczywiście z Arduino sterowanie bezpośrednio tak dużym wyświetlaczem mogłoby się nie udać)? Nie chcesz np. użyć wyświetlacza dedykowanego do RaspberryPi (tak pytam tylko z ciekawości)?

[marek1707 2910]

1 godzinę temu, SOYER napisał:

Jaką maksymalna długość przewodów do uart?

Rzeczywiście, nie ma prostej odpowiedzi na tak postawione pytanie. A ponieważ jest mnóstwo rzeczy jakie możesz zrobić by poprawić lub pogorszyć zasięg transmisji szeregowej to aby zacząć mówić o konkretach, ja bym odwrócił pytanie: a ile potrzeba? (jeśli ktoś pamięta egzamin na ministra wczesnej gospodarki radzieckiej)..

BTW: Jeśli po jednej stronie są linie RX/TX i po drugiej także (a tak jest w tym przypadku), to żadne dodatkowe Arduino po drodze nie jest potrzebne. Kwestią jest czy i jakich transceiverów użyć, jakiego medium i jakiej terminacji linii. Żeby wyświetlacz był responsywny przy większych zmianach zawartości, nie schodziłbym poniżej 57600.

[SOYER 298]

Robię "małe" przeróbki mojego sytemu w domu, stary LCD 20*4 już wyleciał. Rozumiem , że metr to nie problem, takim kablem ładuję szkice, a 15m, po skrętce?

[marek1707 2910]

Chcesz odpowiedź krótką (w rodzaju "to zależy") czy długą? I czy masz już oscyloskop?

[Elvis 1416]

@SOYER Podłączanie długich przewodów bezpośrednio do mikrokontrolera jest na ogół złym pomysłem i szybko się mści (np. podczas burzy). Więc może zamiast UART lepiej wykorzystać standardowy interfejs, chociażby RS-232? Dajesz prosty układzik typu MAX232 i po sprawie. A jak potrzebujesz jeszcze większego zasięgu to i RS485 możesz wykorzystać.

[marek1707 2910]

To jasne, ale zastanawiam się ile w SOYER'ze tkwi jeszcze żyłki eksperymentatora. Motyw z przesyłaniem sygnałów przez długie kable daje duże pole do popisu. Można zbliżyć się do impedancji falowej medium, obejrzeć jak działają drivery, terminatory, filtry, zabezpieczenia ESD czy surge. Może warto kiedyś się w to zanurzyć i nabrać wyczucia?

Uznane standardy transmisji to oczywiście rzecz godna polecenia, w końcu po to je przemyślano, przetestowano i opisano by były wytrychami w skrzynce narzędziowej elektroników. Jednak aby nie stosować ich w ciemno (można, ale coś tracimy)(i dlaczego zrobiono to tak a nie inaczej), fajnie jest mimo wszystko wiedzieć co w trawie piszczy tym bardziej, że podstawy są do ogarnięcia dla każdego amatora.

[SOYER 298]

43 minuty temu, marek1707 napisał:

czy masz już oscyloskop

Niestety nie... wiem, że są takie podłączane do kompa, wystarczy?

25 minut temu, marek1707 napisał:

zastanawiam się ile w SOYER'ze tkwi jeszcze żyłki eksperymentatora.

Tkwi, ale eksperymentator potrzebuje dużo czasu, a z tym u mnie krucho...

36 minut temu, Elvis napisał:

Dajesz prosty układzik typu MAX232

Czyli dwa takie układy, jeden przy Arduino, drugi przy ekranie i 30 metrów to nie problem?

Edytowano 11 lutego przez SOYER