Diody WS2812 zdobyły niezwykle dużą popularność. Niestety ich sterowanie nie jest łatwe. Częstym problemem jest fakt, że w czasie transmisji danych do diod zawieszane są przerwania a jeśli nie to obciążenie CPU, jeśli nie może być wspomagane przez DMA, jest bardzo duże. Nie bez znaczenia jest też potrzeba rezerwacji dużego obszaru RAM na bufor diod co jest bardzo odczuwalne mikrokontrolerach z małą ilością RAM. Wszystkie te problemy rozwiązuje akcelerator.

Do komunikacji z akceleratorem wykorzystano interfejs I2C lub opcjonalnie SPI. Dzięki temu, w czasie transmisji danych, CPU może obsługiwać przerwania a także, możliwe jest, aby sama transmisja odbywała się w przerwaniach. Interfejs SPI umożliwia wysłanie danych szybciej niż miałoby to miejsce w przypadku bezpośredniej transmisji do LED. Opcjonalne tryby koloru 8 i 16-bit pozwalają zmniejszyć zapotrzebowanie na bufor pamięci RAM do 33 lub 66% w stosunku do bezpośredniego sterowania diodami oraz zmniejszają czas wysyłania danych. Biblioteki dla Arduino umożliwiają łatwą obsługę akceleratora.

Charakterystyka:
Maksymalna liczba diod: 640
Liczba akceleratorów 8 (na jednym fizycznym interfejsie)
Paleta barw:
24 R8G8B8 – 16 mln barw
16 R5G6B5 – 65536 barw
8-bit R3G3B2 – 255 barw, każda w 63 odcieniach (16065 barwy)
218 barw 218+16 barw, każda w 63 odcieniach (14742 barw) opcjonalne
256 barw definiowanych przez użytkownika w 63 odcieniach (16128 barw)
Interfejs komunikacyjny: I2C, SPI, USB, UART
Prędkość transmisji:
SPI 6 (8) MHz
I2C 800kHz
UART 921,6kb/s
USB 12Mb/s
Akcelerator akceptuje napięcia do 5V na wejściach interfejsów komunikacyjnych!

