MiniConsole V3

[MR1979]

3 godziny temu, Gieneq napisał:

Robiłeś coś np z Cache albo MPU? Masz pomysł użyć Cache żeby przyspieszyć działanie? 

Tak cache używam cały czas. Jedynie przy korzystaniu z DMA trzeba uważać aby bufory danych trzymać w części pamięci która nie jest cachowana.

Cache dla danego obszaru pamięci wyłączasz konfigurując odpowiednio MPU. Następnie w skrypcie linkera definiujesz sekcje pamięci oraz przyporządkowujesz ją dla bufora korzystając z parametru __attribute__((section(".nazwa"))). Przykład:

/* RAM D3 - not cached memory */
  .ram_d3 :
  {
  	*(.ram_d3)
  } >RAM_D3

 

#define RAM_D3	__attribute__((section(".ram_d3")))

RAM_D3 IMU_HandleTypeDef BSP_himu = {0};

STM32H7 ma jeszcze jednego "asa w rękawie" Są to wydzielone pamięci DTCMRAM i IDCMRAM. Służą one do przechowywania danych oraz instrukcji dla funkcji o najwyższym priorytecie. Dzięki bezpośredniemu i niezależnemu połączeniu z rdzeniem, procesor ma zawsze natychmiastowy i bezzwłoczny dostęp do danych które tam umieścisz. Jeszcze nie korzystałem, ale zamierzam tam wrzucić funkcje obsługi przerwań, oraz struktury przechowujące stan peryferiów (np LCD, Pane dotykowy, IMU).

3 godziny temu, Gieneq napisał:

Będziesz używać ChromArt do akceleracji renderowania?

Tak, używam ChromeArt, czyli DMA2D do akceleracji grafiki. Np demko które widzisz w moim poprzednim poście działa 200FPS w trybie ARGB oraz 250FPS w trybie AL z tablicą CLUT. Oczywiście nie wszystkie klatki są wyświetlane bo LCD ustawiłem na 30Hz.

3 godziny temu, Gieneq napisał:

Jak wygląda dodanie USB z niskiego poziomu?

Akurat dla USB skorzystałem z gotowej biblioteki TinyUSB. Są tam wbudowane drivery dla STM32H7.

3 godziny temu, Gieneq napisał:

Możesz napisać trochę więcej jak piszesz własne drivery? H7 są dość skomplikowane.

Tak. Ponad 3500 stron Reference Manual A do tego dodatkowe noty i manuale. Jest co czytać

U mnie struktura pakietu BSP wygląda następująco:
 

/Projekt
|-BSP // Główne pliki BSP oraz biblioteki wyższego poziomu dla poszczególnych skłądowych pakietu
|	/Components 	// Niskopoziomowe drivery do poszczególnych układów np SDRAM, IMU, QSPI, SDRAM itd
|	/Libs			// Własne biblioteki wyższego poziomu np: grafika 2D, filtr kalmana
|	/STM32H7		// Tu oddzielne niskopoziomowe biblioteki do kazdego z peryferiów STM32H7
|-FATFS // Zaimportoana biblioteka FATFS
|-TINYUSB // Zaimportowana biblioteka tinyUB
|-CM7 // Subprojekt dla rdzenia CM7
|-CM4 // Subprojekt dla rdzenia CM4
|-Drivers
	/CMSIS // Biblioteki CMSIS dla ARM
  	/STM32 // Pozostałości biblioteki HAL z których wciąż jeszcze korzytam (do usunięcia)

Jak piszę drivery:
1. Mam oddzielny projekt gdzie prototypuję funkcjonalność z użyciem HAL
2. Na podstawie reverse engineering HALa oraz dokumentacji zastępuję poszczególne funkcje własnymi
3. W razie problemów robię telefonem zdjęcie rejestrów w działającym rozwiązaniu z HALem i porównuję z moją wersją. To pozwala szybko odnaleźć miejsce gdzie mgło się popełnić błąd w konfiguracji peryferium. Oczywiście trzeba to robić z głową i sprawdzać w dokumentacji co znaczą poszczególne bity.
4. Posiłkuję się też kodem pod podobne układy. Np teraz piszę driver do pamięci QSPI IS25LP128 i wzoruję się na driverze do pamięci innego producenta.
5. Polecam też gdzieś w głównym katalogu projektu pościągać sobie na dysk dokumentację wszystkich układów z których się korzysta. Dobrze jest mieć wszystko lokalnie w jednym miejscu.

