Elvis

23 lutego

Żeby się cieszyć, najpierw trzeba uwierzyć że opisywane rozwiązanie istnieje i jest cokolwiek warte. Na razie słyszymy tylko przechwałki i nic konkretnego. Więc jak dla mnie więcej treści miał offtop o teatrze. I jak na razie bajki dla dzieci są dla mnie bardziej wiarygodne niż ten tajemniczy wynalazek - ale bardzo chętnie zmienię zdanie, tylko daj nam szansę i napisz cokolwiek, bo pisać że wiem ale nie powiem to każdy umie... I chyba lepiej brzmi: za siedmioma górami, za siedmioma lasami..

23 lutego

14 wpisów, mnóstwo tekstu i zupełnie brak treści... Proponuję przejść do jakiegokolwiek konkretu, albo wywalić ten wątek do kosza. Forbot to techniczne forum, a nie kółko filozoficzne, @MKJB ja coś wymyśliłeś, może zbudowałeś i chcesz o tym napisać, to pisz śmiało, chętnie poczytamy

16 lutego

Nie bardzo wiem co miałoby dać @SOYER -owi użycie DMA. Był na forum niedawno użytkownik, który co chwila powtarzał że bez DMA nie ma życia... ale dla kogoś kto jeszcze nie opanował wszystkich niuansów arduino to nie musi być takie ważne. Z drugiej strony są po prostu nowsze moduły arduino, chociażby z rodziny MKR, albo wspomniane ESP.

16 lutego

Używanie Cube bywa czasem zaskakujące. Przykładowo generator kodu, czyli CubeMX potrafi utworzyć zapełenie niedziałający kod, a doszukanie się przyczyny błędu zajmuje więcej niż jego napisanie od podstaw. Z samą biblioteką HAL też bywa niewesoło - mało kto chyba zdaje sobie sprawę, że np. w kodzie obsługi przerwań HAL posiada pętle z aktywnym czekaniem... łatwo można napisać piękny program, który będzie działał tylko czasami. Co więcej w dokumentacji biblioteki nic o takich "kwiatkach" nie znajdziemy. A przeglądanie kodu to nic przyjemnego, bo napisany jest tak, że czasem lepiej czytać z zamkniętymi oczami.

Więc tak jak @marek1707 napisał - STM32 są bardzo fajne, biblioteka Cube HAL też interesująca, ale to na pewno nie jest łatwe, miłe i przyjemne dla początkujących.

11 lutego

A może warto zacząć od zapytania wujka google? Wpisujesz np. "AMD FX 6th gen 8800P error 43" i masz pierwszy wynik:

https://windowsreport.com/amd-error-43-windows-10/

Wygląda więc na to, że nie jesteś jedynym posiadaczem błędu 43, a problem wynika ze złych sterowników. Pewnie jak poszukasz dokładniej w google znajdziesz pełne i działające rozwiazanie problemu.

29 stycznia

W poprzednich odcinkach zobaczyliśmy jak działa program, który przesyła do wyświetlacza dane dla każdego piksela osobno, następnie przetestowaliśmy wersję z buforem dla całej pamięci obrazu. Pierwsza wersja działała bardzo wolno, ale zużywała mało pamięci RAM. Druga działała bardzo szybko, ale bufor zajmował ogromną jak na mikrokontroler ilość pamięci. Teraz spróbujemy przygotować wersję pośrednią - tym razem użyjemy mniej pamięci, ale więcej czasu procesora.

Spis treści:

Obliczanie danych obrazu

Pełny bufor obrazu jak pamiętamy zajmuje 160 x 128 x 2 = 40960 bajtów pamięci. Takie rozwiązanie zapewniło nam możliwość szybkiego tworzenia grafiki w pełnej rozdzielczości oraz 65 tysiącach kolorów. Jednak w wielu zastosowaniach wystarczyłaby nieco mniejsze możliwości, przykładowo gdybyśmy zamiast 16-bitów zastosowali 8, uzyskalibyśmy 256 kolorów, a jednocześnie zmniejszyli zużycie pamięci o połowę. W wielu przypadkach nawet 16 kolorów, czyli 4 bity mogłyby wystarczyć, a jak łatwo policzyć bufor zajmowałby wówczas 10240 bajtów.

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.

Podobnie z rozdzielczością, jeśli tworzymy np. mini konsolę do grania, tryb 80x64 mógłby nam wystarczyć, nadałby nawet nieco stylu "retro". Ogólna idea jest więc taka, że spróbujemy przechowywać mniejszą ilość danych, a następnie przeliczać je na reprezentację oczekiwaną przez wyświetlacz dopiero przed wysłaniem.

Tryb z paletą kolorów

Metod generowania obrazu jest mnóstwo, ja spróbuję przedstawić bardzo prosty, czyli użycie 8-bitowej palety. Bufor obrazu będzie wyglądał podobnie jak wcześniej, ale zamiast typu uint16_t użyjemy uint8_t:

uint8_t lcd_framebuffer[LCD_WIDTH * LCD_HEIGHT];

Jak łatwo policzyć zajmuje on teraz 160 x 128 = 20480 bajtów, czyli nadal sporo, ale zawsze można zastosować kolejne optymalizacje.

Wyświetlacz oczekuje danych w postaci RGB565, czyli 16-bitowych wartości gdzie 5-bitów określa składową czerwoną, 6-zieloną, a 5-niebieską. Paleta to po prostu 256-elementowa tablica, która zawiera wartości opisujące dany kolor:

uint16_t palette[256];

W docelowym programie moglibyśmy dobrać idealną paletę do naszego zastosowania i zapisać ją w pamięci flash (albo w samym programie). Jak wspomniałem tutaj prezentuję jedynie demo, więc paletę będę obliczać:

Prawdę mówiąc takie rozwiązanie nie wyglądało najładniej, bo nie można w nim reprezentować bieli, więc zamiast uzupełniać zerami, uzupełniłem jedynkami - jak napisałem, to tylko demo. Bardzo prosty kod przeliczający 8-bitową paletę, na 16-bitowy kolor dla wyświetlacza wygląda następująco:

static inline uint16_t palette2rgb(uint8_t color)
{
	uint16_t r = ((uint16_t)color & 0xe0) << 8;
	uint16_t g = ((uint16_t)color & 0x1c) << 6;
	uint16_t b = ((uint16_t)color & 0x03) << 3;

	return __REV16(0x18e7 | r | g | b);
}

Ta magiczna wartość 0x18e7 to właśnie uzupełnienie jedynkami - wiem że to brzydki kod, z góry za niego przepraszam, ale to mało istotny fragment, zachęcam oczywiście do zastosowania o wiele lepszych rozwiązań.

Teraz przechodzimy do najważniejszego, czyli przeliczania 8-bitowych danych w buforze, na docelowe 16-bitowe przeznaczone dla wyświetlacza. Przesyłanie po jednym bajcie nie działa wydajnie, więc utworzymy nieduży bufor tymczasowy, ja ustaliłem jego wielkość na 512 pikseli:

#define TX_BUF_SIZE		512

static uint16_t tx_buf[TX_BUF_SIZE];

Skoro wyświetlacz ma rozdzielczość 160 x 128, więc jak łatwo policzyć będziemy ten bufor wypełniać i wysyłać 40 razy, aby przesłać cały obraz. Funkcja do wypełniania bufora wygląda następująco:

static void fill_tx_buf(uint32_t part)
{
	uint16_t *dest = tx_buf;
	uint8_t *src = lcd_framebuffer + part * TX_BUF_SIZE;

	for (uint32_t i = 0; i < TX_BUF_SIZE; i++)
		*dest++ = palette2rgb(*src++);
}

Jako parametr podajemy indeks bufora, czyli wartość 0..39, po jej wykonaniu bufor tx_buf będzie zawierał dane do przesłania. Teraz możemy napisać funkcję rysującą zawartość naszego ekranu:

void lcd_copy(void)
{
	lcd_cmd(ST7735S_RAMWR);

	HAL_GPIO_WritePin(LCD_DC_GPIO_Port, LCD_DC_Pin, GPIO_PIN_SET);
	HAL_GPIO_WritePin(LCD_CS_GPIO_Port, LCD_CS_Pin, GPIO_PIN_RESET);

	for (uint32_t i = 0; i < LCD_WIDTH * LCD_HEIGHT / TX_BUF_SIZE; i++) {
		fill_tx_buf(i);
		HAL_SPI_Transmit(&hspi2, (uint8_t*)tx_buf, 2 * TX_BUF_SIZE, HAL_MAX_DELAY);
	}

	HAL_GPIO_WritePin(LCD_CS_GPIO_Port, LCD_CS_Pin, GPIO_PIN_SET);
}

Musimy jeszcze zmodyfikować naszą bibliotekę graficzną, tak żeby pracowała z 8-bitowymi kolorami, ale to właściwie kosmetyczna zmiana. Czas skompilować program:

Zgodnie z oczekiwaniami zużycie pamięci RAM znacznie spadło i wynosi niecałe 23KB. Przetestujmy wydajność naszego programu:

Jak widzimy rysowanie w lokalnym buforze zajmuje tyle samo czasu, czyli 7ms, natomiast kopiowanie trochę więcej niż poprzednio, bo 37ms zamiast 33ms. Warto przy okazji przetestować wydajność funkcji wypełniającej bufor, czyli fill_tx_buf:

void lcd_test(void)
{
	uint32_t start = HAL_GetTick();

	for (uint32_t i = 0; i < 1000; i++)
			fill_tx_buf(i % (LCD_WIDTH * LCD_HEIGHT / TX_BUF_SIZE));

	uint32_t end = HAL_GetTick();

	printf("lcd_test: %ld us\r\n", end - start);
}

Wywołanie 1000 razy fill_tx_buf zajmuje 110ms, czyli jedno jej wywołanie ok. 110us. Jak pamiętamy używamy jej 40 razy, co zgadza się z pozostałymi pomiarami - trochę ponad 4ms zużyliśmy na obliczenia, ale zaoszczędziliśmy prawie 20KB pamięci. Użycie tablicy zamiast obliczeń pewnie pozwoliłoby skrócić ten czas, ale jak wspominałem, to tylko przykład.

Nie będę wstawiał kolejnego filmu, bo już tyle razy widzieliśmy ekran testowy, że chyba każdy ma go dosyć. Czas udoskonalić nasz program.

Użycie DMA

W poprzedniej części korzystaliśmy z DMA, więc nowy program jest pod wieloma względami "gorszy". Użyjmy więc HAL_SPI_Transmit_DMA zamiast, HAL_SPI_Transmit. Procedura wysyłania będzie wyglądała następująco:

void lcd_copy(void)
{
	lcd_wait_ready();
	lcd_busy = true;

	lcd_cmd(ST7735S_RAMWR);

	HAL_GPIO_WritePin(LCD_DC_GPIO_Port, LCD_DC_Pin, GPIO_PIN_SET);
	HAL_GPIO_WritePin(LCD_CS_GPIO_Port, LCD_CS_Pin, GPIO_PIN_RESET);

	tx_part = 0;
	fill_tx_buf(tx_part++);
	HAL_SPI_Transmit_DMA(&hspi2, (uint8_t*)tx_buf, 2 * TX_BUF_SIZE);
}

Wypełniamy w niej bufor pierwszym fragmentem obrazu i rozpoczynamy wysyłanie. W zmiennej tx_part przechowujemy informację o numerze kolejnego fragmentu do wysłania.

Musimy teraz obsłużyć przerwanie informujące o zakończeniu transmisji i w nim przygotować dane dla następnego fragmentu, albo zakończyć całą operację:

void lcd_copy_done(void)
{
	if (tx_part < LCD_WIDTH * LCD_HEIGHT / TX_BUF_SIZE) {
		fill_tx_buf(tx_part++);
		HAL_SPI_Transmit_DMA(&hspi2, (uint8_t*)tx_buf, 2 * TX_BUF_SIZE);
	} else {
		HAL_GPIO_WritePin(LCD_CS_GPIO_Port, LCD_CS_Pin, GPIO_PIN_SET);
		lcd_busy = false;
	}
}

Po uruchomieniu zobaczymy, że program działa tak samo jak poprzednio. Różnica jest jednak taka, że podczas transmisji przez DMA procesor może wykonywać inne zadania. Jednak czas kopiowania obrazu nadal wynosi 37ms.

Jeszcze jedna ważna uwaga - w przerwaniu generujemy dane dla kolejnego bufora, więc na 110us blokujemy przerwanie. Długie procedury obsługi przerwań to nic dobrego, ale STM32 pozwala na szczęście na ustawienie priorytetów przerwań. Możemy więc przerwaniu od DMA nadać niski priorytet i dzięki temu nasze obliczenia nie będą opóźniały innych, pilniejszych zadań:

Użycie podwójnego bufora

Jeśli podłączymy analizator logiczny to zobaczymy, że komunikacja z wyświetlaczem ma "przerwy". Wynika to stąd, że gdy obliczamy dane dla kolejnego fragmentu ekranu komunikacja jest zatrzymywana. Możemy trochę skomplikować nasz program, ale jednocześnie przyspieszyć działanie. Tym razem użyjemy dwóch buforów, albo raczej jednego większego. Gdy DMA będzie wysyłało jedną część danych, będziemy mieli czas na przygotowanie następnej.

Deklarujemy więc większy bufor:

#define TX_BUF_SIZE		512

static uint16_t tx_buf[TX_BUF_SIZE * 2];

Funkcja wypełniania bufora będzie teraz zapisywać parzyste fragmenty w pierwszej części tx_buf, a nie nieparzyste w drugiej:

static void fill_tx_buf(uint32_t part)
{
	uint16_t *dest = (part % 2 == 0) ? tx_buf : tx_buf + TX_BUF_SIZE;
	uint8_t *src = lcd_framebuffer + part * TX_BUF_SIZE;

	for (uint32_t i = 0; i < TX_BUF_SIZE; i++)
		*dest++ = palette2rgb(*src++);
}

Przed rozpoczęciem transmisji wypełnimy nie jeden, ale dwa bufory:

void lcd_copy(void)
{
	lcd_wait_ready();
	lcd_busy = true;

	lcd_cmd(ST7735S_RAMWR);

	HAL_GPIO_WritePin(LCD_DC_GPIO_Port, LCD_DC_Pin, GPIO_PIN_SET);
	HAL_GPIO_WritePin(LCD_CS_GPIO_Port, LCD_CS_Pin, GPIO_PIN_RESET);

	tx_part = 0;
	fill_tx_buf(tx_part++);
	fill_tx_buf(tx_part++);
	HAL_SPI_Transmit_DMA(&hspi2, (uint8_t*)tx_buf, 4 * TX_BUF_SIZE);
}

Ostatnia zmiana to obsługa nowego przerwania, które będzie wywoływane po przesłaniu połowy danych:

void HAL_SPI_TxHalfCpltCallback(SPI_HandleTypeDef *hspi)
{
	lcd_copy_halfdone();
}

Gdy otrzymamy to przerwanie, będziemy po prostu wypełniać następny bufor:

void lcd_copy_halfdone(void)
{
	fill_tx_buf(tx_part++);
}

Natomiast procedura obsługi końca transmisji prawie się nie zmieniła, jedyna różnica to wielkość bufora:

