Elektroda.pl
Elektroda.pl
X
PCBway
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Dlaczego kolorowe TFT działają wolno z Arduino UNO/Mega i AVRmega/tiny?

LChucki 09 Cze 2019 17:13 8394 74
  • Dlaczego kolorowe TFT działają wolno z Arduino UNO/Mega i AVRmega/tiny?
    Wiele osób zastanawiało się dlaczego kolorowe graficzne wyświetlacze działają bardzo wolno z Arduino UNO/Mega i wszystkimi AVR Mega/Tiny. Przeprowadziłem testy porównawcze wyświetlacza 128x160 ze sterownikiem IL9306 pracującym z interfejsem SPI. Do testów posłużyło Arduino UNO i KA-NUCLEO-F411CE.
    Dlaczego kolorowe TFT działają wolno z Arduino UNO/Mega i AVRmega/tiny?
    Zainstalowałem bibliotekę „TFT_ILI9163C-master” ze strony „Nettigo”. Uruchomiłem przykład „Cube”, efekty widać na filmie.


    Animacją bym tego nie nazwał. Program nie robi nic innego jak animowanie sześcianu (przerwania od timera działają), widać migotanie ekranu (komenda CLS). Wszystko to wynika z faktu, że kasowanie ekranu trwa 237ms, rysowanie sześcianu 40..47ms co daje 3..4 klatki na sekundę.
    Czy da się po poprawić? Nie za bardzo! Można taktować uC 20MHz a nie 16, ale szału nie będzie.
    Często (najczęściej) biblioteki napisane są żałośnie i choć sterownik wyświetlacza ma funkcje rysowania linii, prostokątów czy okręgów to biblioteka ich nie wykorzystuje. Funkcje te pozwalają szybko czyścic ekran (kilkanaście bajtów zamiast kilkudziesięciu tysięcy) rysować linie itp. Podobnie źle są pisane funkcje umieszczania tekstów, zamiast zdefiniować okno wysyłać tylko dane, stawiany jest punkt po punkcie co spowalnia umieszczanie tekstu kilka, kilkanaście razy. Niestety, w przypadku IL9306 i rysowania sześcianu praktycznie nic nie da się zrobić.
    Zagoniłem do pracy ARM STM32F411CE. Zegar ustawiłem na 60MHz, co pozwoliło taktować SPI częstotliwością 15MHz, maksymalną dopuszczalną dla IL9306. Przeniosłem bibliotekę z Arduino, oto efekt:

    Słaby coś ten ARM, animacja niewiele szybsza (użyłem HAL, gdyby wykorzystać dostęp rzez rejestry animacja byłaby prawie 2 razy szybsza niż na UNO). Nie, to nie ARM słaby tylko programista, który przeniósł kod nie wykorzystując możliwości sprzętowych ARM. Stworzyłem bufor na dane dla wyświetlacza (128*160*2=40960bajtów) i zagoniłem do pracy DMA. Efekt:


    Tworzenie klatki animacji trwa ok 2,5ms, transmisja danych do LCD przez DMA poniżej 25ms. Używanie wyświetlacza ma sens! Menu nie rysuje się „godzinami” można wyświetlać animacje. 25ms daje 40 klatek na sekundę! W porównaniu do UNO z 3..4 klatkami to rakieta! Należy zauważyć, że gdy dane są wysyłane do LCD CPU może generować kolejną klatkę!


    Dlaczego napisałem ten artykuł?
    Wielu Arduinowców kusi się reklamami sklepów i kupuje wyświetlacze 320x240 czy nawet 640x480 do UNO czy MEGA. Nie oszukujmy się, bez DMA, szybkiego SPI czy interfejsu równoległego, używanie kolorowych wyświetlaczy bez akceleratora graficznego (np. FT8xx) o dużej rozdzielczości nie ma sensu! Owszem, jeśli będzie to np. termometr, miernik napięcia, gdzie wyświetlany jest jeden ekran, modyfikowana jego część i skorzystamy z okna wyświetlania, ma to sens. Gdy jednak zrobimy menu, przechodzenie pomiędzy poszczególnymi stronami będzie wyglądało żałośnie. O tle innym niż jedna barwa raczej należy zapomnieć.
    Podstawowym problemów AVR-ów jest mała ilość RAM. Gdyby było jej więcej, operacje graficzne można by przeprowadzić na pamięci po czym wysłać cały bufor do wyświetlacza. Nie można skorzystać z mechanizmu przerwań, ponieważ wejście i wyjście z przerwania zajmie więcej czasu niż czekanie aż bufor nadawczy zostanie opróżniony. W takim przypadku, wysłanie całego bufora zajmie ok 41ms dla 16MHz i ok 33ms dla 20MHz (dane teoretyczne). Do tego należy dodać rysowanie grafiki, w tym przypadku max 47ms. Daje to czas ok 90ms czyli ponad 11 klatek na sekundę. Zaletą tego rozwiązania jest brak migotania ekranu, bo nie ma operacji jego kasowania.
    Sytuację ratują Xmega, które nie dość, że mają więcej RAM niż Mega/tiny to są wyposażone w DMA. Niestety, porównanie cen Xmega z AVR wypada na niekorzyść Xmega. Jeśli jeszcze uwzględnimy ich wyposażenie w peryferia, ilość pamięci oraz fakt, że nadal są to CPU 8-bit, nie ma sensu się nimi zajmować.

    Na koniec porównanie ARM z AVR, gdzie na AVR wyraźnie widać rysowanie tła podczas jego zmiany.

    Próbowałem bardziej bajerancki efekt:

    Mimo iż na UNO ustawiłem zmianę wielkości kwadratu tła nie o 1 po każdym wyświetleniu tylko o 10, nic to nie dało. Owszem, można by nie czyścić całego wyświetlacza tylko kilka fragmentów, ale trzeba się narobić a i tak będzie miga :-)

    Mam nadzieję, że teraz użytkownicy AVRmega/tiny ArduinoUNO/Mega i podobnych, dobrze zastanowią się zanim wykorzystają kolorowy wyświetlacz.



    PS
    Kody źródłowe dla Arduino i ARM w załączniku. Kody nie są doskonałe, np. strob CS może być zdejmowany zbyt szybko, co może powodować błędy na ostatnim pikselu. Celem kodów nie było napisanie doskonałych funkcji komunikacji z wyświetlaczem ale pokazanie różnicy pomiędzy uC z wystarczającą ilością pamięci RAM i DMA oraz bez tych udogodnień (UNO z 2kB RAM).

    Fajne! Ranking DIY
    Potrafisz napisać podobny artykuł? Wyślij do mnie a otrzymasz kartę SD 64GB.
    O autorze
    LChucki
    Poziom 30  
    Offline 
    Od rana mam dobry humor...
    Kod z delay to nie kod, to DEMO!
    Możliwości sprzętowe uC trzeba wykorzystywać a nie "machać" GPIO.
    Pozostało mi pomagać głównie na PW.

    Moje publiczne projekty od 1991 roku: http://er-mik.prv.pl/projekty_avt.php
    Specjalizuje się w: zegarmistrz
    LChucki napisał 1818 postów o ocenie 279, pomógł 83 razy. Mieszka w mieście Warszawa. Jest z nami od 2018 roku.
  • PCBway
  • #2
    khoam
    Poziom 35  
    Przydałoby się jeszcze testy z ESP8266 oraz ESP32. Też dla Arduinowców ;)
  • #3
    androot
    VIP Zasłużony dla elektroda
    Polecam zobaczyć TO

    Jest to przykład co można zrobić z ATtiny85 (animowane demo 204 x 240 pikseli i 60 FPS).

    Tekst, który napisałeś jest mocno tendencyjny. To, że w udostępnionym przykładzie ktoś poszedł po linii najmniejszego oporu i czyści za każdym razem cały wyświetlacz, nie znaczy że AVRki nie nadają się do obsługi kolorowego, graficznego LCD.

    Kluczem do sukcesu jest optymalizacja kodu i świadome używanie możliwości danej rodziny mikroprocesorów. Można powiedzieć: kiedyś to byli programiści... (w linku z mojego postu kod napisany w assemblerze).
  • #4
    khoam
    Poziom 35  
    LChucki napisał:
    Zainstalowałem bibliotekę „TFT_ILI9163C-master” ze strony „Nettigo”

    Naprawdę gorszej biblioteki nie mogłeś wybrać, chociaż z drugiej strony ona była dobrym kandydatem do tego, abyś mógł w tej bibliotece wiele poprawić i się wykazać ;)
  • PCBway
  • #5
    LChucki
    Poziom 30  
    khoam napisał:
    Przydałoby się jeszcze testy z ESP8266 oraz ESP32. Też dla Arduinowców ;)

    Można ale po co?
    Znając dokumentację uC można wszystko dość dokładnie wyliczyć. Najważniejsza sprawa to pamięć RAM aby pomieścić bufor wyświetlacza. W drugiej kolejności obecność DMA. Gdy nie ma DMA będą nieduże różnice pomiędzy uC, bo szybkość animacji będzie zależała od tego, jak długo jest rysowana pojedyncza klatka. Gdy uC ma DMA, przeważnie uC zakończy rysowanie klatki animacji zanim DMA zakończy transfer.
    Szybkość SPI ma znaczenie przy powolnych uC (AVR max 10MHz, UNO 8MHz), przy szybkich jest bez znaczenia bo max taktowanie testowanego wyświetlacza to 15MHz a uC może wysyłać 38, 50 czy 80MHz.

    Dodano po 4 [minuty]:

    khoam napisał:
    LChucki napisał:
    Zainstalowałem bibliotekę „TFT_ILI9163C-master” ze strony „Nettigo”

    Naprawdę gorszej biblioteki nie mogłeś wybrać, chociaż z drugiej strony ona była dobrym kandydatem do tego, abyś mógł w tej bibliotece wiele poprawić i się wykazać ;)

    Przepisując ją na ARM jedyna poprawka, to stawianie punktów nie na wyświetlaczu tylko w buforze RAM. Po zakończeniu rysowania ustawiam okno i uruchamiam DMA.

    Nie mam zamiaru poprawiać bibliotek dla Arduino, bo co to da? Jakie będzie przyspieszenie? 5%? 10%? Nadal będzie to żółw. Wykorzystanie możliwości ARM dało przyspieszenie 10..13 razy! Tego na AVRmega nie da się zrobić! Ponadto nie tworzę projektów na Arduino. Jedyne zadanie jakie pełni Arduino w mojej pracy to testowanie modułów i źródło bibliotek (naturalnie do poprawki).

    Dodano po 17 [minuty]:

    androot napisał:
    Tekst, który napisałeś jest mocno tendencyjny. To, że w udostępnionym przykładzie ktoś poszedł po linii najmniejszego oporu i czyści za każdym razem cały wyświetlacz, nie znaczy że AVRki nie nadają się do obsługi kolorowego, graficznego LCD.

    Oczywiście można kasować narysowane wcześniej punkty, wtedy jednak klatka to ok 80ms (nadal daleka droga do 40 klatek na sekundę) ale...
    Jeżeli mam tło to sprawa się komplikuje. Nie widzę sensu walczyć kilka dni z funkcję rysującą gdy można to zrobić we kilka/kilkanaście godzin.

    androot napisał:
    Można powiedzieć: kiedyś to byli programiści... (w linku z mojego postu kod napisany w assemblerze).

    Czyli przenośność kodu żadna. Czasy ASM minęły bezpowrotnie nawet w DSP.

    Dodano po 1 [minuty]:

    androot napisał:
    est to przykład co można zrobić z ATtiny85 (animowane demo 204 x 240 pikseli i 60 FPS).

    Nie zauważasz różnicy pomiędzy 8 kolorami a 65536?

    androot napisał:
    Tekst, który napisałeś jest mocno tendencyjny.

    To przykład, który dałeś na Attimy85 jest mocno tendencyjny!
    Już wstępnie można oszacować, że aby uzyskać 16 bitową głębię koloru uC będzie działał co najmniej 5 razy wolniej i z 60klatek zostanie w praktyce pewnie 10. Porównanie do projektu z Tiny85 miałoby sens, gdyby sterował on wyświetlaczem podobnym do tego, który ja zastosowałem.
    Jeśli chce się udowodnić jak dobre są AVR można zrobić test ze sterownikiem z sprzętowym rysowaniem linii, okręgów, wypełnianiem obszarów. Używając wyświetlacza z takim sterownikiem, czy będzie nim sterował Z-80 czy ARM600MHz nie będzie większej różnicy w szybkości animowania sześcianu. Podobnie z akceleratorem np FT8xx. Niestety, sterowniki ze wspomaganiem sprzętowym są droższe niż bez wspomagania. F800 kosztuje ok 23zł czyli tyle co cały moduł wyświetlacza 128x160 z IL9306! Czy jednak taki test będzie wiarygodny? AVR z sterownikiem ze sprzętowym wspomaganiem i ARM ze sterownikiem bez wspomagania? Nie będzie tak jak porównanie 8 kolorów do 65536.

    Nie che mi się analizować kodów dema, zwłaszcza, że są w ASM, ale pewnie zajętość CPU 100%. W przypadku ARM poniżej 10% i to bez optymalizacji. Zwiększając zegar do 90MHz zajętość CPU będzie ok 7%, ile dałoby optymalizacja? Nie wiem i nie chcę wiedzieć, bo nie mam potrzeby aby CPU działał szybciej. W przypadku 90% moich aplikacji CPU i tak się będzie nudził.
  • #6
    tronics
    Poziom 37  
    Chrome-ART i display na DSI i wynik byłby jeszcze bardziej druzgocący. Z drugiej strony tam gdzie rzeczywiście potrzeba odpowiedniej płynności grafiki (hmi, kamerki) i tak prędzej będzie wykorzystane FPGA, dedykowany osobny akcelerator (jak FT8xx) albo mocniejszy SoC z wbudowanym układem 2D (i mnogością interfejsów, i zewnętrznym RAM i FLASH).
  • #7
    LChucki
    Poziom 30  
    tronics napisał:
    tam gdzie rzeczywiście potrzeba odpowiedniej płynności grafiki

    Na wyświetlaczach o rozdzielczości 128x160 lub podobny filmów nikt nie wyświetla. Wyświetla się tam menu, czasem z prostymi animacjami (np klepsydra). Dobija mnie gdy widzę jak menu czy duże napisy sa rysowane. Wygląda to żałośnie i nigdy bym takiego produktu nie zaakceptował. Kiedyś sprawdziłem na UNO wyświetlacz 320x240 16-bit w trybie prawie równoległym (Mega328 nie ma buskeepera). Grafika była wczytywana z z karty SD z pliku BMP. Trwało to 2,7sekundy!
    Czemu to miałoby niby służyć? Ramka na fotki z jednym żałosnym efektem?

    W necie można znaleźć wiele "genialnych" konstrukcji, wszystko fajnie dopóki nie trzeba przerysować całego menu. Wtedy widać jak linijka po linijce jest rysowany obraz.
    Moje zdanie jest takie, że jak uC nie ma RAM o wielkości takiej aby zmieścić bufor wyświetlacza lub chociaż jego część (połowę, ćwiartkę) to nie ma sensu się w to pchać. Owszem, czasem nie trzeba mieć bufora, ale to sporadyczne sytuacje albo trzeba się namęczyć jak jak w przypadku Domofonu GSM czy Sondy Logicznej a efekt i tak będzie połowiczny.

    Celem tego artykułu, było uświadomienie, zwłaszcza "Arduinowców", że można sobie coś tam porysować ale do sensownych zastosowań graficznych AVR się nie nadaje. Wyjątek stanowić będę projekty, w których jest jeden ekran a modyfikowana jest tylko niewielka jego część, np woltomierz, stacja pogodowa lub projekt, w którym klient ma małe wymagana (ślepy?).
  • #8
    Janusz_kk
    Poziom 24  
    androot napisał:
    Polecam zobaczyć TO

    Ciekawostka, przetaktowany attiny85 na 40Mhz.
  • #9
    LChucki
    Poziom 30  
    androot napisał:
    ktoś poszedł po linii najmniejszego oporu i czyści za każdym razem cały wyświetlacz

    A co zrobić jak co jaki czas muszę zmienić tło?

    Jakiś pomysł?

    Dodano po 5 [minuty]:

    Janusz_kk napisał:
    androot napisał:
    Polecam zobaczyć TO

    Ciekawostka, przetaktowany attiny85 na 40Mhz.

    Ciekaw jestem jak długo wytrzyma człowiek pracując po 16 godzin dziennie?
  • #10
    khoam
    Poziom 35  
    LChucki napisał:
    Celem tego artykułu, było uświadomienie, zwłaszcza "Arduinowców", że można sobie coś tam porysować ale do sensownych zastosowań graficznych AVR się nie nadaje.

    W moim przekonaniu celem tego artykułu było wykazanie wyższości ARM nad AVR, co jest trochę bezproduktywne, ponieważ (prawie) wszyscy wiedzą, że białe jest białe, a czarne jest czarne.

    Do testów proponuję użyć biblioteki lexus2k: https://github.com/lexus2k/ssd1306 (obsługuje również ILI9163 mimo, że opisana jest jako ssd1306 driver). Jest dostępna na wiele platform i niekoniecznie tylko Arduino, stąd pewnie zwykle nie figuruje w linkach w sklepikach "arduinowych".
  • #11
    LChucki
    Poziom 30  
    khoam napisał:
    W moim przekonaniu celem tego artykułu było wykazanie wyższości ARM nad AVR

    Xmega zadziała tak samo dobrze jak ARM. Obciążenie CPU będzie większe, bo to jednak 8-bit ale czas transmisji do LCD będzie taki sam (zakładając, że taktowanie SPI będzie 15MHz) jak i ARM. Niestety, jak już pisałem, cena Xmega nie zachęca.

    khoam napisał:
    Do testów proponuję użyć biblioteki lexus2k:

    I co to da? Magicznie zwiększy się ilość RAM w Mega328 i zadziała DMA? Owszem, lepsze biblioteki dadzą większą szybkość niektórych operacji ale jakim cudem szybciej zostanie wyczyszczony cały wyświetlacz? Gdy wyświetlacz nie ma sprzętowego wypełniania prostokątów to cudów nie ma, trzeba ustawić okno wypełnianego obszaru i wysłać dane w liczbie x * y * 2. Cudów nie ma! Jedyny zysk na operacji wypełniania całego ekranu to "niemachanie" strobem CS bez potrzeby co robi biblioteka, której użyłem.

    Dodano po 2 [minuty]:

    Jeśli ktoś ma ochotę, to niech testuje biblioteki dla AVR. Zobaczymy ile można ugrać?
    Ja tych dla ARM nie przyspieszę chyba, że będę wysyłał dane tylko z obszaru, który został zmodyfikowany. Pytanie czy ma to sens? Co za różnica, czy dane są wysyłane 23ms czy 5ms? Przecież w czasie transmisji CPU nie robi nic!
  • #12
    fotomh-s
    Poziom 21  
    androot napisał:
    Polecam zobaczyć TO

    Jest to przykład co można zrobić z ATtiny85 (animowane demo 204 x 240 pikseli i 60 FPS).

    Tekst, który napisałeś jest mocno tendencyjny. To, że w udostępnionym przykładzie ktoś poszedł po linii najmniejszego oporu i czyści za każdym razem cały wyświetlacz, nie znaczy że AVRki nie nadają się do obsługi kolorowego, graficznego LCD.

    Kluczem do sukcesu jest optymalizacja kodu i świadome używanie możliwości danej rodziny mikroprocesorów. Można powiedzieć: kiedyś to byli programiści... (w linku z mojego postu kod napisany w assemblerze).


    Ja polecam obejrzeć nieco starsze demo jako ciekawostkę: https://www.youtube.com/watch?v=sNCqrylNY-0
  • #13
    LChucki
    Poziom 30  
    fotomh-s napisał:
    Ja polecam obejrzeć nieco starsze demo jako ciekawostkę: https://www.youtube.com/watch?v=sNCqrylNY-0

    Czasy C-64 się przypominają :-)

    Warto wspomnieć o projekcie http://belogic.com/uzebox/index.asp
    https://www.youtube.com/watch?v=y_d2hWXyykI

    Co do projektu na Attiny85 i Uzebox, nie można ich porównywać z testami, które przeprowadziłem. Pomijam przetaktowanie o 100% Attiny85, ale uwzględniam liczbę transmitowanych bitów i głębię kolorów:






    Projektliczba kolorówLiczba bitów w interfejsieRozdzielczośćPrzepustowość
    Attiny8583204x240@60FPS2`937`600 x 3b/s
    Uzebox2568360x224@50..60FPS4`838`400 x 8b/s
    IL9306 ARM655361160x128@40FPS13`107`200 x 1b/s
    IL9306 AVR655361160x128@3..4FPS1`310`700 x 1b/s

    Przepustowość = x * y * głębia kolorów w bitach * FPS

    Tak, że kolego @androot (VIP Zasłużony dla elektroda) jakiś lepszy przykład do porównania poproszę, bez przetaktowania o 100% i transmisję 1-bit albo uwzględnić większą liczbę transmitowanych danych w porównaniu, bo nawet przetaktowany Attiny wypada prawie 3 razy gorzej (ok 5,4 razy gdyby nie był przetaktowany) niż ARM. Ja też mogę porównać sterownik w trybie równoległym, 16-bit, co da w przybliżeniu 11 razy szybszą transmisję przy 65536 kolorach. Proszę sobie policzyć jaka byłaby szybkość transmisji, gdyby istniał w takim przypadku tryb kolorowy 3-bit?
  • #14
    ADI-mistrzu
    Poziom 30  
    W sumie jako ciekawostka, poniżej filmik podobnego tematu opartego na:
    - wyświetlacz 800x480 16bit głębia
    - STM32F103
    - interfejs równoległy (8080)

    Link


    Dane pobierane są z karty SD, nie wykorzystuje żadnych wbudowanych funkcjonalności procesora nawet DNA (jedynie interfejs FSMC).
    uC niema wystarczającej ilości RAM aby zbudować bufor, więc wszystko jest rysowane bezpośrednio na wyświetlaczu i widać migotanie spowodowane czyszczeniem ekranu.

    Podobna kostka wyświetlana jest w 1:06, przy czym przypominam, iż rozdzielczość wyświetlacza jest znacząco większa.
    Podstawowym problemem jest właśnie bezpośrednie rysowanie, zdarza się, iż możliwe jest wyświetlenie obrazu tylko rysując piksel po pikselu, co jest wyjątkowo nie optymalne (80% czasu to adresowanie piksela).

    Poniżej jeszcze inne rozwiązanie na STM32F4 bez używania wewnętrznego akceleratora grafiki czy DMA.

    Link


    Wyświetlacz ma chyba 320x240px, 16 bit głębia kolorów.
  • #15
    LChucki
    Poziom 30  
    ADI-mistrzu napisał:
    W sumie jako ciekawostka, poniżej filmik podobnego tematu opartego na:
    - wyświetlacz 800x480 16bit głębia
    - STM32F103
    - interfejs równoległy (8080)
    Dane pobierane są z karty SD, nie wykorzystuje żadnych wbudowanych funkcjonalności procesora nawet DNA (jedynie interfejs FSMC).

    Menu wygląda żałośnie (miganie). Gdyby ktoś wykonał mi taką robotę, zwyczajnie nie zapłacił bym za taki chłam. Nie "pochwalił" byś się czymś takim w necie, gdybym zrobił takie badziewie. Nie przeszkadza to jednak firmom ze wschodu, sprzedawać migające mierniki USB czy to z LCD czy z 7-seg.

    ADI-mistrzu napisał:
    Poniżej jeszcze inne rozwiązanie na STM32F4 bez używania wewnętrznego akceleratora grafiki czy DMA.

    F429 ma sterownik LCD. Miganie może być powodowane tym, że w złym momencie jest rysowana grafika. Trzeba to robić w "ciemnej" fazie wyświetlania. Jeśli czas synchronizacji pionowej jest za krótki, robi to się gdy fragment, który modyfikujemy został już wyświetlony na wyświetlaczu, przykładowo, rysowana jest linia 20 modyfikujemy linię 19 lub wcześniejszą.
    Gdyby uC miał więcej RAM można zrobić podwójne buforowanie. Ta płytka, jak pamiętam, ma 64MB SDRAM. Powinno się udać generować grafikę w SDRAM po czym, z użyciem DMA, przepisać ją do RAM uC.
  • #16
    ADI-mistrzu
    Poziom 30  
    @LChucki, to nie jest produkt a menu jest tylko do poruszania się i sprawdzenia możliwości. W tym przypadku wyświetlacz jest za duży względem możliwości i migotania się nie wyeliminuje (zbyt długi czas transmisji danych do wyświetlacza).

    Na F429 niema migotania a więc niema sensu w tym przypadku się synchronizować z wyświetlaczem.
    Druga sprawa to eval board z F429 posiada wyświetlacz ze sterownikiem, a więc transfer danych i tak musi odbyć się do niego (czy to po SPI czy równolegle).
    Cała sztuczka polega na tym aby zrobić to w dość krótkim czasie.
  • #17
    LChucki
    Poziom 30  
    ADI-mistrzu napisał:
    Druga sprawa to eval board z F429 posiada wyświetlacz ze sterownikiem

    Na pewno? Może pomyliłem z inna płytką ale wydaje mi się, że sterownik jest w F429 a wyświetlacz to tylko matryca.

    Dodano po 41 [sekundy]:

    ADI-mistrzu napisał:
    Na F429 niema migotania

    Może na filmie wyglądało to jak migotanie.
  • #18
    tronics
    Poziom 37  
    Cytat:
    ale wydaje mi się, że sterownik jest w F429 a wyświetlacz to tylko matryca.
    '
    429 ma Chrome-ART ale ten eval board ma wyświetlacz po SPI co powinno samo w sobie wszystko tłumaczyć.
  • #19
    LChucki
    Poziom 30  
    tronics napisał:
    Cytat:
    ale wydaje mi się, że sterownik jest w F429 a wyświetlacz to tylko matryca.
    '
    429 ma Chrome-ART ale ten eval board ma wyświetlacz po SPI co powinno samo w sobie wszystko tłumaczyć.

    CubeMX pokazuje coś innego:
    Dlaczego kolorowe TFT działają wolno z Arduino UNO/Mega i AVRmega/tiny?
    Jak pamiętam schematy to potwierdzają.
  • #20
    tronics
    Poziom 37  
    Cytat:
    It's a simple graphics engine on STM32F429 work on:
    - system clock is 16MHz (internal HSI)
    - LCD interface SPI (RGB off)
    - FPU not used (any calculations is doing by soft)

    Czemu miałbym się kłócić z autorem nagrania?
  • #21
    LChucki
    Poziom 30  
    tronics napisał:
    Cytat:
    It's a simple graphics engine on STM32F429 work on:
    - system clock is 16MHz (internal HSI)
    - LCD interface SPI (RGB off)
    - FPU not used (any calculations is doing by soft)

    Czemu miałbym się kłócić z autorem nagrania?

    A temu, że Internet, telewizja i radio bardzo często KŁAMIE!

    CubeMX jest niewiarygodny?

    Zamiast ślepo wierzyć w to co ktoś napisał wystarczy zapoznać się z dokumentacją płytki (załącznik). Innej płytki z F429 i wyświetlaczem 2,4" nie znalazłem, więc chyba nie ma pomyłki?
    Od kiedy w SPI mamy Vsync, Hsync, R0..R5, G0..G5, B0..B5, idt, itp?
    Może ktoś tam sobie podłączył wyświetlacz z SPI ale raczej nie pasowałyby wyprowadzenia. Gdyby był na kabelkach ok, ale widać, że jest to wyświetlacz dostarczony razem z płytka DISCOVERY.


    PS
    tronics napisał:

    Czemu miałbym się kłócić z autorem nagrania?

    Z Kaszpirowskim (adin, dwa, czetyrie) https://www.fakt.pl/wydarzenia/swiat/kim-jest-anatolij-kaszpirowski-co-teraz-robi/qjkrcr3 nie kłócił byś się?
    To samo z Nowakiem, kolega po branży w/w?
    Ślepo wierzysz w to co mówią inni?
    Nie weryfikujesz sensacji "Turbinka Kowalskiego"? http://histografy.pl/turbinka-kowalskiego/
    Albo "Perpetuum mobile", których w Internecie są setki jak nie tysiące?

    Moderowany przez gulson:

    3.1.9. Nie ironizuj i nie bądź złośliwy w stosunku do drugiej strony dyskusji. Uszanuj odmienne zdanie oraz inne opinie na forum.

  • #22
    J_Bravo
    Poziom 27  
    Tak czytam o powolności AVR i STM32F4 i nie wiem czy śmiać się czy płakać.
    W załączniku filmy z animacjami które popełniłem naście lat temu podczas NAUKI programowania w .... bascomie...
    Procesor Atmega8 albo 32. Nie pamiętam dokładnie.



    LChucki napisał:
    Menu wygląda żałośnie (miganie). Gdyby ktoś wykonał mi taką robotę, zwyczajnie nie zapłacił bym za taki chłam. Nie "pochwalił" byś się czymś takim w necie, gdybym zrobił takie badziewie


    Patrząc na ww temat pragnę zauważyć że kolegę przerosło narysowanie 12 prostych ;)

    Dodatkowo znalazłem kilka fajnych filmów na youtube:
    Prosta gra na atmega32:
    https://www.youtube.com/watch?v=SaoxAr0_mec
    Prototyp tabletu na Atmega 644
    https://www.youtube.com/watch?v=43EHzRwl84w
    Odtwarzacz filmów na AVR
    https://www.youtube.com/watch?v=rgvySZNpQFI
  • #23
    tronics
    Poziom 37  
    Cytat:
    Zamiast ślepo wierzyć w to co ktoś napisał wystarczy zapoznać się z dokumentacją płytki (załącznik).

    Gdyby RGB888 było jedyną możliwą opcją to IM byłoby odpowiednio pozwierane, a jest wyprowadzone na GPIO. Z tego samego powodu jest wyprowadzone SDA. Niech sobie kolega zerknie do dokumentacji sterownika IL9341 jakie interfejsy obsługuje.
  • #24
    LChucki
    Poziom 30  
    J_Bravo napisał:
    W załączniku filmy z animacjami które popełniłem naście lat temu podczas NAUKI programowania w .... bascomie...
    Procesor Atmega8 albo 32. Nie pamiętam dokładnie.

    Jakie jest obciążenie CPU?
    Bardzie 10% czy bardziej 100%?

    Zrób zmianę tła jak zrobiłem to na filmie

    Uda się zrobić to płynnie?
    Ile czasu będziesz to robił? Mnie zajęło to ok godziny.
    Nie wiedze problemu, aby moja fotka była tłem i poruszała się razem z animacja sześcianu. Wystarczy mi do tego FLASH w uC. Jak to zadział z Mega8 czy 32?
    Ok, niech będzie, wczytaj sobie ta fotkę z zewnętrznej pamięci, jak będzie ta animacja wyglądać? Ja bez próbowania wiem!
    Uczepiłeś się kolego pierwszych filmów ale nie zadałeś sobie trudu, albo SWIADOMNIE pominąłeś to co pokazałem na ostatnich filmach!
    Wiec czekam na efekt pokazany na ostatnim filmnie zrealizowany na Mega8 czy Mega32, nie ważne Bascom, C, czy co tam chcesz. Tydzień wystarczy na realizację? Czy może raczej bliżej nieokreślona przyszłość?

    J_Bravo napisał:
    Patrząc na ww temat pragnę zauważyć że kolegę przerosło narysowanie 12 prostych

    Nie mnie! Użyłem gotowego dema z Arduino.

    Wychowałem się na C-64, wiem, że dużo potrafi ale to sztuka dla sztuki. Demo, to nie realny program. Można obciążyć CPU w 100% i pokazać jaki jest dobry ale realnie, nie na samej animacji kursora kończy się działanie programu. Ja sobie animuję sześcian, manipuluję tłem, dodam pewnie jeszcze z 20 efektów i obciążenie CPU będzie np 30%. AVR owszem, pokaże animację ale w tym czasie będzie gubił ramki USB (mega8 czy 32 obsłuży USB 2.0?, NIE!!!), USART, ETH itp, itd. Trzeba będzie tego AVR otoczyć kilkunastoma układami, typu FTDI, itp, idt. Ile to będzie kosztować? Ile będzie kosztować ARM, który to wszystko bez dodatkowych układów zrealizuje?

    Demo, to demo, nie ma wiele wspólnego z użytkowym programem.

    Dodano po 7 [minuty]:

    tronics napisał:
    Niech sobie kolega zerknie do dokumentacji sterownika IL9341 jakie interfejsy obsługuje.

    Mam zamówioną płytkę F429-DISCO1, jak już ją będę miał, to napiszę czy wyświetlacz na tej płytce ma sterownik IL9341 , bo według mojej wiedzy to jest tylko matryca (sygnały Vsync, Hsybc).
  • #25
    tronics
    Poziom 37  
    Ma kolega w BOMie LCD,SF-TC240T-9370-B-T,2.4
    Powodzenia.
  • #26
    LChucki
    Poziom 30  
    J_Bravo napisał:

    Oglądanie rozpocząłem od od ostatniego filmu i padłem na kolana:
    Cytat:

    132x65 at 9 fps

    Możesz nie rozśmieszać?
    Trzeba mieć dużo wyobraźnia aby tam coś zobaczyć! Na tarczy Nipkowa było lepiej widać! Zajętość CPU pewnie 100%, więc CPU albo gubi ramki danych, które np chciałbym odbierać z USB, albo z 9 klatek na sekundę zrobi się 5. Jak żałośnie wyglądają 4 klatki na sekundę możesz zobaczyć na filmach, które zamieściłem w pierwszym poście.
    Reszty nawet nie chce mi się oglądać, jak jest tam coś wartościowego, to napisz co, wtedy obejrzę, bo teraz to sztuka dla sztuki, niby działa ale do niczego się nie nadaje!
    132x65 at 9 fps Nieme filmy miały 16 klatek na sekundę i wyższą rozdzielczość!


    Szybkość transmisji do wyświetlacza, to nie statystyka, tu nie da się manipulować danymi!
    Jak na razie, AVR nie zbliżył się tego co potrafi uC z wystarczająca ilością RAM. DMA polepsza sytuację ale głównym problemem AVR jest mała ilość RAM.
    Widzę próby manipulowania, tryb 3bit 8 kolorów porównywany do 1bit 65536kolorów!
    9 klatek/sek przy ok połowie rozdzielczości w porównaniu do 40 klatek/sek.

    Proszę sobie odpuścić takie manipulacje i dać porównywalne rozwiązania z AVR, ok 160x128 65536 kolorów 40 klatek/sekundę bez migania, zajętość CPU ok 10%.

    Dodano po 25 [minuty]:

    J_Bravo napisał:
    rototyp tabletu na Atmega 644
    https://www.youtube.com/watch?v=43EHzRwl84w

    Jest menu, pewnie zużywa 100% mocy CPU, reszta w trakcie tworzenia.
    Na bajery absorbuje 100% mocy CPU a w tym czasie nie będzie ściągać e-maila itp.
    Ja takiego tabletu nie chcę. Są chętni?

    Dodano po 5 [minuty]:

    J_Bravo napisał:
    rosta gra na atmega32:

    Proszę czytać ze zrozumieniem:
    " Dlaczego kolorowe TFT działają wolno z Arduino UNO/Mega i AVRmega/tiny?"
    Pisałem, że nawet Xmega pozwala na sensowne używanie wyświetlaczy a kolega, wyskakuje tu z AVR32! Co on ma wspólnego z AVRmega/tiny, o których mowa?
    Może kolega wyjaśnić?
    Według mnie to kolejna, NIEUDANA, próba manipulacji! Manipulacja jeszcze doskonalsza niż ta z przetaktowanym o 100% Attiny wysyłającym po 3bity na raz a tylko z ośmioma kolorami.


    PS
    Też byłem zatwardziałym AVR-owcem (nie Arduinowcem - to byłaby dla mnie hańba) do czasu aż AVR przestał mi wystarczać, okazał się drogi. Po zaznajomienie się z ARM nie wrócę do AVR czy innych 8-bit. Zakończyłem swoją przygodę z AVR jedyna z nimi styczność to suport wcześniejszych projektów i jak się klient uprze. Jak ma kasę to niech się upiera, jego sprawa. Prędzej czy później zarobię na takim projekcie jeszcze raz, bo będzie trzeba go zrobić na ARM.
  • #27
    J_Bravo
    Poziom 27  
    LChucki napisał:

    Jakie jest obciążenie CPU?
    Bardzie 10% czy bardziej 100%?

    100%. Aczkolwiek animacja jest płynniejsza niż twoja na ... ARM.

    LChucki napisał:
    Uczepiłeś się kolego pierwszych filmów ale nie zadałeś sobie trudu, albo SWIADOMNIE pominąłeś to co pokazałem na ostatnich filmach!

    Tak. Odniosłem się do pierwszych filmów. Uważam że działają tak słabo nie z powodu hardware tylko z powodu skopanego software. Wg mnie to "NIEUDANA, próba manipulacji" :twisted: .

    LChucki napisał:
    Nie mnie! Użyłem gotowego dema z Arduino.

    Napisz od nowa to i płynność animacji się pojawi.

    LChucki napisał:
    Oglądanie rozpocząłem od od ostatniego filmu i padłem na kolana:
    Cytat:
    132x65 at 9 fps
    Możesz nie rozśmieszać? .... Nieme filmy miały 16 klatek na sekundę

    Odczyt z karty + wrzut na LCD z 9fps kontra Twój film z 4 fps przy rysowaniu 12 kresek.

    LChucki napisał:
    Jest menu, pewnie zużywa 100% mocy CPU, reszta w trakcie tworzenia.
    Na bajery absorbuje 100% mocy CPU a w tym czasie nie będzie ściągać e-maila itp.
    Ja takiego tabletu nie chcę. Są chętni?

    Nie zgadza się to z twoją tezą ?? Udowodniłem ci że jednak da się użyć GLCD z AVR i może to bardzo ciekawie wyglądać. Płynność jest? Jest. Jakość jest? Jest. Responsywność jest? Jest. Da się? Da.

    ps. Wszystko odbierasz zbyt osobiście. To tylko wymiana poglądów.
  • #28
    Slawek K.
    Poziom 31  
    LChucki napisał:
    Po zaznajomienie się z ARM nie wrócę do AVR czy innych 8-bit. Zakończyłem swoją przygodę z AVR jedyna z nimi styczność to suport wcześniejszych projektów i jak się klient uprze. Jak ma kasę to niech się upiera, jego sprawa. Prędzej czy później zarobię na takim projekcie jeszcze raz, bo będzie trzeba go zrobić na ARM.

    I wszyscy się cieszymy.
    I na tym proponuję zakończyć krucjatę przeciwko AVR.

    Pozdr
  • #29
    LChucki
    Poziom 30  
    J_Bravo napisał:
    LChucki napisał:

    Jakie jest obciążenie CPU?
    Bardzie 10% czy bardziej 100%?

    100%. Aczkolwiek animacja jest płynniejsza niż twoja na ... ARM.

    Skąd wniosek, że jest płynniejsza?
    Widziałeś to na żywo czy sugerujesz się filmem?
    Jeśli filmem to dalsza dyskusja nie ma sensu to jak i fakt, że jeśli animacja zajmuje 100% czasu CPU to nie ma to sensu. uC to nie odtwarzacz animacji. Główne zadanie jest inne, animacja nie może zatrzymać innych procesów.

    J_Bravo napisał:

    LChucki napisał:
    Uczepiłeś się kolego pierwszych filmów ale nie zadałeś sobie trudu, albo SWIADOMNIE pominąłeś to co pokazałem na ostatnich filmach!

    Tak. Odniosłem się do pierwszych filmów. Uważam że działają tak słabo nie z powodu hardware tylko z powodu skopanego software.

    Daj lepszy przykład na Arduino, będę mógł porównać.

    J_Bravo napisał:

    LChucki napisał:
    Nie mnie! Użyłem gotowego dema z Arduino.

    Napisz od nowa to i płynność animacji się pojawi.

    Już pisałem, że nic nie będę poprawiał. Co z tego, że będzie płynnie, skoro zajmnie 100% czasu CPU?
    Sztuka dla sztuki?
    Zauważ, że na ARM, bez problemu uzyskuję płynną animację, małe obciążenie CPU, mam bogatsze wyposażenie uC za przeważnie niższą cenę niż koszt Mega328 czy tym bardziej Mega2560.
    Gdzie sens, gdzie logika aby używać AVR?
    Mam długą listę dlaczego lepiej używać ARM, w skrócie:
    - Przeważnie są tańsze niż AVR o podobnym wyposażeniu.
    - Mają więcej pamięci ram i mogę robić duże bufory nadawcze dla UART, I2c, SPI, USB.
    - Maja bogatsze wyposażenie (liczba usart, I2C, SPI, timerów) i większe możliwości tychże peryferii.
    - Mają DMA (AVR Mega nigdy o czymś takim nie słyszały).
    - Wiele ARM ma USB, w AVR to rzadkość.
    - Wersje z Ethernetem, AVR nie ma wcale z ETH.
    - Mają wielopoziomowy system przerwań.
    - Tańsze narzędzia (debuger).
    - Podczas debugowania na bieżąco widzę stan zmiennych w AVR po zatrzymaniu uC.
    - CubeMX do konfigurowania i generowania kodu.
    - Nie muszę się zastanawiać czy dana jest w ram czy flasch aby użyć stosownej funkcji (z sufiksem _P).
    - argument liczbowy w sprintf, scanf itp nie jest ograniczony do int.
    - przesuwane bitu (w lewo) nie jest ograniczone do 16 bitów.
    Realizując projekt płaci się za czas pracy. Jeśli na AVR muszę męczyć się kilka dni a na tańszym ARM kilka godzin, to który projekt będzie tańszy i o ile?
    Może nie zajmujesz się działalnością zarobkową, uC to hobby i nie ma to znaczenia, dla moich klientów ma i to bardzo duże.
    Zastanów się, chciałbyś zapłacić za projekt na drogim AVR 20'000zł, czy na tańszym ARM 5'000zł? Co wybierasz?

    J_Bravo napisał:

    LChucki napisał:
    Oglądanie rozpocząłem od od ostatniego filmu i padłem na kolana:
    Cytat:
    132x65 at 9 fps
    Możesz nie rozśmieszać? .... Nieme filmy miały 16 klatek na sekundę

    Odczyt z karty + wrzut na LCD z 9fps kontra Twój film z 4 fps przy rysowaniu 12 kresek.

    Nie mój!
    Na ARM mam 40 klatek.

    J_Bravo napisał:

    LChucki napisał:
    Jest menu, pewnie zużywa 100% mocy CPU, reszta w trakcie tworzenia.
    Na bajery absorbuje 100% mocy CPU a w tym czasie nie będzie ściągać e-maila itp.
    Ja takiego tabletu nie chcę. Są chętni?

    Nie zgadza się to z twoją tezą ?? Udowodniłem ci że jednak da się użyć GLCD z AVR i może to bardzo ciekawie wyglądać. Płynność jest? Jest. Jakość jest?

    Tylko CPU nie może w tym czasie robić nic innego.
    Jeśli zaś będzie musiał robić coś innego to zachowa się jak Windows, gdy ściąga mi się e-mail, muzyka odtwarzana Winampem zacina się.

    Dodano po 6 [minuty]:

    Proponuję zejść na ziemię.
    Tak jak nigdy standardowy 8051 nie był szybszy od 6502, tak nigdy AVR nie będzie szybszy od ARM!
    Bez wymaganego bufora w RAM NIGDY nie uzyska się takich efektów jak gdy ta pamięć jest! Nie musi to być ARM, wystarczy (o czym już pisałem) Xmega, niestety cena (też pisałem) nie zachęca!
    Przerwania nie zawsze zastąpią DMA. Tak jest w przypadku szybkich transferów.
    Za przykład może posłużyć nie tylko obsługa TFT ale i sterowanie WS2812, przykładowo https://www.elektroda.pl/rtvforum/viewtopic.php?p=17978284#17978284 policz jakie jest obciążenie CPU? To samo (też UART) robiłem na AVR, przy 18MHz obciążenie ok 90%. Trzeba zaznaczyć, że w przypadku AVR wymagany jest dodatkowy negator, w ARm nie, bo sprzętowo zanegowałem sygnał TXD.
  • #30
    epoxer
    Poziom 13  
    LChucki: Uczepiłeś się tych AVR'ów
    Tak ARM są szybsze, ale kto o zdrowych zmysłach używa MCU (AVR czy ARM Cortex-M) do rysowania płynnej grafiki i obsługi wielu innych zadań.
    Wspomnieliście o projekcie TABLETU, człowiek który to zbudował skupił się na płynności rysowania grafiki. Przecież to nie ma nic więcej z "tabletu", gdzie obsługa plików wykonywalnych? gdzie przydzielanie pamięci dla programów? To projekt rodem sterownik graficzny pieca, gdzie nic po za wbudowanym menu nie zdziałasz.
    Jeżeli ktoś chce płynnej grafiki, niech lepiej zaprzęgnie do tego wyspecjalizowany układ z GPU. Bo dyskusja tutaj przypomina mi bardziej projekty wyświetlania grafiki rodem z Turbo Pascal'a (lat 90'tych) na PC bez użycia OPENGL. Tylko większa prędkość CPU sprawiała, że animacja była bardziej płynna.
    LCD owszem używać czy to w AVR czy ARM, ale nie wymagajcie płynności klatek od MCU, który ma po za tym realizować jeszcze szereg innych działań (TO NIE procesor graficzny!) .
    Jaki by to projekt nie był zajętość mikrokontrolera zawsze skupia się na płynności generowania/przesyłania grafiki do LCD, to logiczne że im szybszy procesor tym więcej FPS i pozostałych zadań wykona.

    Ale wy kłócicie się, że maluch tak jak porsche 911 potrafi jechać 90km/h, Ale przecież Porsche ma jeszcze zapas mocy by jechać szybciej (30% zajętości CPU), a maluch nie (100%). Mimo, że oba potrafią te 90km/h osiągnąć.

    Sam używałem kiedyś AVR, obecnie ARM ale raczej z wygody ich programowania.
    LPC1114 - 48Mhz -> ENC28j60 - mini sterownik programowalny
    (tak wiem, mogę zastosować taki z ETH wbudowanym, ale nie chcę! Jest to taki sam projekt jak z tymi LCD dla zasady, że się da)
    I wyciskam z niego 100% mocy z uwagi na interpreter, który wykonuje cały czas program napisany przez użytkownika.
    https://www.youtube.com/watch?v=HniIPMELIGM

    Tyle tylko, że nie piętnuję tu AVR za to, że działałoby w tym projekcie wolniej ( dłuższy czas wykonania instrukcji programu )
    Szkoda nerwów na takie dyskusje, chyba że lubicie kłótnie dla zasady (bo ja mam rację, a wy nie)
    Każdy używa tego co potrzebuje, jedni ARM'a z 200Mhz do mrugania diodą, a inni ATtiny do LCD.

    Pozdrawiam :)