Pozdr,
Marek

Edytowano Czerwiec 26, 2023 przez MR1979

[Gieneq]

@MR1979 wow, dziękuję za szczegółową odpowiedź  Fajnie że robisz to w tym sprzęcie. Ostatnio jak przy tym pracuję to widząc potencjał H7 teżpomyślałem żeby zbudować taką konsolkę. Tylko trochę mało czasu, ale w przyszłym roku powinno się udać.

Teraz widzę że pisałeś już o DMA2D. 

20 godzin temu, MR1979 napisał:

DTCMRAM i IDCMRAM

Ciekawe, jeszcze nie usiadłem do tego tematu. Pracuję z Azure RTOS, ciekawe czy możnaby przenieść fragmenty kodu żeby poprawić wydajność.

A jak masz skonfigurowany SDRAM? Coś w rodzaju FMC memory mapped, pod adresy ładujesz bitmapy z FLASHa/SD, dalej podwójny framebuffer i na tym operacje DMA2D?

20 godzin temu, MR1979 napisał:

pamięci QSPI IS25LP128

Piszesz też o karcie SD, jak mają ze sobą działać? Coś na zasadzie wgrywania gry z karty SD do FLASHa jako taka instalacja?

Poza tym ostatnio miałem w ręku evalboard z okrągłym wyświetlaczem i układem U5 z NeoChromArt do akceleracji rotacji. Super sprawa. Może wersja 4 konsolki na czymś takim  Zagadnąłem niedawno gościa z ST, do końca roku ma być wsparcie Azure RTOS dla układu MP1. To może też być ciekawa platforma do budowy konsolki  

[MR1979]

2 godziny temu, Gieneq napisał:

A jak masz skonfigurowany SDRAM? Coś w rodzaju FMC memory mapped, pod adresy ładujesz bitmapy z FLASHa/SD, dalej podwójny framebuffer i na tym operacje DMA2D?

32MB SDRAM połączone przez 32-bitową szynę danych na 120MHz. Blok pamięci zmapowany pod adresem 0xC0000000.

Co do buforów ramek to mogę ustawić podwójny lub potrójny. A tryb wyświetlania mogę zmieniać między: ARGB8888, RGB888, AL88m, L88. Mogę też aktywować jedną lub dwie warstwy. DMA2D używam do:
- wypełnienia zadanego obszaru
- kopiowania zadanych obszarów z jednej części pamięci do drugiej
- kopiowania zadanego obszaru + blending

Powyższe funkcje wykorzystuję w bibliotece graficznej wyższego poziomu.
 

3 godziny temu, Gieneq napisał:

Piszesz też o karcie SD, jak mają ze sobą działać? Coś na zasadzie wgrywania gry z karty SD do FLASHa jako taka instalacja?

Planuję coś takiego:
1. W pamięci flash uC będzie bootloader, program konfiguracyjny, funkcje obsługi wszystkich peryferiów (taki BIOS :))
2. W pamięci QSPI ma się znajdować aplikacja, którą będzie się wgrywać z karty SD za pomocą programu konfiguracyjnego
3. Mam zamiar uruchamiać główną aplikację bezpośrednio z QSPI (execute in place - XIP mode). Aplikacja ta będzie odwoływać się do funkcji które są zdefiniowane w pamięci flash uC. Zobaczymy czy w ogóle takie coś jest możliwe
4. SDRAM będzie służył do przechowywania zasobów aplikacji
5. Jądro CM4 będzie odpowiedzialne z dźwięk

Wczoraj udało mi się uruchomić pamięć QSPI w trybie memory-mapped (dostępny pod adresem 0x90000000). Na razie prototyp na HALu. Pamięć działa na 80MHz (max dla tego układu) w trybie DDR (przesył danych na obu zboczach zegara). Uruchomiłem protokół QPI (4 linie są wykorzystywane dla instrukcji, adresu oraz danych). Do tego stosuję tryb SIOO, czyli pomijanie powtarzanych instrukcji. Teoretyczna prędkość odczytu z pamięci flash to około ~76MB/s. Ale protokół komunikacji ma też narzut, więc rzeczywista prędkość przesyłu danych będzie niższa (pewnie coś koło 64MB/s)
Trochę się obawiam że to może być za wolno. Szkoda że mój STM32H7 nie wspiera OctoSPI. Spróbuję, przetestuję i będę myślał co dalej. H7 podczas uruchmiania aplikacji z QSPI wspomaga się pamięciom podręczną więc jest nadzieja.

