Kurs STM32L4 – #11 – kolorowy wyświetlacz TFT (SPI)

[Komentator]

Za nami podstawy pracy z SPI na STM32L4. Pora, aby zająć się obsługą wyświetlacza graficznego. Przy okazji poruszymy również temat stosu. Przejdziemy od omówienia sterownika ST7735S, przez liczne testy, optymalizację kodu i DMA, aż po wykorzystanie gotowej biblioteki graficznej.

UWAGA, to tylko wstęp! Dalsza część artykułu dostępna jest na blogu.

Przeczytaj całość »

Poniżej znajdują się komentarze powiązane z tym wpisem.

[Komentator]

Przypominamy: w komentarzach do kursów rozmawiamy wyłącznie na tematy związane z konkretnym kursem. Mile widziane są również informacje od osób, które korzystały wcześniej z naszych poradników. Wszystko po to, aby kursanci, którzy mają zamiar korzystać z tego kursu nie musieli "przedzierać" się przez dziesiątki postów na inne tematy. Tematy na pytanie, które nie są związane z kursem można zadawać na naszym forum o mikrokontrolerach.

[Treker (Damian Szymański)]

Zachęcam do lektury kolejnej części kursu, która chyba dość dobrze udowadnia, że świadoma praca z wyświetlaczami graficznymi to niełatwy temat. Osoby, które są zainteresowane jeszcze lepszym poznaniem tego tematu powinny zapoznać się również z tą serią poradników. Można tam znaleźć np. informacja o tym jak wykorzystać dwa bufory do tego, aby stworzyć jeszcze lepszy program.

PS załączam gotowy plik z logotypem w formie tablicy - może się przyda 😉 ➡ forbot_logo.zip

[Elvis]

To była faktycznie bardzo długa część, chyba najdłuższa w całym kursie - okazuje się, że kolorowe wyświetlacze wymagają nie tylko więcej pamięci, ale i dłuższego opisu 😉

Przy okazji ciekawostka jak chodzi o komunikację. Jak wspominaliśmy w tekście, wyświetlacz może odbierać dane z prędkością 15 Mbit/s, ale ponieważ mikrokontroler jest taktowany z 80 MHz, a dzielniki dla SPI są potęgami 2, więc użyliśmy dzielnika o wartości 8 i prędkość transmisji została ograniczona do 10 MBit/s. Jest to w zupełności wystarczające dla naszego wyświetlacza, ale czasami prędkość transmisji bywa bardzo ważnym parametrem i wówczas może się "opłacać" użyć niższej częstotliwości taktowania mikrokontrolera. Gdybyśmy zamiast 80 MHz użyli 60 MHz to moglibyśmy dla SPI użyć dzielnika o wartości 4, aby uzyskać prędkość transmisji równą 15MBit/s. Czyli zmniejszenie częstotliwości taktowania całego układu pozwoliłoby na uzyskanie wyższej prędkości transmisji danych (i to aż o 50%).

Kiedyś na forum pojawiło się pytanie, po co wybierać inną niż maksymalną prędkość taktowania - w kursie pokazaliśmy możliwości oszczędzania energii dzięki użyciu niższych częstotliwości, teraz warto więc wspomnieć, że czasem niższe taktowanie może umożliwić szybsze działanie modułów peryferyjnych - i nie dotyczy to wyłącznie SPI.

[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

[Gieneq]

Zainspirowała mnie ta część kursu, kiedyś przez 2 lata walczyłem z OpenGL pisząc własny silnik do gier. Pomyślałem, że popróbuję swoich sił i napisałem implementację Game of Life Conwoya 🙂 

Na pewno da się to zrobić lepiej, ale pomyślałem, że nie będę ruszał kodu biblioteki z kursu więc etap rysowania prosi się o wyrzucenie dużego bufora, implementację podwójnego buforowania, wyrzucenie kolorów, ale gra działa płynnie więc nie ma co się czepiać.

CGOL

Na czym polega tzw. Life nie będę pisał, zapraszam na wiki. Są tam wspomniane 4 reguły gry, które determinują czy komórka umrze, zachowa się, czy ożyje:

• jeżeli komórka żyje i ma 1 sąsiada, to umiera w samotności,
• jeżeli komórka żyje i ma 2 lub 3 sąsiadów, to żyje dalej,
• jeżeli komórka żyje i ma 4 lub więcej sąsiadów, to umiera z zatłoczenia,
• jeżeli komórka umarła i ma dokładnie 3 sąsiadów to ożyje.

4 proste reguły, a powstało na ten temat wiele prac i wciąż trwają poszukiwania nowych "form życia".

Reprezentacja danych

Zastanawiałem się jak zapisać strukturę danych. Nie dość, że każdy piksel musi być jakoś reprezentowany, to jeszcze muszą być 2 struktury, zamiennie używane, żeby w jednym cyklu można było odczytać niezmienione dane. Wpadłem więc na pomysł, żeby każdy bit danych reprezentował jedną komórkę:

#define CGOF_ARR_SIZE 640 // 160 * 128 / 32
static uint32_t cgof[CGOF_ARR_SIZE * 2];

Dodałem do tego funkcje ustawiające komórki i odczytujące. Stosuję tu operacje bitowe, uzyskując dostęp do konkretnych bitów z konkretnego indeksu tablicy:

typedef enum{
	DEAD,
	ALIVE
}cell_t;


cell_t cgol_getState(int x, int y) {
	if(x >= 0 && y >= 0 && x < LCD_WIDTH && y < LCD_HEIGHT)
		return (cgof[x + LCD_WIDTH*(y/32) + part*CGOF_ARR_SIZE] >> (y%32)) & 1;
	return DEAD;
}

void cgol_setState(int x, int y, cell_t s) {
	if(x >= 0 && y >= 0 && x < LCD_WIDTH && y < LCD_HEIGHT) {
		if(s == DEAD)
			cgof[x + LCD_WIDTH*(y/32) + part*CGOF_ARR_SIZE] &= ~(1<<(y%32));
		else
			cgof[x + LCD_WIDTH*(y/32) + part*CGOF_ARR_SIZE] |= (1<<(y%32));
	}
}

W działaniu wzorowałem się na przykładach z biblioteki hagl, można wyróżnić etapy:

• init,
• update,
• render.

Podobny szablon widziałem w silnikach gier więc nie ma tu co dyskutować 🙂

Inicjalizacja jest dość prosta: czyszczę ekran, kasuję dane w buforze. Zmienna part służy do wyboru, którą połową tablicy będę się interesował (z jednej połówki odczytuję, do drugiej zapisuję):

void cgol_init(){
	for(int iy = 0; iy < LCD_HEIGHT; ++iy){
		for(int ix = 0; ix < LCD_WIDTH; ++ix)
			lcd_put_pixel(ix, iy, 0);
	}
	for(int i = 0; i < CGOF_ARR_SIZE*2; ++i)
		cgof[i] = 0;
	part = 0;
}

Update jest nieco bardzie skomplikowany, ale nie ma tu nic zaskakującego - implementacja logiki gry:

void cgol_update() {
	int part_temp = part;

	for(int iy = 0; iy < LCD_HEIGHT; ++iy){
		for(int ix = 0; ix < LCD_WIDTH; ++ix){
			part = part_temp;
			cell_t midstate = cgol_getState(ix, iy);
			int livingcounts = 0;
			livingcounts -= midstate;

			for(int iky = -1; iky < 2; ++iky){
				for(int ikx = -1; ikx < 2; ++ikx){
					int xx = ix + ikx;
					int yy = iy + iky;
					if(cgol_getState(xx, yy) == ALIVE)
						++livingcounts;
					if(livingcounts > 3){
						iky = 3;
						break;
					}
				}
			}

			part ^= 1;
			if(midstate == ALIVE){
				if(livingcounts < 2)
					cgol_setState(ix, iy, DEAD);
				else if(livingcounts > 3)
					cgol_setState(ix, iy, DEAD);
				else
					cgol_setState(ix, iy, ALIVE);
			}

			if(midstate == DEAD){
				if(livingcounts == 3)
					cgol_setState(ix, iy, ALIVE);
				else
					cgol_setState(ix, iy, DEAD);
			}
		}
	}
}

Ustawiam zmienną na fragment tablicy do odczytu, sprawdzam stan komórki i jej 8 sąsiadów. Te podejrzane odejmowanie pozwala uniknąć brzydkiego ifa odrzucającego środkowy element. Następnie przy pomocy operacji XOR ( ^=1) zmieniam połówkę tablicy i zapisuję zaktualizowany stan komórki. Dzięki funkcji setState cała metodyka zapisu danych do bitu z jakiegoś tam indeksu tablicy jest ukryta.

Na koniec wspomniany render, który prosi się o modyfikację, bo jest to przepisanie prawie niezmienionych danych z tablicy do tablicy.

void cgol_render(){
	for(int iy = 0; iy < LCD_HEIGHT; ++iy){
		for(int ix = 0; ix < LCD_WIDTH; ++ix){
			lcd_put_pixel(ix,  iy, cgol_getState(ix, iy)*0xFFFF);
		}
	}
}

Można by tu skorzystać z metody opisanej w artykule elvisa o TFT, gdzie dane są wysyłane przy pomocy mniejszego bufora i palety kolorów. Zużycie pamięci na pewno znacznie by spadło, ale pomimo tych wad i tak działa dobrze.

Na koniec 2 funkcje do rysowania. Jedna przerysowuje predefiniowany kształt oraz umożliwia odbicie wzdłuż osi OX/OY lub obrót o wielokrotność 90*:

void cgol_place(const uint8_t* arr, int lifeform_width, int lifeform_height, int x, int y, int rot, int hflip, int vflip) {
	int xx, yy;

	for(int iy = 0; iy < lifeform_height; ++iy) {
		for(int ix = 0; ix < lifeform_width; ++ix) {
			xx = hflip>0 ? lifeform_width-ix-1 : ix;
			yy = vflip>0 ? lifeform_height-iy-1 : iy;

			if (rot%4 == 1) {
				xx = lifeform_width-xx-1;
				yy = lifeform_height-yy-1;
				cgol_setState(iy + x, ix + y, arr[xx + yy * lifeform_width]);
			} else if(rot%4 == 2) {
				xx = lifeform_width-xx-1;
				yy = lifeform_height-yy-1;
				cgol_setState(ix + x, iy + y, arr[xx + yy * lifeform_width]);
			} else if (rot%4 == 3)
				cgol_setState(iy + x, ix + y, arr[xx + yy * lifeform_width]);
			else
				cgol_setState(ix + x, iy + y, arr[xx + yy * lifeform_width]);
		}
	}
}

Użycie jest dość proste, musimy mieć tylko zdefiniowane tablice z kształtami:

  cgol_place(heart, heart_width, heart_height, 22, 42, 1, 0, 0); //obrócone o 90* w prawo

Druga służy do wygenerowania prostokąta składającego się z komórek o losowych wartościach:

void cgol_place_random_rect(int x, int y, int width, int height){
	for(int iy = 0; iy < height; ++iy){
		for(int ix = 0; ix < width; ++ix){
			HAL_RNG_GenerateRandomNumber(&hrng, &randResult);
			cgol_setState(x+ix, y+iy, randResult % 2 == 0 ? ALIVE : DEAD);
		}
	}
}

Prostokąt ten przydaje się do poszukiwać nowych form życia 👽 Funkcje te nie muszą być optymalne, są używane tylko przy generowaniu świata.

Main

W pliku main.c nie ma zbyt wiele treści. Najpierw wciągam pliki biblioteki, a później prosty szablon:

  /* USER CODE BEGIN WHILE */
  lcd_init();
  cgol_init();
  // add living stuff
  cgol_place(koks_galaxy, koks_galaxy_width, koks_galaxy_height, LCD_WIDTH/2-4, LCD_HEIGHT/2-4, 0, 0, 0);

  cgol_render();
  lcd_copy();

  HAL_Delay(1000);

  while (1)
  {
	  if(manual != 1){
		  cgol_update();
		  if(manual == 2)
			  manual = 1;
	  }
	  while (lcd_is_busy()) {}
	  cgol_render();
	  lcd_copy();

    /* USER CODE END WHILE */

Ten pierwszy render poza pętlą służy przedłużeniu wyświetlania początkowego układu sceny, a zmienna manual służy zatrzymaniu odtwarzaniu i przechodzeniu poklatkowo przy pomocy przycisku na płytce Nucleo. W powyższym kodzie tworze tylko jeden kształt galaktykę Koks'a.

Efekt

Naprawdę wciągającym zajęciem jest oglądanie co wyjdzie z losowo wybranych komórek. Od roku 1970 kiedy to wymyślono te grę powstało wiele skatalogowanych kształtów. Każdy ma swoją nazwę, jedne są bardziej intuicyjne jak np: statek, wanna, ul, bloczek. Inne trochę mniej... xp2_c813z39d1e8 

Na filmie pokazane jest przekształcenie kształtu przypominającego serce w 2 oscylatory (cyklicznie zmieniające się kształty) nazwane pulsarami:

A tu kilka przykładów tego co ustabilizowało się z losowo wybranych pikseli:

Bardzo popularne kształty, choć latarnia (ang. beacon) trafiła mi się dotąd tylko raz. Latarnia jest przykładem oscylatora - środkowy piksel przełącza się, tylko na zdjęciu tego nie widac. Mango tez jest rzadziej spotykane.

A tu mamy tratwę (piękna czyż nie?):

A tu mamy inne formy natury nieożywionej (ang. still life). Te dwa symetryczne to 2 połączone łódki (ang. ship-tie). A te połączone bochenki to... pół piekarni (ang. half bakery):

Pan John Conwoy i jego kumple mieli pewnie ubaw wymyślając nazwy, ale są one na pewno bardzo sugestywne i łatwe do zapamiętania 🙂 

To jeszcze na zakończenie film poklatkowy przedstawiający trochę różnych kształtów i demolkę przy użyciu działa szybowców (ang. glider gun). Szybowiec jest najpopularniejszym ruchomym "stworkiem" w tym świecie, jego kształt stał się symbolem tej gry.

 

W załączeniu pliki cgol.c i cgol.h biblioteki jakby ktoś chciał zgłębić ciekawy świat CGOLa 😄 

cgol.zip

 

Edytowano Czerwiec 9, 2021 przez Gieneq

[ethanak]

Ja powiem tak: mój Nucleo leży sobie od miesiąca jeszcze nie rozpakowany (chociaż staram się przynajmniej poczytać sobie co tam jest ciekawego, ale czas...).

Na razie jak dla mnie najciekawszy odcinek - jestem w miarę świeżo po napisaniu swojego drivera ILI9341 na RPi Pico (nawet fajnie wyszedł, animowane ikonki i takie tam pierdołki), ale mimo że 95% materiału znam, nawet te 5% to coś, co jest warte uwagi, czego się mogę nauczyć i co może w przyszłości zaowocować skonstruowaniem rzeczywistego urządzenia.

Dawaj dalej, @Elvis - czekam na jakiś porządny driver I2S!

Tak przy okazji: mój program wymaga min. 4 MB FLASH (fajnie by było mieć 8), RAM nie jest tu tak istotny (myślę, że nawet w 64 kB bym się zmieścił). Cena gra krytyczną rolę. Coś z gotowych płytek poradzicie czy jestem skazany na ESP32? Lolin32 to ok. 30 PLN... a oprócz jednego drobiazgu (bez podpinania się pod piny gniazda USB nie mogę stwierdzić czy akumulator jest ładowany) wszystko pięknie działa 😞

 

[Elvis]

@ethanak O dźwięku i i2s pisałem jakiś czas temu: https://forbot.pl/blog/co-warto-wiedziec-o-odtwarzaniu-dzwiekow-na-stm32-id43313 ogólnie sama obsługa i2s jest bajecznie prosta, ale już konfiguracja samego przetwornika niekoniecznie. Zdarzają się bardzo proste układy, gdzie wystarczy wysłać dane i gra muzyka, ale niektóre jak chociażby WM8994 są chyba trudniejsze w obsłudze niż opisywany tutaj sterownik wyświetlacza.

Natomiast co do flash-a to można bez problemu podłączyć ile potrzeba do STM32L476, jedyny problem to jak samo podłączenie wykonać, bo na płytce stykowej komunikacja przy wyższych prędkościach bywa niestety awaryjna.

Edytowano Czerwiec 9, 2021 przez Elvis

[Toomas]

Czekałem na tę część i się nie zawiodłem. @Elvis dobra robota, jeszcze nie zdążyłem przetestować wszystkiego w praktyce, ale przeczytałem artykuł z zaciekawieniem. Świetny pomysł, aby opisać kolejne korki, zamiast dawania gotowca! Tematyka trudna, ale przedstawiona w ciekawy sposób :)

[Treker (Damian Szymański)]

@Toomas miło słyszeć, że odcinek Ci się spodobał 🙂

Przy okazji zachęcam do lektury kolejnej części kursu, która została właśnie opublikowana: Kurs STM32L4 – #12 – zewnętrzna pamięć EEPROM (I2C)

[padus]

Bardzo fajny kawałek kursu. Utworzenie własnej biblioteki krok po kroku, no i wykorzystanie innej z własnymi funkcjami - super sprawa. 

[Frantick]

Pytanko po za konkursem, ma ktos moze pomysl jak konwertowac int'y na wchar_t, tak zeby mozna bylo sobie uzyc zmiennej razem z hagl_put_text?

Moje poszukiwania w necie nie wiele przyniosly bo ludzie glownie polecaja uzyc jakis specjalnych wersji printf() do wyswietlania napisow a nie o to mi chodzi. Najbardziej obiecujace znalezisko funkcje itow() badz _itow_s() nie sa zaimplementowane, a przynajmniej tak mi sie wydaje bo nie widze ich w stdlib.h a np. itoa() dla "zwyklych stringow" jest i smiga az milo.

Na koniec chcialem ponownie pogratulowac autorom swietnego odcinka kursu.

[ethanak]

Najprościej: znaleźć kod źródłowy itow (np. pytając o "itow source"), a następnie skopiować ów kod do swojego programu.

 

Edytowano Lipiec 17, 2021 przez Treker
PPF

[Elvis]

@Frantick Najprościej jest użyć wsprintf.

[Leroy]

Cześć 🖐️, w czasie przerabiania kursu natrafiłem na pewien problem.  Funkcja lcd_copy() z HAL_SPI_Transmit() działa poprawnie. Niestety po zmianie na HAL_SPI_Transmit_DMA() pojawił się problem. Na ekranie widzę jedynie kolorowe piksele (inicjalizację wyświetlacza), nie wyświetla się napis "Hello World!". W debuggerze ustawiłem breakpoint w funkcji HAL_SPI_TxCpltCallback(), lecz program nie zatrzymał się w tym miejscu. Dodałem również funkcję HAL_SPI_ErrorCallback() z breakpointem w środku, aby złapać ewentualny błąd - tutaj również program nie dotarł. Zmieniłem z ciekawości na opcję z przerwaniami HAL_SPI_Transmit_IT() - działała bez zarzutu i wywoływała przerwanie informujące o zakończeniu transmisji, które nie było wywoływane przez DMA. Szukając rozwiązania zmieniłem również priorytet przerwania od DMA z 0 na 2 (SysTick ma priorytet 0). W zakładce DMA Settings przy konfiguracji SPI2 zmieniłem Priority z Low na Very High - także bez rezultatu. Czy ktoś z Was spotkał się z czymś takim? Macie może pomysł co może być przyczyną problemu na podstawie tego, co opisałem? Będę wdzięczny za pomoc🙂 

[Leroy]

Problem już rozwiązany 💪 Zresetowałem konfigurację SPI2 w CubeMX, aby na nowo wygenerować kod, ale nic to nie dało. Zmieniłem więc na SPI3 i tam transmisja z DMA zadziałała i został wywołany callback. Po udanej transmisji z wykorzystaniem DMA wyłączyłem SPI3 i ponownie włączyłem SPI2 + DMA i grafika wyświetliła się na ekranie. Najwyraźniej był to problem z konfiguracją po stronie CubeMX, bo kod był w porządku😉 "Reset" polegający na odpaleniu innego SPI jakoś załatwił sprawę🙂