Elektroda.pl
Elektroda.pl
X
Elektroda.pl
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 13 Cze 2019 14:07 7356 74
  • #61
    LChucki
    Poziom 30  
    khoam napisał:
    LChucki napisał:
    ale nie w przypadku np sterownika do akwarium

    Do tego nie jest potrzebny żaden ARM.

    Jak menu ma byc "bajerancie" to ARMmega nie da rady.
    Nie chcę się powtarzać zbyt często, ale klienci mają tablety, komórki i chcą bajerów. Mnie to pasuje, bo konkurencji ze strony 90% Arduinowców (nie ważne czy AVR czy ARM 1GHz, delay i/lub nieumiejętność lub niemożliwość użycia DMA, przerwań robi swoje) nie mam, tak jak i zatwardziałych AVR-owców Mega. Xmega też nie konkurencja bo drogie w stosunku do ARM z dużo lepszym wyposażeniem a to nadal 8-bit z mała ilością RAM (dla kolorowych wyświetlaczy).
    Potrafisz napisać podobny artykuł? Wyślij do mnie a otrzymasz kartę SD 64GB.
  • PCBway
  • #62
    khoam
    Poziom 32  
    LChucki napisał:
    Jak menu ma byc "bajerancie" to ARMmega nie da rady.

    Istotny jest algorytm, jego implementacja oraz obsługa błędów, a "bajerancie" gadżety to można kupić na ali.

    Dodano po 4 [minuty]:

    LChucki napisał:
    Nie chcę się powtarzać zbyt często, ale klienci mają tablety, komórki i chcą bajerów.

    Nic nie stoi więc na przeszkodzie, aby wykorzystać te tablety/komórki jako zdalny interfejs zarządzania, bez konieczności pisania własnych "windows" w samym sterowniku.
  • #63
    LChucki
    Poziom 30  
    khoam napisał:
    Nic nie stoi więc na przeszkodzie, aby wykorzystać te tablety/komórki jako zdalny interfejs zarządzania, bez konieczności pisania własnych "windows" w samym sterowniku.

    Też takie rozwiązania sugeruję ale i to całkiem słusznie, jest to złe rozwiązanie bo np system ma budzić się do życia po resecie w kilka sekund. Jakie szanse na tablecie?
    Jedni mają niewymagających klientów (monety należy wrzucać nie częściej niż co 5 sekund - sam widziałem będąc w szpitalu) inni wymagających (do 10 monet/żetonów na sekundę - naprawdę to potrafią zrobić) a jak nie to taboret w ekranie.
  • #64
    khoam
    Poziom 32  
    LChucki napisał:
    Też takie rozwiązania sugeruję ale i to całkiem słusznie, jest to złe rozwiązanie bo np system ma budzić się do życia po resecie w kilka sekund. Jakie szanse na tablecie?

    Dokładnie takie same tzn. system budzi się po resecie w kilka sekund, a sam sterownik powinien eksponować tylko potrzebne oraz istotne informacje, w tym gotowość do pracy lub sygnalizację błędów.

    Cały ten wątek o kolorowych TFT działających wolno na AVRmega można równie dobrze zastąpić wątkiem o nie działaniu MS Window$ na "niektórych" ARM.
  • PCBway
  • #65
    LChucki
    Poziom 30  
    khoam napisał:
    Dokładnie takie same tzn. system budzi się po resecie w kilka sekund,

    Z tym nie ma problemu ale tablet ruszy za ok 30 sekund i przez te 30 sekund nic nie można zrobić (włączyć, wyłączyć itp).
    Pewnie wiele osób stwierdzi, że 30 sekund to mało. Ja twierdzę, że to zależy po której stronie drzwi od WC się znajdujemy.
    Na "Windzie" menu potrafi otwierać mi się 30 sekund, przeglądarka zawiesza na 30 sekund, w tych sytuacja to ogrom czasu.
    Jeśli to jest mało obrazowe, to proponuję włożyć dwa gwoździe do działającego gniazda 230V, złapać je rękoma i trzymać 30 sekund, wtedy okaże się czy to długo.

    Dodano po 2 [minuty]:

    PS
    Można dyskutować, wolno, szybko. Trzeba animacji, nie trzeba.
    Dla mnie ważne co chce klient, ile płaci, ile ma kosztować produkt, jaki mam czas na zrealizowanie projektu.
    Wiem z praktyki, że na "mocnym" (i przy okazji tanim) uC zrealizuję te zadania szybko przez co stosunkowo tanio.
    Za ARM przemawia cena, możliwości, czas pisania softu. Zalet uC 8-bit nie widzę a znam je dobrze, w kolejności od najlepszego w/g mnie: AVR, 8051, PIC, Z8 (z uC 65xx nie miałem przyjemności, z CPU 6502 tak, nawet na nim coś na wzór CA-80 zbudowałem).
    8-bit to raczej przyzwyczajenia (a raczej niechęć poznania nowego) programistów. Skąd wiem? Też taki kiedyś byłem (ok 4 lata temu). Na szczęście zaparłem się, nauczyłem (pierwsze projekty po ok 3 miesiącach, sensowne po ok roku), i do AVR nie mam zamiaru wracać. Nie ma sensu ekonomicznego. Debuger do STM32, klon 13zł (6 na Ali) 65zł oryginał i to w nowszej wersji. Ile kosztuje debuger do wszystkich rodzajów AVR?
    Pytanie retoryczne, mam (aż jeden) więc wiem ile kosztował. Do STM mam kilkanaście plus kilka w płytkach Discovery (100...150zł/szt) i Nucleo (ok 55zł/szt).
  • #66
    Urgon
    Poziom 36  
    AVE...

    Gratuluję koledze udowodnienia ponad wszelką wątpliwość, że ośmiobitowce w ogólności, a AVR/Arduino w szczególności są gorsze od 32-bitowych ARMów. I wystarczyło koledze do tego użycie niezbyt optymalnego interfejsu i niezbyt optymalnej biblioteki by wykonać dość wymagającą animację z 12 kresek. Brawo. Czy następnym razem kolega będzie udowadniał, że McLaren M4 12C jest troszkę szybszy od małego fiata?

    Trzy pytania:
    1. Czy funkcja czyszczenia ekranu polega na "ręcznym" wyzerowaniu wszystkich bajtów w pamięci kontrolera wyświetlacza?
    2. Czy rysowanie 12 kresek wymaga wpisania danych do całej pamięci kontrolera wyświetlacza?
    3. Czy kolega nie potrafi napisać bardziej optymalnego dema, czy też po prostu nie chce zaprzeczyć sobie i swojej tezie o niższości AVR względem ARM, niechcący udowadniając, iż da się sprawnie animować kostkę z 12 kresek bez konieczności zużywania 100% czasu mikrokontrolera?

    No i czy kolega czasem nie ma jakiegoś tyciego kompleksu na tle małego mikrokontrolera (jeśli koledzy wiedzą, co mam na myśli)?

    Moderowany przez dondu:

    By być konsekwentnym w stosunku do bana dla LChucki, muszę koledze także wręczyć ostrzeżenie, za prowokowanie LChucki

  • #67
    LChucki
    Poziom 30  
    Urgon napisał:
    AVE...
    Gratuluję koledze udowodnienia ponad wszelką wątpliwość, że ośmiobitowce w ogólności, a AVR/Arduino w szczególności są gorsze od 32-bitowych ARMów. I wystarczyło koledze do tego użycie niezbyt optymalnego interfejsu i niezbyt optymalnej biblioteki by wykonać dość wymagającą animację z 12 kresek. Brawo. (...)

    Było już o tym, chyba 3 razy. Czy kolego potrzebuje indywidualnych lekcji? Jesli tak zapraszam, korepetycje 160zł/h. Wyjątkowa okazja.

    Urgon napisał:

    Trzy pytania:
    1. Czy funkcja czyszczenia ekranu polega na "ręcznym" wyzerowaniu wszystkich bajtów w pamięci kontrolera wyświetlacza?

    Było już o tym, proszę przeczytać, ze zrozumieniem, cały wątek. Znudziło mi się powtarzać enty raz to samo.

    Urgon napisał:

    2. Czy rysowanie 12 kresek wymaga wpisania danych do całej pamięci kontrolera wyświetlacza?

    Było już o tym, proszę przeczytać, ze zrozumieniem, cały wątek. Znudziło mi się powtarzać enty raz to samo.

    Urgon napisał:

    3. Czy kolega nie potrafi napisać bardziej optymalnego dema, czy też po prostu nie chce zaprzeczyć sobie i swojej tezie o niższości AVR względem ARM(...)

    Było już o tym, proszę przeczytać, ze zrozumieniem, cały wątek. Znudziło mi się powtarzać enty raz to samo.

    Urgon napisał:

    No i czy kolega czasem nie ma jakiegoś tyciego kompleksu na tle małego mikrokontrolera (jeśli koledzy wiedzą, co mam na myśli)?

    Jaki konkretnie kolega ma problem? Może uda mi się pomóc?
    Domyślam się, że chodzi o terapię indywidualną, cóż, będzie drogo (grupowe są tańsze) ale myślę, ze pomogę w wyleczeniu kompleksu niższości, bo o to chyba chodzi?


    Moderowany przez dondu:

    Po raz kolejny obraża kolega użytkowników forum.

    Ja już nie mam chęci z kolegą się patyczkować. Zbyt wiele razy pobłażaliśmy koledze dając kary porządkowe i pozostawiając możliwość korespondencji przez PW, by mógł kolega swobodnie korespondować z klientami na jego sondę.

    Ban na 6 miesięcy pozwoli nam wszystkim odpocząć.
    W sprawie zmniejszenia dolegliwości kary proszę kontaktować się z adminem głównym.

    Dla jasności sprawy nadmieniam, że moja decyzja NIE MA NIC WSPÓLNEGO z merytoryczną części dyskusji w tym temacie.

    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.

  • #68
    Urgon
    Poziom 36  
    AVE...

    Interfejs równoległy zamiast SPI by zwiększył prędkość animacji tak na moje oko jakieś 4 razy...

    LChucki napisał:

    Urgon napisał:
    1. Czy funkcja czyszczenia ekranu polega na "ręcznym" wyzerowaniu wszystkich bajtów w pamięci kontrolera wyświetlacza?

    Jeśli nie ma funkcji wypełniania prostokątów, a sterownik, którego użyłem do testów nie ma, to innej opcji nie ma!

    Można "zerować" tylko te fragmenty pamięci, które ulegają zmianie. Sterownikowi wszystko jedno, czy się rysuje czarny piksel na białym tle, czy biały piksel na białym tle. Co więcej, jeśli animacja nie jest generowana "na żywo", to można ją zapisać w formie opisu różnic między bieżącą klatką, a poprzednią...

    LChucki napisał:

    Urgon napisał:
    Czy rysowanie 12 kresek wymaga wpisania danych do całej pamięci kontrolera wyświetlacza?

    Nie wymaga i tak dział demo z Arduino. Widać kolega nie zadał sobie trudu sprawdzenia tego a może po prostu nie zna się na tym? W przypadku ARM wysyłam dane do całego LCD ale jaki to problem? I tak dział co najmniej 10 razy szybciej niż z AVR.

    Jasne, po co optymalizować kod, skoro wystarczy wziąć mocniejszy układ?
    Równie dobrze kolega mógł użyć jednego z tych ekranów TFT, co ma wbudowany układ SoC, który to zajmuje się obsługą całej grafiki, a dodatkowo jeszcze może ją ładować z karty SD bez udziału mikrokontrolera. Z czymś takim płynną animację kostki 3D da się zrobić i na czterobitowym mikrokontrolerze z zegarem 32768Hz.

    LChucki napisał:

    Urgon napisał:
    Czy kolega nie potrafi napisać bardziej optymalnego dema

    Pisałem kilka razy, po co? Na ARM działa to dobrze i nie ma powodu aby zyskać 0,001% czasu CPU. Na AVR, jak ktoś odczuwa potrzebę niech pisze lepsze funkcje, ile zyska? 2%? 5%? I nadal będzie to żółw.

    Na RPi działa jeszcze lepiej, bo potrafi aktualizować ekran 1440p 60 razy na sekundę w kolorze 32-bitowym, i jeszcze gratis działa na nim cały system operacyjny. Na AVR, ani nawet na ATXmedze się tego nie da zrobić...

    Cały ten temat jest dla mnie śmieszny dlatego, że kolega nie udowodnił niczego, czego nikt inny by nie wiedział. Choć w sumie kolega udowodnił, że się mu nie chciało zrobić bardziej miarodajnego testu, tj. spróbować stworzyć najpłynniejszą animację z z tak ograniczonymi zasobami na obu platformach by pokazać ogrom różnic w mocy i prędkości działania. Tylko po co, skoro kolega woli iść na łatwiznę. Teza została udowodniona tak czy siak. Teza, która dowodów nie potrzebowała, bo każdy obeznany w temacie wie, że 8 bitów to za mało na płynną grafikę na dużym ekranie. Nawet 32 bity mogą nie starczyć, dlatego Microchip ma w ofercie układy PIC32MZ DA, które to posiadają wbudowany układ GPU i do 32MB pamięci DRAM...
  • #69
    LChucki
    Poziom 30  
    Urgon napisał:
    Można "zerować" tylko te fragmenty pamięci, które ulegają zmianie. Sterownikowi wszystko jedno, czy się rysuje czarny piksel na białym tle, czy biały piksel na białym tle. Co więcej, jeśli animacja nie jest generowana "na żywo", to można ją zapisać w formie opisu różnic między bieżącą klatką, a poprzednią...

    Tak, ale kolega nie raczył zauważyć moich kolejnych animacji. PROSZĘ WIĘC POKAZAĆ A NIE PISAĆ POBOŻNE ŻYCZENIA. Dopóki kolega nie pokaże lepszych procedur, które zrównają się z ARM, dalsza dyskusja NIE MA SENSU!
    Jak zobaczę, to uwierzę i ustosunkuję się do kolejnych zarzutów.

    Dodano po 2 [minuty]:

    Urgon napisał:
    Cały ten temat jest dla mnie śmieszny

    Śmieszne to sa wypowiedzi kolegi, ba jak zwykle, widziałem, słyszałem ale sam nie zrobiłem. Prawda?
    Ja pokazałem, czekam na pokaz kolegi, a nie odwoływanie się do filmów na YT (na YT kilkanaście Perpetuum mobile widziałem - naprawdę działają czy oszustwo, jak Kaszpirowski i Nowak?), czy "podono", "mozna użyc FPGA". Konkrety proszę, projekt kolegi, który działa.
    Tak się składa, że VIC na CPLD+RAM (tańsze wtedy od FPGA) doZ-80, 8051 robiłem, więc tak łatwo nie da się mnie "spławić".
  • #70
    Użytkownik usunął konto
    Poziom 1  
  • #71
    khoam
    Poziom 32  
    @LChucki
    No dobra, mam tylko jedno pytanie: kiedy uznasz, że ten wątek można zakończyć? Jaka jest funkcja celu, którą sobie wyznaczyłeś, zakładając ten wątek?
  • #72
    LChucki
    Poziom 30  
    atollic napisał:
    A ta xmega to nie 8bitowy AVR?

    Już o tym było, proszę ponownie przeczytać cały wątek, ze zrozumieniem, na nierzeczowe zaczepki nie odpowiadam!
  • #73
    tronics
    Poziom 37  
    Cytat:
    Interfejs równoległy zamiast SPI by zwiększył prędkość animacji tak na moje oko jakieś 4 razy...

    No to ARM na 1 porcie może obsłużyć 2x więcej niż AVR, bo rejestry gpio są szersze :) A nawet szybciej bo można taktować do bodajże 50MHz część GPIO. A do tego zaprząc FSMC w wyższych modelach.
    Cytat:
    Można "zerować" tylko te fragmenty pamięci, które ulegają zmianie

    Owszem, ale na ARM zakładając bufor w pamięci można modyfikować naraz 4 bajty, a na AVR 1. Do tego układy z Chrom-ART mają pod tym kątem większe możliwości.
    Cytat:
    Równie dobrze kolega mógł użyć jednego z tych ekranów TFT, co ma wbudowany układ SoC

    Jasne, że można. Można też wziąć gameduino. Tylko i tak będzie zdecydowanie drożej :)
    Ma kolega rację pisząc
    Cytat:
    kolega nie udowodnił niczego, czego nikt inny by nie wiedział.

    To nie wymagało żadnego dowodu. Jakość bibliotek Arduino też nie. Już samo digitalWrite() jest pod tym kątem wskazówką - to NIE JEST ŚRODOWISKO NASTAWIONE NA WYDAJNOŚĆ!
  • #74
    krzysiek_krm
    Poziom 37  
    Urgon napisał:
    AVE...

    Gratuluję koledze udowodnienia ponad wszelką wątpliwość, że ośmiobitowce w ogólności, a AVR/Arduino w szczególności są gorsze od 32-bitowych ARMów. I wystarczyło koledze do tego użycie niezbyt optymalnego interfejsu i niezbyt optymalnej biblioteki by wykonać dość wymagającą animację z 12 kresek. Brawo. Czy następnym razem kolega będzie udowadniał, że McLaren M4 12C jest troszkę szybszy od małego fiata?

    Trzy pytania:
    1. Czy funkcja czyszczenia ekranu polega na "ręcznym" wyzerowaniu wszystkich bajtów w pamięci kontrolera wyświetlacza?
    2. Czy rysowanie 12 kresek wymaga wpisania danych do całej pamięci kontrolera wyświetlacza?
    3. Czy kolega nie potrafi napisać bardziej optymalnego dema, czy też po prostu nie chce zaprzeczyć sobie i swojej tezie o niższości AVR względem ARM, niechcący udowadniając, iż da się sprawnie animować kostkę z 12 kresek bez konieczności zużywania 100% czasu mikrokontrolera?

    No i czy kolega czasem nie ma jakiegoś tyciego kompleksu na tle małego mikrokontrolera (jeśli koledzy wiedzą, co mam na myśli)?

    Po pierwsze, bardzo dobrze że Chucki odkrył te wszystkie zjawiska, na pewno nikt inny by na to nie wpadł.
    Po drugie, żaden to kompleks, tylko po prostu zwyczajowa nadgorliwość neofity, jeszcze niedawno, w poprzedniej inkarnacji, Chucki za AVR-y dałby się pokroić na plasterki.
    A tak poważnie, jest miejsce dla ARM, jest miejsce dla AVR, Tiny, Arduino i co tam jeszcze. I bardzo dobrze, kolego Chucki, bo jak ARM wykończy konkurencję, to wtedy złapią Cię za (... cenzura ...), tak że będziesz śpiewał jak cały chór Stuligrosza.
    khoam napisał:
    No dobra, mam tylko jedno pytanie: kiedy uznasz, że ten wątek można zakończyć? Jaka jest funkcja celu, którą sobie wyznaczyłeś, zakładając ten wątek?

    To proste - kiedy wszyscy inni się zmęczą i post Chuckiego będzie ostatni, czyli jego będzie na wierzchu i od spodu.
  • #75
    LChucki
    Poziom 30  
    Dla mnie temat zamknięty. Nie ma sensu droczyć się z... Jak będzie coś wartego uwagi (nie manipulacje 3 czy 8-bit 8/256 kolorów vs 65536kolorow) to proszę pisać, wtedy zobaczę, odezwę się, jak AVR będzie lepszy od ARMmega/tiny (cena, obciążenie CPU), to zjem wszystkie ARM jakie posiadam.
    Kilkanascie razy czytałem w tym wątku, że złe biblioteki, że można lepiej, szybciej ale NIKT nie pokazała takiej opcji. Powód jest prosty, to tylko przechwałki AVRowców, którzy NIE POTRAFIĄ napisać dobrego kodu tylko sugerują się filmami z YT. Jak wierzą w YT ich sprawa, nie zabraniam nikomu wierzyć w wróżbitów, bienergoterapeutów i innych oszustów https://www.youtube.com/watch?v=ymLpCgcKfv8. Doprawdy nie pojmuję, jak osobo zdrowa psychicznie, przy dzisiejszym poziomie wiedzy, może wierzyć w Perpetuum Mobile, wróżki? Jak wróżą cyganki pokazano w filmie "Komedia małżeńska".