Szukam wyświetlacza do przenośnej konsolki DIY na STM32H753

[kostuch]

10 minut temu, atlantis86 napisał:

Początkowo myślałem nad zrobieniem tego projektu w wersji stacjonarnej i wtedy użycie VGA z jakimś starszym monitorem faktycznie miałoby sens. Jednak finalnie wygrała koncepcja budo "handhelda", stąd poszukiwania wyświetlacza.

Wracając do meritum... 

Może generuj po prostu sygnał composite video - będzie odpowiednio vintage.

Kiedyś coś takiego popełniłem na esp32 z podpiętym 5'' monitorkiem od kamery cofania za kilkanaście pln.

Wyglądało zupełnie jak ZX Spectrum podpięty do telewizora

 

[Treker (Damian Szymański)]

Przypominam o polityce przyjaznego forum - szacunek i życzliwość są tutaj najważniejsze. Emocje w takich momentach nie pomagają, więc skupiajmy się na merytorycznej dyskusji, a nie na osobach. Wszyscy mają prawo do pytań i opinii, ale w kulturalnej formie bez osobistych zaczepek. Jeśli jakiś post wydaje się Wam nieodpowiedni, możecie odnieść się merytorycznie do kwestii technicznych, ocenić go negatywnie za pomocą reakcji, zgłosić wpis moderatorowi lub po prostu go przemilczeć. Pisanie zaczepnych komentarzy to najgorsze rozwiązanie, którego na tym forum nie chcemy.

To ogólna uwaga do wszystkich uczestników (tej oraz innych dyskusji) - razem dbajmy o dobrą atmosferę na forum.

[matsobdev]

31 minut temu, atlantis86 napisał:

I niestety wygląda na to, że @matsobdev ma rację i chcą wyższej przekątnej w proporcji 4:3 będę musiał poszukać wyświetlacza 640x480.

Nie no, są dostępne:

Dnia 6.06.2025 o 00:50, matsobdev napisał:

PS. Wychodzi na to, że dużo jest 5,7" w produkcji (może nie w produkcji, ale dostępnych) nadal o rozdzielczości QVGA.

tylko cena może być zabójcza. A może nie  - warto zapytać. Ale przynajmniej można zamówić tylko dwie sztuki, a nie 1000. Niektóre mają bezpłatny dostęp do datasheetów, choć można jakieś zdjęcia paneli powstawiać i w kilka dni zarobić punkty, żeby pdfa pobrać. Są tam wyświetlacze z interfejsem RGB(888/666) (DPI), TNy (to raczej będą szybkie). Strzelam, że będzie można się z nimi dogadać tak samo jak z tym z GPSu. A też, te 3,5" były taniej niż 60 zł na Ali, nawet za 2 dyszki (ale opinie trzeba czytać, bo były też wadliwe), to do prototypu też się nada, żeby poćwiczyć, a od biedy starego GPSa za 5 zł można wyrwać.

[virtualny]

53 minuty temu, atlantis86 napisał:

Czy my w tym momencie nie mówimy właśnie o interfejsie LTDC, którego użycie zakładam od samego początku?

Przynajmniej nie w sposób jawny od samego początku. Deklaracja o LTDC jest później. W linkowanym przeze mnie wątku wymieniłem zestawy ST w którym każdy pomimo różnorodności rozwiązań podłączył LCD na interfejsie LTDC włącznie z wyświetlaczem 2.4" ze sterownikiem ILI9341 podobnym do pokazanego przeze mnie. I za to podziwiam ST. Popatrz SRAM/DRAM/HexadecaPSRAM/wewnętrzny SRAM procesora/HyperRAM - do wyboru, do koloru. Stąd moje sugestie żeby albo stosować gotowe rozwiązania od ST, albo podejrzeć w jaki sposób ONI to zrobili. Pozwól i wybacz mi że nie odniosę się do innych Twoich wypowiedzi żeby nie wzniecać ognia. Powtórzę mój skrót myślowy że wystarczy mieć schemat wyprowadzeń tasiemki i w zasadzie możesz zrobić wszystko:

Cytat

 

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  HyperRAMTM  Framebuffer LTDC, wyjście RGB 4.3'' 480x272 px 60Hz

 

 Znalazłem te allwinnery:

Pokazywany wyświetlacz być może spełnia Twoje oczekiwania. Jeszcze jedna uwaga - gro takich wyświetlaczy działa na minimum 60Hz refresh rate. Więc w przypadku emulacji sprzętów retro pracujących na 50Hz np. C64 albo wymusisz generowanie klatki 60 razy na sekundę, co zmieni timing i nie będzie to cycle exact. Najprościej mówiąc wówczas program (demo) który trwa 6minut będzie trwał 5 minut. Druga opcja - jeżeli zachowasz 50Hz na LCD 60Hz wówczas generowany obraz będzie gubił klatki, bo inaczej się nie da. W taki sposób działają konwertery na przykład z composite RC do HDMI. Gubienie klatek widoczne jest np. przy scrollach, widać szarpnięcia. Trzecia opcja - użycie ekranu 50 albo 100Hz i aktualizowanie obrazu z częstotliwością 50Hz. Aha pixele w C64 nie są kwadratowe, co oznacza że przy użyciu pixeli kwadratowych będzie lekkie zniekształcenie.

 

 

 

[atlantis86]

8 godzin temu, kostuch napisał:

Wracając do meritum... 

Może generuj po prostu sygnał composite video - będzie odpowiednio vintage.

Prawdę mówiąc to właśnie będzie zbyt vintage.

Z wyjścia kompozytowego korzystałem już w kilku moich projektach retro, wykorzystujących autentyczne elementy z lat osiemdziesiątych. W kolejce czekają kolejne konstrukcje retro, które pewnie dostaną "karty graficzne" na RGB.

W tym przypadku chciałbym jednak trochę odejść od tematyki retro i zrobić coś bardziej współczesnego. To nie ma być kolejna platforma do emulacji. O emulatorach wspomniałem właściwie przy okazji, bo pewnie któryś uda się przeportować. Głównym celem projektu jest jednak zbudowanie platformy, pozwoli na uruchamianie natywnych gier, skompilowanych na to urządzenie i ładowanych do pamięci SDRAM. Myślę tutaj głównie o klasycznym Doomie, bo uruchamianie go na czym tylko się da stało się memem.  A Doom to już jednak czasy grafiki wykraczającej poza telewizory i sygnał kompozytowy...

8 godzin temu, kostuch napisał:

Kiedyś coś takiego popełniłem na esp32 z podpiętym 5'' monitorkiem od kamery cofania za kilkanaście pln.

Wyglądało zupełnie jak ZX Spectrum podpięty do telewizora

Emulacja Spectrum to jednak nie moja bajka. Zbudowałem parę różnych klonów tego komputera (zarówno z wykorzystaniem logiki TTL, jak CPLD/FPGA). Do emulacji na MCU jakoś mnie nie ciągnie. Jak mówiłem - tutaj chciałbym pobawić się w odpalanie natywnego kodu z pamięci. Jeśli przy okazji uda się odpalić w ten sposób jakiś emulator, to potraktuję to jako projekt poboczny. Nie jest to jednak głównym celem.

  

7 godzin temu, matsobdev napisał:

Nie no, są dostępne:

tylko cena może być zabójcza. A może nie  - warto zapytać.

No właśnie jak wstępnie szukałem, to nie widziałem niczego w rozdzielczości QVGA, co miałoby przekątną powyżej 3,5". Bez względu na to czy mowa o modułach z ILI9341, czy czymś bezpośrednio na LTDC. Widzę, że można znaleźć wyświetlacze 640x480, a przeskalowanie do tej rozdzielczości nie powinno być specjalnie obciążającą operacją dla STM32H7 z DMA2D.

6 godzin temu, virtualny napisał:

Przynajmniej nie w sposób jawny od samego początku. Deklaracja o LTDC jest później.

Ok, może nie napisałem tego dostatecznie jasno, ale jest jeszcze jeden powód, dla którego preferuję LTDC. Chcąc w efektywny sposób obsłużyć ILI9341, będę musiał wykorzystać magistrale FMC. Tak to zrobiłem w swoim projekcie z STM32F407 i faktycznie działało to naprawdę dobrze. Problem polega na tym, że magistrala ta będzie mi potrzebna do obsłużenia SDRAM-u, który w tym projekcie jest równie kluczowy jak wyświetlacz. Nie wykluczam, że jest możliwe obsłużenie obydwu urządzeń na jednej magistrali, ale tutaj znowu wpakuję się komplikacje przy projektowaniu strony sprzętowej - obsługa wielu urządzeń na jednej magistrali, prowadzenie dłuższych ścieżek itp. Wolę tego uniknąć i odseparować urządzenia od siebie. STM32H753 ma dostatecznie dużo pinów.

6 godzin temu, virtualny napisał:

Znalazłem te allwinnery:



Wygląda na to, że linki nie działają.

6 godzin temu, virtualny napisał:

Pokazywany wyświetlacz być może spełnia Twoje oczekiwania. Jeszcze jedna uwaga - gro takich wyświetlaczy działa na minimum 60Hz refresh rate. Więc w przypadku emulacji sprzętów retro pracujących na 50Hz np. C64 albo wymusisz generowanie klatki 60 razy na sekundę, co zmieni timing i nie będzie to cycle exact. Najprościej mówiąc wówczas program (demo) który trwa 6minut będzie trwał 5 minut. Druga opcja - jeżeli zachowasz 50Hz na LCD 60Hz wówczas generowany obraz będzie gubił klatki, bo inaczej się nie da. W taki sposób działają konwertery na przykład z composite RC do HDMI. Gubienie klatek widoczne jest np. przy scrollach, widać szarpnięcia. Trzecia opcja - użycie ekranu 50 albo 100Hz i aktualizowanie obrazu z częstotliwością 50Hz. Aha pixele w C64 nie są kwadratowe, co oznacza że przy użyciu pixeli kwadratowych będzie lekkie zniekształcenie.

Jak już wspomniałem powyżej, emulacja sprzętu retro nie jest tutaj głównym założeniem.

Celem projektu jest samodzielne zaprojektowanie i zbudowanie czegoś, co:

• Będzie wyposażone w wyświetlacz, zestaw przycisków (lub innych elementów sterujących), slot karty SD i jakiś rodzaj wyjścia audio. Myślę tutaj o rozwinięciu mojego wcześniejszego projektu odtwarzacza audio, ale z lepszymi parametrami i większym wyświetlaczem.
• Będzie w stanie załadować skompilowany, wykonywalny kod z karty SD do pamięci SDRAM i wykonać go stamtąd.
• Docelowo chciałbym, aby tym wykonywanym kodem był Doom, bo gra słynie z tego, że była i jest portowana na różne platformy. Ale oczywiście testy będę przeprowadzał na znacznie prostszych fragmentach kodu.

Forma przenośnej konsolki wydaje się być idealna do takiego projektu.

Jak już uda mi się uruchomić cos takiego, bo będę chciał zrobić kolejny krok i zaprojektować płytkę z układem wyposażonym w MMU, co pozwoli na załadowanie i odpalenie Linuksa. Wiem, że ludzie robili takie eksperymenty m.in. na Allwinnerach, wyższych modelach układów z rodziny PIC32 albo nawet starych AT91SAM9. W tym przypadku mowa o SBC obsługiwanym przez port szeregowy, już bez wyświetlacza.

Edytowano Czerwiec 8, 2025 przez atlantis86

[virtualny]

4 godziny temu, atlantis86 napisał:

Docelowo chciałbym, aby tym wykonywanym kodem był Doom, bo gra słynie z tego, że była i jest portowana na różne platformy.

ESP32 (S3) ta biała płytka ze zdjęcia:

 

[atlantis86]

8 minut temu, virtualny napisał:

ESP32 (S3) ta biała płytka ze zdjęcia:

Jak najbardziej wiem, że na ESP32 da się go odpalić. Przy czym widać, że trzeba było pójść na kompromisy w kwestii rozdzielczości/aktywnego obszaru ekranu oraz liczby kolorów. Był też projekt polegający na odpaleniu Dooma na Raspberry Pi Pico, ale tam mocnym ograniczeniem z tego co pamiętam była ilość pamięci, więc gra korzystała jedynie z pliku WAD w wersji shareware. Dlatego właśnie będę potrzebował SDRAM-u, żeby zmieścić sam kod gry oraz wszystkie zasoby ładowane z WAD-a. Sam kod mógłbym co prawda wykonywać z flasha, ale jednak zależy mi na tym, żeby binarki były ładowane z karty pamięci i wykonywane z SDRAM-u.

[kostuch]

17 godzin temu, atlantis86 napisał:

 A Doom to już jednak czasy grafiki wykraczającej poza telewizory i sygnał kompozytowy...

To dlaczego szukasz 320x240 ???
Jak byłem młody i grałem w Dooma, to na porządku dziennym była rozdzielczość VGA

Generuj po prostu sygnał VGA (jak nie chcesz composite) i wypuszczaj go w coś takiego:

https://pl.aliexpress.com/item/1005008129581910.html

A jak koniecznie chcesz bezpośrednio sterować LCD, to sam panel też do kupienia jako ZJ050NA-08C

[atlantis86]

22 minuty temu, kostuch napisał:

To dlaczego szukasz 320x240 ???
Jak byłem młody i grałem w Dooma, to na porządku dziennym była rozdzielczość VGA

Tak, jednak engine Dooma generował grafikę w rozdzielczości 320x200. Obraz był rozciągany do proporcji 4:3 przez analogowe monitory. Podobnie wyglądała sytuacja w wielu innych DOS-owych grach z epoki.

