Arduino i FT800 - Sterowanie LED i ekranem dotykowym jednocześnie

Witam,

Program najpierw sterował taśmą WS2811 ale miałem także ekran dotykowy FT800 i postanowiłem stworzyć proste sterowanie parametrów tamtego programu. Napisałem wszystko tylko kiedy klikne w jakikolwiek parametr na ekranie to zatrzymuje mi się efekt na taśmie LED. Z tego co wywnioskowałem to chyba musiałbym to wszystko oprzeć o przerwania. Tak? Jesli moje obserwacje są słuszne to proszę o nakierowanie z czym to się je. Z góry Dziekuję.



Jest pomieszane pare programów za co przepraszam ale walcze dość mocno zarówno z Arduino jak i FT800.

ATmega nie ma szans wysterować WS2812 jeśli jest używane jakieś przerwanie. Weź jakiś tańszy i z 10x szybszy mikrokontroler...

BlueDraco napisał:

ATmega nie ma szans wysterować WS2812 jeśli jest używane jakieś przerwanie. Weź jakiś tańszy i z 10x szybszy mikrokontroler...

Dosyć kategoryczne stwierdzenie... Biorąc pod uwagę jakie cuda robią ludzie na tych prockach idę o zakład, że nie masz racji. Podwójnie nie masz racji, gdyż 10x szybszy procesor nic nie zmieni. To co może coś zmienić to zmiana algorytmu, tak, aby uniknąć blokowania programu. Oczywiście użycie procka z DMA umożliwi osiągnięcie celu nawet przy tak napisanym programie, jednak nie szybkość MCU będzie tu determinantą sukcesu.

Jeśli mówimy o ATmega, to najmniej czasochłonnym sposobem nadawania jest użycie SPI, a wtedy trzeba generować ponad 300.000 przerwań na sekundę, co jest niemożliwe do obsługi, zstaje więc aktywne oczekiwanie na SPI z zablokowanymi przerwaniami. Każdy inny sposób transmisji na ATmega (bibang) również wymaga zablokowania przerwań na czas transmisji do WS2812. W obu przypadkach przerwania są wykluczone.
Byle-jaki Cortex na 20..40 MHz z 12-lub16-bitowym SPI bez problemu obsłuży odpowiednio 200k lub 150k przerwań na sekundę i jeszcze zostanie mu sporo czasu na obsługę innych przerwań.

Stwierdzenie jak widać kategoryczne, acz prawdziwe. Oczywiście XMega da radę, bo i nieco szybsza, i ma DMA, i ma możliwość wyrzeźbienia w sprzęcie stosownego interfejsu.

@BlueDraco Niespecjalnie widzę różnicę pomiędzy 16 vs. 48 MHz. Korzystając na ATMega z UART i tego, że ma bufor, można wysłać na raz 6 bitów dla WSa. To daje nam max. 130 tys. przerwań na sekundę, czyli dla 16 MHz 120 taktów. Liczba spokojnie do obsłużenia na ATMega bez żadnej gimnastyki. Inna sprawa, że krytyczne jest tylko wysyłanie danych do WSa (a i to nie wiadomo, czy musi się odbywać stale), a obsługę GUI można wrzucić na drugi plan.

Ostatnio robiłem obsługę WS'a na stm32. Użycie DMA w połączeniu z Timerem rewelacyjnie rozwiązuje sterowanie WS'a bo nie jest to tylko różnica w MHz.

Przy UART mamy 3 bity na ramkę, a więc 260 kHz. Przy 16 MHz daje to 62 cykle procesora na przerwanie - wątpię, czy przy programowaniu w C ATmega ma szansę się wyrobić. Podwójny bufort UART tu nie pomoże, chyba, że w przerwaniu dorzucimy aktywne oczekiwanie, co wygląda śmiesznie, ale zmniejsza liczbę przerwań o połowę kosztem w tym przypadku dodatkowych 62 cykli spędzonych w przerwaniu (po co?).
Natomiast na pewno ATmega nie może obsługiwać żadnych innych przerwań w czasie transmisji do WS. To po prostu nie jest układ, który nadawałby się do tego zadania - potrzeba czegoś mniej archaicznego i tańszego, np. małego Cortexa za 1,60..2 zł.

Robiłem obsługę WS2812 na kilku różnych Cortexach - bez DMA na 30, 40 i więcej MHz, z DMA od 20 MHz w górę (bo to było na STM32, gdzie są ograniczenia na podzielnik SPI).
Sensowne animacje na WS wymagają generowania min. 40 ramek na sekundę. AVR nie nadąży.

BlueDraco napisał:

Przy UART mamy 3 bity na ramkę, a więc 260 kHz. Przy 16 MHz daje to 62 cykle procesora na przerwanie - wątpię, czy przy programowaniu w C ATmega ma szansę się wyrobić. Podwójny bufort UART tu nie pomoże, chyba, że w przerwaniu dorzucimy aktywne oczekiwanie, co wygląda śmiesznie, ale zmniejsza liczbę przerwań o połowę kosztem w tym przypadku dodatkowych 62 cykli spędzonych w przerwaniu (po co?).
Natomiast na pewno ATmega nie może obsługiwać żadnych innych przerwań w czasie transmisji do WS.

Kompletnie nie masz racji. Po co chcesz w przerwaniu USART na coś czekać? Skoro masz bufor to ładujesz dwa bajty - jeden jest wysyłany, kolejny czeka w kolejce. Wysyłasz więc 6 bitów na raz. Jeśli używasz przerwania TxC, które zgłaszane jest po opróżnieniu bufora i nadajnika USART to będziesz miał tylko 130k przerwań. A nawet jeśli ktoś nie pomyśli i zrobi to byle jak to i 260 k przerwań i 62 takty na przerwanie to wystarczająco dużo, aby obsługę napisać w C. AVR wchodzi w przerwanie w ciągu 4/5 taktów, to nie ARM, który potrzebuje na to wieczności (0WS CM0+ - 15 taktów). Proste uzupełnienie rejestru danych USART z bufora to dwie instrukcje. W takiej konfiguracji nic poza wysyłką danych do WS nie musi być oparte na przerwaniach.

Dodano po 5 [minuty]:

BlueDraco napisał:

Sensowne animacje na WS wymagają generowania min. 40 ramek na sekundę. AVR nie nadąży.

Cenię cie, więc proszę nie pisz bzdur. Przed świętami robiłem animację na WS jako iluminację świąteczną i AVR nie tylko nadążał, ale wręcz się nudził.
A dla przypomnienia - mamy autora wątku, który ma konkretny układ i jakiśtam pasek, którym chce sterować. Nawet nie wiemy czy jakaś animacja tam jest, czy po prostu sobie statycznie kolory ustawia i cała ta nasza dyskusja w związku z tym jest bezcelowa.

Nie możesz załadować w ciemno dwóch bajtów do bufora UART. Przerwanie jest zgłaszane, gdy jest wolne miejsce w buforze - na jeden bajt.

Piszesz o cyklach procesora i instrukcjach na poziomie asemblera - obejrzyj początek i koniec procedury obsługi przerwania napisanej w C i skompilowanej na AVR - zajmie to więcej cykli, niż potrzebuje Cortex. Dodaj jeszcze skok do procedury i możliwości adresowania pamięci przez AVR i masz pełny rozmiar nieszczęścia. Nie wyobrażam sobie użycia AVR do prostych, ale wycyzelowanych animacji, które robiłem, choćby z powodu użycia w nich arytmetyki 32-bitowej - takie operacje wymagają na AVR min. 20x tyle cykli zegara, co na maszynie 32-bitowej - dostęp do danych w pamięci, prosta arytmetyka, odesłanie wyniku, ładowanie i modyfikacja wskaźników. po co tak mordować procesor, który ledwie dycha.

Ostatnio chciałem sobie sprawić prezent w postaci małej, gotowej płytki uruchomieniowej. Myślałem o klonie Arduino Nano lub Micro. Skończyło się na STM32F103 Mini Board za 2.40 USD. Nie lubię F10x z powodu archaicznej wersji CM3 i paskudnego mapowania peryferiali, ale zawsze to coś wygodniejszego w użyciu i o niebo szybszego niż AVR.

BlueDraco napisał:

Nie możesz załadować w ciemno dwóch bajtów do bufora UART. Przerwanie jest zgłaszane, gdy jest wolne miejsce w buforze - na jeden bajt.

Na AVR mamy przerwanie UDRE które działa tak jak piszesz oraz TXC wyzwalane po całkowitym opróżnieniu obu bajtów w buforze.

BlueDraco napisał:

Piszesz o cyklach procesora i instrukcjach na poziomie asemblera - obejrzyj początek i koniec procedury obsługi przerwania napisanej w C i skompilowanej na AVR - zajmie to więcej cykli, niż potrzebuje Cortex. Dodaj jeszcze skok do procedury i możliwości adresowania pamięci przez AVR i masz pełny rozmiar nieszczęścia.

Zależy jak kto napisze procedury przerwań (a łatwo wpaść w pułapkę)

Tutaj masz przerwanie ogólnego przeznaczenia wykonujące się w mniej niż 62 cykle.

Po ustawieniu TXC już jest za późno na załadowanie bajtu, jeśli transmisja ma iść ciągle!

W asemblerze to i na odpowiednio szybkim 51 da się to napisać...

BlueDraco napisał:

Po ustawieniu TXC już jest za późno na załadowanie bajtu, jeśli transmisja ma iść ciągle!

Ale w czym problem? Pomiędzy parami bajtów zostaną dodane krótkie odstępy, o ściśle określonym czasie trwania i wartości 1. I to nawet lepiej bo można je wykorzystać jako początek nadawania kolejnego bitu, w efekcie można upchnąć w dwubajtową ramkę (z wyjątkiem pierwszej) nie 6 a 7 bitów. W AVR czas wejścia w przerwanie jest ściśle określony +/- 1 takt CPU. Jitter na poziomie 60 ns nie przeszkadza w transmisji do WSa.

Dodano po 11 [minuty]:

BlueDraco napisał:

Nie możesz załadować w ciemno dwóch bajtów do bufora UART. Przerwanie jest zgłaszane, gdy jest wolne miejsce w buforze - na jeden bajt.

Piszesz o cyklach procesora i instrukcjach na poziomie asemblera - obejrzyj początek i koniec procedury obsługi przerwania napisanej w C i skompilowanej na AVR - zajmie to więcej cykli, niż potrzebuje Cortex. Dodaj jeszcze skok do procedury i możliwości adresowania pamięci przez AVR i masz pełny rozmiar nieszczęścia.

Aż sobie sprawdziłem - cała funkcja obsługi takiego przerwania zajmuje 38 taktów + 4/5 taktów na wejście w ISR, łącznie max 43 takty. Wobec 123, które mamy (lub nawet 62 jeśli napiszemy to kiepsko i mamy 260k przerwań) to i tak w najgorszym przypadku daje nam 30% czasu procesora do dyspozycji, a w bardziej optymalnym wariancie mamy aż 65% czasu MCU do dyspozycji. Bez jaj, to wystarczy, żeby naprawdę poszaleć.

BlueDraco napisał:

Nie wyobrażam sobie użycia AVR do prostych, ale wycyzelowanych animacji, które robiłem, choćby z powodu użycia w nich arytmetyki 32-bitowej - takie operacje wymagają na AVR min. 20x tyle cykli zegara, co na maszynie 32-bitowej - dostęp do danych w pamięci, prosta arytmetyka, odesłanie wyniku, ładowanie i modyfikacja wskaźników. po co tak mordować procesor, który ledwie dycha.

Są operacje arytmetyczne, które zajmą znacznie więcej czasu na 8-bitowcu, ale 20x więcej to tylko szczególne przypadki. Warto byłoby więc sprecyzować o jakich operacjach mówimy, bo na pewnym poziomie abstrakcji to to co napisałeś może być prawdą lub bzdurą. Prosty przykład - operacje dodawania i odejmowania int na 8-bitowcu będą tylko 4-krotnie dłuższe. Operacje mnożenia na AVR to 4 mnożenia i 3 dodawania o niepełnej długości. Dla float już może być różnie. Ale nieważne. Pochwal się jaka transformacja wymagała operacji na typie 32-bitowym?

Odstęp nie będzie miał ściśle określonego czasu, a ani jednego bitu więcej w ramkę nie upchniesz, nawet gdyby miał określony czas, bo nie zmienisz wartości bitu startu ani stopu UARTa.

Te 30% "wolnego" czasu procesora zajmie kodowanie danych do transmisji. Ciekawe, czy się wyrobi... - niekoniecznie moim zdaniem, zwłaszcza, że występują tu i dane 12-bitowe i indeksowanie pamięci. A cały czas mówimy o dobrze napisanym kodzie asemblerowym. Masochizm jakiś, zważywszy, że praktyczeni za cenę cieniutkiego 16 MHz Arduino z ATmega z 4 KiB RAM można nabyć płytkę z 72 MHz, trochę mniej przestarzałym STM32 z 64KiB Flash i 20 KiB RAM.

He, he, he.

Jakie operacje zajmą duuużo więcej czasu? Np. zwykłe dodawanie dwóch liczb 32-bitowych umieszczonych w pamięci, albo sumowanie wektora danych 16- lub 32-bitowych (na Cortex - 3 instrukcje na element + 2 na odliczenie pętli).
Przez grzeczność nie wspomnę o mnożeniu i dzieleniu.

