ATNEL tech-forum https://forum.atnel.pl/ |
|
Akcelerator WS2812 dla Arduini, AVR, PIC https://forum.atnel.pl/topic22579.html |
Strona 1 z 1 |
Autor: | Zealota [ 24 wrz 2019, o 12:54 ] |
Tytuł: | Re: Akcelerator WS2812 dla Arduini, AVR, PIC |
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. |
Autor: | Semi [ 24 wrz 2019, o 13:36 ] |
Tytuł: | Re: Akcelerator WS2812 dla Arduini, AVR, PIC |
Zealota napisał(a): Wracając do tematu nie rozumiem na czym ma polegać ta akceleracja. 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. Zealota napisał(a): 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). 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 Zealota napisał(a): 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. 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). |
Autor: | Zealota [ 24 wrz 2019, o 14:37 ] |
Tytuł: | Re: Akcelerator WS2812 dla Arduini, AVR, PIC |
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. Semi napisał(a): transmisja danych dla 640 LED trwa około 4,8ms wysłanie danych do ośmiu akceleratorów zajmie 39ms. a zarazem mamy: Semi napisał(a): Wysłanie danych do 640 LED zajmie 19ms 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 |
Autor: | Semi [ 24 wrz 2019, o 15:31 ] |
Tytuł: | Re: Akcelerator WS2812 dla Arduini, AVR, PIC |
Zealota napisał(a): 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ć 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. Zealota napisał(a): Trzeba iść na kompromis, albo duża ilość diod albo duże "fps". 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. |
Autor: | SylwekK [ 24 wrz 2019, o 16:15 ] |
Tytuł: | Re: Akcelerator WS2812 dla Arduini, AVR, PIC |
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ę |
Autor: | SylwekK [ 24 wrz 2019, o 16:59 ] |
Tytuł: | Re: Akcelerator WS2812 dla Arduini, AVR, PIC |
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 |
Autor: | Semi [ 24 wrz 2019, o 17:12 ] |
Tytuł: | Re: Akcelerator WS2812 dla Arduini, AVR, PIC |
SylwekK napisał(a): 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 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. |
Autor: | Semi [ 24 wrz 2019, o 17:50 ] |
Tytuł: | Re: Akcelerator WS2812 dla Arduini, AVR, PIC |
qwertownik napisał(a): Możesz pomyśleć jak to zminiaturyzować najbardziej 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. qwertownik napisał(a): projekt do pokazania w elektronice praktycznej Ciekawy pomysł. |
Autor: | Zealota [ 24 wrz 2019, o 19:30 ] |
Tytuł: | Re: Akcelerator WS2812 dla Arduini, AVR, PIC |
Apropos ledów, to warto zobaczyć: https://www.youtube.com/watch?v=QWoCH6FRdpI Koniecznie od początku do końca. |
Autor: | mirekk36 [ 24 wrz 2019, o 20:37 ] |
Tytuł: | Re: Akcelerator WS2812 dla Arduini, AVR, PIC |
Zealota napisał(a): 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 |
Strona 1 z 1 | Strefa czasowa: UTC + 1 |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |