STM32U5G9J-DK2 LCD 5'' - ciekawy zestaw od ST

[virtualny]

Witam, 

Dzisiaj mały ogląd jednego z nowszych zestawów od ST 

STM32U5G9J-DK2

Ten zestaw zauważyłem w wątku:

jlink-gdb-rust-vscode-docker-cmake-rtt-cubemx-touchgfx-zewnetrzny-flash

Zestaw może mnie nie porwał, ale zaintrygował na tyle, że go nabyłem.

Co jest w zestawie wyjątkowego:

• LCD 5'' 
• Procesor CM-33 32bit 160MHz z:

1. internal flash 4MB
2. internal RAM 3MB !

Szczerze podziwiam, ile ST potrafi upchnąć do jednego chipa 👍

Garść informacji o zestawie i procku:

• 2.5D and vector graphics, (NEO-CHROM)
• JPEG codec,
• LTDC,
• MIPI®DSI,
• 160 MHz ULP Cortex®-M33 MCU,
• 4 MB flash,
• 3 MB SRAM,
• crypto

 

• LCD 5'' 800x480 px 60Hz
• ST-Link V3EC
• 128MB external OCTO-SPI flash max 133MHz

To tak w skrócie. Poniżej fotki z unboxingu i teardown

• TOP

• BOTTOM

• TOP TEARDOWN

• MCU

• ST-LINK V3EC

• ST-LINK V3EC MCU

 

Praktycznie nic nie wiem o GPU unit zawartym w procesorze, nazywanym NEO-CHROM , poza tym że obrabiana grafika czy odtwarzany film/efekt pozostawia procesor nieobciążony i wyrabia się z renderowaniem grafiki w czasie rzeczywistym 60FPS. Równie imponujące jest firmowe demo osadzone w zestawie zaczynając od (reverse zoom) pierwszego efektu po uruchomieniu - totalny czad:

 

Z rzeczy unikalnych jest LCD 5 cali i jest to naprawdę widoczna różnica do ekranów 4 calowych używanych w zestawach discovery ST.

To co jest także wyjątkowe w tym zestawie, to że w samym MCU jest osadzone 3MB RAM'u, co pozwala na umieszczenie frame buffora w internal RAM, bez konieczności montowania zewnętrznego RAM'u. Jest to z punktu widzenia projektantów wielkie ułatwienie i uproszczenie projektu discovery. Dość wspomnieć, że w ten zestaw jest zaprojektowany na (TYLKO!) 4 warstwowej PCB, gdzie w innych discovery kit minimalną normą jest PCB 8 warstw.

Framebuffor oparty na wewnętrznym RAM jest dość specyficzny, do czego trzeba posłużyć się prostą matematyką. A więc gdyby korzystać z trybu ARGB8888, daje to 4 bajty na 1 piksel, a całościowo: 800 * 480 * 4 = 1 536 000 bajtów, czyli 1 500 KB, co jest niespełna 1536KB czyli niecałe 1.5 MB.

Stąd wniosek, że nie da się w trybie ARGB8888 osadzić dwóch framebufforów, ponieważ w takim przypadku nie zostałoby miejsca na zmienne, stos i stertę. Za to bez problemów można działać w trybie single buffer z ARGB8888. Gdyby zmienić tryb LCD na RGB565, wówczas jeden piksel zajmie 2 bajty, co prosto pokazuje że wielkość framebuffora będzie dokładnie równa połowie bufora ARGB8888. Zatem 2 bufory zajmą 1500KB i w tym przypadku zostanie ponad połowa RAM'u na zmienne, stos i stertę, co jest zazwyczaj więcej niż wystarczające.

 

W tym miejscu jestem winien kilku hołdów dla ST:

• Chyba każdy zestaw DISCOVERY  z LCD jest oparty na wewnętrznie skonstruowanym interfejsie LTDC , co jest niebywałym ułatwieniem i pozwala na przenoszenie kodu praktycznie bez zmian, lub ze zmianami kosmetycznymi. Jeszcze trochę rozszerzając temat interfejs LTDC, jest tą warstwą wewnętrzną sprzętu, natomiast kolejną warstwą zewnętrzną sprzętu będzie interfejs zewnętrzny LCD, który na przykład może być oparty na MIPI@DSI, czy RGB, niemniej w pierwszej kolejności pośredniczy pomiędzy aplikacją i sprzętem interfejs LTDC.
• Dokumentacja RM+DS jest napisana wyczerpująco i w miarę przystępnie.
• Interfejs LTDC jest bardzo dobrze zaprojektowany.

Kolejne kamienie milowe od ST dla użytkownika, które należy docenić to:

• Niebywałe wsparcie programistyczne w każdym aspekcie
• ST stworzyło swój własny framework do:

1. projektowania graficznego STM32CubeMX z wieloma osadzonymi bibliotekami
2. programowania w środowisku przeznaczonym specjalnie dla STM32 (STM32CubeIDE)
3. własny framework do osadzania projektów graficznych TouchGFX - ST wykupiło w tym celu duńską firmę programistyczną i przekierowało profil na grafikę dla STM32
4. Inne frameworki dla wszelakich innych opcji programowania STM32 np. w innym IDE jak Visual Studio Code (choćby 

   STM32CubeCLT).

• ST udostępna kody źródłowe swoich dem do sprzedawanych zestawów

• Wszelaki hardware zamontowany w zestawie zostaje wyczerpująco oprogramowany i kod źródłowy jest udostępniony.

• Chociażby skrypty linkera zostały często wydane w dwóch wersjach, jedna do standardowego uruchamiania z flash, druga do kompilowania programów w RAM

• Dla zestawów są dostępne dema dla określonych grup użytego hardware'u jak np. LTDC, audio codec, XIP, slider itd.

• Darmowe kursy online
• Community forum

Jest jeszcze jedna rzecz, za którą kocham ST - to jest właśnie różnorodność projektów hardware i stworzenie do tego projektu rozległego i wyczerpującego software. Chodzi mi o to, że nie jest to tylko elektroniczny scrap, ale dzięki wsparciu jest to oprogramowany, działający produkt. Jako tą różnorodność mam na myśli na przykład:

• STM32F429i discovery kit, który ma dodany zewnętrzny Static RAM na framebuffer (na interfejsie LTDC) dla LCD 2.8'' ze sterownikiem ILI9341
• STM32F746G-DISCO, który ma zewnętrzny DRAM dla LCD opartego na Rocktech'u, także tutaj framebuffer na LTDC 4.3'' 480x272 px 60Hz
• STM32U5G9J-DK2 - dzisiejszy zestaw, który framebuffer ma umieszczony w internal Static RAM, również na LTDC 5'' 800x480 px 60Hz
• STM32H7S78-DK, zestaw który ma  zewnętrzny 32MB Hexadeca-SPI PSRAM (pseudo static RAM), gdzie można mapować framebuffer oczywiście na LTDC
• STM32H747i-DISCO, dual core z external 32MB SDRAM. Framebuffer LTDC, wyjście na DSI LCD 4'' 800x480 px 35 HZ
• STM32H750-DK, DISCO z 16MB external SDRAM. Framebuffer LTDC, wyjście RGB 4.3'' 480x272 px 60Hz
• STM32H735-DK, 16MB OCTOSPI  HyperRAM^TM  Framebuffer LTDC, wyjście RGB 4.3'' 480x272 px 60Hz

Natomiast jako WSPARCIE mam na myśli to, że do wszystkich powyżej wymienionych jak i bardzo wielu niewymienionych zestawów udostępnione są TONY, dosłownie TONY działającego oprogramowania. Po kilkanaście - kilkadziesiąt pakietów z przykładami dla każdego typu zestawu, dokumentacje, schematy, noty aplikacyjne... Także co bardzo ważne i żeby było łatwiej, każdy zestaw ma bibliotekę nazwaną BSP (Board Support Package), która zawiera szeroki wachlarz funkcji konfigurujących dla danego zestawu.

Moim zajęciem przy każdym zestawie jest  oprogramowanie LCD, aby można było na nim stawiać własnego piksela.

Ustaliłem, że:

• RAM zaczyna się od adresu 0x2000000 i ciągnie się do 0x202F0000 (3008 KB)
• Framebuffer jest mapowany od 0x200C0000
• W trybie ARGB8888 LCD jest odświeżany 60Hz, a w trybie RGB565 58Hz
• Drugi framebuffer w trybie RGB565 może zaczynać się od 0x2017B800 i kończyć na 0x20237000
• Od początku RAM do pierwszego framebuffora jest dostępnego RAM 768 KB
• Od końca drugiego framebuffora do końca RAM pozostaje 740 KB wolnego RAM

 

ST mnie nie zawiodło, do moich prób ze stawianiem pikseli wystarczył dla mnie do zainicjowania LCD firmowy przykład z pakietu "Board Examples" nazwany BSP.

Na wszystkich wcześniejszych wymienionych zestawach stawiałem ploty w trybie ARGB8888. Aby w tym zestawie działać w trybie RGB565 musiałem dostosować raptem kilka linii kodu, ponieważ kolor jest reprezentowany przez 16 bitów bez składowej "A" musiałem zamienić:

// --- CLEAR OLD PLOTS IN THE 2ND BUFFER WHICH IS INVISIBLE ---
for(i = 0; i < pl02_calc ; i++) {*( uint16_t*) (plots02[i]) = (uint16_t) 0x0000;}
//	zamiast
for(i = 0; i < pl02_calc ; i++) {*( uint32_t*) (plots02[i]) = (uint32_t) 0xFF000000;}

// store plots values in first buffer
for(i = 0; i < pl02_calc ; i++) {*( uint16_t*) (plots02[i]) = (uint16_t) 0xFFFF;}
//	zamiast
for(i = 0; i < pl02_calc ; i++) {*( uint32_t*) (plots02[i]) = (uint32_t) 0xFFFFFFFF;}

także należało zmienić procedurę obliczania adresu plota we framebufforze:

//        plots01[pl01_calc] = (FRAME_ADDRESS + (2*((helper_y * screen_X)+ helper_x ))) ;
plots01[pl01_calc] = (FRAME_ADDRESS + (((helper_y * screen_X)+ helper_x ) << 1)) ;
//	zamiast
//        plots01[pl01_calc] = (FRAME_ADDRESS + (4*((helper_y * screen_X)+ helper_x ))) ;
plots01[pl01_calc] = (FRAME_ADDRESS + (((helper_y * screen_X)+ helper_x ) << 2)) ;

 

Do pełni szczęścia musiałem dokonać zmiany kilku definicji niezbędnych do skonfigurowania vectordotów jak:

//======================================
#define FRAME_ADDRESS   ((uint32_t)0x200C0000)
#define FRAME_2_ADDRESS ((uint32_t)0x2017B800)
//======================================
#define screen_X 800
#define screen_Y 480
//======================================

 

I tylko tyle wystarczyło, żeby vectordoty bezbłędnie odpaliły się na moim nowym zestawie:

 

 

 

 

Binki i hex zamieściłem na githubie. Zarówno do vectordotów, jak i do odtworzenia firmowego dema.

STM32U5G9J DK2 VECTORDOTS