Oryginalnie założyłem, że chyba najprościej będzie zastosować wyświetlacz o najbliższej rozdzielczości. Z drugiej strony zastosowanie VGA chyba ma więcej sensu. Nawet jeśli nie użyję tej rozdzielczości w grach, to będę miał większe pole do działania jeśli chodzi o interfejs użytkownika.

 

[atlantis86]

Ok, wygląda na to, że udało mi się znaleźć model wyświetlacza pasujący do projektu.

Rozdzielczość 640x480, przekątna 5,7", interfejs LVDS, dodatkowo panel dotykowy.

Teraz trzeba będzie zacząć projektować płytkę. A właściwie płytki - główną część planuję umieścić na relatywnie małej, czterowarstwowej płytce. Jeśli koszt nie będzie zbyt duży, to może nawet zdecyduję się na sześć warstw. Tu będzie mieścił się STM32, SDRAM, obwód zasilania, karta SD oraz DAC. Przyciski/joypady umieszczę na osobnych modułach, połączonych z płytą główną za pomocą przewodów/tasiemek flex. Możliwe zresztą, że zamiast łączyć elementy sterujące bezpośrednio z pinami GPIO STM32, zastosuję jakąś magistralę i niewielkie mikrokontrolery na modułach z przyciskami.

[virtualny]

• SDRAM
• SD
• DAC
• LCD 640x480, z RGB888. W praktyce może być że na przykład LTDC będzie połączone z 24 liniami kolorów, ale będzie konwertowało tryb RGB565 do RGB888... policzmy na każdą możliwą opcję:

- dla RGB565 wielkość ramki = 640*480*2 = 614 400 Bajtów , co dla 60FPS daje 614400 * 60  = 36 864 000 bajtów/ sekundę

- dla RGB888 ramka 921 600 bajtów, transfer 55 296 000 bajtów / sekundę

- dla ARGB8888 ramka 1 228 800 , transfer 73 728 000 bajtów/sekundę

To statystyczne prędkości transferu. Teraz... nie jestem pewien, nigdy czegoś takiego nie projektowałem, ani się nad tym nie zastanawiałem... Mogę się mylić. Sposób dostępu do pamięci i faktyczny transfer danych:

Dla 60Hz 640x480 pixel clock jest 25.125 MHz dla uproszczenia 25MHz. 

Przy dostępie 8 bit do RAM już tylko dla RGB565 widać że nie zdąży pobrać się danych obrazu do wysłania w tempie 25MHz i będzie to 50MHz, aby zdążyć pobierać i wysyłać dane. Plus drugie tyle dla zapisu do RAM  czyli 100MHz. Dla RGB888 byłaby potrzeba dostępu do RAM 100MHz dla 55 296 000 bajtów, bo  nie zdąży przy 50 MHz niestety. No i w połączeniu z równoległym zapisem byłoby to 200MHz aby zdążyć wysyłać dane i je "wymieniać" - Double bufforing jak najbardziej wskazany. Dobra wieść, że dla ARGB8888 takie same ograniczenia wystarczą aby przerzucać dane i je wymieniać.

To może bardziej tabelarycznie dla dostępu do RAM 8bit:

• RGB565 100MHz dla transferu i równoległego zapisu
• RGB888 200MHz
• ARGB8888 200MHz

I teraz przy dostępie 16 bit do RAM wszystko spadnie o połowę czyli:

• RGB565 50MHz  dla transferu i równoległego zapisu
• RGB888 100MHz
• ARGB8888 100MHz

Pewnie nie ma po co tworzyć kolejnej opcji dla dostępu 32 bit do RAM, ale prosto byłoby podzielić przez 2 opcję dla 16 bit.

I teraz jeżeli miałoby dojść do współdzielenia RAM do wykonywania w nim kodu programu, to już nawet nie jestem w stanie sobie wyobrazić jak to by miało wpłynąć na szybkość i kolizje z obsługą LCD.

Stąd mój postulat żeby na wszelki wypadek dodać dwa 8 nóżkowe układy QSPI FLASH w trybie dual QSPI jeżeli obsługuje to procesor, a zdaje się że H7 obsługuje. No więc po prostu ten flash mógłby pracować w memory mapped mode zamiast wykonywania programu w RAM. Nawet jeżeli byłby nieużywany, to takie małe zabezpieczenie na wszelki wypadek.

 

edit:

W sumie monitor nie wie z jaką częstotliwością przerzucasz dane - gdyby zrobić taką niby analogową sztuczkę żeby zaprogramować LTDC na 12.5MHz, podwoić liczbę linii poziomych, zmniejszyć back i front poche horyzontalne o połowę, dwukrotnie zwiększyć liczbę linii dla porch'ów vertykalnych i byłby taki natywny 320x240 w 640x480. Wielkość framebuffor'a spadłaby do 150KB - ciekawe, pewnie dałoby się to zrobić...

Edytowano Czerwiec 10, 2025 przez virtualny

[atlantis86]

Dzięki za zwrócenie na to uwagi. No cóż, w takim razie chyba faktycznie bezpieczniej zostać przy opcji z pamięcią 16bit.

Tak swoją drogą, jeszcze poszukałem i okazuje się, że TME ma w swojej ofercie większe wyświetlacze o rozdzielczości 320x240. Co prawda opis na stronie mówi o interfejsie 8bit MCU/8080, ale z rozpiski pinów w dokumentacji wynika, że jest to LTDC. Przy tej rozdzielczości pamięć powinna już wyrabiać.

Kolejna sprawa to oczywiście kwestia zasilania. Będzie trzeba albo poszukać gotowego kontrolera generującego wszystkie potrzebne napięcia, albo wrzucić na płytkę kilka dodatkowych przetwornic.

BTW jak patrze jeszcze raz, to oczywiście w przypadku poprzedniego wyświetlacza 640x480 popełniłem błąd. Interfejs to LVDS nie LTDC, a więc nie nadaje się do współpracy z STM32.

Swoją drogą, czy można jakoś zmusić STM32Cube, aby przydzielił osobne zestawy pinów na linie adresowe/danych dla SDRAM i wyświetlacza LCD, np. na ILI9341? Kiedy próbowałem to konfigurować w FMC wychodziło na to, że magistrala jest wspólna. A to będzie problematyczne z punktu widzenia projektu PCB. Osobne magistrale rozwiązywałyby ten problem, ale nie widzę możliwości ustawienia tego w konfiguracji. Dlatego finalnie zacząłem się przyglądać LTDC. A może jednak jakoś da się uzyskać cos takiego w STM32?

Edytowano Czerwiec 11, 2025 przez atlantis86

[virtualny]

54 minuty temu, atlantis86 napisał:

TME ma w swojej ofercie większe wyświetlacze o rozdzielczości 320x240

Ten by Ci robotę zrobił. Framebuffer 4 razy mniejszy. Jaki byczy pixel. 

57 minut temu, atlantis86 napisał:

640x480 popełniłem błąd. Interfejs to LVDS nie LTDC, a więc nie nadaje się do współpracy z STM32.

A nie wystarczyłoby tylko podpiąć po 6 najstarszych bitów z LTDC od kolorów?

 

[atlantis86]

2 godziny temu, virtualny napisał:

Ten by Ci robotę zrobił. Framebuffer 4 razy mniejszy.

I chyba właśnie postawię na te wyświetlacze. Największą wadą tutaj niestety jest konieczność dostarczenia pełnego zestawu napięć, więc będzie trochę zabawy z przetwornicami. Ale niestety, prostsze rozwiązania odpadają. Wyświetlacz na magistrali równoległej (pracujący z FMC) musiałby pracować na tej samej magistrali co SDRAM, a to mocno skomplikowałoby sprawę (znacznie dłuższe ścieżki, dodatkowe pojemności montażowe). Chcąc odseparować te urządzenia jestem skazany na LTDC. W sumie testowo mógłbym spróbować z jakimś szybkim wyświetlaczem na SPI, jednak tutaj widzę dwa problemy:

• Większość dostępnych wyświetlaczy na SPI jest mała - przekątna w okolicy 3,5".
• Większość jest zbudowana na module z goldpinami - wygodne do prototypowania z Arduino, ale jeśli chce się to zastosować w projekcie, to zwiększa gabaryty urządzenia, przynajmniej w porównaniu do tasiemki.

Pierwsze eksperymenty pewnie i tak zacznę na jakimś Discovery.

2 godziny temu, virtualny napisał:

Jaki byczy pixel. 

Piksele i tak byłyby spore - gry które planuję na to odpalić renderują się w niskich rozdzielczościach. Jedynym powodem dla jakiego brałem pod uwagę 640x480 było to, że nie sądziłem, że uda mi się znaleźć duży wyświetlacz 320x240.

2 godziny temu, virtualny napisał:

A nie wystarczyłoby tylko podpiąć po 6 najstarszych bitów z LTDC od kolorów?

LVDS to zupełnie inny standard, wykorzystujący transmisję szeregową po parach różnicowych. Można chyba kupić jakieś kontrolery, pozwalające na podpięcie takiego ekranu do standardowych wejść wideo, ale LTDC w STM32 nie jest z tym kompatybilne.