Akcelerator dla wyświetlaczy graficznych

[RFM]

To, że kolorowe wyświetlacze graficzne podłączone do AVR działają z szybkością żółwia z amputowanymi trzema kończynami wie każdy, kto wypróbował wyświetlać w sposób dynamiczny. Wydaje się, że jedyna alternatywa to FT8xx ale sama płytka z takim akceleratorem kosztuje 65 zł. W porównani do ceny wyświetlacza 128x128 za 20..25zł to wysoka cena. Ponadto FT8xx steruje bezpośrednio matrycą a nie sterownikiem wyświetlacza. Czy nie ma innego wyjścia i wyświetlacz będzie działać jak na filmnie z linku https://es2.000webhostapp.com/Szescian_3D_Arduino_UNO.mp4? Nie może działać tak https://es2.000webhostapp.com/Szescian_3D_ARM_z_DMA.mp4?

MOZE! Praktycznie skończyłem akcelerator dla wyświetlaczy. Na razie małych, do 128x128 na STM32F105RBT6. Układ kosztuje 13zł, więc jest dwa razy tańszy niż FT8xx a kosztuje połowę tego co sam wyświetlacz 128x128. Biblioteki dla Arduino są prawie skończone.  Akcelerator, zależnie od operacji, przyspiesza działanie wyświetlacza od 6..7 razy przy stawianiu pikseli, do 120 razy dla operacji wypełniania ekranu. Animacja taka jak https://es2.000webhostapp.com/Szescian_3D_i_animowane_tlo.mp4 nie jest już problemem.

Pokrewnym projektem z akceleratoem graficznym jest dopalacz dla WS2812.

[Treker (Damian Szymański)]

@RFM cieszę się, że chcesz pochwalić się swoim projektem, ale w takiej formie (brak zdjęć i szczegółów) właściwie nie wiadomo o czym piszesz. Masz jakieś pytania w sprawie tego projektu? Jeśli nie i chciałeś się nim pochwalić to pomocny byłby dokładniejszy opis, który tłumaczyłby szerzej działanie Twojego akceleratora.

[RFM]

Protel Schematic.pdf

Arduino.zip

Akcelerator_Graficznych_LCD_STM32.zip

Schemat i soft dla Arduino i STM32 w załączniku.

Idea działania jest prosta, akcelerator przyjmuje dane 8-bit o kolorze, położeniu punktu itp co już daje ok dwukrotne przyspieszenie bo np LCD wymaga CMD, 2 bajty X, 2 bajty Y, 2 bajty koloru - razem 7 bajtów. Akcelerator zadowalają 4 bajty  (CMD, X 1 bajt, Y 1 bajt, kolor - 1 bajt). Ponadto ma sprzętowe funkcje czyszczenia ekranu, wypełniania obszarów, rysowania linii, stringów a co najważniejsze dane do LCD są wysyłane gdy AVR przyśle wszystko co chce wyświetlić po czym wyda komendę DISPLAY. Wtedy akcelerator wysyła dane do LCD w 31ms z wykorzystaniem DMA. Można więc wysyłać dane długo, po czym w 30ms przesłać do LCD (klasyczne podwójne buforowanie). Poza obsługą LCD (właściwie sterownika) akcelerator ma 4 wyjścia cyfrowe, 4 wejściowe i 1 PWM.

Dołączam film, w którym UNO steruje wyświetlaczem.

Film.rar

Na fotografii zestaw uruchomieniowy.

1 godzinę temu, Treker napisał:

w takiej formie (brak zdjęć i szczegółów)

Limity w praktyce nie pozwalają na umieszczenie czegoś większego.

1 godzinę temu, Treker napisał:

Masz jakieś pytania w sprawie tego projektu?

Czy to ma sens? Czy warto zrobić taki akcelerator dla większych wyświetlaczy nawet 480x320? Wstępnie wygląda to obiecująco, niestety cena uC to ok 40zł.

Aktualizacja:

Link do filmu https://es2.000webhostapp.com/Szescian_3D_Akcelerator+UNO_Red-White.mp4

Wysłanie danych o 32k pikseli (128x128 8-bit) do Akceleratora:

CLS góra UNO-akcelerator, dół zestaw UNO-LCD bezpośrednio:

Porównanie jednej klatki animacji sześcianu w zestawie UNO-LCD (dół) z pracą z akcelerometrem przy czym  linie nie są rysowane sprzętowo (muszę zmodyfikować soft dla Arduino):

Dla zainteresowanych pliki z analizatora logicznego - niestety, 8.8M

Dodam, że akcelerator pracuje na zasadzie bufora (na zakładkę). DMA przyjmuje dane, pętla główna dekoduje komendy. AVR nie musi czekać na wykonanie komendy poza sytuacją, w której chce wydać komendę DISPLAY. W takim przypadku trzeba czekać aż BUSY przyjmie poziom wysoki. W czasie wysyłania danych przez akcelerometr do LCD można wysyłać kolejne komendy ale nie wszystkie. Jeśli będą operować na danych, które jeszcze przez DMA nie zostały wysłane, to pojawią się zakłócenia. Na razie nie ma możliwości odczytu licznika danych wysłanych, jest tylko informacja o zakończeniu wysyłki. W sumie, AVR coś tam jeszcze robi poza wysyłaniem danych o obrazie, więc ma na to co najmniej 30ms, po tym czasie może wysyłać kolejne dane do akceleratora.

Zasada działania jest podobna do FT8xx ale nie taka sama. W FT8xx ograniczeniem jest ok 2000 obiektów, tu tego ograniczenia nie ma.

[Sabre]

@RFM filmiki które podlinkowałeś na jakimś dziwnym hoście nie wyświetlają się w ogóle.

[Treker (Damian Szymański)]

Też niestety miałem problemy z ich uruchomieniem (trzeba pobrać na dysk). Dlatego zachęcam, aby filmy umieszczać jednak np. przez YouTube

[RFM]

23 minuty temu, Treker napisał:

Też niestety miałem problemy z ich uruchomieniem (trzeba pobrać na dysk)

To zależy od przeglądarki, odtwarzacza i systemu operacyjnego. U mnie działa bez problemu, za to z wysyłaniem na YT mam często problemy.

 

 

[RFM]

Dodałem do akceleratora sprites znane z komputerów takich jak  Amiga, C-64 czy Atari. W tych komputerach dostępne było kilka "duszków". Tego nawet w FT8xx nie ma (chyba, że jednobarwne). Teraz duszki nawet na UNO działają:

Widać dwa duszki "duszki". Jeden nie ma oczu, widać jak przenikają przez siebie a pod nimi tło i sześcian. Z punktu widzenia programu dla Arduino duszek, to prostokątny obiekt, w którym kolor 0, jaki by nie był, jest przeźroczysty. Taki duszek jest wysyłany jak bitmapa, więc po podaniu rozmiaru i współrzędnych okna  wysyłany jest blok danych a nie piksel po pikselu co pozwala przyspieszyć transfer 4-krotnie w stosunku do adresowania piksel po pikselu.

Nie ma ograniczenia co do ilości i rozmiarów duszków. Liczba kolorów 255 + przeźroczyste tło.



PS
Im dłużej robię akcelerator tym więcej ograniczeń Arduino na AVR widzę. Rzeczy banalne dla ARM dla AVR sa trudne do zrobienia albo niemożliwe. Zmuszany jestem sięgać do rozwiązań z lat 80! Ówczesne mikroprocesory osiągały typowo ok 1MIPS (max ok 3 - pomijam tu 16/32-bit MC680x0 i inne nie 8-bit) więc "dopalacze" były niezbędne ale AVR ma 20 MIPS (tak się chwali producent) przy 20MHz, w praktyce jakieś 15 i nadal wymaga dopalaczy
W przypadku Xmega jest lepiej ale cena nie zachęca, ARM będzie lepszy i przeważnie tańszy.

[RFM]

Funkcja ofsetu pozwala na operowanie na ujemnych wartościach współrzędnych. Co to daje? Po co piksel w punkcie -1? Taka możliwość pozwala chowac się duszkom ze ekranem

Dotychczas było to możliwe tylko z prawej strony ekranu oraz na dole, teraz także na górze i po lewej co widać na filmie.

Jakie jeszcze opcje można dodać? Co w ogóle taki akcelerator jest potrzebny? Może nikomu nie przeszkadza to, że widać rysowanie obiektów i miganie ekranu?

 

 

[RFM]

Oczywiście duszki mogą być animowane. Proszę popatrzeć na żółtego

 

[deshipu]

Wszystko bardzo dobrze, dużo pracy w to poszło i całkiem fajny system z tego wyszedł. Tylko przez moją przekorność jakoś nie mogę przestać się zastanawiać po co w tym wszystkim to UNO tam jeszcze jest — przecież STM32 z palcem w nosie sobie poradzi także z tym programem, który UNO miało wykonywać i całość się znacznie uprości, bo odpada komunikacja.

[RFM]

3 minuty temu, deshipu napisał:

po co w tym wszystkim to UNO tam jeszcze jest — przecież STM32 z palcem w nosie sobie poradzi także z tym programem