Nawet na AVR taktowanym zegarem 8MHz, uzyskanie wymaganych rygorów czasowych dla WS2812 nie jest trudne. Niestety generowanie wymaganych czasów najczęściej odbywa się przez pętle opóźniające. W konsekwencji w czasie transmisji danych program nie może robić nic innego. W AVR konieczne jest zawieszenie przerwań, bo ewentualne wydłużenie poziomu wysokiego na wejściu Din WS2812 o ponad 600ns (jeden takt CPU w AVR) może powodować błędy w transmisji, natomiast przerwanie trwające ponad 20μs gdy Din ma znajduje się w poziomie niskim może zostać zinterpretowane jak sygnał RESET (LATCH) dla WS2812. Problem może rozwiązać transmisja z użyciem UART lub SPI ale wymaga to przepływności 2,4MB/s, możliwej do uzyskania dla AVR ale skorzystanie z mechanizmu przerwań USART powoduje 80...90% obciążenie CPU nawet gdy skorzysta się z wstawek assemblerowych. Pojawiają się także trudności z obsługą innych przerwań w czasie transmisji do diod spowodowane tym, że większość AVR nie ma wielopoziomowego systemu przerwań a nadawanie do WS2812 musi mieć najwyższy priorytet. Innym mankamentem jest zapotrzebowanie na pamięć RAM, które wynosi osiem bajtów na diodę gdy korzystamy z UART, dziewięć gdy z SPI co oznacza, że na 1000 led potrzeba 8 lub 9kB RAM. W pamięć 8kB wyposażone są tylko nieliczne AVRmega a program wymaga pamięci na stos, stertę, zmienne. Co ważne, w przypadku użycia USART, mikrokontroler musi być taktowany zegarem co najmniej 18MHz. Wszystko to powoduje, że jedynym AVRmega, który jest w stanie wysterować dużą liczbę diod jest ATmega1284. Wydawać się może, że problem rozwiąże zewnętrzna pamięć danych, którą można podłączyć do niektórych AVR, ale dostęp do takiej pamięci zajmuje dwa razy więcej czasu niż do wewnętrznej SRAM przez co obciążenie CPU wzrośnie.
Opcjonalnie przewidziano możliwość komunikacji przez UART i USB. Wykorzystanie I2C/SPI pozwala na transmisję danych bez blokowania przerwań a nawet zrealizować ją na przerwaniach, dzięki czemu CPU może realizować inne zadania w czasie transmisji. Opcjonalne tryby 8 i 16-bitowego kodowania koloru pozwala zmniejszyć zapotrzebowania na RAM o 66/33% przyspieszyć transmisję danych. Użyty w akceleratorze mikrokontroler STM32F072C8 posiada 16kB RAM co pozwala umieścić bufory dla 640 LED i danych odbieranych przez I2C/SPI.
Do jednej magistrali I2C, co pozwala wysterować 5120 diod (ekran o rozdzielczości 128x32 ma 4096 pikseli). W przypadku SPI, można podłączyć więcej niż osiem akceleratorów, przy czym każda kolejna ósemka wymaga osobnego sygnału strobu. Biorąc pod uwagę fakt, że przy zegarze SPI 8MHz, transmisja danych dla 640 LED trwa około 4,8ms wysłanie danych do ośmiu akceleratorów zajmie 39ms. Maksymalna częstotliwość odświeżania wyniesie 26Hz co oznacza, że do obsługi większej ilości niż 5120 LED potrzebny będzie mikrokontroler z większą ilością interfejsów SPI oraz DMA. Tak jak w przypadku AVRmega liczba SPI może zostać łatwo zwiększona, ponieważ przeważnie USART może pracować w roli SPI, tak problem DMA pozostaje. W takiej sytuacji należy sięgnąć po większy mikrokontroler. Xmega mają DMA ale w porównaniu do ARM ich możliwości nie są oszałamiające a cena bardzo często wyższa. ARM rozwiąże problem DMA, RAM ale w takim przypadku po co akcelerator skoro sam ARM bez problemu wysteruje tysiące LED a większość czasu spędzi w uśpieniu? Przed zastosowaniem akceleratora warto zastanowić się, czy nie lepiej, zamiast na AVR czy PIC, program napisać na ARM? W Internecie krążą mity na temat skomplikowania ARM. Prawda jest niego inna, program na ARM pisze się łatwiej niż na AVR zwłaszcza jak korzysta się z darmowych narzędzi dostarczanych przez producenta.





W załączniku dokumentacja, programy i filmy.

Mam pewne wątpliwości co do opisu, nie mogę wywnioskować na czym polega ta "akceleracja", być może brakuje mi wiedzy, ale na razie brzmi to jak jakieś voodoo, ale po kolei.

Żeby "wysterować" jedną diodę WS2812 w łańcuchu należy przekazać do wejścia diody sygnał o długości mniej więcej 24*1,2 = 288 [us].
Następnie należy odczekać tzw czas resetu. W zależności od rodzaju / klonu diody może to być albo 9, 30 a czasami więcej mikrosekund.
Zatem minimalny czas na zmianę koloru dla pojedynczej diody to: 288 + czas_resetu, dla diod "jakie wskazałem" może to być 288 + 30 = 318 [us]. Dla n-diod będzie to n*288 + 30 [us]
Zatem żeby zmienić wartość koloru dla 640 diod to potrzebny jest czas 18,4 [ms] co odpowiada odświeżaniu 54 fps.

Tak przy okazji ta nazwa "reset" nie jest sensowna, bardziej to czas "latch", czyli po jakim czasie niskiego stanu, na wejściu diody, następuje zatrzaśniecie przesłanych danych. W ten sposób jesteśmy w stanie co pewien czas (nazwijmy go odświeżania) zmieniać wyświetlanie koloru. Być może to tylko semantyka...

Wracając do tematu nie rozumiem na czym ma polegać ta akceleracja.
Ja bym sobie wyobrażał to tak, że "jedziemy" na kilka kanałów (łańcuchów) diod i synchronizujemy owe kanały. To niestety nie wynika z opisu, nawet załączony schemat ma tylko jedno wyjście na łańcuch diod, zatem o co chodzi?

Obejście zajęcia pamięci to mogę zrozumieć. Kodujemy kolory w buforze pamięci RAM na 16 bitach (nie na 32, gdzie 32-24=8 bitów jest pustych). Musimy pamiętać, że i tak musimy posłać szeregowo 24 bity - brakujące bity zerujemy tak, by pojedynczy stan PWM miał nieznaczące zera, niestety tracimy na zakresie jasności.
Natomiast przyśpieszenia transmisji to już nie kumam, bo żeby poprawnie przekazać kolory do łańcucha to nie ominiemy czasu wg wzoru: n*288 + czas_resetu ( [us], gdzie n ilość diod ).

W celu uzupełnienia, żeby otrzymać sensowne 30 fps z jednego kanału to można podłączyć co najwyżej ok 1150 diod, a dla 24 fps ok 1400.

Tak jak pisałem wyżej warto byłoby doprecyzować na czym polega ta "akceleracja", ja nie umiem tego wywnioskować z opisu.

Dane można wysyłać taktując SPI zegarem 8MHz. Sterując bezpośrednio LED zegar to 800kHz. Wysłanie danych do 640 LED zajmie 19ms - 1/(800000/24/640). Używając SPI 1,9ms - 1/(8e6/24/640) więc 10 razy mniej czasu. Gdy użyjemy palety 16-bit 1,2ms - 1/(8e6/16/640), 8-bit 0,64ms - 1/(8e6/8/640). Bezpośrednio WS2812 nie przyjmą danych 8 czy 16 bit, tylko i wyłącznie 24-bit. Akcelerator konwertuje dane z 8/16 bit na 24. Dane do samych led będą więc wysyłane tyle i muszą ale mikrokontroler wysyłając do akceleratora może to zrobić szybciej a także i wolniej. Przerwy w transmisji danych do akceleratora w niczym nie przeszkadzają gdyby takie przerwy zrobić podczas transmisji danych do LED efekt jest znany.


Nic nie jest puste. Konwersja z 16 na 24-bit wygląda podobnie jak z 16 na 18 w LCD. W przypadku 8-bit gdy wybieram kolor np 1, to jest mu przypisane RGB(255,0,0), kolor 2 to np RGB(0,255,0) itd według "bezpiecznej palety" 218 barw https://pl.wikipedia.org/wiki/Kolory_w_Internecie

Jak już napisałem nic się nie traci. W przypadku 16-bit dane transkodowane sa z R5G6B5 na R8G8B8 przy czym nie jest tak, ze najmłodsze bity sa zerowane. Tak jak w przypadku transkodowania w LCD z 16 na 18-bit, tak i tu, stan najmłodszych bitów danych wyjściowych jest zależny od stanu najstarszych bitów wejściowych.
W przypadku trybu 8-bit 218 barw powstał problem regulacji jasności, którego nie ma w 24 czy 16 bit. Jak kolor czerwony ma przypisane RGB(255,0,0) to ma i konie. Dlatego wprowadziłem możliwość regulacji jasności (32 poziomy), podobnie w trybie 8-bit R3G3B2. Tu działa także mechanizm jak w LCD. Na przykładzie barwy niebieskiej gdzie sa tylko 2 bity na kolor.
bity wejściowe 00 to wyjściowe 00000000
01 -> 01010101
10 -> 10101010
11 - > 11111111

Kolejna zaleta, to że w czasie transmisji danych do akceleratora działają przerwania a nawet można zrealizować ją na przerwaniach. To na AVR jest możliwe, ale jak pisałem, nie łatwe i ma sporo ograniczeń.


Podsumowując:
- Dane mogą być wysyłane szybciej (SPI 8MHz) niż gdyby bezpośrednio sterować LED.
- Kolory można kodować także w 16 bit co zmniejsza czas transmisji o 33% jak i o tyle zapotrzebowanie na RAM.
- Możliwe kodowanie 8-bit co zmniejsza czas transmisji o 66% jak i o tyle zapotrzebowanie na RAM.
- Bezproblemowo działają przerwania.
- Transmisja może być realizowana na przerwaniach.


Teraz kończę akcelerator graficznych LCD. Przyspieszenie wynika z:
- Transmisji 8 a nawet 4-bit.
- Kodowania współrzędnych jednym a nie dwoma bajtami (dla LCD do 255x255).
- Komend CLS, LINE, STRING coś jak w FT801.

Łatwo oszacować przyspieszenie. Kodowanie 8-bit to w przypadku wysyłania treści obrazka dwa razy mniej danych. Gdy użyjemy 4-bit (16 barw) to wysłanie rysunku np ikony daje przyspieszenie 4 krotne.
Przy stawianiu pojedynczych pikseli, klasycznie wygląda to tak:
CMD, X, Y, COLOR, łącznie 7 bajtów (CMD jeden, pozostałe po dwa)
Do akceleratora:
także CMD, X, Y, COLOR ale wszystkie dane 8-bit co daje 4 bajty. Przyspieszenie ok 43%.
W przypadku wysyłania stringu czy linii przyspieszenie jest rzędu setek a nawet tysięcy razy.

------------------------ [ Dodano po: 33 minutach ]

Taki akcelerator można by zbudować na AVR ale:
- W czasie transmisji danych do LED przez akcelerator nie może odbierać danych z mikrokontrolera sterującego. W konsekwencji trzeba zapewnić mechanizm czekania mikrokontrolera aż akcelerator będzie gotów. W praktyce max odświeżanie spada więc 2 razy. W ARM problemu nie ma dane wysyłane są do LED a CPU przyjmuje kolejną ramkę do wyświetlenia.
- AVR nie przyjmie danych po SPI taktowanym 8MHz. Nie próbowałem, ale prawdopodobnie max to 1MHz co daje 128 cykli maszynowych pomiędzy bajtami. Ile rozkazów? Można szacować jakieś 90. Szału nie ma a trzeba jeszcze wejść/wyjść z przerwania, odłożyć/zdjąć dane na/z stos. Można kombinować w pętli głównej. Przy 2MHz pomiędzy bajtami są tylko 64 cykle (ok 45 rozkazów), 4MHz 32 cykle (22 rozkazy) 8MHz 16 cykli (11 rozkazów).

Dzięki za próbę doprecyzowania.
Niestety wzór, który podałem n*24*1,2[us] + czas_resetu wg mnie wywraca całość "na plecki", przynajmniej na obecnym moim pojmowaniu tego zagadnienia

Częstotliwość zboczy powinna oscylować wokoło 800 kHz (1/1,25[us] = 800KHz), bo tak wynika z dokumentacji tych diod. Oczywiście SPI można sobie pędzić różnie, ale bez naruszania zboczy na wyjściu (u Ciebie to chyba J4 ze schematu).
Pewnie można zejść do 0,8 [us] na bit, bo tak próbowałem "przetaktować" różne takie diody i potrafiło to działać, a efektem byłby możliwy, poprawnie sterowany, o 10 % większy łańcuch w zadanym czasie.


a zarazem mamy:
To 19 ms to oczywiście poprawna wartość, wg nawet mojego wzoru, a to wcześniejsze zdanie?
Wyczytałem, że transmisja dla 640 LED potrwa ok 4.8 ms - to mi nie pasowało.