3 godziny temu, Gieneq napisał:

Poza tym ostatnio miałem w ręku evalboard z okrągłym wyświetlaczem i układem U5 z NeoChromArt do akceleracji rotacji. Super sprawa. Może wersja 4 konsolki na czymś takim  Zagadnąłem niedawno gościa z ST, do końca roku ma być wsparcie Azure RTOS dla układu MP1. To może też być ciekawa platforma do budowy konsolki  

Tak. Czytałem o tym układzie. Ma akcelerator 2,5D. Czyli wspiera też proste funkcje do grafiki 3D. Jeżeli kiedyś się pojawi zaktualizowana wersja H7 z nową akceleracją to oczywiście rozpocznę pracę na kolejną wersją Dla mnie idealnie by było gdyby następca H7 zamiast FMC miał już kontroler pamięci DDR3 oraz włąśnie ten prosty akcelerator neoChromArt. No i jeszcze wbudowany PHY dla USB HS by się przydał

Co do RTOS to jeszcze mam małe doświadczenie.

Pozdr,
Marek

 

[MR1979]

Hej!

Wciąż pracuję nad projektem. BSP (Board Support Package) wciąż się rozwija. Od ostatniego postu dodałem:

1. Pełna obsługa pamięci QSPI w trybie QPI DDR przy 80MHz. Jest też memory mapping.
2. Konfiguracja i podstawowe funkcje interfejsu I2S. Mogę już odtwarzać pojedyncze sample z użyciem DMA.
3. Obsługa zegara czasu rzeczywistego wraz z podtrzymywaniem bateryjnym oraz funkcje zapisu/odczytu rejestrów backup
4. Sprzętowe dekodowanie JPEG i integracja z pozostałymi bibliotekami graficznymi
5. Dodałem do BSP także niezbędne funkcje do konfiguracji peryferiów: RCC, HSEM, PWR

HAL został już prawie całkowicie wykluczony z projektu. Aktualnie używam tylko do obsługi USART, który nie został jeszcze zaimplementowany w BSP.

Zaczynam też pisać grę wg pomysłu synka (lat 6 :)).

Poniżej krótki filmik z programem gdzie testuję poszczególne funkcje. Widać na nim obsługę JPEG (tło), RTC (zegar) oraz testową animacje postaci do gry. Demko w trybie ARGB pracuje w 60 fps.

 

PS. Sorki za słabą jakość dźwięku.

[MR1979]

Postępy z prac nad konsolką

Znudziły mi się już latające kuleczki na ekranie, a firmware jest już na tyle dojrzały że czas napisać pierwszą grę. Po konsultacjach z sześcioletnim szefem działu gier i zabaw wybór padł na platformówkę gdzie królik ma zbierać marchewki i unikać szkieletów.

Po miesiącu prac i licznych konsultacjach z synkiem efekt jest następujący:

 

Od razu napiszę że assety (grafika i animowane postacie) kupiłem w sieci. Znacznie to przyspieszyło tworzenie gry. Engine gry platformowej napisałem sam.

Aktualnie gra działa w rozdzielczości 800x480 w trybie ARGB1555. Są dwie warstwy tła z paralaksą oraz trzy warstwy kafelek z których złożone są mapy. Pojedyncza klatka generuje się w 17 do 20ms, co przy wymogu 30FPS zostawia jeszcze dużo czasu procesora na inne rzeczy. Muzyka odtwarza się z pliku mod i zajmuje się tym drugi rdzeń uC. Ogólnie to cały dźwięk to jeszcze prowizorka i ta część będzie napisana od nowa.

Zaimplementowane funkcje:
- Importowanie mapek z programu Tiled
- Importowanie Tilesetów
- Wyświetlanie tła z paralaksą
- Wyświetlanie kafelek z obsługą warstw
- Możliwość animacji wybranych kafelek
- Animowane postacie i obiekty
- Prosty silnik fizyki obiektów (grawitacja, kolizje, możliwość przepychania obiektów i ustawiania jednych na drugi)
- Animacje postaci
- Zbieranie wybranych obiektów
- Automatyczna optymalizacja wyświetlania mapy (np kafelki które nie mają przezroczystych pikseli są wyświetlane dużo szybciej bo DMA2D przełącza się w tryb bez miksowania z tłem).

