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:

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:

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:

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):

Teraz możemy skonfigurować timer I event system odpowiedzialny za generowanie przebiegu odpowiadającego jedynce:

W kolejnym etapie konfigurujemy timer TCC1 odpowiadający za generowanie przebiegu rozpoznawanego jako zero:

Na koniec jeszcze udostępniamy zsumowany przebieg na pinie PORTC4:

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:

Aby sprawdzić, czy wszystko działa, możemy wysłać ciąg testowy:

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:

Tak to wygląda w powiększeniu (widać wygenerowane bity o wartości 1 i 0):

I na koniec, powiększenie i pomiar czasu trwania, wskazujący, że mieścimy się w specyfikacji protokołu:

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)

"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

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

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.

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.

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.

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.

Sterowanie sprzętowe w psoc5 Link

@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.

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

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ł.

R-MIK napisał:

Są tez 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...zstaw-1mm.html?search_query=ws2812&results=45.

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.

Na Ali są panele po 1200 diod (30*40), elastyczne, po $130 za panel. Coś takiego:


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.

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.

@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:

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):



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

Sareph napisał:

R-MIK napisał:

Są tez tu: https://kamami.pl/diody-led-matryce-linijki/5...pu-ws2812.html?search_query=ws2812&results=45 ale to "składak". Troche większy: https://kamami.pl/diody-led-matryce-linijki/2...zstaw-1mm.html?search_query=ws2812&results=45.

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)

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.

Moderowany przez tmf:

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

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.

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

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



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.

@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).

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ł.