[SaS]

Należy zacząć od tego, że nie potrzeba kilku rdzeni (takie myślenie wynikało z nieznajomości mechanizmu DMA, którego nie ma w AVR, jest dopiero w Xmega ale te mają za mało RAM na kolorowe wyświetlacze o dużej rozdzielczości). Jak przewidywałem wystarczy jeden resztę załatwi DMA i ewentualnie wbudowany w mikrokontroler sterownik.

Wyświetlacz z linku wymaga sterownika, ESP32 takiego nie ma więc odpada. Nawet nie ma wystarczającej liczby GPIO aby programowo 9co raczej niemożliwe) wysterować wyświetlacz. Pozostaje więc:
1) Sterownik np FT80x, 81x, 9xx, zdecydowanie najłatwiejsze rozwiązanie.
2) Mikrokontroler ze sterownikiem, trochę trudniejsze ale widziałem, że STM dostarcza biblioteki. Warto zapoznać się z budową STM32F429I-DISC1 a najlepiej kupić i poćwiczyć zanim się coś zbuduje samemu. To i tak taniej niż zamówienie PCB no chyba, że ma się możliwość wykonania płytek z metalizacja i raczej obowiązkową maską.
3) FPGA, zdecydowanie najtrudniejsze rozwiązanie ale ze względu na montaż bo bez problemu można znaleźć w TQFP.

Rozwiązanie nr 1 najłatwiejsze, bo można w ELTY kupić PCB ze sterownikiem. Niestety, FT8xx mają ograniczenia. Nie polecam najprostszego FT80x. On jest dobry jak już się zna te układy i wie co można co nie. Niby FT8xx pozwalają na stawianie pojedynczych pikseli ale będzie to działać dosyć wolno. Wydaje się, ze SPI może pracować do 25MHz ale mogą być problemy z dłuższymi lub źle wykonanymi połączeniami.

Najrozsądniejsze wydaje się rozwiązanie nr 2 ale wymaga trochę pracy za to można osiagnąc efekty, które na na FT8xx są niemożliwe lub trudne do osiągnięcia albo działają wolno.

[elvis]

@ElektronPL, niestety nie znam asemblera xtensy, ale prawdę mówiąc takie podejście to raczej niezbyt dobry pomysł. Zobacz jak działa biblioteka FabGL http://www.fabglib.org/ Masz w niej gotową implementację sterownika VGA, to co potrzebujesz jest bardzo podobne, więc powinno bez problemu się udać dostosować kod.

[ElektronPL]

Należy zacząć od tego, że nie potrzeba kilku rdzeni (takie myślenie wynikało z nieznajomości mechanizmu DMA, którego nie ma w AVR, jest dopiero w Xmega ale te mają za mało RAM na kolorowe wyświetlacze o dużej rozdzielczości). Jak przewidywałem wystarczy jeden resztę załatwi DMA i ewentualnie wbudowany w mikrokontroler sterownik.

Wyświetlacz z linku wymaga sterownika, ESP32 takiego nie ma więc odpada. Nawet nie ma wystarczającej liczby GPIO aby programowo 9co raczej niemożliwe) wysterować wyświetlacz. Pozostaje więc:
1) Sterownik np FT80x, 81x, 9xx, zdecydowanie najłatwiejsze rozwiązanie.
2) Mikrokontroler ze sterownikiem, trochę trudniejsze ale widziałem, że STM dostarcza biblioteki. Warto zapoznać się z budową STM32F429I-DISC1 a najlepiej kupić i poćwiczyć zanim się coś zbuduje samemu. To i tak taniej niż zamówienie PCB no chyba, że ma się możliwość wykonania płytek z metalizacja i raczej obowiązkową maską.
3) FPGA, zdecydowanie najtrudniejsze rozwiązanie ale ze względu na montaż bo bez problemu można znaleźć w TQFP.

Rozwiązanie nr 1 najłatwiejsze, bo można w ELTY kupić PCB ze sterownikiem. Niestety, FT8xx mają ograniczenia. Nie polecam najprostszego FT80x. On jest dobry jak już się zna te układy i wie co można co nie. Niby FT8xx pozwalają na stawianie pojedynczych pikseli ale będzie to działać dosyć wolno. Wydaje się, ze SPI może pracować do 25MHz ale mogą być problemy z dłuższymi lub źle wykonanymi połączeniami.

Najrozsądniejsze wydaje się rozwiązanie nr 2 ale wymaga trochę pracy za to można osiagnąc efekty, które na na FT8xx są niemożliwe lub trudne do osiągnięcia albo działają wolno.

Zupełnie nie rozumiem jak ma działać ten układ sterownika FT80x. Czy jego się jakoś programuje? Bo przecież ten wyświetlacz potrzebuje bardzo konkretnych parametrów sygnału a nie jest to jakiś standard.
Nie rozumiem czemu ESP32 odpada, bo nie ma sterownika - uruchomiłem ten wyświetlacz nawet na Arduino UNO (oczywiście nadawałem po prostu czarny obraz bo UNO nie ma tyle pamięci ale mimo wszystko) a ESP32 jest znacznie szybsze i ma wystarczająco pamięci. Poza tym, jak to za mało GPIO? Potrzeba 11 pinów (D0-D7, VS, HS, CLK) a ESP ma więcej (chyba że ja coś źle interpretuje) - komendy dla wyświetlacza wysyłam z innego mikrokontrolera.
Nie chcę się wzbraniać przed czymś nowym, ale po pierwsze standardowo jak się z czymś zaczyna to nie rozumie się tego do końca a to powoduje strach, po drugie nie lubię gotowców bo z doświadczenia często to nie działa albo działa ale nie wykorzystuje pełni potencjału.

[SaS]

Jak nie rozumiesz jak działa FT80x to przeczytaj notę katalogową, tam jest wszystko wyjaśnione.

ESP się nie nadaje. bo nie ma kontrolera i wszystkie sygnały trzeba generować programowo. Z tego powodu wygodniej mieć dwa rdzenie ale nie unikniesz sytuacji, w której te zależności dadzą w łeb. Obstawiam, ze problem pojawi się przy intensywnym używaniu tego samego obszaru RAM przez oba rdzenie.

ZAPAMIĘTAJ! ZAWSZE lepiej używać sprzętu niż programowych rozwiązań! Popróbuj jak działa a często nie, programowy UART na Arduino. Z wyświetlaczem będzie podobnie ale w kierunku czasem działa przeważnie nie. Chcesz wynaleźć koło na nowo, pchać się w jakieś niepewne soft łaty to się pchaj, narobisz się a później pewnie sięgniesz po sprzętowy kontroler bo soft nie daje rady. Jak chcesz zobaczyć jakie mogą być problemy to użyj LCD z łatą 74HC595 po SPI do RPi i spróbuj na tym wyświetlić film. I co, taki szybki, 4 rdzenie a nie radzi sobie za dobrze z wyświetlaniem statycznych obrazków o filmach już nie wspomnę.

Co do gotowców, jaki problem go poprawić? Do FT8xx masz gotowce przygotowane przez FTDI. Do STM ze sterownikiem przez STM-a. Wolisz wszystko pisać od zera? Pisz ale pchasz się w soft rozwiązania. Zastanów się, jak te soft rozwiązania byłyby takie super to po co byłyby sterowniki sprzętowe? naciąganie klientów?

[SaS]

Zerknąłem w notę wyświetlacza i ja bym sobie dał z nim spokój. Dane RGB trzeba wysyłać niejako szeregowo dużo łatwiej gdy wysyła się je równolegle. Wymagana przepływność jest 3 razy mniejsza.
Wygenerowałeś czarny obraz, bo czarny czy biały to banał, na D0-D7 ustawiasz same zera czy jedynki i generujesz zegar i synchro. Zaświeć pojedyncze piksele po kolei R G B wtedy możesz mówić o małym sukcesie bo pełny to gdy nie będzie artefaktów przy wyświetlaniu grafiki na całym wyświetlaczu gdy jeden rdzeń będzie zatrzymywany przez drugi gdy będą dobierać się do wspólnych zasobów a z tego co wiem ESP nie ma dwóportowej pamięci RAM bo to domena sterowników graficznych.

Wydaje mi się, że nie do końca wiesz jak działa CPU i kara graficzna bo gdybyś wiedział to nie kombinowałbyś z softwarową grafiką. Jako nieorientowanego pewnie zmyliły Cię filmy gdzie AVR generuje obraz wideo tyle, że nie zaóważyłeś, że paleta barw ma tam 3 ewentualnie 8 bit a nie 24 a i rozdzielczości mniejsze i to znacznie.

[elvis]

@Sas, nie pisz że esp32 się nie nadaje, tylko że Ty nie potrafisz tego zrobić.

Inni potrafią i jakoś się im udaje wyświetlać obraz na monitorze VGA:

[ElektronPL]

Zerknąłem w notę wyświetlacza i ja bym sobie dał z nim spokój. Dane RGB trzeba wysyłać niejako szeregowo dużo łatwiej gdy wysyła się je równolegle. Wymagana przepływność jest 3 razy mniejsza.
Wygenerowałeś czarny obraz, bo czarny czy biały to banał, na D0-D7 ustawiasz same zera czy jedynki i generujesz zegar i synchro. Zaświeć pojedyncze piksele po kolei R G B wtedy możesz mówić o małym sukcesie bo pełny to gdy nie będzie artefaktów przy wyświetlaniu grafiki na całym wyświetlaczu gdy jeden rdzeń będzie zatrzymywany przez drugi gdy będą dobierać się do wspólnych zasobów a z tego co wiem ESP nie ma dwóportowej pamięci RAM bo to domena sterowników graficznych.

Wydaje mi się, że nie do końca wiesz jak działa CPU i kara graficzna bo gdybyś wiedział to nie kombinowałbyś z softwarową grafiką. Jako nieorientowanego pewnie zmyliły Cię filmy gdzie AVR generuje obraz wideo tyle, że nie zaóważyłeś, że paleta barw ma tam 3 ewentualnie 8 bit a nie 24 a i rozdzielczości mniejsze i to znacznie.

Arduino DUE wyświetla bez problemu grafiki w pełnym kolorze 24bit na całym ekranie i bez żadnych artefaktów tylko nieco za wolno - więc się da i nie było to trudne. Zgadzam się w 100% z tym: wsparcie hardwerowe jest zawsze lepsze od programu. Co nie zmienia faktu, że czasem soft wystarcza a może uprościć budowę fizyczną - zważywszy że będę musiał zaprojektować a potem samemu wykonać taką płytkę to może i warto. Nie chcę zmieniać tego wyświetlacza bo 1 - już go kupiłem a 2 - mimo niewielkiej rozdzielczości jego stripe mode wygląda naprawdę ładnie. Wbrew pozorom ten wyświetlacz mimo że jest horyzontalny to jest rozdzielczość to 160x240 (piksele rozciągnięte na szerokość) - więc nie tak dużo. Po zgrubnym przejrzeniu datasheet tego układu wątpię aby mógł współpracować z tym wyświetlaczem bo on chce równolegle wysyłać wszystkie kolory (ale może można to zmienić bo się jakoś bardzo nie wczytywałem).
Chciałbym wykorzystać do tego wyświetlacza dedykowany układ (do formatu UPS051) i próbowałem znaleźć ale nieskutecznie.

[SaS]

@Sas, nie pisz że esp32 się nie nadaje, tylko że Ty nie potrafisz tego zrobić.

Inni potrafią i jakoś się im udaje wyświetlać obraz na monitorze VGA:

i to jest paleta 24-bit?
Na moje oko do 24-bit brakuje 20.
To jest typowa sztuka dla sztuki, scrolling tragiczny.

[elvis]

A moim zdaniem takie pisanie że się nie da to taki trolling tragiczny.
Nie tylko że się da, ale ja wierzę w kolegę @ElektronPL że obsłuży ten wyświetlacz i podzieli się efektami

A co do kolorów, to nigdzie nie było mowy że ma być 24-bit. W przypadku VGA problemem jest sygnał analogowy, bo zrobienie 8bitowego dac-a jest o wiele trudniejsze, stąd 3 bity koloru. Ale skoro wyświetlacz odbiera dane cyfrowe to i 24-bitowa paleta nie będzie problemem. Bo raczej na tyle kolorów i tak zabraknie pamięci.

[ElektronPL]

A moim zdaniem takie pisanie że się nie da to taki trolling tragiczny.
Nie tylko że się da, ale ja wierzę w kolegę @ElektronPL że obsłuży ten wyświetlacz i podzieli się efektami

A co do kolorów, to nigdzie nie było mowy że ma być 24-bit. W przypadku VGA problemem jest sygnał analogowy, bo zrobienie 8bitowego dac-a jest o wiele trodniejsze, stąd 3 bity koloru. Ale skoro wyświetlacz odbiera dane cyfrowe to i 24-bitowa paleta nie będzie problemem. Bo raczej na tyle kolorów i tak zabraknie pamięci.

Tak czy inaczej spodobało mi się ESP32 więc kupie i spróbuję się pobawić z tym wyświetlaczem. Pamięci starczy bo potrzebuje 115200 bajtów na cały obrazek (160x240x24bit). Podeśle jakieś zdjęcia jak odpalę ten ekranik i zobaczę na ile to się nadaje z czystej ciekawości. A nawet jak będzie to działaś średnio (w co wątpię) to się przynajmniej nowego sprzętu nauczę - na pewno mi się kiedyś jeszcze przyda. Tylko muszę znaleźć jakie są asemblerowe polecenia sterowania GPIO. (nie pogardzę pomocą bo cięzko mi coś znaleźć i chyba będę musiał zerknąć w pliki płytki ESP32 i zobaczyć co się dzieje gdy wykonuje się polecenie digitalWrite())