Będzie miał ściśle określony czas, o ile nie wyłączę lub nie będę wykorzystywał innych przerwań. Nie chce mi się teraz kombinować, ale 6,5 bita prześlę przez USART w takiej konfiguracji w trybie SPI i bity startu oraz stopu mi niestraszne.
Liczyłem 43 takty max dla kodu w C (na podstawie testowego kodu, który sobie napisałem - raptem trzy linie), w asemblerze napiszę tę funkcję w max. 10-15 taktów, a jak się uprę to zejdę poniżej 6.
Proponowałbym się trzymać tematu dyskusji - bo nie piszemy o tym co jest lepsze, tylko czy się da. A okazuje się, że się na 8-bitowcu da i to bez problemu.
Co do operacji np. dodawania - na AVR, który nie ma tak jak np. Z80 możliwości wykonywania operacji arytmetycznych na pamięci, operacja dodawania dwóch liczb z pamięci będzie wymagała ich pobrania i wykonania 4 instrukcji dodawania, czyli łącznie 12 instrukcji, na ARM 3. Daleko do wspomnianego 20-krotnego pogorszenia wydajności. Ale na 8-bitowcu, który umożliwia wykonywanie operacji arytmetycznych na pamięci będzie to szybsze.
Niemniej nie to mnie ciekawi - ciekawi mnie do jakich transformacji potrzebujesz typów 32-bitowych? Bo wymyśleć nie mogę

Np. do liczenia pozycji obiektu na taśmie z 576 szt. WS2812 z subpikselową dokładnością z równania ruchu jednostajnie przyspieszonego.

Hmm, 576 diod, nawet w szeregu to troszę ponad 9 bitów, dodajmy tą dokładność subpikselową, powiedzmy 12-14 bitów? No nie wiem, możesz rozwinąć?

żeby liczyć pozycję z równania z kwadratem czasu, potrzeba ok. 11 bitów w części ułamkowej. Docelowo pozycja jest liczona z 8 bitami ułamkowymi, przez które mnożę kolor piksela przy akumulacji. Przy ruchu jednostajnym liczę pozycję od razu z tylko 8 bitami ułamkowymi. Sorry, tak to wyszło. Przy 16 bitach całości albo były widoczne skoki w animacji (przy 4 bitach ułamka), albo wyskakiwało poza zakres.

Panowie co do tego co wyświetlam na ws2811, wyświetlam animacje. Obecnie imitacje płomienia. Po waszych wiadomościach nie do końca dla mnie zrozumiałych wnioskuję że nie uda się tego zrobić na arduino. A jeśli zrobiłbym to np na dwóch arduino połączonych razem? Jeden do obsługi wyświetlacza a drugi do WS?

Czy jest jakiś istotny powód, by nie zrobić tego na płytce z np. STM32 za 12..45 zł?

Praktycznie do tego zadania potrzebujesz mikrokontrolera z SPI obsługiwanym przez DMA i pamięcią o pojemności 12 * liczba WS2812 + pewnie z 1..2 KiB na struktury danych.

A mógłbyś mi polecić jakąś płytkę z prockiem która obsłuży ekran, diody i moze coś jeszcze po rozbudowie? Czy te procesory o których mówimy można programowac językiem Arduino?

I czy pomysł dwóch odrębnych Arduino jest zły?

Rolnik95 napisał:

Panowie co do tego co wyświetlam na ws2811, wyświetlam animacje. Obecnie imitacje płomienia. Po waszych wiadomościach nie do końca dla mnie zrozumiałych wnioskuję że nie uda się tego zrobić na arduino. A jeśli zrobiłbym to np na dwóch arduino połączonych razem? Jeden do obsługi wyświetlacza a drugi do WS?

A skąd taka konkluzja? Przez kilka postów pisałem, że się da, padły nawet sugestie jak to zrobić. Czyli przerzucić obsługę WS do przerwania i wykorzystać sprzętowy interfejs USART. Jeśli z tym sobie nie dasz rady, to IMHO po przesiadce na ARM prędzej osiwiejesz niż to zrobisz

A mógłbys podac mi jakies przykłady abym mógł sobie je przeanalizawac?

Pomysł dwóch Arduino jest zły, bo transmisja danych do WS zarzyna procesor i uniemożliwia odbiór danych z innego Arduino. Można to niby załatwić dodatkowym sygnałem gotowości, ale po co używać dwóch wolnych modułów do tego, do czego wystarczy jeden szybki i tańszy?

Tania platforma z LCD, która bez problemu poradzi sobie też z WS: LPC1768 Mini-DK2 (bez wbudowanego interfejsu debuggera, tylko możliwość ładowania programu przez USB lub dołączenia debuggera.

Inny pomysł z gotowym LCD - to płytki STM32F429 i 467 Discovery, z modułem debugowania na pokładzie.

Rolnik95 napisał:

A mógłbys podac mi jakies przykłady abym mógł sobie je przeanalizawac?

Przeczytaj wszystkie części:
http://mikrokontrolery.blogspot.com/2011/03/Diody-WS2812B-sterowanie-XMega.html
DMA nie masz, więc końcówka cie nie dotyczy, ale sama zasada jest niezależna od MCU.

Przepraszam ale dopiero się uczę i nie rozumiem tego co kolega mi wysłał. Czy mogę prosić jakieś ukierunkowanie? Czy da się czy nie ? Czy now procek czy dam rade z arduino?