MiniConsole V3

[_LM_]

Tu chodziło że przy qfn trudniej zweryfikować poprawność lutowania też się na tym przejechałem 

[_LM_]

1 godzinę temu, MR1979 napisał:

Przy pinie hold lepiej dać pull-up bo układ będzie upierdliwy podczas programowania uC (odcina zasilanie przy resecie).

Znany temat, ale że korzystam z esp32 to używam zdalnego upgradeu, czasem jak program poleci w maliny to trzeba rsa podłączyć 

[MR1979]

Cześć!

Po dłuższej przerwie postanowiłem pochwalić się jakie są postępy przy projekcie mojej konsolki na STM32H7. W końcu udało mi się rozdzielić projekt firmware oraz aplikacji. Oto co nowego:

1. Firmware:

- Separacja od aplikacji. Firmware może być niezależnie modyfikowany i rozwijany.

- Dodałem interfejs dla aplikacji. Aplikacje mogą korzystać ze sprzętu tylko poprzez udostępnione funkcje.

- Wiele poprawek małych błędów i poprawiona stabilność

- Usprawniłem podsystem dźwiękowy

- Dodana animacja dla wyłączenia konsolki

2. Stworzyłem szablon projektu do tworzenia aplikacji:

- Wgrywanie przez STLink nie usuwa firmware'u. Aplikacje rezydują w pamięci QSPI.

- Programy mogą być debugowane jak każde inne projekty STM32H7

- Napisałem drivery pozwalające na dostęp do warstwy sprzętowej poprzez udostępnione funkcje

3. Pierwsza gra:

- Przepisałem kod jako oddzielny projekt

- Nowi przeciwnicy z lepszym "AI"

- Nowa muzyka i dźwięki, zapisane jako mp3, miksowane w czasie rzeczywistym

- Poprawiona fizyka

Poniżej krótki filmik:

Pozdrawiam,
Marek

 

[Treker (Damian Szymański)]

@MR1979 gratulacje, świetny projekt!

