Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Europejski lider sprzedaży techniki i elektroniki.
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

W pełni sprzętowa realizacja protokołu WS2812B dla XMEGA

tmf 24 Gru 2017 00:06 5805 51
  • W pełni sprzętowa realizacja protokołu WS2812B dla XMEGA
    Właściwie mamy już Święta i świąteczny konkurs w DIY. A w nim sporo konstrukcji opartych na programowalnych diodach WS2812B. Stąd też, aby ułatwić innym realizację świątecznych projektów oświetleniowych, postanowiłem podzielić się rozwiązaniem pozwalającym na w pełni sprzętowe sterowanie tego typu diodami.

    Cytat:
    Jednocześnie, jako jeden z moderatorów działu DIY oświadczam, że nie biorę udziału w konkursie m.in. ze względu na potencjalny konflikt interesów. Także prezentowane rozwiązanie zamieszczam wyłącznie, aby, jak mam nadzieję, ułatwić życie innym.


    Diody WS2812B są fajne, ale mają pewną wadę – protokół transmisji danych nie pasuje do żadnego standardowego interfejsu spotykanego w mikrokontrolerach. W efekcie możemy spotkać się z różnymi rozwiązaniami transmisji danych, od prostych, polegających na manglowaniu pinem IO, np.: Link
    do nieco bardziej skomplikowanych, wykorzystujących częściowo dostępny hardware, np. interfejs SPI lub UART, np.: Link
    W tym ostatnim przykładzie, do komunikacji zaprzęgnięty został UART i dostępne w XMEGA DMA, co znacznie odciąża mikrokontroler, a przede wszystkim ułatwia tworzenie efektów – nie musimy przeplatać obliczeń z wysyłaniem danych. Wadą tego przykładu jest konieczność transkodowania danych – informacje RGB muszą zostać przekodowane tak, aby przy wysyłce przez UART do WS2812B utworzyć poprawny ciąg danych. Proces transkodowania nie jest skomplikowany ani jakoś szczególnie obciążający dla mikrokontrolera, ale czy da się pójść o krok dalej i zrealizować całkowicie sprzętowo wysyłanie danych?
    Do kontynuowania tematu zainspirował mnie artykuł kolegi @piotr_go pod tytułem „W pełni sprzętowe sterowanie LEDów WS2812B na STM32F030 by piotr_go” (Link).




    Autor użył mikrokontrolera STM32F030 i do realizacji transmisji danych wykorzystał DMA i timer. Pomyślałem więc, czy da się zrealizować w pełni sprzętową transmisję na innych mikrokontrolerach, w tym 8-bitowcach? Postanowiłem to sprawdzić, jednocześnie próbując nie powielać rozwiązania kolegi @piotr_go. Ponieważ ze względu na konieczność zapewnienia ciągłego strumienia danych dla WS2812B, a jednocześnie możliwości łatwego wykonywania obliczeń, przyda nam się DMA, postanowiłem wziąć oczywiście 8-bitową XMEGę. Pierwsze, w pełni sprzętowe rozwiązanie dla XMEGA zostało opublikowane jakiś czas temu:
    Link
    Problem w tym, że wykorzystuje ono układ logiki programowalnej, dostępny wyłącznie w XMEGA serii E5. Ponieważ są to małe procesorki, posiadające niewiele RAMu, więc automatycznie średnio nadają się do sterowania setkami, a może nawet tysiącami diod WS2812B jednocześnie. Niestety inne rodziny XMEGA nie posiadają modułu XCL, więc zaprezentowane rozwiązanie nie daje się na nie przenieść.
    Ale nic straconego. Wyzwanie przyjęte – i uprzedzając fakty – rozwiązane.
    Zacznijmy od założeń:
    -nie chcę powielać rozwiązania kolegi piotr_go, raz, że chcę wymyślić coś oryginalnego, dwa, że w XMEGA mamy tylko 4 kanały DMA, więc wolę je zostawić do transmisji danych do WS2812B, a nie do samego generowania impulsów sterujących,
    -w XMEGA mamy sporo timerów, więc tych mi nie szkoda,
    -rozwiązanie powinno zapewnić całkowicie sprzętową transmisję danych, bez konieczności ich transkodowania.
    Nie powiem, rozwiązanie problemu zajęło mi trochę czasu – mniej więcej 4 godziny, ale się udało. Zacznijmy więc od początku. Ponieważ dane do WS2812B transmitowane są szeregowo, więc oczywistym jest, że rozwiązanie sprzętowe musi wykorzystać jakiś serializer – z dostępnych w XMEGA mamy interfejsy SPI lub UART. SPI wykluczyłem a priori, gdyż nie współpracuje w trybie master z DMA i ma pojedyncze buforowanie nadajnika. Stąd też nawet jeśli SPI by się nadawało do realizacji sprzętowej transmisji, to byłoby to niezbyt wygodne. Na placu boju pozostał więc interfejs UART. W XMEGA jego wykorzystanie ma same zalety:
    -ma dwupoziomowy bufor nadajnika, dzięki czemu nawet bez DMA możemy stosunkowo łatwo zapewnić wysyłanie ciągłego strumienia danych,
    -da się go połączyć z DMA w celu automatyzacji przesyłu danych, co z kolei znacznie ułatwia nam pisanie aplikacji generującej efekty świetlne,
    -może pracować w trybie master SPI, co z kolei potrzebne jest do serializacji danych.
    Ok, interfejs wybrany, teraz musimy wyrzucane przez niego zera i jedynki zamienić na format zrozumiały dla WS2812B. Dla przypomnienia, 0 i 1 nadawane są w następujący sposób:
    W pełni sprzętowa realizacja protokołu WS2812B dla XMEGA
    Czas trwania bitu możemy podzielić na trzy części po około 400 ns. Nadanie zera oznacza utrzymanie stanu wysokiego przez 1/3 czasu trwania bitu i stanu niskiego przez 2/3 czasu trwania bitu, z kolei nadanie jedynki wymaga działania dokładnie odwrotnego – przez 2/3 czasu utrzymujemy stan wysoki, a przez 1/3 stan niski. Co się nadaje, do generowania impulsów o zadanym czasie? Oczywiście timer. A skoro nadanie zera lub jedynki wiąże się ze zmianą wypełnienia, to oczywiście użyjemy timera w trybie PWM. I tu jest pewien problem. Wypełnienie PWM musi się zmieniać w zależności od tego, czy nadajemy jeden, czy zero. Dodatkowo, w XMEGA timer nie ma trybu one shot, czyli raz skonfigurowany będzie nadawał zera lub jedynki w nieskończoność. Te dwa problemy na chwilę mnie zatrzymały. Jak pisałem, założenie było takie, że nie używam DMA do modulacji szerokości impulsu. Z pomocą przyszedł znany użytkownikom XMEGA i nowszych ATTiny tzw. event system. Umożliwia on elastyczne połączenie nadajnika zdarzeń z odbiornikiem. W przypadku timera, event system może wywołać jedną z wybranych akcji – np. wyzerować timer (TC_EVACT_RESTART_gc). Dzięki temu można łatwo połączyć wybrane zdarzenie na pinie IO z np. zerowaniem timera. Skoro jednak muszę generować dwa impulsy o różnym wypełnieniu, to muszę użyć dwóch timerów, jeden będzie odpowiedzialny za generowanie bitu o wartości 0, a drugi bitu o wartości 1. W moim przypadku będą to odpowiednio timery TCC1 i TCC0. Ktoś może się oburzyć moją rozrzutnością, ale w użytym mikrokontrolerze mam do dyspozycji osiem 16-bitowych timerów, więc dwa timery na jedną gałąź sterowania WSami to nie problem. Jest tylko jeszcze jeden mały kłopot – wyjścia PWM timerów są na różnych pinach, więc impulsy przez nie generowane trzebaby zsumować. Teoretycznie, ponieważ wyjścia w tym procesorze mogą pracować w trybie wired-OR, nie powinno być problemu. Ale jednak mały problem jest – WS2812B wymaga transmisji z szybkością ok. 800 kbps, co raczej utrudnia wykorzystanie trybu wired-OR (zbyt wolny czas opadania zboczy, wymuszany pasywnie przez rezystory np. wbudowane w port MCU). A zastosowanie zewnętrznej bramki byłoby porażką – miał być użyty wyłącznie mikrokontroler. I tu pojawia się przyjemna cecha odróżniająca ARMy od XMEGA i generalnie AVR. W przeciwieństwie do ARM, dla danego pinu możemy włączyć więcej niż jedną funkcję alternatywną. Jeśli włączymy na danym pinie dwa wyjścia PWM, to uzyskany przebieg będzie sumą logiczną dwóch przebiegów generowanych przez każdy z timerów. Czyli jest pięknie, dokładnie o to nam chodziło.
    Pozostaje jeszcze jedna rzecz – jak w zależności od tego czy UART nadaje jeden czy zero, wybierać jeden z timerów? Załóżmy, że timer TCC1 stale generuje przebieg odpowiadający nadawaniu zer. Aby nadać jedynkę, wystarczy więc w nadawanym przebiegu wydłużyć czas trwania stanu wysokiego – a więc nałożyć przebieg generowany przez TCC0. I tu sprawa jest prosta – przez event system, z wyjścia TxD UARTa, w przypadku, gdy stan tego wyjścia jest niski (nadajemy zero), wysyłamy sygnał zerujący timer TCC0, odpowiadający za generowanie przebiegu odpowiadającego nadawaniu bitu o wartości 1. Z kolei jeśli TxD jest w stanie wysokim, to timer TCC0 nie jest blokowany i generuje przebieg odpowiadający jedynce, nakładany na przebieg generowany przez TCC1. Bingo! W ten sposób mamy załatwione całkowicie sprzętowe nadawanie danych do WS2812B.
    Na koniec jeszcze jedno – generowanie RESET. Jak wiemy, wysyłka danych do WS2812B musi być poprzedzona wygenerowaniem sygnału RESET o czasie trwania co najmniej 50 µs:
    W pełni sprzętowa realizacja protokołu WS2812B dla XMEGA
    Czas minimalny jest podany w nocie, a czas maksymalny? Ten może być dowolnie długi – utrzymywanie magistrali w stanie resetu nie ma wpływu na samo funkcjonowanie naszej diody. Oczywiście, możemy reset wygenerować programowo, ale przecież miało być sprzętowo. Pogłówkujmy więc jeszcze trochę. Spokojnie możemy założyć, że jeśli nie transmitujemy żadnych danych, to magistralę możemy trzymać w stanie resetu. Ma to kilka zalet:
    -przypadkowe śmieci nie zmienią nam stanu diod,
    -diody są natychmiast gotowe do transmisji danych.
    Tylko mały problem – jak odróżnić sytuację, kiedy transmitujemy dane, od bezczynności? Przypominam – chodzi o rozwiązanie całkowicie sprzętowe, a nie jakieś programowe wygibasy. Sprawa jest prosta – jeśli nadajemy do WS2812B dane, to linia SCK (XCK UART) interfejsu UART jest aktywna – będzie na niej przebieg prostokątny, o okresie odpowiadającym okresowi trwania transmitowanego bitu. Jeśli nic nie transmitujemy, to linia będzie w stanie niskim (oczywiście zależy to od wykorzystywanego trybu pracy SPI). To teraz już mamy z górki. Brak impulsów na SCK powinien wymusić niski stan magistrali sterującej WS2812B. Ponieważ przy nieaktywnym SCK (brak nadawania danych), niski stan panuje także na linii TxD, więc automatycznie timer TCC0 (odpowiedzialny za generowanie przebiegu odbieranego jako jeden) utrzymywany jest w stanie zerowania – na jego wyjściu PWM panuje stan niski. Problemem w tej sytuacji jest tylko TCC1, który nam stale generuje bity o wartości zero. No to co trzeba zrobić? Ano też go wyzerujmy – czyli kolejny kanał event system i zdarzenie zerowania timera. W efekcie niski stan na SCK nam wyzeruje timer TCC1, czyli na wyjściu PWM też będzie zero, a więc cała linia sterująca WS2812B będzie w stanie niskim. W momencie nadawania danych, SCK będzie okresowo w stanie wysokim (wypełnienie tego przebiegu wynosi 50%), co odblokuje TCC1, który będzie mógł generować przebieg odpowiadający nadawaniu zera.
    A więc mamy całkowicie zrealizowany sprzętowo interfejs dla WS812B, niczym nie musimy sterować programowo, po prostu w chwili, gdy wyślemy informację o kolorze RGB do UART, wszystko magicznie przekoduje się samo.
    O ile wiem, pokazana realizacja jest pierwszą całkowicie sprzętową implementacją protokołu WS2812B dla XMEGA innej niż E5.
    Opisana zasada zadziała także dla wielu innych mikrokontrolerów, praktycznie wprost będzie można ją przenieść m.in. na mikrokontrolery ARM SAM Dxx i inne Atmela/Microchipa.
    Koniec gadania, czas na praktykę. W przykładzie użyłem XMEGA256A3BU – bo była pod ręką – a to dzięki uprzejmości forumowego kolegi Leon Instruments. Kod bez zmian zadziała praktycznie na każdej XMEGA.
    Procesor będzie taktowany z wewnętrznego generatora 32 MHz – przyda nam się wysoka częstotliwość taktowania przy generowaniu skomplikowanych efektów graficznych. Zacznijmy od konfiguracji SPI:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Tu nie mamy nic nietypowego – wykorzystujemy USARTC0, na pin PORTC1 wyprowadzony będzie sygnał SCK, a na PORTC3 sygnał TxD. Z tych pinów zroutujemy sobie sygnały przez event system. Niestety ponieważ sygnał XCK (SCK) zanim jest transmitowany przez event system, nie przechodzi przez inwerter portu, musimy połączyć fizycznie piny PORTC1 z PORTC5 – jest to jedyna, drobna niedogodność prezentowanego rozwiązania.
    Teraz konfiguracja timera (funkcja TimerInit) – zacznijmy od przemapowania wyjścia PWM timera TCC0 z domyślnego (PORTC0) na wyjście współdzielone z TCC1 (PORTC4):
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Teraz możemy skonfigurować timer I event system odpowiedzialny za generowanie przebiegu odpowiadającego jedynce:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    W kolejnym etapie konfigurujemy timer TCC1 odpowiadający za generowanie przebiegu rozpoznawanego jako zero:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Na koniec jeszcze udostępniamy zsumowany przebieg na pinie PORTC4:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    I to wszystko. Jeśli wejście DIN diody WS2812B podłączymy do pinu PORTC4, będziemy mogli nią w prosty sposób sterować. Przyda nam się jeszcze prosta funkcja wysyłająca do niej dane w formacie RGB:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Aby sprawdzić, czy wszystko działa, możemy wysłać ciąg testowy:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Powyższy kod nie robi nic imponującego – ustawia kolory pierwszych sześciu diod. Kompletny przykład znajduje się w załączniku. Oczywiście możemy ten przykład łatwo rozbudować o przesyłanie danych z wykorzystaniem DMA (wystarczy zaprogramować kanał na przesyłanie danych do USARTC0), możemy także wykorzystać pozostałe dostępne UARTy i timery, i w ten sposób stworzyć nawet cztery niezależne kanały-interfejsy do łańcucha diod WS2812B. Dzięki temu, bez problemu możemy wysterować nawet kilkanaście tysięcy diod WS2812B naraz!
    Warto jeszcze rzucić okiem na generowane przebiegi. Zacznijmy od ogólnego oscylogramu (na górze sygnał SCK, w środku nadawane dane - sekwencja 255, 0, 255, na dole, wygenerowany sprzętowo sygnał dla WS2812B:
    W pełni sprzętowa realizacja protokołu WS2812B dla XMEGA
    Tak to wygląda w powiększeniu (widać wygenerowane bity o wartości 1 i 0):
    W pełni sprzętowa realizacja protokołu WS2812B dla XMEGA
    I na koniec, powiększenie i pomiar czasu trwania, wskazujący, że mieścimy się w specyfikacji protokołu:
    W pełni sprzętowa realizacja protokołu WS2812B dla XMEGA
    Warto zauważyć, że możemy bardzo precyzyjnie ustalać zarówno okres, jak i czasy trwania stanu wysokiego i niskiego, co zapewnia nam możliwość ścisłego dostosowania się do wymagań użytego protokołu.

    Zapraszam do komentowania.
    WS2812-Har..are.zip Download (45.28 kB)


    Fajne!
  • #2 24 Gru 2017 01:02
    R-MIK
    Poziom 38  

    Sprytne.
    Szkoda, ze na AVRmega nie ma sposobu. Nic nie wymyśliłem, wszystko sprowadzała się do CPLD. Kto nie lubi CPLD, to pozostaje 2 x CD4541BE i bramka sumująca. Można oczywiście pobawić się w RC i zrobić na multiwibratorach (4538, 74HC123) a pewnie da się tez na 74HC00.

  • #3 24 Gru 2017 14:08
    Cersunited
    Poziom 16  

    "Diody WS2812B są fajne, ale mają pewną wadę – protokół transmisji danych nie pasuje do żadnego standardowego interfejsu spotykanego w mikrokontrolerach."
    Autor postu chyb nie zgłębił się w projekty komercyjne jak i DIY na różnych SoC i innych ARMach. Od dawna już do tego stosowany jest SPI, sam kilka lat temu pisałem soft do sterowania WS poprzez WiFi wykorzystując właśnie SPI. Przy okazji zdrowych i wesołych Świąt dla wszystkich :)

  • #4 24 Gru 2017 14:20
    R-MIK
    Poziom 38  

    Cersunited napisał:
    "Diody WS2812B są fajne, ale mają pewną wadę – protokół transmisji danych nie pasuje do żadnego standardowego interfejsu spotykanego w mikrokontrolerach."
    Autor postu chyb nie zgłębił się w projekty komercyjne jak i DIY na różnych SoC i innych ARMach. Od dawna już do tego stosowany jest SPI, sam kilka lat temu pisałem soft do sterowania WS poprzez WiFi wykorzystując właśnie SPI. Przy okazji zdrowych i wesołych Świąt dla wszystkich :)

    Jeden bit SPI odpowiada jednemu bitowi WS2812, czyli 3 zapisy do SPI wysyłają dane do jednego(jednej) WS2812?

  • #5 24 Gru 2017 18:25
    Cersunited
    Poziom 16  

    R-MIK>> jeżeli interesują Cie szczegóły mogę odszukać ten kod. Było to pisane na CC3200 z SPI jako data dla WS.

  • #6 24 Gru 2017 19:50
    tesla1697
    Poziom 2  

    Bo widzisz kolego. Tu nie chodzi o to by co roku kupować coraz to lepszy i szybszy procesor i więcej RAM'u, tylko żeby tak zoptymalizować kod aby działał też i na starszym sprzęcie.
    Kiedyś gdy nie było dostępnych dużych mocy obliczeniowych programy i gry musiałby być pisane dobrze zoptymalizowane (przeważnie asm). Teraz gdy procesory przez połowę czasu nic nie robią można odpuścić optymalizację dla wszystkich wodotrysków. Niestety przekłada się to na koszta.

    I teraz co za problem sterować WS nawet z jakiegoś GPIO procesora co ma kilka Ghz. Sztuką jest zrobić to na malutkim uC, a potem powielić to wprost proporcjonalnie dla tego wypasionego procka.

  • #7 24 Gru 2017 20:41
    Pong.Chu
    Poziom 16  

    tesla1697 napisał:
    Bo widzisz kolego. Tu nie chodzi o to by co roku kupować coraz to lepszy i szybszy procesor i więcej RAM'u, tylko żeby tak zoptymalizować kod aby działał też i na starszym sprzęcie.
    Kiedyś gdy nie było dostępnych dużych mocy obliczeniowych programy i gry musiałby być pisane dobrze zoptymalizowane (przeważnie asm). Teraz gdy procesory przez połowę czasu nic nie robią można odpuścić optymalizację dla wszystkich wodotrysków. Niestety przekłada się to na koszta.


    Ja nie bronię nikomu cyzelować przez 5 lat kodu na 8051 a dzielę się jedynie moimi przemyśleniami dotyczącymi tego jak wygląda forum elektroda. Powiedz mi po co chcesz optymalizować kod aby działał na starszym sprzęcie? Jaki masz w tym cel?
    Zmarnujesz kilka miesięcy lub tygodni swojego życia a w tym czasie Chińczyk nauczy się jak programować małego RISCa 32bitowego z megabajtami pamięci aby działał szybciej, może i nawet nieoptymalnie i będzie marnował zasoby ale to on sprzeda swój produkt Tobie a nie Ty jemu. Koszta to jest właśnie marnowaniu czasu ludzkiego na zbędną i głupią pracę optymalizowania na jakieś stare dziwolągi. Bo można zaprząc do roboty tych samych ludzi aby zrobili coś nowego i innowacyjnego nawet z cenę marnowania pamięci. Postęp polega na tym że marnujesz magebajty pamięci bo je masz i dodajesz nowe funkcje a nie optymalizujesz wykonywanie kodu na rupieciach.
    Nie wiem czemu ale na forum elektroda ludzie za pewną nobilitację odbierają robienie rzeczy nieracjonalnych - jakby nie zauwazyli że PRL się skończył i już nie trzeba "kombinować" i "załatwiać".

  • #8 24 Gru 2017 20:57
    R-MIK
    Poziom 38  

    Cersunited napisał:
    R-MIK>> jeżeli interesują Cię szczegóły mogę odszukać ten kod. Było to pisane na CC3200 z SPI jako data dla WS.

    Naturalnie temat mnie interesuje. Jeśli 3 bajty to jedna dioda WS2812 a u mnie 3, to łatwo policzyć, że można sterować 3 razy więcej LED przy tej samej wielkości ram a tej w AVR jest przeważnie mało. Jest to jeden z powodów, dla których wracam (w pewnym sensie wracam) do ARM.

  • #10 25 Gru 2017 10:30
    tmf
    Moderator Mikrokontrolery Projektowanie

    Cersunited napisał:
    "Diody WS2812B są fajne, ale mają pewną wadę ? protokół transmisji danych nie pasuje do żadnego standardowego interfejsu spotykanego w mikrokontrolerach."
    Autor postu chyb nie zgłębił się w projekty komercyjne jak i DIY na różnych SoC i innych ARMach. Od dawna już do tego stosowany jest SPI, sam kilka lat temu pisałem soft do sterowania WS poprzez WiFi wykorzystując właśnie SPI.


    To pochwal się kodem, jak przy pomocy samego SPI sterować WS'ami bez konieczności transkodowania danych. W połączeniu np. z innymi peryferiami, da się, ale to niczym się nie różni pod względem kombinowania od zaprezentowanego przeze mnie rozwiązania.
    Także chętnie poznałbym jaki ARM ma interfejs bezpośrednio dostosowany do sterowania WS'ami.

  • #11 25 Gru 2017 11:31
    lvy
    Poziom 10  

    Miło widzieć jak dalej się rozwija programowanie Xmeg, zwłaszcza że dzięki obfitym peryferiom często wygrywa w specyficznych zastosowaniach z ARMami (np gdzie potrzeba zbierania danych z 8 uart, dodatkowej komunikacji na kolejnych 3 uartach, 2x SPI i 2xi2c + kupka gpio i możliwe wgrywanie programu przez USB). jedyne inne rozwiązania ARM'owe na które trafiłem albo były w obudowach BGA i miliony połączeń, albo były drogie i niedostępne. Dlatego brawa dla autora za upór w publikowaniu!

    Pytanie do autora: czy dało by się z zewnętrznego eepromu/flasha przy pomocy event system odczytywać dane dla diod?

    ps. A co do porównania chińczyków i programowania to wolę przemilczeć ich umiejętności.

  • #12 25 Gru 2017 12:06
    tmf
    Moderator Mikrokontrolery Projektowanie

    lvy napisał:
    Pytanie do autora: czy dało by się z zewnętrznego eepromu / flasha przy pomocy event system odczytywać dane dla diod?


    Tu nie ma potrzeby komplikować. Np. z pamięci SPI lub równoległej możesz odczytywać dane, np. przy pomocy DMA i transferować je bezpośrednio na UART / SPI użyty do komunikacji w WS'ami.

  • #15 25 Gru 2017 21:50
    tmf
    Moderator Mikrokontrolery Projektowanie

    @KeinXor Dosyć egzotyczne to jest. Natomiast coś z tą implementacją jest mocno nie tak, skoro autor pisze, że podczas transferu danych CPU jest zajęty w 10-12% (i to CPU taktowany ponad 70 MHz!). W mojej implementacji, CPU w ogóle nie jest zajęty. Po ustawieniu DMA zapomina o transferze. Nawet zakładając konieczność podkradania cykli, to przy 32 MHz taktowania XMEGi byłoby to nie więcej niż 0,3%. Ciekawe z czego wynika to obciążenie w psoc, bo przecież UDB realizuje wymianę danych w pełni sprzetowo. Swoją droga, procki wyglądają ciekawie.
    Swego czasu były (i chyba nadal są) procesory Atmela z FPGA - FPSLIC się to nazywało. Tyle, że tu implementacja byłaby w FPGA, podobnie jak zresztą we wskazanym przez ciebie psoc5 - gdzie są konfigurowalne UDB. Takie coś mamy w znacznie mniej egzotycznej XMEGA E5 (nazywa się XCL) - podałem link w pierwszym poście do realizacji interfejsu do WS z jej wykorzystaniem.

  • #16 26 Gru 2017 11:00
    KeinXor
    Poziom 24  

    tmf napisał:
    @KeinXor Dosyć egzotyczne to jest. Natomiast coś z tą implementacją jest mocno nie tak, skoro autor pisze, że podczas transferu danych CPU jest zajęty w 10-12% (i to CPU taktowany ponad 70 MHz!). W mojej implementacji, CPU w ogóle nie jest zajęty. Po ustawieniu DMA zapomina o transferze. Nawet zakładając konieczność podkradania cykli, to przy 32 MHz taktowania XMEGi byłoby to nie więcej niż 0,3%. Ciekawe z czego wynika to obciążenie w psoc, bo przecież UDB realizuje wymianę danych w pełni sprzetowo. Swoją droga, procki wyglądają ciekawie.
    Swego czasu były (i chyba nadal są) procesory Atmela z FPGA - FPSLIC się to nazywało. Tyle, że tu implementacja byłaby w FPGA, podobnie jak zresztą we wskazanym przez ciebie psoc5 - gdzie są konfigurowalne UDB. Takie coś mamy w znacznie mniej egzotycznej XMEGA E5 (nazywa się XCL) - podałem link w pierwszym poście do realizacji interfejsu do WS z jej wykorzystaniem.


    Tak zgadza się pierwsza opublikowana implementacja sterowania obciążała procesor i była na posc4, spowodowane było to niewykorzystaniem DMA.
    Aktualna wersja działa na psoc5 i wykorzystuje DMA.

    -----edit-----
    Tu wersja DMA https://github.com/PolyVinalDistillate/PSoC_DMA_NeoPixel

  • #17 26 Gru 2017 13:01
    Sareph
    Poziom 17  

    R-MIK napisał:
    Ciekawe kiedy pojawią się wyświetlacze 7-seg WS2812? Matryce 5x7 już widziałem.

    Hmm, a gdzie jeśli można wiedzieć? Bo jakby to były takie rozmiaru 30mm, to bym się bardzo chętnie poczęstował.

  • #18 26 Gru 2017 18:39
    R-MIK
    Poziom 38  

    Sareph napisał:
    R-MIK napisał:
    Ciekawe kiedy pojawią się wyświetlacze 7-seg WS2812? Matryce 5x7 już widziałem.

    Hmm, a gdzie jeśli można wiedzieć? Bo jakby to były takie rozmiaru 30 mm, to bym się bardzo chętnie poczęstował.

    Na Youtube widziałem. Są też tu: https://kamami.pl/diody-led-matryce-linijki/5...pu-ws2812.html?search_query=ws2812&results=45 ale to "składak". Trochę większy: https://kamami.pl/diody-led-matryce-linijki/2...staw-1mm.html?search_query=ws2812&results=45..

  • #19 26 Gru 2017 18:47
    Sareph
    Poziom 17  

    R-MIK napisał:
    Takie to wiem, że są, ale kompletnie mnie nie interesują, duże to i bez osłon. Mnie interesuje coś co może zastąpić max7219 + matryca 8x8 (32x32mm). Wyświetlacze 7 albo lepiej 16 segmentowe na ws2812 też mogły by być ciekawe, no ale nie ma najwyraźniej żadnej z tych opcji.

  • #20 26 Gru 2017 18:52
    tmf
    Moderator Mikrokontrolery Projektowanie

    Na Ali są panele po 1200 diod (30*40), elastyczne, po $130 za panel. Coś takiego:
    W pełni sprzętowa realizacja protokołu WS2812B dla XMEGA

    Co do WS2812B, to szkoda tylko, że nie ma ich w wersji z rozdzielczością 12 bitów/kolor. Niestety po uwzględnieniu gammy, z 8-bitowej głębi zostaje tylko trochę ponad 7 bitów, w dodatku kwantyzacja daje o sobie znać.

    Dodano po 3 [minuty]:

    @Sareph Tego typu panele widziałem zbudowane tylko ze zwykłych LEDów. Moduły 8x8 z kilkubitowym kolorem wysterujesz ze zwykłego MCU, w darmowych przykładach do jednej z moich książek, jest przykład dla XMEGA, gdzie jest sterowanie 3 bity na kolor. Przy pomocy FPGA da się sterować tego typu matrycami z rozdzielczością 8 bitów/kolor.

  • #21 26 Gru 2017 19:29
    Sareph
    Poziom 17  

    tmf napisał:
    Co do WS2812B, to szkoda tylko, że nie ma ich w wersji z rozdzielczością 12 bitów/kolor. Niestety po uwzględnieniu gammy, z 8-bitowej głębi zostaje tylko trochę ponad 7 bitów, w dodatku kwantyzacja daje o sobie znać.

    Jak już tak o tych bitach, to mi by nawet 4-5bit i tylko monochromatyczna wersja pasowała, ale...

    tmf napisał:
    @Sareph Tego typu panele widziałem zbudowane tylko ze zwykłych LEDów. Moduły 8x8 z kilkubitowym kolorem wysterujesz ze zwykłego MCU [...]
    ... 3 bity to już za mało. Bo w moim wypadku tak na prawdę nie chodzi o poziomy jasności pikseli a bardziej całego wyświetlacza, bo mają dostosować do jasności otoczenia. A samo mieszanie kolorów czy tam nawet same kolory, to miły dodatek, jednak tylko dodatek. To czego bym oczekiwał, to moduł matrycowy, który jest rozmiarów standardowej matrycy 8x8, ma dyfuzor, osłonę, własny kontroler, daje się łączyć kaskadowo i ma regulacje jasności przynajmniej na poziomie całego wyświetlacza w zakresie minimum 4 bit. Innymi słowy, takie zastępstwo dla max7219 + matryca o nie gorszej funkcjonalności i rozmiarze. ;)

  • #22 26 Gru 2017 20:22
    tmf
    Moderator Mikrokontrolery Projektowanie

    @Sareph Jeśłi tak to nie ma problemu. Przejrzyj przykłady o których wsominałem (nie pamiętam w której książce to opisałem, ale w którejś o XMEGA), jasność można regulować nawet z kilkunastobitową precyzją, w XMEGA jest to realizowane całkowicie sprzętowo, łącznie z odświeżaniem matrycy, więc cały CPU masz do dyspozycji. W mono dodatkowo z 5 bitową głębię też uzyskasz. Zobacz na to:
    W pełni sprzętowa realizacja protokołu WS2812B dla XMEGA
    Zdjęcie z aparatu nie oddaje efektu, ale wygląda to naprawdę świetnie.
    BTW, to pająk, na którym to testowałem (drivery to SCT2024, oraz P-MOSFETy w SOT23 jako drivery kolumn):
    W pełni sprzętowa realizacja protokołu WS2812B dla XMEGA
    W pełni sprzętowa realizacja protokołu WS2812B dla XMEGA
    W pełni sprzętowa realizacja protokołu WS2812B dla XMEGA
    Do malkontentów - proszę nie krytykować tego pająka, to był tylko proof-of-concept do celów testowych.

  • #23 26 Gru 2017 22:32
    R-MIK
    Poziom 38  

    tmf napisał:
    Do malkontentów - proszę nie krytykować tego pająka, to był tylko proof-of-concept do celów testowych.

    To nie DIY, gdzie jak ktoś nie potrafi się do niczego przyczepić, to pisze "kable niepospinane, brak obudowy, itp".

  • #24 27 Gru 2017 12:07
    Marek_Ertew
    Poziom 15  

    Sareph napisał:
    R-MIK napisał:
    Takie to wiem, że są, ale kompletnie mnie nie interesują, duże to i bez osłon. Mnie interesuje coś co może zastąpić max7219 + matryca 8x8 (32x32mm). Wyświetlacze 7 albo lepiej 16 segmentowe na ws2812 też mogły by być ciekawe, no ale nie ma najwyraźniej żadnej z tych opcji.
    Gdzieś obiła mi się o oczy matryca jakiej szukasz. Wymiary 8x8 pikseli i raster 5mm. Wyprowadzenia 2x 8 pinów, ale piny opisane jako DIN, DOUT, 2x GND i 2x VCC. Nie jestem pewien czy na pokładzie były WS2812 czy konkurencyjne układy ale na pewno sterowały LEDami RGB. Niestety jak na złość teraz tego nie mogę znaleźć.

    Wyświetlacze 7-segmentowe istnieją w wersji DIY, fabrycznych modułów nie spotkałem.
    https://www.youtube.com/watch?v=gl8RiE_fSo4 (do kupienia)
    https://youtu.be/dANsWZ2awww?t=1m26s (wersja Mirka)

  • #25 28 Gru 2017 10:00
    Sabre
    Poziom 18  

    Są diody podobne do WS2812B nazywają się hucznie DotStar. Mają rozmiar 2x2mm ale mają interfejs dwuprzewodowy (zegar plus dane).
    Co prawda nie znalazłem nigdzie gotowej matrycy ze zdjęć z tej aukcji, ale pewnie gdzieś jest dostępna.

    W pełni sprzętowa realizacja protokołu WS2812B dla XMEGA

    Moderowany przez tmf:

    Link do aukcji usunąłem (regulamin), wstawiłem zdjęcie modułu.

  • #26 28 Gru 2017 10:31
    tmf
    Moderator Mikrokontrolery Projektowanie

    Fajne, tylko dokumentacja skąpa. Na plus - sterowanie przez SPI, tyle, że nie podają max taktowania. Wg przykładu z noty, przy odświeżaniu 50 Hz max 319 diod w szeregu, a więc gorzej niż w przypadku WS2812B.

  • #27 28 Gru 2017 10:46
    Sabre
    Poziom 18  

    Jeszcze raz umieszczam link, tym razem do hasła a nie do jednej aukcji.

  • #28 28 Gru 2017 11:12
    Sareph
    Poziom 17  

    Ciekawe te dotstary, tylko krótki szereg... ale odkryłem, że WS2812 występują w takiej formie (5mm):

    W pełni sprzętowa realizacja protokołu WS2812B dla XMEGA

    I tak w sumie, jakby można je było dostać jako 3mm, to jak dla mnie byłby ideał. Bo zostaje tylko maskownice wydrukować na drukarce 3D (albo wyciąć laserem) i byłaby kompaktowa matryca w dowolnie konfigurowalnym rozmiarze.

  • #29 28 Gru 2017 11:25
    Sabre
    Poziom 18  

    @Sareph one występują już od dość dawna w takich obudowach. Modele to APA106, APA102 i PL9823. Niestety ja się naciąłem i dostałem z Chin zwykłe RGB nie APA106 w 5mm obudowie (na szczęście po długiej batalii z aliexpress odzyskałem pieniądze). Mam APA106 w 8mm, mlecznej obudowie. Zrobiłem z nich lampki na choinkę. Mają troszkę inny protokół sterowania, ten do WS2812B nie działał poprawnie, musiałem troszkę wydłużyć czasy i zamienić dane dla kolorów RGB w tych jest chyba GRB w protokole (nie pamiętam już dokładnie).
    W pełni sprzętowa realizacja protokołu WS2812B dla XMEGA

  • #30 28 Gru 2017 14:52
    tmf
    Moderator Mikrokontrolery Projektowanie

    Sareph napisał:
    I tak w sumie, jakby można je było dostać jako 3mm, to jak dla mnie byłby ideał.

    To nie jest problemem, można dać zwykłe diody RGB i do nich sterownik WS2811. Chociaż przy takim kombinowaniu dałbym jakiś lepszy sterownik z 12 bitami na kanał.

TME logo Szukaj w ofercie
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME
TME Logo