void lcd_copy_done(void)
{
	if (tx_part < LCD_WIDTH * LCD_HEIGHT / TX_BUF_SIZE) {
		HAL_SPI_Transmit_DMA(&hspi2, (uint8_t*)tx_buf, 4 * TX_BUF_SIZE);
		fill_tx_buf(tx_part++);
	} else {
		HAL_GPIO_WritePin(LCD_CS_GPIO_Port, LCD_CS_Pin, GPIO_PIN_SET);
		lcd_busy = false;
	}
}

Program jest nieco bardziej skomplikowany, ale w nagrodę otrzymaliśmy czas kopiowania identyczny jak w wersji z poprzedniego odcinka, ale zużyliśmy mniej pamięci:

Na zakończenie jeszcze mały przykład wykorzystania naszego nowego programu.

Program demonstracyjny

Jakiś czas temu na forum pojawił się wątek z pytaniem o sposób wyświetlania kołowego progres baru.

Pytanie sprowokowało ciekawą dyskusję na temat możliwości wydajnej realizacji takiego zadania. Skoro mamy opanowane sterowanie wyświetlacza TFT, możemy spróbować narysować nieco podobny element, a przy okazji sprawdzić jak nasza "biblioteka" sprawdzi się w realnym przykładzie.

Zacznijmy od małej powtórki z matematyki oraz pewnego uproszczenia. Dla ułatwienia rysujmy tylko połowę progres-bara, zawsze możemy później rozbudować program.

Rysowanie pionowych linii jest na ogół dość szybką operacją, więc zastanówmy się jak narysować wykres pionowymi (albo poziomymi) liniami. Kąt alfa oraz promienie r₁ i r₂ to nasze dane. Ja wybrałem rysowanie pionowych linii, więc x będzie zmienną.

Wszyscy pamiętamy z matematyki wzór okręgu: x² + y² = r². Po karkołomnych przejściach matematycznych uzyskujemy więc:

y₁ = sqrt(r₁ - x²)

y₃ = sqrt(r₂ - x²)

Funkcja sqrt to pierwiastek. Jeśli ktoś jest miłośnikiem optymalizacji to wartości y1 i y2 może raz policzyć i trzymać w tablicy (najlepiej w pamięci Flash). Jak wspominałem program to demo, więc na razie nie będzie aż tak optymalny.

Zostaje jeszcze obliczenie y2. Jest to odrobinę trudniejsze, może wymagać szybkiej powtórki z trygonometrii, a jak pamiętamy tg(alpha) = y/x, więc:

y₂ = x * tg(alpha)

Tutaj znowu możemy tablicować wartości, ale na początek zostawmy prostą wersję. Mamy więc dla każdego x obliczone y₁, y₂ i y₃. Teraz wystarczy sprawdzić jak y₂ ma się do pozostałych i są możliwe 3 przypadki:

jeśli y₂ <= y₁ to nic nie rysujemy
jeśli y₂ >= y₃ to rysujemy "pełną" linię od y₁ do y₃
a jeśli y₁ < y₂ < y₃ to linię od y₁ do y₂

Rysowanie możemy więc wykonać następującym programem:

void draw_bar(uint32_t r1, uint32_t r2, uint32_t alpha)
{
	float t = tan(alpha * M_PI / 180.0);

	bar_circle(0, 0, r1, WHITE);
	bar_circle(0, 0, r2, WHITE);
	bar_line(0, 0, r1 * cos(alpha * M_PI / 180.0) * 0.8f, r1 * sin(alpha * M_PI / 180.0) * 0.8f, WHITE);

	for (uint32_t x = 0; x <= r2; x++) {
		uint32_t y1 = (x < r1) ? sqrt(r1 * r1 - x * x) : 0;
		uint32_t y2 = sqrt(r2 * r2 - x * x);
		uint32_t y3 = x * t;

		if (y3 > y2)
			bar_line(x, y1, x, y2, WHITE);
		else if (y3 > y1)
			bar_line(x, y1, x, y3, WHITE);
	}
}

Funkcje bar_circle i bar_line są dodane aby "przenieść" nasz początek współrzędnych w odpowiednie miejsce:

static void bar_circle(uint32_t x, uint32_t y, uint16_t r, uint8_t color)
{
	lcd_circle(LCD_WIDTH - 1 - x, LCD_HEIGHT - 1 - y, r, color);
}

static void bar_line(uint32_t x1, uint32_t y1, uint32_t x2, uint32_t y2, uint8_t color)
{
	lcd_line(LCD_WIDTH - 1 - x1, LCD_HEIGHT - 1 - y1, LCD_WIDTH - 1 - x2, LCD_HEIGHT - 1 - y2, color);
}

Dodajmy jeszcze "wskazówkę", pomiar czasu działania oraz wyświetlanie wartości:

void draw_test_screen(uint32_t value)
{
	char buf[32];
	uint32_t start = HAL_GetTick();

	lcd_clear(BLUE);
	draw_bar(117, 127, value);
	sprintf(buf, "%ld", value);
	lcd_fill_rect(110, 90, 150, 120, BLACK);
	lcd_draw_string(120, 100, buf, &Font16, WHITE, BLACK);
	lcd_copy();

	uint32_t time = HAL_GetTick() - start;
	printf("drawing: %lu ms\r\n", time);
}

Teraz program jest gotowy:

Nawet bez tablicowania wartości i z arytmetyką zmiennopozycyjną rysowanie zajmuje ok 22ms.

Kopiowanie to 33ms, mamy więc prawie 20 klatek na sekundę, ale pewnie dałoby się więcej.

Podsumowanie

Początkowo planowałem napisanie jednego, może dwóch artykułów odnośnie sterowania wyświetlaczem TFT. Okazało się jednak, że temat jest o wiele obszerniejszy i ciekawszy, a 5 części to właściwie dopiero wstęp. Mam nadzieję, że udało mi się pokazać jak można sterować wyświetlaczem kolorowym oraz zachęcić do własnych eksperymentów i udoskonalania zaprezentowanych rozwiązań.

Spis treści:

29 stycznia

Jest mi bardzo przykro jeśli kogoś rozczarowałem. Prawdę mówiąc planowałem tylko napisać artykuł o tym jak działa wyświetlacz TFT podłączony do STM32... a później jakoś tak samo wyszło, żeby trochę temat rozwinąć, porównać z Arduino itd. Nie miał to być kurs pisania bibliotek graficznych, ani kompendium wiedzy o grafice komputerowej.

Natomiast co do czyszczenia ekranu i migotania, to właśnie o to chodziło żeby pokazać (i co ważniejsze zmierzyć) ile czasu zajmuje rysowanie oraz kasowanie zawartości ekranu.

28 stycznia

W poprzednich częściach zapoznaliśmy się z demonstracyjnym kodem dostarczanym przez producenta wyświetlacza. Wiemy jakie zalety i wady ma to rozwiązanie, nadszedł moment, żeby spróbować napisać własną wersję.

Spis treści:

Własna biblioteka graficzna

Specjalnie wybrałem model mikrokontrolera, w którego pamięci zmieści się cały bufor ekranu. Jak pamiętamy konieczne jest 160 x 128 x 2 = 40960 bajtów pamięci, co nie jest jednak problemem dla układu STM32L476. Kolor każdego piksela jest przechowywany jako 16-bitowa wartość, możemy więc utworzyć bufor pisząc po prostu:

uint16_t lcd_framebuffer[LCD_WIDTH * LCD_HEIGHT];

Wybrałem poziomą orientację ekranu, więc LCD_WIDTH ma wartość 160, a LCD_HEIGHT 128. Przykładowa procedura rysowania punktu może wyglądać następująco:

void lcd_set_pixel(uint32_t x, uint32_t y, uint16_t color)
{
	if (x < LCD_WIDTH && y < LCD_HEIGHT)
		lcd_framebuffer[x + y * LCD_WIDTH] = __REV16(color);
}

Jak widzimy jest to po prostu zapisanie do tablicy przechowywanej w pamięci RAM, działa więc błyskawicznie. Wywołanie __REV16 było mi potrzebne, aby zamienić kolejność bajtów - można byłoby odpowiednio przeliczyć kody kolorów, ale zamiana bajtów to raptem jedna instrukcja asemblera (oczywiście jak ktoś będzie chciał optymalizować kod może, a nawet powinien tego typu błędy wyeliminować).

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.

Kasowanie ekranu również odbywa się w pamięci, więc kod również jest prosty:

void lcd_clear(uint16_t color)
{
	uint16_t *p = lcd_framebuffer;
	uint16_t *end = lcd_framebuffer + LCD_WIDTH * LCD_HEIGHT;
	color = __REV16(color);
	while (p != end)
		*p++ = color;
}

Obecnie całe rysowanie odbywa się w lokalnej pamięci, dopiero gotowy obraz jest kopiowany na ekran. Przy pierwszym podejściu użyję HAL_SPI_Transmit, ale tym razem do przesłania wszystkich danych na raz (zamiast po jednym bajcie jak poprzednio):

void lcd_copy(void)
{
	lcd_cmd(ST7735S_RAMWR);

	HAL_GPIO_WritePin(LCD_DC_GPIO_Port, LCD_DC_Pin, GPIO_PIN_SET);
	HAL_GPIO_WritePin(LCD_CS_GPIO_Port, LCD_CS_Pin, GPIO_PIN_RESET);

	HAL_SPI_Transmit(&hspi2, (uint8_t*)lcd_framebuffer, 2 * LCD_WIDTH * LCD_HEIGHT, 500);

	HAL_GPIO_WritePin(LCD_CS_GPIO_Port, LCD_CS_Pin, GPIO_PIN_SET);
}

Przed wysłaniem danych wykonywana jest komenda wyświetlacza RAMWR. Jej wykonanie powoduje zapis do zdefiniowanego okna zaczynając od pozycji (0, 0). Natomiast samo okno jest ustawiane raz podczas inicjalizacji sterownika - ma ono rozmiar całego wyświetlacza, czyli 160x128 pikseli.

Zmieniłem trochę wyświetlany obraz bo w mojej wersji używam tylko poziomej orientacji wyświetlacza. Program działa następująco:

Nie bardzo to widać, ale obraz jest rysowany w pętli - tym razem jednak nie widać kasowania, ani rysowania obrazu:

Rysowanie w pamięci RAM zajmuje ok 6ms. Procedury nie są jakoś szczególnie zoptymalizowane, do rysowania linii i okręgów używany jest algorytm Bresenhama, czcionki są identyczne jak w kodzie WaveShare. Kopiowanie danych z bufora do wyświetlacza trwa 33ms, czyli tyle ile powinno. Biblioteka HAL jak widzieliśmy poprzednio nie jest demonem szybkości, gdy wysyłamy za jej pomocą pojedyncze bajty, jednak transmitując duży bufor, jej użycie jest już całkiem sensowne (a na pewno łatwe).

Użycie DMA

Kopiowanie za pomocą funkcji HAL_SPI_Transmit ma pewną wadę, przez 33ms mikrokontroler jest zajęty tylko kopiowaniem. Do tego celu można jednak wykorzystać mechanizm DMA, dzięki czemu procesor będzie mógł wykonywać inne zadania, a samo kopiowanie będzie odbywało się w pełni sprzętowo (a więc i z maksymalną szybkością).

Użycie DMA w środowisku STM32CubeIDE jest dziecinnie proste - prawie wszystko robimy za pomocą graficznych kreatorów.

Napisałem prawie, bo jednak trochę programowania jeszcze nam zostanie. Poza tym kod wygenerowany przez CubeMX nie zawsze działa... W przypadku L476 w wersji CubeIDE 1.1.0 kolejność inicjalizacji SPI oraz DMA jest niepoprawna, więc domyślnie tworzony kod po prostu nie działa.

Niestety nie udało mi się zmusić CubeMX do generowania kodu włączającego DMA zanim zacznie konfigurację SPI. Obejściem było wyłączenie wywoływania inicjalizacji DMA zupełnie i ręczne dodanie odpowiedniego kodu. Może w kolejnej wersji narzędzia ten błąd zniknie, ale zobaczymy. Warto też pamiętać, że domyślne priorytety przerwań mogą zupełnie zawiesić kod biblioteki HAL.

W każdym razie zmiany w kodzie programu związane z użyciem DMA są właściwie kosmetyczne. Pierwsza to nieco inne sterowanie pinem CS - poprzednio ustawialiśmy go w stan wysoki zaraz po powrocie z wywołania HAL_SPI_Transmit. Teraz musimy dodać obsługę przerwania, które będzie wywołane po zakończeniu transmisji. Dopisujemy więc:

void HAL_SPI_TxCpltCallback(SPI_HandleTypeDef *hspi)
{
	lcd_copy_done();
}

A w funkcji lcd_copy_done sterujemy odpowiednio pinem CS. Druga zmiana wynika z działania DMA w tle - nie chcemy zmieniać zawartości bufora ekranu, gdy DMA przesyła dane. Potrzebujemy więc flagi, która będzie informowała, że trwa transmisja (moglibyśmy oczywiście użyć podwójnego buforowania, ale 40KB to już i tak ogromny bufor jak na mikrokontroler).

Oczywiście zamiast HAL_SPI_Transmit wywołujemy teraz HAL_SPI_Transmit_DMA. Sam program działa jak poprzednio, zyskaliśmy jednak 32ms na wykonywanie czegoś ciekawszego przez procesor.

Program demonstracyjny

Wiemy już jak sterować wyświetlaczem i uzyskać całkiem sensowne czasy działania. Odbyło się to za cenę dużego użycia pamięci, ale mamy możliwość rysowania prawie 25 klatek na sekundę.

Jako przykład użycia kodu, wykorzystałem demo rysujące animowany tunel, które jest dokładnie opisane pod tym adresem. Pierwszy program oblicza kolory tekstury oraz bufory dla współrzędnych - wszystko jest opisane na blogu do którego podałem link, nie będę się więc rozpisywał o zasadzie działania programu. Użycie pamięci wzrosło do prawie 90KB

Ale efekt jest chyba dość ładny:

Program jest zaskakująco prosty (w pętli głównej wywoływana jest tylko funkcja draw_tunnel

uint16_t texture[texHeight][texWidth];
uint8_t distanceTable[LCD_HEIGHT][LCD_WIDTH];
uint8_t angleTable[LCD_HEIGHT][LCD_WIDTH];


static void precalc(void)
{
    for (int y = 0; y < texHeight; y++) {
    	for (int x = 0; x < texWidth; x++)
    		texture[y][x] = (x * BLUE / texWidth) ^ (y * BLUE / texHeight);
    }

	for(int y = 0; y < LCD_HEIGHT; y++)
		for(int x = 0; x < LCD_WIDTH; x++) {
			float ratio = 16.0;
			int dx = x - LCD_WIDTH / 2;
			int dy = y - LCD_HEIGHT / 2;
			float d = sqrt(dx * dx + dy * dy);
			int distance = (int)(ratio * texHeight / d) % texHeight;
			int angle = texWidth / 2 + (int)(texWidth / 2 * atan2(dy, dx) / M_PI);
			distanceTable[y][x] = distance;
			angleTable[y][x] = angle;
	  }
}

static void draw_tunnel(void)
{
	static uint32_t animation = 0;
	animation++;

    int shiftX = (int)(texWidth * 0.05 * animation);
    int shiftY = (int)(texHeight * 0.025 * animation);

	lcd_wait_ready();
    for(int y = 0; y < LCD_HEIGHT; y++)
    	for(int x = 0; x < LCD_WIDTH; x++) {
    		uint16_t color = texture[(unsigned int)(distanceTable[y][x] + shiftX)  % texWidth][(unsigned int)(angleTable[y][x] + shiftY) % texHeight];
    		lcd_set_pixel(x, y, color);
    }
    lcd_copy();
}

Podobnie jak w opisywanym blogu, użyłem również użyć gotowej tekstury (zapisanej w pamięci Flash). Takie rozwiązanie jest nawet korzystniejsze jak chodzi o użycie pamięci RAM:

Efekt działania programu:

Możliwe jest również zaoszczędzenie pamięci przez wykorzystanie symetrii tablic wykorzystywanych podczas rysowania "tunelu". Takie program jest nieco bardziej skomplikowany, ale pozwala na uzyskanie efektu "rozglądania się" kamery:

Podsumowanie

Jak widzimy współczesne mikrokontrolery mają ogromną moc obliczeniową, odpowiednio optymalizując kod mogą całkiem sprawnie poradzić sobie ze sterowaniem niewielkiego wyświetlacza TFT. Odbywa się to za cenę użycia pamięci RAM, ale odpowiednio optymalizując kod można to zapotrzebowanie nieco zmniejszyć. W kolejnej części opiszę jak użyć trybu z mniejszą liczbą kolorów, dzięki czemu zapotrzebowanie na pamięć bardzo spadnie.

Spis treści:

28 stycznia

Jak wspominałem na początku, wśród programów przykładowych dostarczanych przez producenta wyświetlacza znajdziemy przykłady nie tylko dla Arduino, ale również STM32. Działanie z Arduino Uno już widzieliśmy, czas wypróbować jak nasz moduł będzie działał z mikrokontrolerem firmy STMicroelectronics.

Spis treści:

Uruchomienie kodu przykładowego

Okazuje się, że program przykładowy ma kilka wad. Projekt został przygotowany dla kompilatora firmy Keil (obecnie ARM) - nie jest to może wada jeśli mamy licencję, ale jeśli jej akurat nie mamy to użycie gcc byłoby znacznie tańsze. Druga sprawa to wybrany model mikrokontrolera oraz płytka. Przykłady są dla STM32F103 oraz płytki XNUCLEO-F103RB produkcji WaveShare oczywiście... Niestety F103 ma "tylko" 20KB pamięci RAM, a jak pamiętamy bufor ekranu to ponad 40KB. Do tego płytka WaveShare nie jest chyba zbyt popularna, a na pewno mniej niż oryginalne płytki serii Nucleo.

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.

Na szczęście przeniesienie projektu do darmowego środowiska STM32CubeIDE oraz zmiana płytki na inną to bardzo proste zadanie. Wybrałem moją ulubioną płytkę NUCLEO-L476RG

Mikrokontroler STM32L476 ma podobne do F103 taktowanie maksymalne (80MHz), ale dużo więcej pamięci RAM, bo aż 128KB, chociaż "tylko" 96KB dostępne domyślnie. To jednak powinno w zupełności wystarczyć. Dodatkowa zaleta to o wiele łatwiejsza konfiguracja zegarów - w przypadku L4 wszystkie magistrale mogą pracować z taką samą prędkością jak rdzeń, więc będzie łatwiej wszystko liczyć.

Utworzenie projektu w CubeIDE jest bardzo proste, szczególnie wykorzystując wtyczkę CubeMX. Sam kod wymaga dosłownie kosmetycznych zmian i po chwili mamy gotowy projekt.

Mikrokontroler jest taktowany maksymalną częstotliwością, czyli 80MHz, natomiast SPI pracuje z dzielnikiem 8, co daje równe 10MHz. Program podobnie jak w wersji dla Arduino Uno prawie nie wykorzystuje pamięci RAM. Jak łatwo się domyślić jest bardzo podobny do omawianego poprzednio... producentowi chyba nie chciało się go optymalizować pod inną platformę. Przy okazji ciekawostka - kto zgadnie jak wygląda i działa wersja dla Raspberry Pi ?

Ale żeby nie przynudzać - uruchamiam program i...

Pewnie nie tego się spodziewaliśmy po STM32. Porównajmy czasy rysowania i kasowania:

Ciężko w to uwierzyć, mamy 32-bitowy mikrokontroler pracujący z częstotliwością 80MHz, a rysowanie raptem odrobinę szybsze niż poprzednio. Natomiast kasowanie działa dużo wolniej...

Warto upewnić się że to nie błąd pomiarowy, podłączamy analizator:

Pierwszy wykres potwierdza, że kasowanie zajmuje mnóstwo czasu. Na środkowym widzimy, że SPI faktycznie działa na 10 MHz, natomiast ostatni pokazuje przyczynę problemu. Między wysyłanymi bajtami są jeszcze większe przerwy niż na Arduino Uno!

Optymalizacja

Okazuje się, że CubeIDE faktycznie pozwala szybko utworzyć projekt. Jednak mogą w nim czaić się pewne niespodzianki. Pierwsza to ustawienia optymalizacji kodu:

Domyślnie wybrany jest brak optymalizacji, czyli opcja kompilatora -O0. Arduino używało chociaż optymalizacji wielkości programu, czyli -Os. Niestety bez optymalizacji nawet o wiele szybszy procesor może słabo działać. Zmieniamy więc ustawienia i oglądamy rezultat (film nagrany przy maksymalnej optymalizacji, czyli -O3):

Różnica między -Os (po lewej) i -O3 (po prawej) nie jest zbyt znacząca, ale obie wersje działają o wiele szybciej niż domyślny brak optymalizacji:

Na Arduino Uno rysowanie zajmowało ponad 1200ms, teraz 530ms - jest więc dużo lepiej. Z drugiej strony dwie klatki na sekundę szału nie robią. Do tego to kasowanie, może warto mu się chwilę przyjrzeć.

Biblioteka HAL

Chyba wszyscy słyszeli zarówno o bibliotece HAL dla STM32, jak i bibliotekach Arduino. Co więcej na pewno wszyscy słyszeli że pierwsza jest świetna, profesjonalna i wydajna, a druga wręcz przeciwnie. Może się jednak okazać że to nie zawsze jest prawda.

Przykładowy program wysyła dane po jednym bajcie. Kod który został dostarczony przez WaveShare wygląda następująco:

uint8_t SPI_Write_Byte(uint8_t value)                                    
{    
#if 0
	HAL_SPI_Transmit(&hspi1, &value, 1, 500);
	
//	 unsigned char Read_Buf;
//	HAL_SPI_TransmitReceive(&hspi1, &value, &Read_Buf,1, 500);
//	return Read_Buf;
	
#elif 0
	char i;
	for(i = 0;i < 8;i++){		
		SPI_SCK_0;
		if(value & 0X80)
			SPI_MOSI_1;
		else
			SPI_MOSI_0;
		Driver_Delay_us(10);
		SPI_SCK_1;
		Driver_Delay_us(10);
		value = (value << 1); 	
	}
#else
	
    __HAL_SPI_ENABLE(&hspi1);
	SPI1->CR2 |= (1)<<12;
	
	while((SPI1->SR & (1<<1)) == 0)
		;
        
        *((__IO uint8_t *)(&SPI1->DR)) = value;
        
        while(SPI1->SR & (1<<7)) ; //Wait for not busy

        while((SPI1->SR & (1<<0)) == 0) ; // Wait for the receiving area to be empty
        
        return *((__IO uint8_t *)(&SPI1->DR));

#endif
}

Jak widać ktoś tam coś grzebał... W przykładach używam pierwszej opcji, czyli po prostu wywołuję HAL_SPI_Transmit. Na Arduino Uno to samo realizowało wywołanie SPI.transfer(__DATA).

Jeśli ktoś zajrzy do implementacji HAL_SPI_Transmit, zobaczy ponad 170 linii kodu, który ciężko nazwać optymalnym:

Natomiast Arduino to kilka linijek w dodatku oznaczonych jako inline:

To tłumaczy dlaczego programiści WaveShare coś próbowali grzebać w rejestrach... Im też nie podobało się tak wolne działanie biblioteki. Użycie biblioteki LL, albo rejestrów zamiast HAL daje w tym miejscu ogromne przyspieszenie działania. Jednak takie optymalizacje w sumie i tak nie mają zbyt wiele sensu. Trzeba się pogodzić z rzeczywistością i napisać własną wersję biblioteki wyświetlacza.

Biblioteka LL

Jeszcze mały update - napisałem że optymalizacja nie ma sensu... ale sam chciałem się upewnić że winny powolnemu działaniu jest HAL. Myślałem, że skasowałem wersję z biblioteką LL, ale w repozytorium git-a nic nie ginie. Udało mi się więc odszukać i przetestować wersję z LL zamiast HAL:

Jak pamiętamy kasowanie ekranu wymaga przesłania 160 x 128 x 16 = 327680 bitów danych. Ponieważ SPI pracuje z częstotliwością 10MHz, więc w idealnej sytuacji transmisja zajmuje niecałe 33ms. Nasz kod nie jest idealny, ale jak widać użycie biblioteki LL pozwoliło ze 128ms zejść do 45ms. No i uzyskać 3 klatki na sekundę...

Podsumowanie

W tej części zobaczyliśmy jak na STM32 działa program demonstracyjny dostarczany przez producenta wyświetlacza. Wiemy już że sama zmiana mikrokontrolera nie wystarczy, konieczna będzie również zmiana programu. O tym jak napisać własny program oraz użyć bufora w pamięci RAM napiszę za chwilę, w kolejnej części.

Spis treści:

28 stycznia

Buforowanie w RAM będzie jak najbardziej - chociaż najpierw będzie kod od WaveShare, tak dla porównania.

27 stycznia

W poprzedniej części zobaczyliśmy jak działa wyświetlacz TFT podłączony do Arduino Uno. Wiemy już, że nie jest to demon szybkości, czas przeanalizować nieco dokładniej przyczyny takiego, a nie innego działania. Ta część będzie nieco bardziej techniczna od poprzedniej, znajdziemy w niej więcej obliczeń oraz odniesień do dokumentacji. Niestety pewna dawka "teorii" będzie konieczna dla zrozumienia działania wyświetlacza oraz poprawienia wydajności.

Spis treści:

Dlaczego to tak wolno działa?

Na początek coś prostego, czyli oszacowanie ilości danych koniecznych do przesłania.

Dla porównania zacznijmy od wyświetlacza alfanumerycznego, takiego jak był używany w kursie Arduino. Wyświetlacz posiada dwa wiersze po 16 znaków, a każdy znak jest przesyłany jako bajt. Mamy więc razem 32 bajty danych. Mnożąc przez 8 bitów w każdym bajcie otrzymujemy więc 256 bitów. W kursie STM32 F1 używany był graficzny wyświetlacz o rozdzielczości 84 na 48 pikseli. Każdy piksel mógł być albo zapalony, albo wygaszony, więc do jego sterowania wystarczał jeden bit. Mamy więc 84 x 48 = 4032 bity, czyli inaczej 504 bajty danych.

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.

Teraz czas na bohatera tego artykułu - domyślna biblioteka używa trybu 16-bitowego koloru, a rozdzielczość ekranu to 160 na 128 pikseli. Mnożymy więc 160 x 128 x 16 i uzyskujemy wynik 327680 bitów, albo 40960 bajtów. Z tych ogólnych rachunków łatwo wywnioskować, że aby wyświetlić obraz na naszym ekranie TFT musimy przetworzyć 1280 razy więcej danych niż w przypadku wyświetlacza alfanumerycznego. To chyba jest najprostsza i najbardziej ogólna odpowiedź na pytanie dlaczego jest wolno...

Oczywiście nie jest to pełna odpowiedź, ale mam nadzieję że pokazuje ona o ile trudniej jest szybko wysterować wyświetlacz TFT.

Jak szybko powinien działać nasz program?

Poprzednio zmierzyliśmy czas rysowania ekranu i wyszło nam ponad 1200 ms, kasowanie zawartości zajmowało ok. 96 ms. Spróbujmy teraz oszacować jak szybko "powinien" nasz program działać, albo raczej jaka jest granica związana z prędkością interfejsu SPI. W konfiguracji interfejsu widzimy linijkę:

  SPI.setClockDivider(SPI_CLOCK_DIV2);

A jak wiemy Arduino UNO jest taktowane z częstotliwością 16 MHz. Dzieląc przez dwa, otrzymujemy 8 MHz dla interfejsu SPI, co daje 8'000'000 bitów na sekundę. Skoro dane obrazu wymagają 327800 bitów, więc teoretycznie przesłanie danych zajmuje 327800 / 8000000 = 0,041 s, czyli 41 ms. Taki czas dawałby nam przyzwoite 24 klatki na sekundę, ale nawet kasowanie ekranu działa ponad dwa razy wolniej niż powinno, o rysowaniu nawet lepiej nie wspominać.

Analiza procedury kasowania ekranu

Zacznijmy od podłączenia analizatora stanów logicznych i upewnienia się, że wszystko działa jak oczekujemy. Na początek pomiar czasu kasowania ekranu - łatwo go zmierzyć, bo wysyłamy kod koloru białego czyli same bajty 0xff:

Na razie wszystko wygląda zgodnie z oczekiwaniami. Sprawdźmy więc, czy na pewno SPI pracuje z częstotliwością 8 MHz.

Częstotliwość się zgadza, ale niemiłym zaskoczeniem są przerwy między wysyłanymi bajtami danych:

Niestety, ale między wysłaniem kolejnych bajtów procesor musi mieć trochę czasu - na odczyt statusu zakończenia transmisji, powrót z procedury, załadowanie kolejnej danej, a to wszystko trwa. Optymalizacja programu jest oczywiście możliwa, ale wymagałaby rezygnacji z użycia klasy SPI dostarczanej przez Arduino oraz chyba wskazane byłoby dodanie wstawek w asemblerze. W każdym razie taka optymalizacja nie jest prostym zadaniem, to niewątpliwie ciekawe wyzwanie, ale niekoniecznie przeznaczone dla początkujących.

Na tą chwilę pozostaje się chyba pogodzić z tym, że maksymalna transmisja to nie 8 Mb/s, ale około połowa tej prędkości. To nadal całkiem niezły wynik, gdyby rysowanie zajmowało tyle samo czasu, co kasowanie mielibyśmy 10 klatek na sekundę. Zobaczmy więc dlaczego rysowanie jest tak strasznie powolne.

Sterownik obrazu

Nasz wyświetlacz wyposażony jest w kontroler ST7735S, poprzednio podawałem do niego link, ale na wszelki wypadek podam jeszcze raz. Zachęcam do zapoznania się z całą dokumentacją, ale chwilowo opiszę tylko absolutne minimum niezbędne z zrozumienia sterowania oraz poprawienia wydajności programu.

Do komunikacji z ST7735S można użyć jednego z czterech interfejsów. Dostępne są dwa interfejsy równoległe (6800/8080) oraz dwa szeregowe, określane jako 3- i 4- przewodowy. W przypadku opisywanego modułu niestety nie ma wyboru i dostępny jest tylko ostatni, czyli "4-line Serial".

Jak pisaliśmy wcześniej jest to SPI, ale nie do końca... co więcej nazewnictwo linii w module, standardzie SPI i dokumentacji sterownika jest inne. Poniżej przykładowy diagram przedstawiający komunikację:

Linia CSX to odpowiednik linii CS zarówno w module wyświetlacza, jak i standardzie SPI. Nazwa SDA jest najczęściej używana w interfejsie i²c, ale tutaj oznacza po prostu linię danych, która na module ma nazwę DIN, a łączymy ją z pinem MOSI (Master-Output-Slave-Input). Warto pamiętać, że SDA może być używana też do odczytu danych... Zostańmy jednak przy jednokierunkowej transmisji.

Kolejna linia to D/CX, na naszym module oznaczona jako DC - która nie jest częścią standardu SPI, więc pozostaje ją połączyć z pinem GPIO i sterować "ręcznie". Na koniec SCL, czyli linia zegara, na module dostępna jako CLK, a standardowo nazywana SCLK, albo SCK.

Mamy więc straszny bałagan w nazwach, ale na koniec w sumie prostą sytuację - jednokierunkowy interfejs SPI oraz dodatkową linię DC. Jak widzimy transmisja polega na przesyłaniu 8-bitowych bajtów, czyli nic strasznego.

Sterowanie ST7735S polega na przesyłaniu do niego komend. Pierwszy bajt zawiera wówczas kod komendy, a podczas jego przesyłania linia DC powinna być ustawiona w stan niski. Same kody dostępnych poleceń znajdziemy w dokumentacji sterownika, przykładowo:

Po niektórych komendach przesyłane są parametry - podczas ich transmisji linia DC musi być w stanie wysokim. To ile parametrów jest potrzebnych znajdziemy w dokumentacji. Obsługiwanych komend jest dużo, na szczęście nie musimy ich wszystkich od razu poznawać. Dostarczony program przykładowy zawiera kod niezbędny do uruchomienia wyświetlacza, właściwie jedyne na co warto w nim zwrócić na początek uwagę to możliwość zmiany orientacji wyświetlacza. To bardzo wygodna opcja, dzięki niej nasz wyświetlacz może pracować zarówno w pionie (jak w przykładach z poprzedniej części), jak i w poziomie, co moim zdaniem ładniej wygląda. Ale najważniejsze, że wszystko jest wspierane sprzętowo, nie musimy więc programowo obracać obrazu.

Przesyłanie danych obrazu

Inicjalizacja wyświetlacza jest wykonywana tylko raz, więc w naszych amatorskich zastosowaniach jej optymalizacja może być mniej istotna. Warto natomiast zrozumieć jak wygląda przesyłanie obrazu. Do tego celu wykorzystywane są trzy komendy: CASET (0x2a), RASET (0x2b) oraz RAMWR (0x2c).

Pierwsze dwie definiują wielkość okna, do którego będziemy zapisywać dane:

Gdy przesyłamy CASET podajemy dwa parametry (każdy 2-bajtowy), które ustalają współrzędne x początku i końca okna, RASET ustala współrzędne y. Ustalenie wielkości okna jest konieczne przed rozpoczęciem zapisu danych. Do zapisu używamy komendy RAMWR:

Po wysłaniu RAMWR możemy przesyłać już dane obrazu. Jak widzimy to nic specjalnego.

Dlaczego więc kod przykładowy działa tak wolno?

Teraz gdy wiemy już trochę więcej o działaniu ST7735S, możemy wrócić do kodu dostarczanego przez WaveShare. Na początek metoda LCD_ST7735S::LCD_SetWindows:

void LCD_ST7735S::LCD_SetWindows( POINT Xstart, POINT Ystart, POINT Xend, POINT Yend ){

	//set the X coordinates
	LCD_WriteReg ( 0x2A ); 				
	LCD_WriteData_8Bit ( 0x00 );						//Set the horizontal starting point to the high octet
	LCD_WriteData_8Bit ( (Xstart & 0xff) + sLCD_DIS.LCD_X_Adjust);			//Set the horizontal starting point to the low octet
	LCD_WriteData_8Bit ( 0x00 );				//Set the horizontal end to the high octet
	LCD_WriteData_8Bit ( (( Xend - 1 ) & 0xff) + sLCD_DIS.LCD_X_Adjust);	//Set the horizontal end to the low octet

	//set the Y coordinates
	LCD_WriteReg ( 0x2B );
	LCD_WriteData_8Bit ( 0x00 );
	LCD_WriteData_8Bit ( (Ystart & 0xff) + sLCD_DIS.LCD_Y_Adjust);
	LCD_WriteData_8Bit ( 0x00 );
	LCD_WriteData_8Bit ( ( (Yend - 1) & 0xff )+ sLCD_DIS.LCD_Y_Adjust);
		
	LCD_WriteReg(0x2C);		
}

Można oczywiście dyskutować, czy używanie "magicznych liczb" to elegancki sposób programowania, ale jak widzimy są tutaj wykonywane trzy, znane nam komendy: CASET, RASET oraz RAMWR. Więc po wywołaniu tej metody możemy już przesyłać dane obrazu (używając np. metody LCD_SetColor).

To brzmi całkiem nieźle, ale teraz zobaczmy implementację rysowania punktu:

void LCD_ST7735S::LCD_SetPointlColor ( POINT Xpoint, POINT Ypoint, COLOR Color ){	
	if ( ( Xpoint <= sLCD_DIS.LCD_Dis_Column ) && ( Ypoint <= sLCD_DIS.LCD_Dis_Page ) ){		
		LCD_SetCursor (Xpoint, Ypoint);		
		LCD_SetColor ( Color , 1 , 1);
	}
}

void LCD_ST7735S::LCD_SetCursor ( POINT Xpoint, POINT Ypoint ){
	LCD_SetWindows ( Xpoint, Ypoint, Xpoint , Ypoint );
}

Czyli chcąc narysować jeden punkt najpierw ustawiamy okna o wielkości 1x1, a następnie zapisujemy dwa bajty koloru. Czyli jak łatwo policzyć na jeden piksel przesyłamy 13 bajtów.

Pomijając niezbyt optymalny kod, to właśnie jest przyczyna tak strasznie powolnego rysowania. Każda linia, okręg, a nawet znak rysowane są jako punkty. A każdy z tych punktów wymaga aż 13 transmisji przez SPI (po których są jeszcze przerwy). To wszystko daje nam rysowanie demonstracyjnego ekranu w czasie ponad sekundy zamiast 40-90 ms.

Co ciekawe kasowanie obrazu jest wykonywane optymalniej - raz ustawiane jest okno na cały ekran, a następnie po prostu przesyłane są wszystkie dane. Dlatego zajmuje to 96, a nie 1000 ms.

Podsumowanie

Mam nadzieję, że w tej części udało mi się pokazać dlaczego sterowanie wyświetlaczem działa wolniej niż moglibyśmy tego oczekiwać. Okazuje się, że kod dostarczany przez producenta to raptem demo. Jeśli chcemy sensownie sterować wyświetlaczem, musimy napisać własny program.

Możliwości optymalizacji to między innymi:

ograniczenie odrysowywanego obszaru
zwiększenie prędkości komunikacji przez SPI (wyświetlacz obsługuje do 15MHz, wypadałoby również wyeliminować przerwy między wysyłanymi bajtami)
o wiele wydajniejsze jest jednoczesne odrysowywanie okna, rysowanie punktów działa strasznie wolno

Użyte rzez Waveshare rozwiazanie ma za to jedną, niezaprzeczalną zaletę - używa bardzo mało zasobów mikrokontrolera. Wszystkie dane obrazu są od razu wysyłane, więc za cenę prędkości ograniczyliśmy wykorzystanie pamięci.

W kolejnej części przetestuję działanie przykładów dla STM32 oraz pokażę jak można przyspieszyć rysowanie obrazu - chociaż już nie na Arduino Uno.

Spis treści:

26 stycznia

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:

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:

20 stycznia

Nikt w geodezji nie mierzy palcami. Przy okazji prośba do admina - o wywalenie tego offtopicu do kosza. To chyba nie ma nic wspólnego z tematem, ani PPF.

A żeby była jasność - GPS jest używany w geodezji i błąd pomiarowy rzędu milimetrów można uzyskać z tymi trzema palcami w ...

20 stycznia

1 minutę temu, ethanak napisał:

Zredukowano != wyeliminowano.

Oczywiście że nie wyeliminowano. Każdy pomiar jest obarczony błędem, nawet najdokładniejszy geodezyny. Błąd można więc tylko zredukować, nigdy wyeliminować.

20 stycznia

Błąd był celowy, gdy wprowadzano GPS do użycia, ale później wprowadzany błąd bardzo zredukowano.

Na bazie różnic między pomiarem dokładnym, a uzyskanym z GPS działa DGPS (https://pl.wikipedia.org/wiki/Różnicowy_GPS).

Niestety w przypadku tanich odbiorników nie liczyłbym na jakąkolwiek użyteczność rozwiązania opisywanego w artykule. Profesjonalne odbiorniki GPS to zupełnie inna półka - proponuję sprawdzić ich ceny, gdyby można było w takich zastosowaniach użyć popularnych odbiorników używanych np. w telefonach, czy nawigacjach samochodowych, już dawno firmy sprzedające urządzenia za dziesiątki tysięcy złotych musiałyby zmienić asortyment...

Tanie czytniki zwracają potworną wręcz ilość błędnych odczytów - nie jest to jedna i ta sama wartość, ale seria mocno losowych odczytów. To że wyniki wyświetlane w telefonie wyglądają sensownie, zawdzięczamy tylko odpowiednim algorytmom filtrującym oraz wykorzystaniem danych z wielu źródeł.

Ale jako ciekawostkę zachęcam do podłączenia taniego odbiornika GPS i pobrania danych NMEA - z tego co wiem, takie surowe dane nie przydadzą się właściwie do niczego.

15 stycznia

Bez problemu można i 16 grafik dotyczących gita przygotować

12 stycznia

Proponuję wyłączyć antywirusa i spróbować ponownie (https://forum.arduino.cc/index.php?topic=513525.0)

8 stycznia

W obsłudze przerwania masz wywołanie TIM_OC1Init, po pierwsze nie jestem pewien, czy zmienna channel jest poprawnie ustawiona, ale co ważniejsze Init służy do inicjalizacji - a z tego co rozumiem chciałeś tylko zmienić wypełnienie PWM. Do tego lepiej użyć TIM_SetCompare4.

8 stycznia

@aldenham Bardzo dobrze, że pytałeś i bardzo się cieszę że sprawa się wyjaśniła Po prostu skoro już wiemy, że problem nie dotyczył DMA można pytania wydzielić z tego tematu - to nic złego i mam nadzieję że admin bez problemu to załatwi.

Jeśli będziesz miał kolejne pytania odnośnie tablic, wskaźników i printf-ów, to też pytaj - na pewno pomożemy, w końcu po to jest Forbot.

Wracając do printf-ów, nie wiem jakie ostrzeżenia generował kompilator, mogło chodzić o użycie typów bez znaku i wtedy zamiast %d można zastosować %u. Ale możliwe, że ostrzeżenia dotyczyły użycia wskaźników w miejscu gdzie powinny być liczby - więc jeśli ten problem pojawi się przy poprawnym użyciu tablic, napisz co wyświetla kompilator i jaki dokładnie masz kod.

8 stycznia

Widzę, że kolega @miszczu18 wyprzedził mnie w tłumaczeniu o co chodziło w programie

Proponuję więc zostawienie DMA na chwilę w spokoju i powtórkę z działania tablic oraz wskaźników w języku C - bez tego raczej ciężko będzie napisać właściwie jakikolwiek program.

Natomiast od administratora mam prośbę o wydzielenie tej dyskusji do oddzielnego tematu, dotyczy ona podstaw C i nie ma nic wspólnego z DMA, ani kursem STM32.

7 stycznia

Przyznam, że nic nie zrozumiałem - bufory mają i powinny mieć inne adresy, to co wstawiasz wygląda właśnie na adres bufora źródłowego, bo 536873560 czyli 0x20000a58 to adres w pamięci SRAM. Co więcej 536873592 - 536873560 = 32, a tyle wynosi wielkość bufora źródłowego, więc możemy się domyślać że wyświetliłeś tutaj adresy buforów, a nie ich zawartość.

Funkcje copy_cpu/dma nie zmieniają adresów buforów, a jedynie kopiują dane. Więc adresy powinny być różne, ale ich zawartość identyczna.

7 stycznia

@aldenham piszesz, że wyniki są jednakowe, a chwilę później że różne. Mogłbyś nieco dokładniej opisać co masz na myśli?

6 stycznia

Taka uwaga z innego forum, ale chyba warta poprawienia - zmienna pinAlarmuPozycja nie jest resetowana do początkowej wartości, więc po wpisaniu poprawnego hasła, przy kolejnych próbach wystarczy wpisać tylko koniec pinu. Wypadałoby to poprawić i dodać pinAlarmuPozycja=1 w odpowiednich miejscach, żeby nikt nie pisał o błędach w kursach Forbot-a

2 stycznia

Wygląda na to, że po prostu nie zainstalowałeś sterownika. Plik .7z to archiwum, podobnie jak .zip, albo .rar. Drugi błąd to informacja, że nie masz programu do rozpakowania tego archiwum - możesz pobrać i zainstalować darmowy: https://www.7-zip.org/7z.html

Jak rozpakujesz .7z i zainstalujesz sterownik to powinno działać.

2 stycznia

@hantercv spróbuj podłączyć sam konwerter usb-uart do komputera i sprawdź, czy Windows poprawnie go wykrywa. Jeśli nie to nie ma sensu podłączać malinki, najpierw musisz mieć wirtualny port COM, a na zdjęciu wygląda na problem ze sterownikami.

Jeśli windows nie wykrywa konwertera, to najlepiej spróbować z innym komputerem - możliwe że jest to uszkodzony układ, ale w 99% przypadków problem jest po stronie oprogramowania.

Zaloguj się »

Elvis

Zawartość

Rejestracja

Ostatnio

Wygrane dni

Typ zawartości

Fora

Posty napisane przez Elvis

Sztuczne serce - porozmawiajmy... 💓

Sztuczne serce - porozmawiajmy... 💓

Odzyskanie stanu zmiennej po resecie

Odzyskanie stanu zmiennej po resecie

Karta graficzna błąd 43

Sterowanie wyświetlaczem TFT - część 5

Sterowanie wyświetlaczem TFT - część 3

Sterowanie wyświetlaczem TFT - część 4

Sterowanie wyświetlaczem TFT - część 3

Sterowanie wyświetlaczem TFT - część 2

Sterowanie wyświetlaczem TFT - część 2

Sterowanie wyświetlaczem TFT - część 1

Zestaw małego geodety DIY – pomiar odległości dzięki GPS

Zestaw małego geodety DIY – pomiar odległości dzięki GPS

Zestaw małego geodety DIY – pomiar odległości dzięki GPS

Konkurs na artykuł o elektronice – w puli nagród 2300 zł

O co z tym chodzi? Błąd kompilacji

Problem z przebiegiem PWM w STM32

Problem ze zrozumieniem operacji na tablicach i wskaźników (STM32 DMA)

Problem ze zrozumieniem operacji na tablicach i wskaźników (STM32 DMA)

Problem ze zrozumieniem operacji na tablicach i wskaźników (STM32 DMA)

Problem ze zrozumieniem operacji na tablicach i wskaźników (STM32 DMA)

Kurs Arduino II - #5 - klawiatura, własny system alarmowy

Kurs Raspberry Pi - #5 - instalacja/komunikacja przez UART

Kurs Raspberry Pi - #5 - instalacja/komunikacja przez UART

Menu

Więcej

Ta strona korzysta z plików cookies!