Z drugiej strony to chyba myślę, że może o czymś innym rozmawiamy, Kolega o technikach "wewnętrznych", które mają za zadanie przygotować peryferia pod efekt finalny czyli 800KHz na pinie, a ja pisałem tylko o tym, co już jest "za pinem" - a tu 800 KHz i finalnej ilości diod/fps nie da się oszukać. Trzeba iść na kompromis, albo duża ilość diod albo duże "fps". Nic innego do głowy mi nie przychodzi

Odradzam działanie poza dopuszczalnymi przez producenta granicami. Efekt może być taki, że u jednej osoby program dział u innej nie. Inna seria diod i przetaktowanie jest nieskuteczne.

Można wysyłać dane równolegle do kilku łańcuchów LED. W przypadku AVR wyjścia nie ma w ARM, kilka SPI lub UART i DMA to nie problem.
W AVR można ewentualnie podłączyć kilka akceleratorów (bez problemu można podłączyć ich 8) a w każdym małą ilość LED i SPI na MAX. Przy SPI 8MHz dane wysyłane są ponad 8 razy szybciej niż do led bezpośrednio. Można więc w tym samym czasie wysłać dane do 8 łańcuchów. Zamiast do 800 LED mogę wysłać do 6400 lub do 800 odświeżając 8 razy częściej. Gdy użyję palety 16-bit, a na oko, różnicy pomiędzy 24 a 16 bit nie widać, to łańcuchów może być 10 lub odświeżanie 10 razy częstsze.


Akcelerator powstał na prośbę znajomego, zagorzałego AVR-owca, po trochu też od pewnego czasu Arduino-wca. Dobrze, że już odpuścił 8051, bo gdy ja działałem na 6833x w C on męczył się na 8051 w ASM. Teraz chłopak walczy z AVR i ESP, ja z STM32.

Może i cel dobry, ale kompletnie tego nie widzę w praktyce. Jeśli ktoś potrzebuje migadełka do choinki czy na imprezę urodzinową to wystarczy zwykły AVR, który obleci sporo led i jeszcze więcej efektów. Jeśli to ma być poważniejszy projekt to po co w ogóle zawracać siebie głowę i AVR i ARM? Nie wystarczy sam ARM? Wg mnie to takie trochę naginanie rzeczywistości na siłę, ale może się mylę

_________________
http://www.sylwekkuna.com

Oczywiście wystarczy ale widzę, że jest grupa programistów, która lubi obkładać AVR niezliczonymi układami jak ekspandery portów zamiast użyć większego AVR. LCD przez PCF8574 choc wyprowadzeń mikrokontrolera jest na tyle dużo, ze można bez problemu podłączyć bezpośrednio. Nextion (STM32) + AVR zamiast użyć ARM. Czasem używają 2 płytek arduino a wystarczyłaby jedna. Moda jakaś na budowanie z dużej ilości elementów i drogo? Nie, raczej niewiedza i strach przez nowym.


Jeszcze nie zabrałem się za pisanie biblioteki dla dopalacza LCD ale wyniki pierwszych testów czasowych już są. Wysłanie danych o 128x128 pikseli trwa 47ms

Tradycyjną opcją dwa razy dłużej. Ważne jest jednak coś jeszcze, to, że nie widać jak "obrazek" jest rysowany, bo wyświetlony zostaje w 30ms. Sama więc transmisja może trwać długo ale na ekranie treść pojawi się "natychmiast" - klasyczne podwójne buforowanie. Oczywiście w czasie gdy dane są wysyłane do LCD, ARM może przyjmować kolejne dane. Ten dopalacz będzie bardziej przydatny niż do WS2812 tym bardziej, że planuję opcję dla wyświetlacza za do 480x320. Pierwsze testy już robiłem. Samą treść przekazuję do LCD w ok 30ms gorzej będzie z odbiorem z AVR.