Do zrobienia:
- Na razie brak AI przeciwników, dlatego postacie są nieruchome
- Dźwięk i muzyka do napisania od nowa. Docelowo drugi rdzeń ma funkcjonować jako karta muzyczna. Wciąż jeszcze nie mam koncepcji jak to ogarnąć
- Menu, więcej map, punkty, itd itp...
 

Pozdrawiam,
Marek
 

 

Edytowano Październik 25, 2023 przez MR1979

[Gieneq]

@MR1979 brawo! Rewelacja 

[Misiek_86]

Mega projekt, gratulacje

[MR1979]

Raport z prac:

Wizualnie i funkcjonalnie niewiele się zmieniło. Wciąż ta sama gra, a BSP nie ma żadnych nowych funkcji.

Udało mi się natomiast przenieść aplikację (grę) na pamięć QSPI, skąd jest bezpośrednio uruchamiana.
Gra korzysta z funkcji które znajdują się w firmware zapisanym w wewnętrznej pamięci flash uC.

Oto co daje takie rozwiązanie:

- Rozdzielenie firmware (obsługa sprzętu, drivery, podstawowe biblioteki) od aplikacji (np gra).

- Pamięć flash qspi można zapisywać setki tysięcy razy

- W przyszłości firmware będzie zawierać bootloader oraz menu do wyboru aplikacji oraz konfiguracji konsolki. Zmiana aplikacji będzie polegać na wgraniu nowego wsadu do pamięci QSPI konsolki.

 

Aby to wszystko było możliwe musiałem napisać tzw. "external loader" (nie wiem jak to po polsku) który mogę załadować do CubeIDE oraz CubeProgrammer. Jest to mały programik ładowany do pamięci RAM uC w momencie aktualizacji oprogramowania przez złącze SWLink. Pośredniczy on w komunikacji między komputerem a dowolną zewnętrzną pamięcią podłączoną do kontrolera. W moim przypadku pozwala na dostęp do pamięci QSPI z poziomu CubeIDE lub CubeProgrammer.

Tu instrukcja z której korzystałem: https://www.st.com/content/st_com/en/support/learning/stm32-education/stm32-moocs/external_QSPI_loader.html

 

W pliku konfiguracyjnym linkera dodałem sekcję pamięci QSPI oraz zdefiniowałem nowy region dla aplikacji .qspi zaczynający się od adresu 0x90000000 i rozmiarze 16MB. Przed wystartowaniem aplikacji należy jeszcze skonfigurować MPU (Memory Protection Unit) dla nowego reginu pamięci oraz zainicjować pamięć QSPI w trybie memory mapped.

 

Wszystkie funkcje które są częścią aplikacji (gry) przeniosłem do nowo utworzonego regionu za pomocą __attribute__((section(".qspi"))).

 

Najbardziej obawiałem się spadku wydajności całego systemu co doprowadziłoby np do spadku wyświetlanej liczby klatek. Okazało się że nie ma tragedii i czas potrzebny na render pojedynczej klatki pozostał bez zmian. To oczywiście zasługa cache uC. Sama pamięć QSPI działa w trybie QPI z transmisją DDR przy zegarze 80MHz. To max na co pozwalał zastosowany przeze mnie układ. Dodatkowo uaktywniłem funkcję SIOO która pozwala na wysyłanie pola instrukcji tylko podczas pierwszego połączenia. Pozwala to dodatkowo zaoszczędzić trochę na transferze.

Pozdrawiam,
Marek

[Treker (Damian Szymański)]

@MR1979 świetna robota, miło się czyta takie worklogi!

[Gieneq]

Dnia 3.11.2023 o 20:26, MR1979 napisał:

Najbardziej obawiałem się spadku wydajności całego systemu co doprowadziłoby np do spadku wyświetlanej liczby klatek. Okazało się że nie ma tragedii i czas potrzebny na render pojedynczej klatki pozostał bez zmian. To oczywiście zasługa cache uC.

@MR1979 super aktualizacja  a mógłbyś napisać coś więcej jak to obsługujesz?

[MR1979]

12 minut temu, Gieneq napisał:

@MR1979 super aktualizacja  a mógłbyś napisać coś więcej jak to obsługujesz?

Możesz bardziej sprecyzować pytanie?

[MR1979]

Witam!

Postępy z prac:

1. Firmware konsolki:

Zmieniłem organizację pamięci. Od nowa skonfigurowałem MPU (memory protection unit) oraz zmieniłem skrypty linkera. Uwzględniłem też ochronę pamięci, tak aby po przełączeniu w tryb "unprivileged" aplikacja ograniczony dostęp do zasobów konsolki. W niedługim czasie mam zamiar rozdzielić całkowicie kod firmware oraz kodu aplikacji. Docelowo aplikacje będą niezależnym projektem. Jeszcze nie zdecydowałem jak aplikacja będzie wywoływać funkcje konsolki z firmware. Są dwie opcje:

- Przez przerwanie SVC z odpowiednimi parametrami. Jest to trudniejsza metoda ale pozwala na funkcjonowanie aplikacji z mniejszym poziomem dostępu i pełną kontrolę nad dostępem do zasobów
- Przez tablicę wektorów do wybranych funkcji z firmware. Jest to opcja łatwiejsza ale wtedy aplikacje działają z pełnym dostępem do zasobów konsolki

Poza tym jak zwykle poprawiłem kilka błędów które ujawniły się podczas prac nad grą.

Mapa pamięci konsolki:

Konfiguracja regionów MPU dla rdzenia CM7 i CM4:

 

2. Gra:

Rozbudowałem grę o następujące funkcjonalności:

- Nowy rozbudowany tileset mapy
- Przeciwnicy się poruszają oraz atakują. Są sterowani przez proste AI
- Możliwość niszczenia przeciwników przez skoczenie na nich
- Możliwość latania w bańce mydlanej
- Dodałem płomienie oraz kolce jako przeszkody
- Kolekcjonowanie przedmiotów
- Interakcje z przedmiotami (np trzeba zebrać klucz aby otworzyć skrzynkę)

Filmik z aktualnej wersji gry:

 

To tyle na dziś, pozdrawiam.

[H1M4W4R1]

13 minut temu, MR1979 napisał:

Rozbudowałem grę

Te telepanie na moście Aż oczy bolą... Przydałby się jakiś algorytm do wygładzenia ruchu (osobiście prawdopodobnie zrobiłbym to predykcyjnie - jeżeli w następnym cyklu fizycznym zajączek jest w odległości zbliżonej do aktualnej (przed przesunięciem wynikającym z grawitacji) oraz zbliżonej do poprzedniej, to uznaje to za gładką przestrzeń, mimo iż pod spodem jest malutka szpara, w którą powinien wpaść. Najmniej skomplikowane obliczeniowo

[MR1979]

12 godzin temu, H1M4W4R1 napisał:

Te telepanie na moście Aż oczy bolą... Przydałby się jakiś algorytm do wygładzenia ruchu (osobiście prawdopodobnie zrobiłbym to predykcyjnie - jeżeli w następnym cyklu fizycznym zajączek jest w odległości zbliżonej do aktualnej (przed przesunięciem wynikającym z grawitacji) oraz zbliżonej do poprzedniej, to uznaje to za gładką przestrzeń, mimo iż pod spodem jest malutka szpara, w którą powinien wpaść. Najmniej skomplikowane obliczeniowo

Jestem świadom tego problemu. Planuję jedną z dwóch opcji: importowanie wielokątów opisujących obszar kolizji dla każdego kafelka, albo zastosowanie maski w postaci bitmapy opisującej obszary kolizji. Wielokąty mogę łatwo stworzyć w programie Tiled (korzystam z niego do projektowania map). Bitmapy mogę stworzyć dowolnym programie graficznym.

Gdy uda mi się wydzielić kod gry do oddzielnego projektu to zaimplementuję któreś z tych rozwiązań.

[MR1979]

Noworoczny update z prac nad konsolką:

Aktualnie opracowuję wizualną część firmware, w tym panel konfiguracyjny. Aktualnie ukończyłem:

• Panel testowania i konfiguracji klawiatury i joysticka. Joystick można kalibrować.
• Panel testowania i konfiguracji IMU (akcelerometr i żyroskop), także z opcją kalibracji.
• Panel ustawiania daty i czasu w zegarze RTC.
• Programowy restart i wyłącznie urządzenia
• Wszystkie ustawienia przechowywane w rejestrach backup RTC (pamięć podtrzymywana z baterii)
• Poprawione wiele błędów

Całość działa na bibliotece GUI mojego autorstwa

 

Poniżej filmik: