Diody ws2812b sterowane przez UART

[Elvis]

Jak łatwo było przewidzieć zabrałem się za WS2812B stanowczo zbyt późno - miało być piękne oświetlenie choinki, a są standardowe lampki, czyli jak zwykle. Właściwie to w tym roku jest nawet gorzej niż w  poprzednie Święta, bo wtedy zrobiłem sterowanie używając ESP32 i przez WiFi można było przesyłać dane do wyświetlenia. Niestety gdzieś mi się ten program zagubił, a nowego nie napisałem, więc żeby w przyszłym roku nie zaczynać przygody z WS2812 znowu od początku, dopiszę jeszcze trochę moich przemyśleń odnośnie tych diodek.

Na początek starałem się pokazać, że Arduino UNO w zupełności wystarcza do sterowania oświetleniem choinki - przynajmniej do czasu, aż będziemy chcieli bardziej rozbudować program i dodać do niego więcej funkcji niż tylko sterowanie ws2812b.

Teraz spróbuję użyć jednego z typowych modułów peryferyjnych, czyli UART-a do sterowania WS2812B. Przy okazji zmieniam mikrokontroler na stm32l476 - jest do tego kilka powodów. Po pierwsze znacznie lepiej znam stm32 niż atmegę, więc jak dla mnie jest łatwiej. Po drugie Arduino i atmega328p ma raptem 2KB pamięci RAM. To pewnie wystarczyłoby do sterowania lotem na księżyc, ale w dzisiejszych czasach programy są zasobożerne, a sama biblioteka Adafruit_Neopixel zużywa po 3 bajty na każdą diodę w łańcuchu - więc jak dodamy rozbudowane sterowanie i wymagania biblioteki, może zacząć brakować pamięci. Użycie UART-a też nie ułatwia oszczędzania pamięci, bo jeden bit jest reprezentowany za pomocą trzech, więc ilość danych rośnie, albo konieczne jest kolejne komplikowanie kodu. W każdym razie wybrałem STM32L476 bo mam go aktualnie "na tapecie", mikrokontroler posiada 128KB pamięci RAM, spory wybór peryferiów, DMA oraz możliwość inwersji wyjścia Tx z UART, co będzie za chwilę przydatne.

Jednak sterowanie, które opisuję można równie dobrze zastosować do innych mikrokontrolerów, nawet do Arduino.

O samym UART-cie nie będę za wiele pisał, był już omawiany przy okazji kursu STM32F1 (https://forbot.pl/blog/kurs-stm32-f1-hal-komunikacja-z-komputerem-uart-id22896) oraz STM32F4 (https://forbot.pl/blog/kurs-stm32-f4-7-komunikacja-przez-uart-id13472)

Na początek szybkie utworzenie projektu w STM32CubeIDE, konfiguracja zegara oraz UART1. Zaczynam od standardowych ustawień czyli prędkość 115200, 8 bitów danych itd.

Taka konfiguracja jest bardzo łatwa do przetestowania, można też upewnić się, że wszystkie niuanse odnośnie komunikacji przez uart działają tak jak myślimy. Ponieważ dane są przesyłane w kolejności od najniższego bitu, wyślę wartość 0x0f, czyli najpierw powinny być cztery bity o wartości "1", a następnie cztery "0".

Analizator poprawnie odczytuje przesłane dane, na diagramie widać bit startu, cztery bity "1", a następnie zera. Mniej to widać, ale na końcu jest bit stopu. Wszystko działa, jak powinno, ale do sterowania WS2812B potrzebny jest taki przebieg:

Czyli najpierw stan wysoki przez czas zależny od wartości bitu, a później stan niski. UART domyślnie działa zupełnie odwrotnie - start ma wartość "0", a stop "1".

Można sobie z tym poradzić sprzętowo dodając negację wysyłanego sygnału, ale w przypadku stm32l476 wystarczy zmienić ustawienia modułu:

Teraz wysyłane dane muszą być zanegowane, więc zamiast 0x0f wysyłam 0xf0. Efekt jest dużo bliższy oczekiwaniom ws2812:

Trzeba jeszcze poprawić czasy, można też trochę zoptymalizować sterowanie. Wysyłając wartość 0xf0 uzyskałem sygnał o odpowiednim kształcie, ale "marnuję" cały bajt na wysłanie jednego bitu.

Okazuje się, że w jednej ramce UART-a bez problemu zmieścimy aż trzy bity.

Ponieważ zanegowaliśmy wyjście bit startu jest automatycznie dodawany i ma wartości "1". Następnie transmitujemy (również zanegowany) bit danych, a na koniec bit zerowy. Na końcu ramki jest bit stopu, który podobnie jak start jest dodawany sprzętowo. To oznacza, że potrzebujemy wysłać raptem 7 bitów - używając UART najczęściej przesyłamy 8-bitowe dane, ale bez problemu można zmienić ustawienia na 7 bitów.

Zostaje jeszcze korekta czasu transmisji. Jak pamiętamy przesłanie całego bitu do ws2812b zajmuje 1,25 us, co odpowiada 800 b/s. Ponieważ UART musi wysyłać 3 bity na jeden odbierany przez ws2812b, więc i prędkość musimy zwiększyć trzykrotnie. Daje nam to wartość 2,4Mb/s, która często pojawia się w poradnikach internetowych.

Teraz już tylko zmiana ustawień CubeMX

Konfiguracja peryferiów jest już gotowa, teraz trzeba napisać program.

UART wysyła 7-bitowe dane, które i tak będziemy przechowywać jako 8-bitowe bajty. Ponieważ wysyłamy 3 bity na każdą ramkę UART, więc możliwych jest 8 wartości. Jako dane wejściowe przyjmujemy wartość 0-7, którą możemy zapisać binarnie jako b₂b₁b₀. Wynik to 8-bitowa liczba, ale najwyższy bit nie ma znaczenia (więc niech będzie zerem). Pamiętając o tym, że UART wysyła dane zaczynając od najniższego bitu możemy przygotować następującą tabelkę:

Teraz możemy napisać funkcję, która zakoduje nam dane w sposób oczekiwany przez UART. Jako wejście dostajemy 24-bity czyli jasność dla składowej czerwonej, zielonej i błękitnej. W wyniku otrzymamy 8 bajtów, bo tyle wymaga nasz sposób kodowania. Program może wyglądać następująco:

static const uint8_t ws_code[] = {
		  ~0x24, ~0x64, ~0x2c, ~0x6c,
		  ~0x25, ~0x65, ~0x2d, ~0x6d
};

void ws_encode(uint8_t r, uint8_t g, uint8_t b, uint8_t *buf)
{
	uint32_t value = (g << 16) | (r << 8) | b;

	for (int i = 0; i < 8; i++) {
		uint32_t tmp = (value >> 21) & 0x7;
		*buf++ = ws_code[tmp];
		value <<= 3;
	}
}

To już właściwie wszystko - resztę robi za nas biblioteka HAL. Jedno co musimy zrobić to zadeklarować bufor, w którym będziemy mieli po 8 bajtów na każdą diodę ws2812b:

#define PIXELS 	1*144

static uint8_t ws2812b_buf[PIXELS * 8];

Następnie wypełniamy bufor używając wcześniej napisanej funkcji ws_encode (oczywiście warto ją dostosować i zoptymalizować w zależności od potrzeb).

Na koniec musimy wysłać zawartość naszego bufora przez UART. Na początek możemy użyć:

	  HAL_UART_Transmit(&huart1, ws2812b_buf, sizeof(ws2812b_buf), HAL_MAX_DELAY);

Jednak ta metoda niewiele nam da w porównaniu z "machaniem pinami" używanym wcześniej. Okazuje się, że obsługa przerwań i tym razem może mieć wpływ na komunikację. W rzeczywistości ten kod działa, ale opóźnienia wywołane przerwaniami mogą zakłócić transmisję.

Aby tego uniknąć należy wyłączać przerwania, to jak wiemy nic dobrego. Inną możliwością jest wykorzystanie DMA do przesyłania danych. Ponieważ używamy standardowego modułu UART, wystarczy że użyjemy:

	  HAL_UART_Transmit_DMA(&huart1, ws2812b_buf, sizeof(ws2812b_buf));

Na zakończenie jeszcze uwaga odnośnie użycia pamięci - zaprezentowane podejście jest bardzo proste, ale też mocno "naiwne". Dla długich pasków zużywamy mnóstwo pamięci, a wcale nie jest to konieczne. Mając DMA można obsługiwać przerwanie po przesłaniu połowy danych i wypełniać wówczas bufor danymi. Dzięki temu zaoszczędzimy mnóstwo RAM-u.

Ale ta i inne optymalizacje to temat na kolejny wpis. Tym razem chciałem tylko zaprezentować jak łatwe jest użycie UART-a do sterowania WS2812B i jak można przygotować dane w formacie oczekiwanym przez ten moduł.

.

Edytowano Grudzień 25, 2019 przez Elvis

[Mobius]

Jak rozwiązać sprzętowo problem niezgodności poziomów napięć? Jak to zrobiłeś na ESP32?

Edytowano Grudzień 26, 2019 przez Mobius

[Elvis]

Postaram się dzisiaj o tym napisać. Wczoraj nie było już czasu na zajmowanie się napięciami - jednak ws2812b trzeba zajmować się przed Świetami

[Mobius]

WS ma wejście C-MOS. Poziom H to 0,7 zasilana co daje 3,5V. Układ zasilany z 3,3V nie ma szans poprawnie wysterować WS2812 zasilanego z 5V.

Edytowano Grudzień 26, 2019 przez Mobius

[ethanak]

Pierwsza leda zasilana z obniżonego napięcia (np. przez diodę prostowniczą). Dobre jak masz oddzielne ledy, a nie pasek :(

[Elvis]

Na to nie wpadłem, ale ciekawa opcja żeby użyć samego ws2812b

[Mobius]

2 godziny temu, ethanak napisał:

Pierwsza leda zasilana z obniżonego napięcia (np. przez diodę prostowniczą). Dobre jak masz oddzielne ledy, a nie pasek

Ale ta dioda będzie świeci słabiej i jest droższa od jednego rezystora podciągającego.

Edytowano Grudzień 26, 2019 przez Mobius

[Elvis]

O ile napięcie zasilania diody będzie wynosiło co najmniej 3,5V, nie będzie świeciła słabiej. Po drugie używanie rezystorów podciągających i wyjścia OD to jedno z najgorszych rozwiązań. Właściwie wszystko inne jest lepsze.

[Mobius]

11 minut temu, Elvis napisał:

O ile napięcie zasilania diody będzie wynosiło co najmniej 3,5V, nie będzie świeciła słabiej.

Będzie bo WS2812 nie mają źródeł prądowych. Zauważalne zmniejszenie jasności jest już przy 4,5V a przy 4,1 bardzo duże.

 

12 minut temu, Elvis napisał:

używanie rezystorów podciągających i wyjścia OD to jedno z najgorszych rozwiązań

Dlaczego?

W katalogu napisano, że LED ma być zasilany napięciem 5V +/1 10% a 3,5V to już odchyłka 30% więc 3 razy większa niż dopuszczalna.

 

[ethanak]

48 minut temu, Mobius napisał:

Będzie bo WS2812 nie mają źródeł prądowych. Zauważalne zmniejszenie jasności jest już przy 4,5V a przy 4,1 bardzo duże.

Ciekawe - w urządzeniu którym moja kochana małżonka posługuje się od dłuższego czasu nie widać różnicy...

 

 

[Elvis]

Specjalnie jeszcze raz przetestowałem - i u mnie też nie widać różnicy. Od 3,5V które deklaruje producent diody świecą z taką samą jasnością. Wcześniej wykonałem serię pomiarów i moim zdaniem od napięcia zależy prąd pobierany przez ws2812b kiedy są wyłączone, czyli im wyższe napięcie tym więcej prądu się marnuje. Natomiast różnica między "ciemnym" prądem, a pobieranym podczas świecenia jest niezależna od napięcia. Nie mam jak tego zmierzyć, ale moim zdaniem ta różnica to prąd faktycznie płynący przez diody świecące, więc ws2812b ma wyjścia prądowe, chociaż na wejściu pobiera prąd zależny od napięcia.

W tych pomiarach, kolumna PWM=0 określa prąd (w miliamperach) jaki płynie gdy diody są wyłączone. Przy PWM=64 wypełnienie wynosi 25%, ale ciekawa jest ostatnia kolumna, czyli różnica między tymi prądami. Jak widać jest ona (w granicach błędu pomiaru) stała.

Edytowano Grudzień 26, 2019 przez Elvis

[Mobius]

Te deklarowane 3,5V to Absolute Maximum Ratings a to nie to samo co zalecane napięcie pracy w przypadku WS2812 4,5 do 5,5V.

 

[ethanak]

Tyle, że przy zastosowaniu diody napięcie zasilania to 4.3V a nie 3.5V (czyli niewiele mniej niż "zalecane"[1] 4.5V), a wystarczy do przekroczenia progu 0.7 * Vdd z pinu układu zasilanego z 3.3V.

--

[1] w datasheecie znalazłem owszem owe maximum ratings, ale nie ma nic o 4.5.. 5.5V z wyjatkiem wzmianki o zasilaniu w trakcie pomiarów. Co ciekawsze, maximum Vdd określone jest na 5.3V...

Edytowano Grudzień 26, 2019 przez ethanak

[dambo]

Warto zaznaczyć, że te diodki są cały czas ulepszane przez producenta i aktualnie jest dostępny już model WS2812B-V5 i w nim jest "signal recognition range reduced to less than 2.8V - compatible with 3.3V ARM & 3.0V Bluetooth Chips" - link do stronki producenta: http://www.world-semi.com/solution/list-4-1.html#141

Dodatkowo już nie trzeba dawać kondensatorka przy nich - chyba aż takie parcie było ze strony klientów, że ten 0.1 centa czy mniej do zaoszczędzenia jest warty uwagi + wiadomo x części w montażu mniej itp - wyjaśnili to ładnie w pdfie ze stronki wyżej.

[BlackJack]

dambo warto też zauważyć że WS2812x to, już przestarzałe diody zastępowane powoli przez Ws2813 i 2815, które są pozbawione kilku wad poprzedniczek.