Oczywiście, nawet program będzie prostszy bo nie trzeba walczyć z odczytem danych z SPI. Podobnie można pytać, po co do Arduino dołącza się dziesiątki ekspandery portów gdy można użyć większego uC? Po co WAV player skoro bez problemu załatwi to ARM i będzie się nudził?  Po co wyświetlacz z FT8xx skoro wystarczy STM32F429?. Przykłady można mnożyć i mnożyć.

Cel urządzenia jest jeden, umożliwić arduinowcom płynną obsługę LCD. Sytuacja i tak jest dobra, bo użyty w akceleratorze STM jest tańszy niż UNO a widziałem już wiele konstrukcji gdzie dodatki, z mojego punktu widzenia zbędne, były droższe niż UNO!

Trzeba sobie uświadomić jedno (co niedawno sobie uświadomiłem) - arduinowiec nie przesiądzie się na ARM i pisanie softu w czymś innym niż ArduinoIDE. Na hasło debuger arduinowiec mdleje. Arduinowiec nie będzie się uczył i koniec, taki jego wybór.  Nie użyje RTOS (na AVR nie ma to sensu), nie będzie pisał nisko poziomowo (po rejestrach). Do akcelerometru dostaje gotową bibliotekę i może pisać swój soft.

 

[Gieneq]

16 minut temu, deshipu napisał:

przecież STM32 z palcem w nosie sobie poradzi także z tym programem, który UNO miało wykonywać i całość się znacznie uprości, bo odpada komunikacja.

Ciekawe co na to pan Chińczyk, który produkuje to 

Na pokładzie Atmega 128, którą podłącza się do drugiej Atmegi. Komunikacja po UARCie, a można było po I2C. Dziwne ale wygoda jednak jest.

[RFM]

3 minuty temu, Gieneq napisał:

Ciekawe co na to pan Chińczyk, który produkuje to 

Na pokładzie Atmega 128, którą podłącza się do drugiej Atmegi. Komunikacja po UARCie, a można było po I2C. Dziwne ale wygoda jednak jest.

Widziałem już konstrukcję gdzie jedno UNO odczytuje dwa enkodery (łącznie 6 pinów) i steruje dwoma silnikiami krokowymi (4 piny) przez sterownik. Kilkanaście wyprowadzeń wolnych. Drugie UNO odczytuje dane sterujące silnikami krokowymi (4 piny) i przez PCF8574 steruje LCD alfanumerycznym. Pierwsze pytanie to po co PCF skoro na tym drugim UNO jest tyle wolnych pinów aby  LCD sterować bezpośrednio? Drugie, po co to dodatkowe UNO skoro na tym sterującym silnikiem są wolne wyprowadzenia i można sterować bezpośrednio ostatecznie przez expander wyświetlaczem?

Odpowiedź jest prosta, ktoś co "toto" zbudował albo robił to z "klocków" i nie potrafił połączyć dwóch programów, albo soft był napisany tak, że nie potrafił dodac dodatkowych funkcji, np obsługa LCD powodowała złe działanie silników.

Takie są realia wśród arduinowców. Niestety :-(

[Gieneq]

Ja bym tego tak od razu nie skreślał. W samochodach została wprowadzona magistrala CAN. Redukuje to liczbę kabli, zwiększa niezawodność i wprowadza modułowość. Każde urządzenie musi mieć jednak jakąś elektronikę, która umożliwia wpięcie się w magistralę. CAN ma się świetnie więc chyba to był dobry pomysł.

Kiedyś wpadłem na powiedzmy idealny pomysł, który jak się okazało ktoś już wymyślił. Moduły al'a Grove, z samym I2C. Nawet najprostsza dioda sterowana byłaby po I2C. Ale fakt, że można rozpoznać fizyczne połączenia układu elektronicznego, odczytując adresy urządzeń wpiętych w magistralę to byłoby coś! Choć niesamowicie przekombinowane. Jest to jednak odejście od standardów makerskich, a pójście w stronę klocków lego.

[Sabre]

@RFM każdy pisze programy w tym, w czym potrafi najlpeij. Sam jestem od zawsze bascomowcem i nie czuję potrzeby przesiadania się na cokolwiek innego. Wszystko to czego potrzebuję piszę sam albo szukam kodu w sieci bo a nóż już ktoś mnie ubiegł. Chodzi o to żeby się nie męczyć, a nie o to, żeby wszystko było optymalne do granic możliwości. Wiem, że to nie jest prawidłowe podejście, ale skoro coś wystarcza komuś do jakiegoś zadania, to prom kosmiczny nie będzie tym sterowany. Jeśli natomiast ktoś będzie chciał połączyć hobby z pracą to myślę, że sam doszedł już do pewnej kultury pisania kodu i wie, że na Arduino, czy Bascomie świat się nie kończy .