Muszę się kiedyś i ja zająć wreszcie graficznymi wyświetlaczami. Na razie nie było potrzeby i przede wszystkim czasu na testy, ale już w głowie mam cykliczny przesył tak jak to zrobiłem dla LCD 16x2 gdzie jego obsługa zajmowała w pętli głównej kilkanaście mikrosekund, a nie kilkadziesiąt ms. Ciekaw jestem tylko czy tak się da w tym przypadku

_________________
http://www.sylwekkuna.com

O ile będziesz miał odpowiednio dużo RAM i DMA to tak. Niewielki (160x128) kolorowy LCD wymaga ponad 40kB na bufor. Masz więc pierwszy, w przypadku AVR, problem. Możesz kombinować z zewnętrznym RAM ale dostęp do niego jest wolniejszy niż do wewnętrznego SRAM. Drugi problem to czas transmisji. Na AVR realnie nie wyciśniesz 8 czy 10MHz, owszem zegar taki będzie ale pomiędzy bajtami przerwy. Można kombinować jakieś bloki po np 32 bajty, nie sprawdzać czy bajt wyszedł z SPI tylko wstawić NOP. Powiedzmy, że nie masz przerw, które przy standardowym podejściu są dłuższe niż transmisja bajtu. Aby wysłać 40,96kB potrzebujesz, (taktowanie 20MHz, SPi 10MHz) 32ms. Oczywiście to iluzja, poniżej 40 raczej nie zejdziesz a pewnie będzie to bliżej 50. Aby więc uzyskać sensowne FPS, CPU nie może robić nic innego jak wysyłać dane. Rozwiązaniem jest DMA. Kolejne to że SPi w wyświetlaczach najczęściej może pracować do 15MHz a to dla AVR jest nieosiągalne.
Przy wyświetlaczach 320x240 i AVR zapomnij. Pierwszy problem brak RAM. Drugi szybkość transmisji. W przypadku SPI kasowanie ekranu trawa teoretycznie 60ms w praktyce pond 100. Nawet mając bufor w RAM max to 10 FPS. Bez bufora (320x240 to 153kB RAM) stawiasz piksel po pikselu wysyłając 7 bajtów. Gdybyś wysyłał z bufora są to tylko 2 bajty.

------------------------ [ Dodano po: 11 minutach ]

Tryb równoległy pochłonie trochę pinów, zatrzask adresu nie jest potrzebny. AVR musi mieć busskepper, machanie pinami aby wygenerować WR nie ma sensu. Nadal jednak problem braku RAM. Jak dasz zewnętrzny, to trzeba dodać dekoder adresu, bankowanie - gra niewarta świeczki.

------------------------ [ Dodano po: 21 minutach ]

Dobra rada. Zanim zaczniesz kupować wyświetlacze, podłączać, próbować weź kalkulator w dłoń i policz. Ostrożnie podchodź to FPS, wyjdzie 10 i stwierdzisz, że wystarczy. Otóż nie! Jeśli dane będziesz wysyłał 100ms będzie widać rysowanie grafiki, kasowanie ekranu. Aby nie było takich efektów nie możesz przekroczyć 30, max 40 ms.

Obsługiwałem różne LCD, od mono 100x32 do 480x320 kolor, po I2C, SPI, równolegle (FCM w SPT32). Masz wątpliwości pytaj. Przy większych rozdzielczościach i AVR, jedyne sensowne rozwiązanie to FT8xx.

To jest prototyp. Ma złącza SPI, I2C, USB, UART, SWD, kilka testowych. Finalnie płytka może być co najmniej 2 razy mniejsza a myślę, że i 3. Jak pomyśleć, że to do Arduino to niepotrzebny stabilizator 3,3V.


Ciekawy pomysł.

Apropos ledów, to warto zobaczyć:
https://www.youtube.com/watch?v=QWoCH6FRdpI
Koniecznie od początku do końca.

Heh - COŚ PIĘKNEGO dla oka ... i takie projekty - pokazują, że w sumie mało ważne na jakim to procku ... ważne żeby aż TAK przemyśleć całość - magiczny efekcik

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]