[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

[MR1979]

Hej! Update z projektu konsolki:

• Nareszcie udało mi się ukończyć część systemu odpowiedzialną za wybieranie i flashowanie aplikacji
• Aplikacje są zapisywane w oddzielnych folderach w głównm katalogu.
• Kod programu znajduje się w pliku w formacie Intel Hex, który jest automatycznie generowany przez CubeIDE.
• Dodałem też do interfejsu aplikacji kilka nowych funkcji. Między innymi dostęp do daty i czasu z RTC.

Demko na załączonym filmiku:

 

Postanowiłem też upublicznić kod firmware oraz szablon aplikacji:

https://github.com/MarekRyn/MiniConsoleV3_Firmware

https://github.com/MarekRyn/MiniConsoleV3_AppTemplate

Przeglądając kod projektu, proszę miejcie na względzie że nie jestem profesjonalnym programistą. Oczywiście jestem otwarty na sugestie i krytykę.

Pozdrawiam,
Marek

 

[MR1979]

Hej!

W końcu przeportowałem grę Doom na swoją konsolkę.

Gra jest w pełni funkcjonalna i działa z 25-30FPS w rozdzielczości 640x400. Przy muzyce musiałem trochę oszukać, bo nie mam jeszcze możliwości odgrywania plików midi. Zamiast tego wyodrębniłem wszystkie ścieżki dźwiękowe i przekonwertowałem je do mp3. Tak więc gra odtwarza muzykę z plików mp3 wgrywanych w locie podczas rozgrywki.

Poniżej filmik:

Z pozostałych nowości to rozbudowałem funkcjonalność USB. Dodałem do konsolki możliwość emulacji klawiatury, myszki, game pada oraz połączenia szeregowego. Wszystkie te funkcje są dostępne dla aplikacji poprzez API.

Pozdrawiam,
Marek

 

[MR1979]

Cześć!

Kolejna gra gotowa! Tym razem padło na Quake. Gra jest w pełni funkcjonalna w trybie jednego gracza. Udało mi się uruchomić dźwięk oraz muzykę. Podobnie jak przy porcie gry Doom, muzyka została skonwertowana do mp3 i jest ładowana z karty SD. Sama gra renderuje się w 320x200 i jest upscalowana do 640x400.

Największy problem miałem z brakiem myszki. Poradziłem sobie wykorzystując wbudowany akcelerometr. Celowanie odbywa się przechylając odpowiednio obudowę konsolki.

Poniżej krótki filmik:

Z pozostałych wieści to po kolejnych optymalizacjach Doom oraz Doom 2 działają w 30 klatkach

[MR1979]

Hej!

Rozszerzyłem firmware konsolki o możliwość odtwarzania plików wideo (AVI).

Wspierane kodeki:
- Wideo: MJPEG ze sprzętowym dekodowaniem
- Audio: MPEG1 Layer 3 (MP3) ze stałym bitrate, dekodowane na drugim rdzeniu

Zaimplementowane funkcje:
- Inicjalizacja
- Podstawowa kontrola (Play, Pauza, Przejdź do wybranej klatki)
- Przewijanie do przodu i do tyłu z podglądem

Wydajność:
- Oprogramowanie odtwarza pliki do pełnej rozdzielczości wyświetlacza (800x480) przy 30 klatkach na sekundę. Wspierane są też dowolne niższe wartości, np 24 klatki/s.
- Oprogramowania automatycznie dostosowuje się do wybranego trybu wyświetlania: ARGB8888, RGB888, ARGB1555, ARGB4444 przy podwójnym lub potrójnym buforze ramki

Poniżej mała demonstracja:

 

 

Pozdrawiam,
Marek

 

Edytowano Wrzesień 27, 2024 przez MR1979

[MR1979]

Tym razem przeportowałem emulator konsolki NES. To już chyba komplet obowiązkowych pozycji

Bazą do projektu był kod źródłowy Nofrendo NES emulator na ESP32 (https://github.com/espressif/esp32-nesemu/tree/master)

 

 

 

Pozdrawiam,
Marek

[Treker (Damian Szymański)]

@MR1979 jak zawsze świetna robota, miło się patrzy na ten projekt. Aż "strach" pytać jakie dalsze plany Co kolejnego planujesz w kontekście tej konsoli?

[MR1979]

Hej!

5 minut temu, Treker napisał:

@MR1979 jak zawsze świetna robota, miło się patrzy na ten projekt. Aż "strach" pytać jakie dalsze plany Co kolejnego planujesz w kontekście tej konsoli?

Generalnie projekt jest już ukończony. Mam jeszcze tam wlutowany moduł BLE oparty na nrf52832, ale zainstalowałem go trochę w ciemno i nie jestem pewien czy uda mi się go uruchomić. Środowisko programowania Seggera jest trochę upierdliwe jeżeli chodzi o licencje i nie mam doświadczenia z tym uC. Jak się uda połączyć, to dodam jeszcze jakąś komunikacje Bluetooth (symulacja myszki / klawiatury / pada + połączenie szeregowe). Mam już te funkcjonalności opracowane po USB ale bezprzewodowo byłoby lepiej. Fajnie gdyby udało się skomunikować dwie konsolki po bluetooth.

Pozdro!

[atlantis86]

Naprawdę imponujący projekt, robi wrażenie.

Nie wiem czy zostało to wspomniane gdzieś wcześniej w opisie, ale jak właściwie uruchamiana jest gra po załadowaniu? Bezpośrednio na krzemie, czy zostaje jej przypisany jakiś osobny task w FreeRTOS, który zajmuje się jej wykonywaniem? Dlaczego gry ładowane z karty są zapisywane w pamięci flash QSPI i stamtąd wykonywane? Czy SDRAM nie byłby do tego nieco bardziej odpowiedni?

Sam już od jakiegoś czasu zastanawiam się nad stworzeniem czegoś podobnego, ale w znacznie prostszej wersji. Od strony sprzętowej raczej postawiłbym na jakiś prostszy ekran LCD (16bit, może nawet SPI). Chciałbym poeksperymentować z wykorzystaniem pamięci SDRAM w takich projektach, a także poćwiczyć pisanie bootloadera, który pozwoliłby mi na załadowanie kodu z karty do pamięci i wykonanie go z niej. Trochę ćwiczenie na drodze do kolejnego celu, który sobie wyznaczyłem - odpalenia Linuksa na samodzielnie zbudowanej płytce. Dooma też chciałbym kiedyś uruchomić na czymś samodzielnie zbudowanym.

Myślicie, że STM32H743 albo STM32H753 nadadzą się do takiego projektu? Akurat mam je pod ręką.

Jeśli chodzi o obsługę MIDI, to zastanawiam się czy w swoim planowanym projekcie nie użyć układu VS1053. Korzystałem już z niego w kilku swoich projektach. Scalak nie tylko potrafi obsługiwać większość popularnych kodeków audio, ale też jest w stanie odtwarzać MIDI. Do tego potrafi mieszać dekodowane audio z sygnałem otrzymywanym na wejściu liniowym, w domenie analogowej. W dość prosty sposób rozwiązywałoby to wiec kwestię obsługi MIDI w grach takich jak DOOM, a do tego dawało możliwość odtwarzania muzyki (mp3, aac, wma) bez angażowania procesora. Same efekty dźwiękowe można by produkować z próbek PCM za pomocą jakiegoś DAC-a i kierować na wejście liniowe VS-a.

Edytowano 24 maja przez atlantis86

[MR1979]

Hej @atlantis86!

Dzięki za pozytywny komentarz do projektu. Widziałem też prywatną wiadomość. Z braku czasu nie mogłem wcześniej odpisać, ale teraz odpowiem na wszystkie pytania (z wiadomości prywatnej też):

Dnia 24.05.2025 o 00:05, atlantis86 napisał:

Nie wiem czy zostało to wspomniane gdzieś wcześniej w opisie, ale jak właściwie uruchamiana jest gra po załadowaniu? Bezpośrednio na krzemie, czy zostaje jej przypisany jakiś osobny task w FreeRTOS, który zajmuje się jej wykonywaniem? Dlaczego gry ładowane z karty są zapisywane w pamięci flash QSPI i stamtąd wykonywane? Czy SDRAM nie byłby do tego nieco bardziej odpowiedni?

W projekcie przyjąłem następujący podział:
1. Wewnętrzna pamięć FLASH uC - Firmware konsolki, system operacyjny, podstawowe funkcje do obsługi plików, dźwięku i grafiki.
2. SDRAM - Przeznaczona na bufor ramki (grafika), oraz dane aplikacji
3. Pamięć QSPI - tu znajduje się kod aplikacji.

Wybrałem takie rozwiązanie gdyż pamięć FLASH uC ma ograniczoną ilość zapisów, a sam firmware konsolki i tak zajmuje jej większość. Dodatkowo STM32 cachuje program znajdujący się w QSPI i jest to rozwiązanie wspierane i zalecane (execute in place i memory mapped mode).

Uznałem że używanie SDRAM do przechowywania aplikacji nie byłoby dobrym rozwiązaniem. W uC STM32 RAM (wewnetrzny i zewnętrzny) jest przeznaczony głównie do przechowywania danych. Rdzeń jest fabrycznie przystosowany do takiego podziału: D-CACHE (cache danych) jest dla RAM a I-CACHE (cache instrukcji) wspiera pamięć FLASH oraz zewnętrzne pamięci jak QSPI. To jedna z głównych różnic między mikrokontrolerem a klasycznym procesorem.

System uruchamia się następująco (w dużym skrócie):
1. Start zasilania
2. Konfiguracja wszystkich pryferiów (ekran, dźwięk, pamięci, akcelerometr, karta SD, itd. itp.)
3. Sprawdzanie w jakim trybi uruchamia się konsolka (uruchomienie aplikacji, konfiguracja, pamięć masowa)
4. Odczytanie z pamięci QSPI: entry point do funkcji init aplikacji, entry point do funkcji main aplikacji, oraz nazwy folderu domowego dla aplikacji
5. Ustawienie folderu domowego jako głównego dla aplikacji (aplikacja nie może zapisywać i odczytywać poza swoim folderem na karcie SD)
6. Skok do funkcji init aplikacji
7. Skok do funkcji main aplikacji

Co do samego systemu operacyjnego to nie korzystam z FreeRTOS. Wszystko opiera się na pętli (maszyna stanów) oraz przerwaniach. Dźwięk obsługuje drugi rdzeń. Dostęp do karty SD obsługuję przez FatFS.

Dostęp do poszczególnych funkcji firmware rozwiązałem tworząc dużą tablicę wektorów z adresami dla każdej funkcji. Ta tablica znajduje się zawsze pod stałym adresem.

Dnia 24.05.2025 o 00:05, atlantis86 napisał:

Myślicie, że STM32H743 albo STM32H753 nadadzą się do takiego projektu? Akurat mam je pod ręką.

Do prostej konsolki się nadadzą w zupełności. Ważne żebyś miał jak największą obudowę, co pozwoli na podłączenie pamięci SDRAM z 32-bitową linią danych, przycisków, ekranu. Drugi rdzeń nie będzie potrzebny jeżeli nie planujesz zaawansowanej obsługi dźwięku (dekodowania i miksowanie wielu ścieżek mp3, raw, mod itp...). Zaplanuj sobie co chcesz mieć w swojej konsolce i zobacz w CubeMX czy uda ci się to wszystko podłączyć do wybranego uC.

Dnia 24.05.2025 o 00:05, atlantis86 napisał:

Jeśli chodzi o obsługę MIDI, to zastanawiam się czy w swoim planowanym projekcie nie użyć układu VS1053. Korzystałem już z niego w kilku swoich projektach.

Nie mam doświadczenia z VS1053 ale wydaje mi się że lepszym wyjściem byłaby obsługa dźwięku przez drugi rdzeń. Ma to ogromną zaletę gdyż masz bezpośredni dostęp do pamięci SDRAM gdzie aplikacja będzie przechowywać dane. Wadą tego rozwiązania jest że niestety sam musisz napisać firmware który to wykona oraz ogarnąć komunikację między rdzeniami. Ponad to w twoim rozwiązaniu - jak sam przyznajesz - będziesz musiał miksować próbki PCM na uC przed wysłaniem do VS1053.

Dnia 24.05.2025 o 00:05, atlantis86 napisał:

Czy twoim zdaniem możliwe jest wykonanie takiego projektu na dwustronnej (ewentualnie czterowarstwowej) płytce? Jak widzisz w przypadku swojego odtwarzacza zaczynałem od samodzielnie trawionej płytki, chociaż w pewnym momencie natknąłem się już na problemy z czterobitowym SDIO, gdy różnica w długościach ścieżek była za duża. W innych swoich projektach udawało mi się bez większego problemu używać USB 2.0 albo FastEthernetu na samodzielnie trawionych płytkach. Niemniej w tym przypadku już na starcie skorzystam z JLCPCB...

Wydaje mi się że 4 warstwy to minimum dla tak dużego projektu. Oddzielna warstwa zasilania oraz masy bardzo ułatwia projektowanie i pozwala na zachowanie odpowiedniej impedancji gdzie jest to wymagane. Różnica w cenie nie jest aż tak duża, więc po co ryzykować.

Dnia 24.05.2025 o 00:05, atlantis86 napisał:

Jak newralgiczną kwestią jest podpięcie pamięci SDRAM do mikrokontrolera. Powinienem się trzymać jakichś konkretnych zasad czy wystarczy, że połączenia będą możliwie jak najkrótsze?

SDRAM w STM32 może działać max z częstotliwością tylko 100 - 120MHz, więc wymagania nie są zbyt krytyczne, ale ja staram się trzymać następujących zasad:
1. Dobierz grubość ścieżki tak aby impedancja wynosiła 50 omów.
2. Staraj się aby wszystkie linii danych miały w miarę jednakową długość. Jak się nie uda to też będzie działać.
3. Staraj się aby linie adresowe miały w miarę jednakową długość. Jak się nie uda to też będzie działać.
4. Jeżeli nie możesz zapewnić jednakowej długości, to linia zegarowa zawsze powinna być najdłuższa.
5. Staraj się aby pamięć i uC były jak najbliżej siebie.

Dnia 24.05.2025 o 00:05, atlantis86 napisał:

Czy twoim zdaniem wykonalne jest uruchomienie DOOM-a na nieco słabszym, jednordzeniowym MCU? W projekcie planuję użyć STM32H753 (ewentualnie STM32H750 lub STM32H743) bo mam ich trochę w podręcznych zapasach.

Myślę że da radę. Nie wiem czy z pełnym dźwiękiem i muzyką, ale samą grę powinieneś uruchomić bez problemu.

Kod źródłowy firmware oraz przykładowy szablon aplikacji znajduje się na moim githubie:

https://github.com/MarekRyn/MiniConsoleV3_Firmware

https://github.com/MarekRyn/MiniConsoleV3_AppTemplate

Pozdrawiam,
Marek

[atlantis86]

1 godzinę temu, MR1979 napisał:

Hej @atlantis86!

Dzięki za pozytywny komentarz do projektu. Widziałem też prywatną wiadomość. Z braku czasu nie mogłem wcześniej odpisać, ale teraz odpowiem na wszystkie pytania (z wiadomości prywatnej też):

Dzięki za odpowiedź i za pomoc.

1 godzinę temu, MR1979 napisał:

Wybrałem takie rozwiązanie gdyż pamięć FLASH uC ma ograniczoną ilość zapisów, a sam firmware konsolki i tak zajmuje jej większość. Dodatkowo STM32 cachuje program znajdujący się w QSPI i jest to rozwiązanie wspierane i zalecane (execute in place i memory mapped mode).

Hmm... Tylko czy ograniczenie liczby cykli zapisu/kasowania nie odnosi się także do układu flash na QSPI? Właśnie dlatego preferuję użycie do tego SDRAM-u.

Poza tym użycie SDRAM-u jest dla mnie kluczowe z innego powodu. Ten projekt ma być przystankiem na drodze do celu, którym jest odpalenie Linuksa na samodzielnie zaprojektowanej i zlutowanej płytce. Oczywiście to już nie na STM32H7, ale na jakimś układzie z rozbudowanym MMU. Wtedy tak czy inaczej nie ucieknę od wykonywania kodu z zewnętrznego RAM-u.

1 godzinę temu, MR1979 napisał:

Uznałem że używanie SDRAM do przechowywania aplikacji nie byłoby dobrym rozwiązaniem. W uC STM32 RAM (wewnetrzny i zewnętrzny) jest przeznaczony głównie do przechowywania danych. Rdzeń jest fabrycznie przystosowany do takiego podziału: D-CACHE (cache danych) jest dla RAM a I-CACHE (cache instrukcji) wspiera pamięć FLASH oraz zewnętrzne pamięci jak QSPI. To jedna z głównych różnic między mikrokontrolerem a klasycznym procesorem.

Hmm... Jesteś pewien, że nie STM32H7 nie pozwalają na cache-owanie instrukcji z SDRAM-u? Robiłem na razie bardzo ogólne rozeznanie w temacie, ale jak dotąd nie trafiłem na informacje które mówiły, że byłoby to dopuszczalne tylko dla wbudowanego flasha i pamięci flash QSPI. Zdaję sobie sprawę, że tak czy inaczej wykonywanie kodu z zewnętrznego SDRAM-u będzie się wiązało ze spadkiem wydajności. Miałem nadzieję, że przynajmniej I-Cache  poprawi nieco sytuację.

Mój plan na zminimalizowanie tego problemu był taki, żeby we flashu mikrokontrolera umieścić zestaw zestaw funkcji pomocniczych, odpowiedzialnych za obsługę sprzętu, generowanie grafiki, dostęp do peryferiów, kopiowanie danych z/do pamięci itp. Tam również znajdowałyby się funkcje obsługi przerwań. Aplikacja wykonywana z SDRAM-u miałaby do nich dostęp za pośrednictwem callbacków. Czyli kluczowe fragmenty kodu wykonywałyby się z flasha.

Mam nadzieję, że wystarczy to przynajmniej do odpalenia Dooma z sensownym frameratem.

1 godzinę temu, MR1979 napisał:

Do prostej konsolki się nadadzą w zupełności. Ważne żebyś miał jak największą obudowę, co pozwoli na podłączenie pamięci SDRAM z 32-bitową linią danych, przycisków, ekranu.

SDRAM z 32-bitową magistralą danych jest konieczna w tego typu projekcie? Zastosowanie szesnastobitowej pamięci będzie zbyt dużym kompromisem, jeśli chodzi o wydajność? Mam trochę takich pamięci w podręcznym zapasie części (kupione kiedyś, z myślą o innym projekcie). Czy jednak powinienem się rozejrzeć za 32-bitowymi?

1 godzinę temu, MR1979 napisał:

Drugi rdzeń nie będzie potrzebny jeżeli nie planujesz zaawansowanej obsługi dźwięku (dekodowania i miksowanie wielu ścieżek mp3, raw, mod itp...).

Jeśli chodzi o dźwięk to zastanawiam się, czy nie zastosować rozwiązania sprzętowego w postaci VS1053. Potrafi dekodować większość formatów audio (MP3, WAV, AAC, WMA, MIDI) - to załatwiałoby kwestię odtwarzania muzyki. Chyba tylko MOD trzeba by dekodować software'owo. Do tego jakiś DAC do odtwarzania sampli z efektami dźwiękowymi.

1 godzinę temu, MR1979 napisał:

Zaplanuj sobie co chcesz mieć w swojej konsolce i zobacz w CubeMX czy uda ci się to wszystko podłączyć do wybranego uC.

Już teraz widzę, że większość pinów pójdzie u mnie na interfejs pamięci SDRAM oraz wyświetlacza LTDC. Nawet zastanawiałem się czy nie poszukać jakiegoś wyświetlacza na szybkim SPI. Nie mam ambicji, żeby iść w rozdzielczość powyżej 320x240, więc teoretycznie powinno się udać uzyskać ładną animację. Jednak nie udało mi się znaleźć żadnego wyświetlacza pasującego do projektu. Natomiast wyświetlacze z kontrolerem, pracujące na magistrali FMC odpadają, bo jest ona już zajęta przez SDRAM.

Zastanawiam się czy nie oszczędzić trochę linii przez zmianę podejścia do kontrolerów. Rozważam wykonanie dwóch osobnych płytek (prawej i lewej) z przyciskami i gałkami analogowymi, z których każda posiadałaby jakiś mały mikrokontroler. Całość byłaby połączona jakąś lokalną magistralą, a STM32H7 dostawałby po prostu ramki z informacjami na temat aktualnego stanu przycisków i analogów.

1 godzinę temu, MR1979 napisał:

Nie mam doświadczenia z VS1053 ale wydaje mi się że lepszym wyjściem byłaby obsługa dźwięku przez drugi rdzeń. Ma to ogromną zaletę gdyż masz bezpośredni dostęp do pamięci SDRAM gdzie aplikacja będzie przechowywać dane. Wadą tego rozwiązania jest że niestety sam musisz napisać firmware który to wykona oraz ogarnąć komunikację między rdzeniami. Ponad to w twoim rozwiązaniu - jak sam przyznajesz - będziesz musiał miksować próbki PCM na uC przed wysłaniem do VS1053.

VS1053 ma własny, wewnętrzny bufor. Jedyne co trzeba zrobić, to wysyłać mu ba bieżąco dane do odtwarzania. Nawet większość formatów jest w stanie sam rozpoznać. Używałem go w kilku swoich projektach i np. bardzo mocno upraszczał implementację radia internetowego - wystarczyło właściwie tylko buforować dane odbierane ze streama po HTTP i sukcesywnie przesyłać do kodeka. On zajmował się resztą. Miksowanie (np. muzyki z efektami dźwiękowymi) prawdopodobnie dałoby się załatwić w domenie analogowej. Jeszcze z tego nie korzystałem, ale z tego co kojarzę VS1053 potrafi skierować na wyjście liniowe jednocześnie zdekodowany strumień oraz to, co aktualnie dostaje na wejściu liniowym. Więc można by tam posłać sygnał z drugiego DAC-a.

Tym co mnie najbardziej przekonuje do tego układu, to natywna, całkiem niezła obsługa MIDI. To załatwiałoby w dość prosty sposób ścieżki dźwiękowe w takich grach jak Doom czy Wolfenstein.  No cóż... Niestety układ nie jest w stanie jednocześnie odtwarzać muzyki i dekodować próbek PCM z efektami dźwiękowymi.

1 godzinę temu, MR1979 napisał:

5. Staraj się aby pamięć i uC były jak najbliżej siebie.

Widzę, że tutaj są dwie szkoły:

1. Mikrokontroler i pamięć po przeciwległych stronach płytki. Połączenia jak najkrótsze, ale przelotka na każdej linii.
2. Mikrokontroler i pamięć na tej samej stronie płytki, obok siebie. Zmniejszona liczba przelotek, ale kosztem dłuższych ścieżek.

Które podejście polecasz?

1 godzinę temu, MR1979 napisał:

Myślę że da radę. Nie wiem czy z pełnym dźwiękiem i muzyką, ale samą grę powinieneś uruchomić bez problemu.

Kod źródłowy firmware oraz przykładowy szablon aplikacji znajduje się na moim githubie:

Wielkie dzięki, rzucę okiem.

Edytowano 13 godzin temu przez atlantis86

[MR1979]

Hej!

25 minut temu, atlantis86 napisał:

Hmm... Jesteś pewien, że nie STM32H7 nie pozwalają na cache-owanie instrukcji z SDRAM-u? Robiłem na razie bardzo ogólne rozeznanie w temacie, ale jak dotąd nie trafiłem na informacje które mówiły, że byłoby to dopuszczalne tylko dla wbudowanego flasha i pamięci flash QSPI. Zdaję sobie sprawę, że tak czy inaczej wykonywanie kodu z zewnętrznego SDRAM-u będzie się wiązało ze spadkiem wydajności. Miałem nadzieję, że przynajmniej I-Cache  poprawi nieco sytuację.

Sprawdziłem, oczywiście I-Cache działa też z pamięciami podłączonymi przez FMC (czyli też z SDRAM). Moja pomyłka. Pamiętaj tylko aby odpowiednio skonfigurować dostęp do pamięci w MPU (Memory Protecton Unit) mikrokontrolera.

27 minut temu, atlantis86 napisał:

SDRAM z 32-bitową magistralą danych jest konieczna w tego typu projekcie? Zastosowanie szesnastobitowej pamięci będzie zbyt dużym kompromisem, jeśli chodzi o wydajność? Mam trochę takich pamięci w podręcznym zapasie części (kupione kiedyś, z myślą o innym projekcie). Czy jednak powinienem się rozejrzeć za 32-bitowymi?

Zastosowałem 16-bitową pamięć w drugiej wersji konsolki. Było to tak wąskie gardło że musiałem zarzucić ten projekt i zaprojektować kolejną wersję z 32-bitową szyną danych. Przy czym muszę nadmienić że korzystałem z wyświetlacza 800x480. Przy 320x200 pewnie będzie ok.

Co do dźwięku w DOOM, to tam masz próbki PCM i często się zdarza że odtwarzasz kilka sampli jednocześnie (np kilku przeciwników + odgłosy strzału). Co do muzyki to nie jest MID, tylko MUS. Musisz przekonwertować format. Moja konsola nie odtwarza MID i poratowałem tak że zrobiłem konwersję mus->mid->mp3 i tak odtwarzałem ścieżki. Konwersja MUS->MID nie jest trudna. Gdzieś w sieci znalazłem kod w C.

36 minut temu, atlantis86 napisał:

Widzę, że tutaj są dwie szkoły:

1. Mikrokontroler i pamięć po przeciwległych stronach płytki. Połączenia jak najkrótsze, ale przelotka na każdej linii.
2. Mikrokontroler i pamięć na tej samej stronie płytki, obok siebie. Zmniejszona liczba przelotek, ale kosztem dłuższych ścieżek.

Które podejście polecasz

Ja wybrałem opcję 1.

Pozdrawiam,
Marek