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

[atlantis86]

Rozglądam się właśnie za elementami do jednego z przyszłych, planowanych projektów - przenośnej konsolki na STM32H753.

Będę potrzebował do niej kolorowego wyświetlacza, który spełniałby następujące wymagania.

• Najlepiej proporcje 4:3. Mój plan zakłada odpalanie na tym portów starszych gier (Wolfenstein, Doom, może Prince of Persia) oraz emulatorów systemów, które były dostosowane do pracy z tymi proporcjami. Ekran panoramiczny zupełnie nie pasuje do tych założeń, gdyż wymusiłby pozostawienie czarnych pasów po bokach.
• Najlepiej rozdzielczość 320x240. Jak wyżej - większa kompatybilność ze starymi tytułami.
• Przekątna pomiędzy 4" i 6".
• Zdolność wyświetlania dynamicznych sekwencji, najlepiej z odświeżaniem w okolicy 60 Hz bez smużenia.
• Z uwagi na powyższe odpadają ekrany SPI. Interfejs 16 lub 24 bitowy, bezpośrednia transmisja danych z MCU.
• Połączenie z płyta główną przez kabel flex - odpadają wszystkie "testowe" rozwiązania z goldpinami.
• Funkcjonalność ekranu dotykowego jest dla mnie całkowicie zbędna.

Możecie polecić coś, co spełniałoby te założenia?

[matsobdev]

Może nie 4 cale, ale niegdyś "GPSy" 3,5" królowały, to w miarę tanio jakieś wyświetlacze np. od Innolux da się dostać.

PS. Dotyk to może być wartość dodana w postaci ochrony ekranu.

Edytowano 1 czerwca przez matsobdev

[kostuch]

Większość "gołych" wyświetlaczy (takich z wiszącą tasiemką) ma opcję konfiguracji interfejsu spi/parallel

np:

https://pl.aliexpress.com/item/1005004869149426.html?spm=a2g0o.detail.pcDetailTopMoreOtherSeller.1.68a12x6T2x6TlA&gps-id=pcDetailTopMoreOtherSeller&scm=1007.40050.354490.0&scm_id=1007.40050.354490.0&scm-url=1007.40050.354490.0&pvid=d15fdcc4-e640-4be2-b0d7-bf32e67cb57c&_t=gps-id:pcDetailTopMoreOtherSeller,scm-url:1007.40050.354490.0,pvid:d15fdcc4-e640-4be2-b0d7-bf32e67cb57c,tpp_buckets:668%232846%238112%231997&pdp_ext_f={"order"%3A"3"%2C"eval"%3A"1"%2C"sceneId"%3A"30050"}&pdp_npi=4%40dis!PLN!57.77!51.99!!!15.12!13.61!%40211b81a317489398611901410eb9cd!12000030822797606!rec!PL!741615005!XZ&utparam-url=scene%3ApcDetailTopMoreOtherSeller|query_from%3A

 

[virtualny]

Nie spotkałem wyświetlaczy 4" i powyżej z tak niską rozdzielczością 320x240.

Poniżej link do wyświetlacza 3.2" 320x240

LCD 16bit

Wyświetlacz z dołu:

z góry:

 

Schemat:

Specyfikacja:

3.2 inch LCDv1.1.pdf

DEVEBOX 1908M.pdf

 

Wyświetlacz możliwości:

• 16Bit równoległy interfejs i8080
• Możliwość przełączenia w tryb SPI (R12 w miejsce R13)
• Sterownik ILI9341
• Dodatkowe 8MB flash SPI z wgranymi czcionkami
• Rezystancyjny touch panel z kompatybilnym chipem XPT2046 
• Zasilanie 3V3 (możliwość przerobienia na 5V)
• Wyświetlacz jest połączony z płytą taśmą flex. Można ją wyjąć i wg załączonego schematu podłączać do własnego interfejsu.

Datasheet ILI9341:
ILI9341 Datasheet.pdf

 

Działanie tego wyświetlacza zarządzanego przez STM32F103C8T6/CBT6:

 

 

 

Edytowano 4 czerwca przez virtualny

[kostuch]

Pytanie po co parallel 16bit (albo i fullRGB 24bit)?

Stare spectrum/atari/commodore miały kolor 8bit.

A jak wyświetlacz ma więcej niż 320x240 to można sobie zasymulować "border" na którym było widać paseczki ładowania z taśmy magnetofonu

 

[ethanak]

Nie chciałem się wtrącać bo niespecjalnie się znam... ale mój Vice na Zero 2 W (lekko podkręconym) wyrabia 50 fps na SPI 320x240.

[atlantis86]

  

Dnia 1.06.2025 o 23:33, matsobdev napisał:

Może nie 4 cale, ale niegdyś "GPSy" 3,5" królowały, to w miarę tanio jakieś wyświetlacze np. od Innolux da się dostać.

PS. Dotyk to może być wartość dodana w postaci ochrony ekranu.

No właśnie jakby nie patrzeć to jednak 3,5" jak na dzisiejsze standardy to dość mały wyświetlacz. Z drugiej strony większość (nieco) większych ma już proporcje 16:9, a więc może się okazać, że realny rozmiar obrazu w formacie 4:3 wyświetlanego na czymś takim nie będzie dużo większy. Dlatego jednak najchętniej celowałbym w coś powyżej 5" w proporcjach 4:3...  

Dnia 4.06.2025 o 10:03, virtualny napisał:

Nie spotkałem wyświetlaczy 4" i powyżej z tak niską rozdzielczością 320x240.

Poniżej link do wyświetlacza 3.2" 320x240

Przekątna 3,2" to jednak bardzo mało. W takim razie może inaczej: czy operacja upscale'owania obrazu z rozdzielczości w okolicy 320x240 do jakiejś wyższej rozdzielczości bardzo obciąża procesor? jest szansa, że STM32H7 wyrobi się w sensownym czasie (zwłaszcza gdyby użyć DMA2D) i nie wpłynie to mocno na framerate?

  

Dnia 4.06.2025 o 12:34, kostuch napisał:

Pytanie po co parallel 16bit (albo i fullRGB 24bit)?

Stare spectrum/atari/commodore miały kolor 8bit.

Bo chyba właśnie taka magistrala jest obsługiwana przez interfejs LTDC w STM32. Więcej linii danych to szybsza transmisja danych z framebuffera do wyświetlacza. A jeśli wyświetlacz potrafi wyświetlać więcej kolorów, to nie chcę wprowadzać sztucznych ograniczeń.

Dnia 4.06.2025 o 12:34, kostuch napisał:

A jak wyświetlacz ma więcej niż 320x240 to można sobie zasymulować "border" na którym było widać paseczki ładowania z taśmy magnetofonu

To jest akurat bardzo dobry pomysł.

  

Dnia 4.06.2025 o 13:03, ethanak napisał:

Nie chciałem się wtrącać bo niespecjalnie się znam... ale mój Vice na Zero 2 W (lekko podkręconym) wyrabia 50 fps na SPI 320x240.

Możliwe, jednak wolałbym wyeliminować wszelkie wąskie gardła w komunikacji pomiędzy wyświetlaczem i pamięcią.

LTDC pozwala chyba jednak znacznie wydajniej korzystać z DMA2D, niż SPI.

[virtualny]

Nie chciałbym być odbierany jako jakiś złośliwy tetryk, czy demotywator, ale muszę tu nakreślić wielkość tego przedsięwzięcia.

 

Jeżeli chcesz tak "po fachowemu" osadzić wyświetlacz na LTDC, to tak naprawdę z poniżej wymienionych powodów polecam ci gotowe rozwiązania od ST. Szczególnie warto zainteresować się kitami w których występuje w nazwie tajemnicza litera "U". W poniżej linkowanym wątku wymieniłem przykładowe kity oraz ich sposób reprezentacji graficznej. Zaś kity z literą "U" wyrabiają się w 60 klatkach i nie obciążają głównego procka.

STM32U5G9J

Wymienione kity podłączają LCD na każdy możliwy (i niemożliwy) sposób - nawet takie cudo jak zapodałem poprzednio na ILI9341 ma swój własny framebuffer i programując grafikę odwołujesz się do RAM, a nie składasz jakichś funkcji odwołujących się do komunikacji z ILI9341. Więc teraz lista powodów z jakich powinieneś skorzystać z gotowych rozwiązań oferowanych przez producenta:

• Cena - zestawy są bardzo tanie i np. STM32U5G9J (LCD 5" 800x480 @60Hz ) nie przekracza 400 zł brutto - gwarantuję, że przy produkcji jednostkowej i prototypowaniu Twojego pomysłu nie wystarczy Ci 1000 złotych na wykreowanie czegoś co będzie miało  o wiele mniejsze możliwości. Nie mówiąc o poprawianiu bugów, które są nieuniknione.
• Wiedza - To producent (ST) wie najlepiej jak korzystać i okiełznać LTDC, który sam go zaprojektował i udowodnił że potrafi działać i to znakomicie, co pokazał w każdym swoim zestawie Discovery,  EVAL itd.
• Czas - Takie rzeczy projektuje dosłownie nie kilka osób, ale sztab fachowców - jedni od projektowania PCB, inni od projektowania interfejsów i w końcu specjaliści od debugowania sprzętowego, jak i programowego.
• Magia - Sztab specjalistów tworzy oprogramowanie, które sprawia, że wyprodukowany zestaw nie jest tylko prawidłowo połączonym elektronicznym scrappem, ale ta rzecz zaczyna być "żywa". Myślę że jednej osobie na przeczytanie wszystkich dokumentacji użytych komponentów i napisanie do nich sterowników mogłoby nie starczyć życia - ten sztab tworzy BSP (Board Suppor Package) - czyli zestaw oprogramowania/funkcji/bibliotek do konfigurowania i zarządzania devboardem.
• rzeczywistość - Zakładając że zdołałbyś przebrnąć przez powyższe zagadnienia samemu, należałoby to uznać tak naprawdę za preludium do preludium, bowiem teraz pozostałaby sprawa oprogramowania emulacji listy maszyn, które ta konsola miałaby udawać. Już przy samym C64 VICE było pisane i rozwijane przez sztab ludzi, a to dopiero raptem rodzina 6502. Nie wspominając że na przykład emulację stacji dysków do C64 zrobił człowiek orkiestra Gideon, który upakował to w logice kilku milionów tranzystorów FPGA, a projekt poprawiał i rozwijał przez wiele lat... Teraz jeszcze dochodzą różnice w używanych adapterach video np. VIC/VICII dla C64 (już muzykę czyli SID'a sobie darujmy). W C64 przykładowo istnieje multum sztuczek odkrytych przez programistów, które działają na sprzęcie (i są używane) w sposób, w jaki nie przewidzieli tego sami konstruktorzy C64. Na przykład wyświetlanie grafiki na borderach ($D016 trick). Dla samej komórki VIC $D011 istnieje multum tricków, które musiałbyś oprogramować, aby każdy program dla tej maszyny działał właściwie. A tu dopiero preludium do C64... A gdzie inne retro sprzęty jak Atari, Sinclair, Amiga czy SNES...

 

Życzę wielu sukcesów i radości z projektowania.

 

[matsobdev]

Zawsze zostaje 640x480 - piksel z bufora na 2x2 pikselach na LCD Tutaj łatwo już znajdziesz 5 calowy czy podobny. Sprawdź jeszcze Panelook. Może nie w kwestii zakupu, ale zawsze można wiedzieć, co można znaleźć i jak to nazwać, szukając tego.

 

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.

Edytowano 5 czerwca przez matsobdev

[atlantis86]

13 godzin temu, virtualny napisał:

Nie chciałbym być odbierany jako jakiś złośliwy tetryk, czy demotywator, ale muszę tu nakreślić wielkość tego przedsięwzięcia.

Z "wielkości" przedsięwzięcia zdaję sobie sprawę i właśnie trochę o to w nim chodzi. To ma być wyzwanie, żeby nauczyć się czegoś nowego.

Między innymi dlatego w tym wypadku rezygnuję z mojego typowego podejścia (samodzielne trawienie płytki) i będę chciał zbudować to na czterowarstwowej płytce z fabryki, z dwiema wewnętrznymi warstwami wykorzystanymi na masę i VCC.

13 godzin temu, virtualny napisał:

Jeżeli chcesz tak "po fachowemu" osadzić wyświetlacz na LTDC, to tak naprawdę z poniżej wymienionych powodów polecam ci gotowe rozwiązania od ST. Szczególnie warto zainteresować się kitami w których występuje w nazwie tajemnicza litera "U". W poniżej linkowanym wątku wymieniłem przykładowe kity oraz ich sposób reprezentacji graficznej. Zaś kity z literą "U" wyrabiają się w 60 klatkach i nie obciążają głównego procka.

No dobrze, ale to są devkity. Zaletą devkita jest to, że zawiera wszystko. W niektórych przypadkach może to być jednak wadą, bo zawiera także elementy, których zupełnie nie potrzebuję i nie mam zamiaru wykorzystywać. Nie będzie natomiast kilku tych, których akurat potrzebuję, więc będę musiał je dodać na zewnętrznym module. To sprawi, że koniec końców urządzenie będzie toporne.  Projektując wszystko samodzielnie mam szansę upchnąć wszystko na jednej płytce, dodatkowo rozmieszczając gniazda i przyciski tak, aby pasowały do mojego konkretnego zastosowania.

Devkit jest dobry do przetestowania części programowej. I nie mówię - biorę pod uwagę zakup jakiegoś Discovery z STM32H7 i wyświetlaczem, żeby zacząć coś pisać równolegle z projektowaniem własnego hardware'u.

13 godzin temu, virtualny napisał:

• Cena - zestawy są bardzo tanie i np. STM32U5G9J (LCD 5" 800x480 @60Hz ) nie przekracza 400 zł brutto - gwarantuję, że przy produkcji jednostkowej i prototypowaniu Twojego pomysłu nie wystarczy Ci 1000 złotych na wykreowanie czegoś co będzie miało  o wiele mniejsze możliwości. Nie mówiąc o poprawianiu bugów, które są nieuniknione.

Doskonale zdaję sobie z tego sprawę. Przy czym sporą część elementów już mam, bo pozostały mi po innych projektach, co powinno nieco zmniejszyć koszt. Elektronika amatorska to nie jest tanie hobby.

13 godzin temu, virtualny napisał:

• Wiedza - To producent (ST) wie najlepiej jak korzystać i okiełznać LTDC, który sam go zaprojektował i udowodnił że potrafi działać i to znakomicie, co pokazał w każdym swoim zestawie Discovery,  EVAL itd.
• Czas - Takie rzeczy projektuje dosłownie nie kilka osób, ale sztab fachowców - jedni od projektowania PCB, inni od projektowania interfejsów i w końcu specjaliści od debugowania sprzętowego, jak i programowego.
• Magia - Sztab specjalistów tworzy oprogramowanie, które sprawia, że wyprodukowany zestaw nie jest tylko prawidłowo połączonym elektronicznym scrappem, ale ta rzecz zaczyna być "żywa". Myślę że jednej osobie na przeczytanie wszystkich dokumentacji użytych komponentów i napisanie do nich sterowników mogłoby nie starczyć życia - ten sztab tworzy BSP (Board Suppor Package) - czyli zestaw oprogramowania/funkcji/bibliotek do konfigurowania i zarządzania devboardem.

Nie przesadzajmy. To nie są żadne czary, to są sprzętowe interfejsy wbudowane w mikrokontroler. Nie tylko są dokładnie opisane w dokumentacji układu, ale także ich obsługę obejmują biblioteki HAL dostarczone przez STM oraz narzędzia takie jak STM32Cube. Pod tym względem ich obsługa nie różni się aż tak bardzo od zwykłego SPI czy UART-a i nie wymaga posiadania żadnej "wiedzy tajemnej".

I tak - od strony sprzętowej jest kilka pułapek na które można wpaść. Bo z jednej strony mamy dość wysokie częstotliwości, z drugiej równoległe magistrale, gdzie poszczególne linie powinny być podobnej długości i trzymać impedancję. To jest właśnie jeden z powodów dla których jednak stawiam na czterowarstwową płytkę z fabryki, a nie dwustronną, domowej produkcji.

Zresztą mogę powiedzieć, że parę lat temu słyszałem już, że w domowych warunkach nie da się używać wbudowanego w mikrokontrolery interfejsu FastEthernet - większość amatorskich projektów używała wolnego ENC28J60 na SPI, nawet jeśli MCU zawierał znacznie szybszy MAC. Tymczasem w kilku swoich projektach udało mi się użyć tego interfejsu z zewnętrznym PHY na magistrali RMII (a więc 50 MHz), montując to na samodzielnie trawionej płytce. Jasne, testu EMC pewnie by nie przeszedł, ale działa stabilnie. Korzystając z SDIO na wyższych częstotliwościach faktycznie trafiłem na problemy, gdy różnica długości ścieżek była za duża (i wtedy faktycznie już musiałem sięgnąć po fabryczną płytkę). Tak więc mniej-więcej jestem świadom problemów, na jakie trzeba będzie uważać. I prawdę mówiąc oczekuję, że bardziej problematyczna może się okazać pamięć SDRAM na interfejsie FMC, niż wyświetlacz.

13 godzin temu, virtualny napisał:

• rzeczywistość - Zakładając że zdołałbyś przebrnąć przez powyższe zagadnienia samemu, należałoby to uznać tak naprawdę za preludium do preludium, bowiem teraz pozostałaby sprawa oprogramowania emulacji listy maszyn, które ta konsola miałaby udawać. Już przy samym C64 VICE było pisane i rozwijane przez sztab ludzi, a to dopiero raptem rodzina 6502. Nie wspominając że na przykład emulację stacji dysków do C64 zrobił człowiek orkiestra Gideon, który upakował to w logice kilku milionów tranzystorów FPGA, a projekt poprawiał i rozwijał przez wiele lat..

No i właśnie po to ludzkość stworzyła kompilatory, żeby nie trzeba było za każdym razem wynajdywać koła na nowo.

Tak, pisanie od podstaw gry czy emulatora retro platformy byłoby ogromnym przedsięwzięciem. Na szczęście nie muszę tego robić. Istnieje całe mnóstwo otwartego oprogramowania, które można przeportować. I ludzie to robią, czego przykładem są projekty emulatorów uruchamianych na ESP32 albo Raspberry Pi Pico. Podobnie ze starymi grami - jeśli dostępny jest kod źródłowy, to często wystarczy pozbyć się odwołań do biblioteki SDL, zastępując je własną warstwą pośredniczącą w komunikacji ze sprzętem. W przypadku takiego Dooma spora część pracy już została zrobiona, bo istnieją np. takie projekty jak Doom Generic, gdzie wystarczy dostarczyć własne callbacki do obsługi grafiki, sterowania i systemu plików (chociaż obsługa dźwięku wymaga już trochę więcej pracy).

Edytowano 6 czerwca przez atlantis86

[virtualny]

4 godziny temu, atlantis86 napisał:

Nie przesadzajmy. To nie są żadne czary, to są sprzętowe interfejsy wbudowane w mikrokontroler.

Jak na człowieka, który przed chwilą poszukiwał wyświetlaczy, które ciężko (jeżeli w ogóle) można znaleźć wypowiadasz się jak znawca, czy ktoś kto uruchomił podobne projekty wielokrotnie. Wszystko w sferze słów jest proste, a potem tworzy się vaporware... Na moje niefachowe oko, to 4 warstwy mogą nie wystarczyć  na zroutowanie dużego mikrokontrolera i extra ramu, zalecałbym analizę schematów i gerberów wymienionych poprzednio zestawów, gdzie jedynym zestawem na 4 layers PCB był zestaw STM32U5G9J. Discovery kits startują od 8 layers. Był taki ponieważ używany chip miał wbudowane 3MB internal static ram, więc nie trzeba było routować połączeń pomiędzy extra ramem a MCU, tylko ram procesora został użyty jako framebuffer. 

4 godziny temu, atlantis86 napisał:

Istnieje całe mnóstwo otwartego oprogramowania, które można przeportować.

Czyli wracamy do propozycji ethanak'a :
 

Dnia 4.06.2025 o 13:03, ethanak napisał:

Nie chciałem się wtrącać bo niespecjalnie się znam... ale mój Vice na Zero 2 W (lekko podkręconym) wyrabia 50 fps na SPI 320x240.

 

No i co dla mnie w tutaj najważniejsze:

4 godziny temu, atlantis86 napisał:

No i właśnie po to ludzkość stworzyła kompilatory, żeby nie trzeba było za każdym razem wynajdywać koła na nowo.

 

Zaraz przyjrzymy się "mądrości" kompilatora, powiem w skrócie że każdy kto jest w stanie zrozumieć assembler, gdyby zatrudnił w swojej firmie programistę w assemblerze i zobaczyłby, że ten programista tworzyłby takie "mądrości" jak ów kompilator, stwierdziłby że zatrudnił idiotę i natychmiast go zwolnił, jako człowieka wprowadzającego zamieszanie i zwiększone koszty w projektach jakie prowadzi. Ale spójrzmy na konkrety aby nie być gołosłownym - napisałem i skompilowałem prostą funkcję, zliczającą pętlę for z jednym rozkazem "NOP" w pętli. Rozkaz "NOP" jest tylko po to, żeby ktoś słabo zaznajomiony w assemblerze był w stanie rozpoznać "środek" pętli for. Oto kod w C (bez włączonej optymalizacji "O0") 

void function1(void){
	uint32_t i;
	for(i = 0 ; i < 222 ; i++){
		__NOP();
	}
}

int main(void)
{
	function1();
	while(1){;}
}

 

Teraz może w odwrotnej kolejności - pokażę najpierw jak ja bym zaimplementował tą pętlę for:

0800010c <function1>: // 12 bytes long
 800010c:	2300      	movs	r3, #0
 800010e:	bf00      	nop
 8000110:	3301      	adds	r3, #1
 8000112:	2bdd      	cmp	r3, #221	@ 0xdd
 8000114:	d9fb      	bls.n 	800010e
 8000116:	4770      	bx	lr

 

Program robi dokładnie to, co pętla w C zażądała: iteruje 222 razy w pętli i używa "NOP'a" W rejestrze LR jest adres powrotu z wywołania, a rejestr R3 jest zmienną. Jeżeli chodzi o zamazanie wartości rejestru R3 bez jego odtworzenia jest to zgodne ze standardem AACP, gdzie nie trzeba odtwarzać czterech najmłodszych rejestrów  (R0-R3) po wywołaniu procedury. Oczywiście kto by chciał mógłby dodać na początku "push {r3)" i przed powrotem z procedury (przed "bx lr") "pop {r3}. Nie ma się nad czym rozwodzić, program zajmuje 12 bajtów, jest banalnie prosty i robi dokładnie to, czego się od niego oczekuje.

 

Więc teraz przyjrzyjmy się jaki kod wynikowy wygenerował ten mądry kompilator - tu naprawdę bez czepiania się będzie spora litania:

 

0800010c <function1>: // 38bytes long
 800010c:	b480      	push	{r7}
 800010e:	b083      	sub	sp, #12 //!!! po co 12 bajtów skoro potrzebne 4?
 8000110:	af00      	add	r7, sp, #0 // !!! po co? dlaczego nie mov r7,sp ???
 8000112:	2300      	movs	r3, #0
 8000114:	607b      	str	r3, [r7, #4] // zmienna na stos
 8000116:	e003      	b.n	8000120 <function1+0x14>
 8000118:	bf00      	nop
 800011a:	687b      	ldr	r3, [r7, #4]
 800011c:	3301      	adds	r3, #1
 800011e:	607b      	str	r3, [r7, #4]
 8000120:	687b      	ldr	r3, [r7, #4]
 8000122:	2bdd      	cmp	r3, #221	@ 0xdd
 8000124:	d9f8      	bls.n	8000118 <function1+0xc>
 8000126:	bf00      	nop	// Że niby PO CO???
 8000128:	bf00      	nop	// Że niby PO CO???
 800012a:	370c      	adds	r7, #12
 800012c:	46bd      	mov	sp, r7
 800012e:	bc80      	pop	{r7}
 8000130:	4770      	bx	lr

 

Teraz polecę w podpunktach:

• Kompilator udowodnił, że to co się da zrobić w 12 bajtach można zrobić także w 38
• Niby do rozkazu "push {r7} specjalnie nic nie mam, gdyby nie to, że kompilator w swojej mądrości rozpoczyna w tym miejscu deklarowanie zmiennej na stosie nie wiedzieć po jaką cholerę w tym wypadku...
• drugi rozkaz "sub sp, #12" oznacza zmniejszenie stosu o 12 bajtów w celu umieszczenia na nim zmiennej o długości 4 bajtów!!! Już mój domniemany zatrudniony przeze mnie programista w assemblerze zapala w mojej głowie czerwoną kontrolkę i pytanie: "Czy to jest pomyłka, czy on jest idiotą?". Oczywiście jestem przekonany, że nie znajdzie się nikt, kto byłby w stanie uzasadnić konieczność allokacji 12 bajtów dla zmiennej 4 bajtowej, jak i osadzania tej lokalnej zmiennej na stosie (!)
• trzeci rozkaz "add    r7, sp, #0" - chyba w tym wypadku kompilator chce się popisać swoją mądrością, że potrafi prosty rozkaz "mov r7,  sp" zamienić na  rozkaz "add    r7, sp, #0" używający jednostki arytmetyczno-logicznej w myśl zasady "zapłaciłeś, to masz i używaj" ???
• kolejny rozkaz "mov r3, #0" to jeden z niewielu do jakich nie mam żadnych obiekcji
• Rozkaz "str    r3, [r7, #4] " jest tylko konsekwencją tego że zmienna lokalna zostaje posłana na stos ALE ... kolejny idiotyzm to offset dla zmiennej to "#4" i oczywiście nie ma na to żadnego logicznego wyjaśnienia (!!!)
• "8000116:    b.n    8000120" tu następuje skok do porównania wielkości zmiennej w pętli. Mogłoby go nie być wcale, ale ok, rozumiem, że to jest taka sztampa na wypadek aby nie robić zbędnej iteracji gdyby kod w C miał od razu spełniony warunek na przykład "for( i = 225 ; i < 222 ; i++), więc to wybaczam - nie czepiam się.
• rozkaz "nop" - kolejny rozkaz bez zastrzeżeń do niego
• "ldr    r3, [r7, #4] - chciałbym podkreślić że w tym dokładnie wypadku w rejestrze R3 jest cały czas dostępna zmienna iteracji no ale kompilator w swej mądrości  stwierdza że "mądrzejsze" byłoby komunikowanie się ze zmienną poprzez stos (?)
• "adds r3, #1" to odpowiednik naszego "i++" - bez zastrzeżeń
• "str    r3, [r7, #4]" - zapisanie zmiennej na stos - z uwagami ja wyżej - ani nie ma takiej konieczności czy logiki, ani nie ma uzasadnienia dla offsetu "#4"
• UWAGA: "ldr    r3, [r7, #4] - szczyt geniuszu i ostrożności - procesor dla pewności odczytuje zmienną ze stosu do tego samego rejestru, z którego jeden rozkaz wcześniej ("str    r3, [r7, #4]") tą zmienną z rejestru zapisał - mój wyimaginowany programista zatrudniony przeze mnie nie dokończył prostej pętli - wyrzuciłem go natychmiast na zbitą twarz, uznając że jest zbędnym balastem dla firmy. Ale cóż ... bądźmy dobrej myśli i zobaczmy że kompilator w swojej przeogromnej mądrości jeszcze potrafi nas zaskoczyć...
• "cmp    r3, #221" - sprawdzenie warunku - bez uwag
•  "8000124:    bls.n    8000118" - powtarzanie pętli jeżeli warunek niespełniony
•  UWAGA: "8000126:    nop" tylko kompilator w swojej mądrości wie, że po tak wyczerpującej pętli procesor musi "prewencyjnie odpocząć" otrzymując rozkaz "nic nie rób" (No operation")
• " nop " I prawem serii kompilator ponawia kolejnego nop'a (!!!) Dlaczego? Bo ponieważ.
• "adds r7, #12" początek przywracania stosu, którego w ogóle nie trzeba było w tym przypadku zmieniać... (wystarczyłby sam "R3")
• "mov sp, r7"  - teraz kompilator ciut "zaszpanował", że odwrotnie jak w wypadku trzeciego rozkazu "add    r7, sp, #0" zamiast "mov r7, sp" można użyć najprostszej i najbardziej czytelnej formy... i gdyby nie to że te zabawy ze stosem były nadmiarowe, to byłyby propsy.
• "pop {r7}" odtworzenie R7, co należy uznać za słuszne, gdyż jak wspomniałem wg AACP można zamazać tylko 4 najmłodsze rejestry (Jeżeli procedura nie oddaje parametru zwrotnego w R0). Jednak do znudzenia będę powtarzał że jest to wynik redundancji kodu.
• "bx lr" - no comments

Ufff - tyle zajmuje stworzonej przez "mądrość" kompilatora prostej pętli "for(i = 0 ; i < 222 ; i++) { __NOP();}

I nie myślcie że tylko ta pętla będzie szczytem idiotyzmu, bo cały program jak spojrzeć będzie obfitował w takie smaczki jak przerzucanie danej z rejestru na przykład R4 do R3 ("mov r3, r4") i natychmiast po tym  z R3 do R4 (!!!) "mov r4, r3" - tak wygląda geniusz kompilatora !!! Bezmyślne allokacje stosu, redundancja kodu i kolejne szaleństwa jak bezzasadne "nop'y".

A 99,9% użytkowników będzie powtarzać utarte slogany jak "Compiler is your's best friend" przyzwyczajonych do tego, że jak coś nie wychodzi, to trzeba wymienić proca na "lepszy/szybszy/bardziej nowoczesny".

 

I na pożegnanie powstrzymam szarżujących na mnie obrońców kompilatora z tekstami że użyłem "O0" czyli BEZ optymalizacji (przy optymalizacjach też nieraz można się za głowę złapać" ALE:

 

Istnieje coś takiego jak "MISRA" , a jest to  takie wydumane wyobrażenie mające na celu generowanie kodu bezpiecznego i powtarzalnego w szczególności dla urządzeń medycznych i sterowania odpowiedzialnych części jak np. rozjazdy kolejowe... Otóż organizatorzy/fundatorzy (czy jak zwał "zarządzacze") tej całej MISRY wydumali sobie że w miejscu kiedy kompilator tworzy największy syf przy "O0" kod jest najbardziej "safe i portable".

 

 

 

 

 

 

 

 

 

 

[atlantis86]

21 godzin temu, virtualny napisał:

Jak na człowieka, który przed chwilą poszukiwał wyświetlaczy, które ciężko (jeżeli w ogóle) można znaleźć wypowiadasz się jak znawca, czy ktoś kto uruchomił podobne projekty wielokrotnie.

Jeśli przed chwilą celowo użyłeś chwytu erystycznego żeby wyjść na bardziej kompetentnego w dyskusji, to musisz trochę poćwiczyć. Słabo ci idzie i niestety widać to jak na dłoni. Jeśli nie zrobiłeś tego celowo, to radze poczytać czym jest erystyka. To co próbowałeś zrobić nazywa się fałszywą dychotomią - czyli sztucznym sprowadzeniem sytuacji do jedynie dwóch możliwości. Twoim zdaniem muszę być albo początkującym (który nie ma pojęcia o czym mówi) albo ekspertem (który nie potrzebuje pomocy). W prawdziwym świecie zwykle wypadamy gdzieś pomiędzy.

I właśnie tak jest w moim przypadku. Sporo konstrukcji już złożyłem (jak nie wierzysz, to niejedna jest opisana na tym forum). Niektóre nawet znalazły się na stronie głównej Hackaday'a. Podpinałem już do STM32 wyświetlacze na magistrali równoległej i obsługiwałem je przez HAL, chociaż były to chińskie moduły na z goldpinami (a teraz chciałbym użyć bardziej profesjonalnego LCD na tasiemce). Nie korzystałem jednak z bardziej zaawansowanych "ficzerów", jak np. DMA2D.

Miałem po prostu nadzieję, że ktoś może korzystał z takiego wyświetlacza i jest w stanie polecić konkretny model/źródło, a także podzieli się doswiadczeniami.

21 godzin temu, virtualny napisał:

Wszystko w sferze słów jest proste, a potem tworzy się vaporware... Na moje niefachowe oko, to 4 warstwy mogą nie wystarczyć  na zroutowanie dużego mikrokontrolera i extra ramu

Ta opinia jest oparta na czym? Tak się składa, że schematy różnych konstrukcji już analizowałem. Zobacz sobie chociażby polski projekt komputera jednopłytkowego Sarge-at91 (opisywany w "Elektronice Praktycznej" w 2009 roku). Konstrukcja wykorzystuje dwustronną płytkę, na której znajdują się dwa układy pamięci SDRAM (u mnie będzie tylko jeden) i trochę różnych peryferiów. Do tego sprawę komplikuje jeszcze fakt, że trzeba było poprowadzić jeszcze jedną domenę zasilania, bo użyty tam at91 wymagał zewnętrznego stabilizatora dla vCore. Autor konstrukcji nie wszystko zrobił zgodnie ze sztuką (płytka dwustronna, więc trzeba było iść na pewne kompromisy) ale układ działa. I to w sposób powtarzalny, bo sam złożyłem i uruchomiłem kiedyś kilka sztuk tego komputerka.

Mając do dyspozycji cztery warstwy powinno być dużo, dużo łatwiej. Po pierwsze mamy dostęp do ciągłej warstwy referencyjnej masy pod liniami szybkich magistral, po drugie odpada problem z prowadzeniem zasilania i masy.

21 godzin temu, virtualny napisał:

 Discovery kits startują od 8 layers.

Tak, ale Discovery to zestaw deweloperski. Z definicji na płytce trzeba upchnąć jak najwięcej peryferiów. Więcej warstw na płytce pozwala znacznie łatwiej to ogarnąć, do tego producent zamawia PCB masowo, więc działa prawo skali - nie ma sensu oszczędzać na warstwach.

21 godzin temu, virtualny napisał:

Czyli wracamy do propozycji ethanak'a :

Gdybym chciał sobie zrobić konsolę na Raspberry Pi Zero, to zrobiłbym konsole na Raspberry Pi Zero. Projekt na jeden weekend, do ogarnięcia na płytce uniwersalnej, z wykorzystaniem już istniejącego oprogramowania w stylu RetroPie.

Tyle tylko, że ja szukam projektu, który będzie kolejnym wyzwaniem i przy którym się czegoś nauczę: obsługi wyświetlacza, korzystania z bardziej zaawansowanych peryferiów, pisania bootloaderów, projektowania bardziej zaawansowanych płytek w KiCadzie.

21 godzin temu, virtualny napisał:

Zaraz przyjrzymy się "mądrości" kompilatora, powiem w skrócie że każdy kto jest w stanie zrozumieć assembler, gdyby zatrudnił w swojej firmie programistę w assemblerze i zobaczyłby, że ten programista tworzyłby takie "mądrości" jak ów kompilator, stwierdziłby że zatrudnił idiotę i natychmiast go zwolnił, jako człowieka wprowadzającego zamieszanie i zwiększone koszty w projektach jakie prowadzi.

Sorry, ale to jest oczywista oczywistość. Tak, doskonale zdaję sobie sprawę z tego, że nawet dzisiaj kompilatory nie generują kodu tak wydajnego, jak coś napisanego natywnie w asemblerze. Zwłaszcza jeśli źródło powstało zgodnie ze wszystkimi współczesnymi paradygmatami, które akcent stawiają na czytelności i przenośności kodu. Tylko coś za coś. Nie byłbyś w stanie tworzyć współczesnych, dużych projektów programistycznych, pisząc je od podstaw w asemblerze.

No i najważniejsze: jak właściwie to zagadnienie ma się do tego, o czym rozmawiamy? Nijak. Bo jednak zdecydowana większość bibliotek doskonale przenosi się pomiędzy różnymi rodzinami i architekturami, działając poprawnie po skompilowaniu. A wspomniany "Doom" jest tutaj swoistym symbolem, bo ludzie odpalali go właściwie na wszystkim, co tylko było w stanie uciągnąć tę grę. O ile oryginalny kod od ID Software posiadał trochę asemblerowych wstawek x86, to współczesne forki są znacznie bardziej przenośne.

Edytowano 7 czerwca przez atlantis86

[virtualny]

2 godziny temu, atlantis86 napisał:

Jeśli przed chwilą celowo użyłeś chwytu erystycznego żeby wyjść na bardziej kompetentnego w dyskusji, to musisz trochę poćwiczyć. Słabo ci idzie i niestety widać to jak na dłoni.

Jeżeli tracę czas, kompletuję schematy, fotki i dokumentację do LCD i widzę 0 pobrań, a Ty jak panna na wydaniu zmieniasz zdanie, a  w sferze słów wszystko jest proste. To jak mam Ciebie traktować?

Pomijam już że przez grzeczność mógłbyś zrozumieć i docenić że straciłem czas próbując Tobie pomóc...

 

3 godziny temu, atlantis86 napisał:

Gdybym chciał sobie zrobić konsolę na Raspberry Pi Zero,

 

Ja miałem na myśli reużycie przez rekompilację Vice - sorry, ale znów wychodzi tu zaprzeczenie samemu sobie, że chcesz wyzwania, by w końcu użyć gotowego rozwiązania. Dla mnie rekompilacja Vice do jakiejś platformy to faktycznie byłoby wyzwanie.

 

3 godziny temu, atlantis86 napisał:

No i najważniejsze: jak właściwie to zagadnienie ma się do tego, o czym rozmawiamy? Nijak.

Pytasz? Stwierdzasz? Czy sam sobie odpowiadasz?

Ja  zająłem stanowisko co do twojego entuzjastycznego podejścia co do znakomitości kompilatora.  To nie ja rozpocząłem rozmowę o kompilatorach prawda? Popraw mnie jeśli się mylę.

I tak przy okazji fajnie się przekonać na czym stoi MISRA z obowiązkowym kompilowaniem bez optymalizacji no nie? Sterowanie urządzeń odpowiedzialnych za bezpieczeństwo i życie...

 

2 godziny temu, atlantis86 napisał:

Miałem po prostu nadzieję, że ktoś może korzystał z takiego wyświetlacza i jest w stanie polecić konkretny model/źródło, a także podzieli się doswiadczeniami.

Przecież próbowałem podzielić się doświadczeniem, zrobiłem zdjęcia, odkopałem PDFy i schemat a Ty zlałeś to jednym zdaniem bez choćby słowa podziękowania. Teraz odpowiedz sobie sam - czy w ogóle tutaj warto komukolwiek próbować pomagać?

 

Proszę bardzo dzielę się doświadczeniami poniżej na zdjęciu wyświetlacz, jakiego używałem do odpalania grafiki na dwóch różnych zabij mnie nie pamiętam ale chyba allwinerach. Jeden taki co często był używany w odtwarzaczach DVD, F1xxx cośtam i drugi coś miał w nazwie jak S3... sprawdziłem w zakupach Licheepi Zero V3S oraz Lichee Nano. Zabij mnie nie mogę znaleźć i zrobić fotki.

 

Te Lichee było kiepsko z dokumentacją i nie przypadły do gustu. Odpalały się na VGA (złączu D-SUB) i działało, jak bym miał ze sto lat dodatkowego życia, to pewnie bym się w nie bardziej zagłębił. Co do wyświetlaczy i doświadczeń:

Generalnie wszystkie te wyświetlacze mają tasiemkę i na niej są wyprowadzone kolory i wyjścia sterujące jak Hsync i Vsync. No i z tego wszystkiego co robiły te allwinery wyszła taka myśl że można zamiast tracić kasę na wyświetlacz, wyprowadzić to wszystko na VGA (D-SUB) i odtwarzać na normalnych monitorach - to ta druga, biała płytka - nie mój projekt ale działa. Były też pomysły że na przykład można by pozbawić wyświetlacza DISCO F746G i mieć gotowy sterownik VGA, ale nie znalazło się w dobrej cenie z uszkodzonym LCD.

Doświadczenie - praktycznie dowolny wyświetlacz do którego masz chociaż schemat wyprowadzeń na tasiemce. Na zdjęciu widać też przejściówkę z allwinnera na VGA, tak to działało.

Wszystko ma ograniczenia np. to na ESP32 przy rozdzielczości 800x600 zaczyna glitchować. 640x480 uciągnie.

 

Nie ma za co...

 

[atlantis86]

16 godzin temu, virtualny napisał:

Jeżeli tracę czas, kompletuję schematy, fotki i dokumentację do LCD i widzę 0 pobrań, a Ty jak panna na wydaniu zmieniasz zdanie, a  w sferze słów wszystko jest proste. To jak mam Ciebie traktować?

Ok, chciałbym tylko zauważyć, że mój (lekko) złośliwy komentarz był jedynie odpowiedzią na złośliwość z Twojej strony. To nie ja użyłem argumentu ad personam w połączeniu z erystycznymi manipulacjami.

Jeśli poczułeś się dotknięty brakiem podziękowania za załączone materiały, to oczywiście dziękuję. Problem polega na tym, że proponowane przez Ciebie rozwiązanie nie spełnia wymagań o których pisałem w oryginalnym poście. Wyświetlacze na ILI9341 akurat kojarzę dość dobrze. Czegoś takiego użyłem w jednym swoim projekcie. Był ona także użyty w jednym cudzym, który kiedyś składałem. To są niezwykle popularne wyświetlacze, stosowane w wielu projektach. Wygodnie się je obsługuje przez magistralę równoległą, za pomocą FMC w STM32. Niestety ciężko znaleźć coś o wyższej przekątnej niż 3,5". A to niestety mało. Zaproponowany przez Ciebie model ma jedynie 3,2". Rozumiesz już dlatego pominąłem tamtą sugestię bez komentarza i szukałem dalej?

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. Odpadają więc rozwiązania na ILI9341 i zostaje LTDC.

16 godzin temu, virtualny napisał:

Pomijam już że przez grzeczność mógłbyś zrozumieć i docenić że straciłem czas próbując Tobie pomóc...

Piszesz o grzeczności, ale to Ty pierwszy zacząłeś osobiste wycieczki. Poza tym, znacznie więcej czasu zmarnowałeś na zupełnie niezwiązane z tematem dywagacje na tematy oczywiste (np. rozważania nad jakością asemblerowego kodu generowanego przez kompilatory), przekonywanie mnie że projekt jest niewykonalny, pomimo braku argumentów merytorycznych i empirycznych dowodach wskazujących na coś zupełnie innego, istnieją przecież amatorskie projekty wykorzystujące rozwiązania o których mówimy.

16 godzin temu, virtualny napisał:

Ja miałem na myśli reużycie przez rekompilację Vice - sorry, ale znów wychodzi tu zaprzeczenie samemu sobie, że chcesz wyzwania, by w końcu użyć gotowego rozwiązania. Dla mnie rekompilacja Vice do jakiejś platformy to faktycznie byłoby wyzwanie.

Nieźle. To już drugi raz, jak używasz fałszywej dychotomii w tej dyskusji. Robisz to specjalnie? Trochę głupie zagranie kiedy się już wie, że druga strona ogarnia erystykę. Z drugiej strony w polskich szkołach nie uczy się podstaw retoryki, więc jestem w stanie uwierzyć, że to nie było celowe...

W takim razie pozwól, że wyjaśnię: poziom trudności projektów stanowi spektrum. Pomiędzy prostym odtworzeniem cudzego projektu i zbudowaniem czegoś absolutnie od podstaw istnieją jeszcze wartości pośrednie. Przeportowanie Dooma na urządzenie, które samemu się zaprojektowało to ciągle ambitny projekt, o sporym potencjale edukacyjnym. Przynajmniej ja tak uważam.

16 godzin temu, virtualny napisał:

Generalnie wszystkie te wyświetlacze mają tasiemkę i na niej są wyprowadzone kolory i wyjścia sterujące jak Hsync i Vsync.

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

16 godzin temu, virtualny napisał:

No i z tego wszystkiego co robiły te allwinery wyszła taka myśl że można zamiast tracić kasę na wyświetlacz, wyprowadzić to wszystko na VGA (D-SUB) i odtwarzać na normalnych monitorach - to ta druga, biała płytka - nie mój projekt ale działa.

A widzisz, coś takiego też początkowo brałem pod uwagę. 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.

Edytowano 8 czerwca przez atlantis86

[Elvis]

@atlantis86, dostępne są wyświetlacze 7-10" z wejściem VGA, przykładowo: https://pl.aliexpress.com/item/1005008558996530.html