W pełni sprzętowe sterowanie LEDów WS2812B na STM32F030 by piotr_go

R-MIK wrote:

Żadna rewelacja. Natknąłem się na noty katalogowe producenta w tym temacie.

Oj, chyba nie...
Wszystkie dotychczasowe metody wymagały ręcznego podzielenia bajta na bity przez co jeden bit zajmował jeden bajt, albo wymagało to przeliczeń "w locie".
U mnie wysyłasz 3 bajty (3 8mio bitowe transfery SPI) na diodę i nic więcej.

piotr_go wrote:

Oj, chyba nie...

Nie chyba a na pewno!
Kolega R-MIK chyba nie czuje w ogóle powagi sytuacji . To że oto na naszych oczach dokonał się przełom w walce z podstawową uciążliwością protokołu WS2812B, dokonany za pomocą dwóch prozaicznych mostków.
Co prawda użycie SPI "jeden do jednego", przewinęło się tu gdzieś na forum, ale zastosowana była zewnętrzna konwersja wartości bitu metodą czysto analogową (tzn. jakieś RC + tranzystory), co znacznie ustępuje tej tutaj realizacji, złożonością układową, koniecznością wzięcia pod uwagę tolerancji wartości elementów itd.

Bardzo sprytne i eleganckie rozwiązanie, muszę przyznać. Choć w szczegółach niezbyt jeszcze uniwersalne, jeśli by przenosić na inną konfigurację STM32 (port F jako wartość CNT), ale nie widzę też jakiś przeszkód by np. użyć przerwań do ładowania CNT, by nie być związanym wyborem pinu i portu.
Podoba mi się i rodzi pomysły na wykorzystanie trochę inne niż samodzielna migałka (np. jako przejściówka I2C->łańcuch WS2812B), tym bardziej że to groszowa kość a widać jak mało jej potencjału jest tu zużyte.

Akurat wysyłanie po SPI do WS robiłem ja, tylko 2 x 12 bitów i akurat na STM32F3, działać działało ok. Nie chwaliłem się dalszym kodem, gdyż moja wiedza z C nie jest powalająca i jak bym kod pokazał to by mnie szanowni koledzi zjechali jak burą sucz. W każdym razie plus za pełny gotowiec.

oskar777 wrote:

Akurat wysyłanie po SPI do WS robiłem ja, tylko 2 x 12 bitów i akurat na STM32F3, działać działało ok. Nie chwaliłem się dalszym kodem, gdyż moja wiedza z C nie jest powalająca i jak bym kod pokazał to by mnie szanowni koledzi zjechali jak burą sucz. W każdym razie plus za pełny gotowiec.

Nie, sorry, kolejne kodowanie softwarowe.

A nie było przypadkiem coś na temat wysyłania przez SPI w EP?

vp32 wrote:

A nie było przypadkiem coś na temat wysyłania przez SPI w EP?

Tak, ale przed zapisem do SPI trzeba było przeliczyć na krótsze i dłuższe impulsy.

@piotr_go Ciekawy pomysł, tym bardziej, że w miarę uniwersalny i da się go przenieść na inne procki o odpowiednio rozbudowanych peryferiach. Natomiast historycznie nie jest to pierwsza całkowicie sprzętowa implementacja protokołu dla WSów - chyba pierwsza była dla XMEGA serii E5 z wykorzystaniem posiadanego przez te procesory bloku logiki programowalnej, m.in. na stronie kol. Dondu (http://mikrokontrolery.blogspot.com) jest w komentarzach przykład implementacji na ten procesor. Wcześniej były implementacje semisprzętowe, ja pokazałem na USART, z kodowaniem 3 bitów na zapis.

@piotr_go - mógłbyś wstawić kluczowy fragment kodu jako syntax? Będzie wtedy to szybciej dostępne.

Ja bawiłem się w 4 bity na bit i timerami oraz przesuwaniem bitów.

Poza tym nie krytykujmy Panowie - przypomnijcie sobie ile razy jako początkujący cieszyliście się, że gdzieś znaleźliście rozwiązanie albo wskazówkę jak to zrobić.

vp32 wrote:

czym się różni Twój pomył od tego p z EP?

W wersji EP (SPI) bajt musi być podzielony ręcznie na bity i każdy bit wysłany jako 4 bity przez SPI.
0-ro jako 1000 (krótszy impuls)
1-ka jako 1100 (dłuższy impuls)
U mnie nic nie dzielisz, wysyłasz jak jest, generacją dłuższych i krótszych impulsów automatycznie zajmuje się timer + dma + io.

Kolejny dobry, przemyślany i pożyteczny pomysł Piotra.
Szkoda tylko, że niektórzy bez sprawdzenia maja pretensje .

Piotrze, czyżby trzeba było się przerzucić na inne procesory niż AVR i PIC ?

Freddy wrote:

czyżby trzeba było się przerzucić na inne procesory niż AVR i PIC ?

Przy cenie poniżej 2zł za tego ARMa to się ostatnio zastanawiałem czy go nie dać zamiast attiny10 w jednym z projektów.
Ja AVRów już nie kupuję od kilku lat. Jak mi się zapasy skończą i nie obniżą cen to będzie koniec moich projektów z ich wykorzystaniem.
No może poza tymi w sot23-6, bo ARMów takich jeszcze nie widziałem.

piotr_go wrote:

Ja AVRów już nie kupuję od kilku lat. Jak mi się zapasy skończą i nie obniżą cen to będzie koniec moich projektów z ich wykorzystaniem.

JA tak samo, i przerzuciłem się częściowo na PIC, bo mam ich sporo, łącznie z PIC32 i dsPIC, więc trzba wykorzystać .
AVR jeszcze mam jakieś 3-4 sztuki, więc trzeba wykorzystać.

Jak dla mnie to nadal nie jest do końca jasne jak działa ten układ po przeczytaniu opisu. Rozumiem na razie tyle, że bajty wysyła się po SPI i tyle Jak sygnały między tymi peryferiami są dokładnie połączone i jaki jest przepływ danych (skąd / dokąd)? Jak są skonfigurowane te peryferia?
Byłbym wdzięczny za wytłumaczenie

Witam!
Gratuluję autorowi ciekawego sposobu komunikacji z WS2812B! Ja jeszcze bawię się AVR-ami, a nawet Bascomem W układzie z filmiku



wykorzystałem ATTiny85. Bufor danych do wysłania oczywiście w pamięci RAM. 3 bajty na diodę (RGB). Każdy bajt bezpośrednio określa jasność świecenia danej struktury, bez żadnych konwersji. Efekty świetlne to bezpośrednie operacje na buforze napisane w BASCOM AVR. Ponieważ założyłem wyłącznie wykorzystanie wewnętrznego oscylatora RC, oraz biorąc po uwagę "szybkość" BASCOM'a- analizą danych w buforze i ich wysyłką do WS2812B zajmuje się podprogram- wstawka asemblerowa- wywoływany cyklicznie. Zalety układu: 1 scalak 8pin, wykorzystanie wewnętrznego generatora RC 8Mhz, transmisja NZR 800kHz (high speed), całość realizowana programowo. Wady: 3bajty RAMu/WS2812B, cena ATTiny85. Pod względem hardware'u chyba prościej się nie da;)

Pozdrawiam i życzę dalszych sukcesów!

radoslav006 wrote:

Jak dla mnie to nadal nie jest do końca jasne jak działa ten układ po przeczytaniu opisu. Rozumiem na razie tyle, że bajty wysyła się po SPI i tyle

Dalej sygnał zegara ze SPI odpala timer (input capture trigger, zajrzyj do PDFa) generujący impulsy i DMA kopiujące wartość z portu F do licznika timera. Dzięki temu timer przeskakuje cykl jeśli na linii MOSI jest 0.

W większości aplikacji sterowanie WS opiera się tylko i wyłącznie o sprzętowe implementacje np SPI, I2C nawet UART. Sam ponad rok temu robiłem sterowanie na CC3200 i nie wyobrażam sobie tego realizować programowo. Będę miał chwilę to wrzucę opisywaną taśmę led po Wi-Fi wrz ze sterowaniem po SPI.

Pomysł naprawdę odlotowy.
Spróbuję zaadoptować na AVR-XMEGA.

Przestrzegam przed układami WS2812 i podobnymi. Podany przez producenta w dokumentacji czas opisany jako "Reset Code" niby wynosi 50 µs. Jednak w praktyce okazuje się, że wystarczy już ok. 6-7 µs, by doszło do zresetowania taśmy. Testowałem to z już z kilkoma taśmami.

maciej_333 wrote:

czas opisany jako "Reset Code" niby wynosi 50 µs. Jednak w praktyce okazuje się, że wystarczy już ok. 6-7 µs, by doszło do zresetowania taśmy.

Cenna praktyczna uwaga.
Co prawda w dokumentacji ten czas jest podany jako "Above 50 µs" i dotyczy wymagań protokołu, czyli czasu jaki na 100% będzie interpretowany jako stan RES. Tak że nie bardzo jest się o co czepiać producenta. Ale faktycznie, brak w dokumentacji czasu minimalnego, który doświadczalnie określony podałeś.

maciej_333 wrote:

Przestrzegam przed układami WS2812 i podobnymi. Podany przez producenta w dokumentacji czas opisany jako "Reset Code" niby wynosi 50 µs. Jednak w praktyce okazuje się, że wystarczy już ok. 6-7 µs, by doszło do zresetowania taśmy. Testowałem to z już z kilkoma taśmami.

Tylko dlaczego przestroga?
Każdy producent podaje czas maksymalny, a często wystarczy dużo krócej.
Czy to jest wadą?

Piotrus_999 wrote:

A ja za to mam cotexa w obudowie DIP

Też do WS2812B
Szkoda tylko że LPC8xx tyle kosztują i są mało dostępne, bo Switch Matrix to świetny pomysł.
Zrobiłem na nim efekty do taśmy 300 led. Chcesz binarkę do wypróbowania?

Freddy wrote:

maciej_333 wrote:

Przestrzegam przed układami WS2812 i podobnymi. Podany przez producenta w dokumentacji czas opisany jako "Reset Code" niby wynosi 50 µs. Jednak w praktyce okazuje się, że wystarczy już ok. 6-7 µs, by doszło do zresetowania taśmy. Testowałem to z już z kilkoma taśmami.

Tylko dlaczego przestroga?
Każdy producent podaje czas maksymalny, a często wystarczy dużo krócej.
Czy to jest wadą?

Różnie ten czas podają w dokumentacji, ale zawsze wychodzi jako ok. 10 % czasu maksymalnego. Chyba nie jest to normalne. Jest to bardzo poważna wada w mojej ocenie. Dotyczy to oczywiście wolnych mikrokontrolerów np. EM78P153 na którym wykonywałem sterownik taśmy dla ponad 100 diod. Przy generowaniu danych dla diod "w locie", zgodnie z określonym algorytmem sterowania czas 6-7 µs jest bardzo mały. Sytuacja ta dotyczy nawet zegara 20 MHz w tym przypadku.

@maciej_333 Widzisz, bo noty trzeba umieć czytać. Ty interpretujesz parametry wybiórczo, abstrahując od innych, co jest błędem. Zauważ, że oprócz czasu resetu masz tam podaną min. szybkość transmisji (>400 kbps), oraz czasy dla Th i Tl, z których wynika, że pomiędzy bitami nie powinno byc przerw. Przerwę trzeba uwzględnić w czasie trwania bitu. A z tego jasno wynika, że jeśli pomiędzy bitami wrzucasz przerwy, to robisz to poza specyfikacją, nie dziw się więc, że czasami coś jest nie tak. Czasy trwania stanu niskiego masz podane jako 600 lub 800 ns +/- 150ns, czyli co się stanie jeśli stan L będzie trwał dłużej to tylko wróżka wie. Dla resetu masz podany gwarantowany minimalny czas po którym układ się zresetuje, a nie, że dla czasów poniżej 50us układ nie wejdzie w reset. Różnica subtelna, ale istotna.

W którym miejscu u Piotra jest wartość (zmienna, stała liczba) wskazująca ilość podłączonych diod?

vp32 wrote:

W którym miejscu u Piotra jest wartość (zmienna, stała liczba) wskazująca ilość podłączonych diod?

for(i=0; i<300; i++){

https://lpc8xx.wordpress.com/ - zmienić tylko na LPC824 i można przez DMA puszczać.

michalko12 wrote:

zmienić tylko na LPC824 i można przez DMA puszczać.

W STM32F030 też można użyć DMA do SPI (tylko już mi się nie chciało dodawać tego w zamieszczonym przykładzie ).

tmf wrote:

@maciej_333 Widzisz, bo noty trzeba umieć czytać. Ty interpretujesz parametry wybiórczo, abstrahując od innych, co jest błędem. Zauważ, że oprócz czasu resetu masz tam podaną min. szybkość transmisji (>400 kbps), oraz czasy dla Th i Tl, z których wynika, że pomiędzy bitami nie powinno byc przerw. Przerwę trzeba uwzględnić w czasie trwania bitu. A z tego jasno wynika, że jeśli pomiędzy bitami wrzucasz przerwy, to robisz to poza specyfikacją, nie dziw się więc, że czasami coś jest nie tak. Czasy trwania stanu niskiego masz podane jako 600 lub 800 ns +/- 150ns, czyli co się stanie jeśli stan L będzie trwał dłużej to tylko wróżka wie. Dla resetu masz podany gwarantowany minimalny czas po którym układ się zresetuje, a nie, że dla czasów poniżej 50us układ nie wejdzie w reset. Różnica subtelna, ale istotna.

Każde 24-bity dla kolorów R, G i B wysyłam zgodnie z dokumentacją. Zatem nie ma tam żadnych opóźnień. Jednak mając kilkanaście bajtów pamięci RAM muszę każde 24-bity obliczać "w locie". Właśnie tu powstaje opóźnienie.