argbController (1)

Dokładnie w ten trend wpisuje się oświetlenie LED stosowane w komputerach PC, w przypadku którego funkcjonalność podporządkowana jest niejednokrotnie niebanalnej formie. Producenci urządzeń stosują do realizacji założonych celów projektowych nowoczesne elementy LED w postaci adresowalnych diod (obecnych na rynku od dobrych paru lat), dzięki czemu mogą uzyskać skomplikowane sceny świetlne. Trafny przykład stanowią tu wszelkiego rodzaju wentylatory przeznaczone do różnych podzespołów PC: jeszcze nie tak dawno służyły wyłącznie chłodzeniu – natomiast dzisiaj stanowią element co najmniej estetyczny, którego jednym (i nie mniej istotnym) z zadań jest generowanie sceny świetlnej. Ale nie tylko wentylatory wyposaża się w tego rodzaju funkcjonalność. Takie samo zjawisko stało się udziałem klawiatur, myszy, monitorów czy nawet obudów PC lub podkładek(!) pod mysz. I tutaj pojawia się problem. Mamy wiele urządzeń w jednym zestawie, z których każde może generować podświetlenie w sobie tylko znany sposób, przez co efekt finalny nie musi być zgodny z oczekiwaniami. Jak nad tym zapanować? Jak to wszystko zsynchronizować? Jak tym globalnie sterować? Miłośnikom nowoczesnego sprzętu przyszli z pomocą producenci płyt głównych, którzy zaczęli stosować zarówno specjalne złącza do sterowania oświetleniem LED, jak i niezbędne oprogramowanie. Początkowo były to złącza RGB, nieoferujące wprawdzie możliwości indywidualnego sterowania poszczególnymi peryferiami wyposażonymi w podświetlenie LED, lecz przynajmniej pozwalające na zastosowanie tego samego ustawienia dla wszystkich podzespołów zamontowanych w obudowie.

W końcu pojawił się „jakiś” standard cyfrowy (używam słowa „jakiś”, gdyż – po pierwsze – nie jest to standard otwarty, a po drugie – nie jest on wspierany globalnie przez wszystkich producentów z opisywanej branży). Mowa o podświetleniu LED standardu ARGB Gen2, którego złącza znajdziemy na płytach głównych takich producentów, jak ASUS, ASROCK, MSI czy GIGABYTE; co ciekawe: złącza różnego typu. Z lektury dostępnej w Internecie można wywnioskować, że największym promotorem wspomnianego standardu jest firma Cooler Master, produkująca systemy chłodzenia komputerów klasy PC oraz niezbędne sterowniki (w tym oświetlenia). Ale tą drogą poszły również inne firmy, więc uznajmy, że ARGB Gen2 stał się w świecie oświetlenia PC standardem – jednak, o czym wspomniałem na wstępie, standardem zamkniętym (i to zamkniętym na tyle skutecznie, że w Internecie znajdziecie niewiele informacji z tego zakresu). Jedną z bardziej użytecznych dokumentacji, na które możemy się natknąć, jest ta dotycząca adresowalnej diody LED typu SK6112-RG-002 produkcji dalekowschodniej firmy pod (nic niemówiącą Europejczykowi) nazwą DONGGUAN OPSCO OPTOELECTRONICS CO., LTD, dzięki której możemy zorientować się, z jakim rozwiązaniem mamy do czynienia. Na szczęście – jak zwykle bywa w podobnych sytuacjach – znalazł się pasjonat, który dzięki inżynierii wstecznej sterownika Coolermaster A1, jak i skąpej dokumentacji diody LED, opracował oraz opublikował na GitHubie (pod nickiem cpldcpu) szczegóły protokołu komunikacyjnego, zwalniając mnie z tej żmudnej pracy. Trzeba mieć jednak na uwadze, że wspomniane opracowanie nie musi być zgodne ze szczegółową dokumentacją producenta (i – na dobrą sprawę – prawdziwe), gdyż powstało jedynie na drodze eksperymentalnej. Tym niemniej jego autor (de facto bazujący na chińskich opracowaniach) sprawdził swoją pracę pod kątem użyteczności z elementami tego standardu, więc możemy przyjąć uzyskane przez niego wyniki jako bazę do dalszego działania. Warto zauważyć, że część spośród kluczowych mechanizmów obsługi komunikacji opisywała (na szczęście) dokumentacja diody SK6112-RG-002.

Zacznijmy od początku. Elementy LED standardu ARGB Gen2 są adresowalnymi diodami LED, zgodnymi z dobrze znanym standardem diod WS2812 i podobnych. Znaczy to ni mniej, ni więcej tyle, że sterowane protokołem diody WS2812 będą zachowywały się zgodnie ze swoim pierwowzorem. Jednak diody ARGB Gen2 udostępniają bardzo ciekawe rozszerzenia protokołu WS2812, dzięki czemu możemy nimi sterować w jeszcze bardziej elastyczny sposób. Wystarczy wspomnieć, że każdy element ARGB Gen2 możemy zarówno indywidualnie konfigurować, gdyż ma on specjalny rejestr modyfikujący pewne ustawienia sprzętowe – jak i odczytywać niektóre dane w nim zapisane (tak naprawdę w zasadzie tylko 2). Tak, tak, nie przesłyszeliście się, interfejs komunikacyjny diod ARGB Gen2 pozwala na dwukierunkową komunikację! Co więcej, protokół komunikacyjny tychże elementów LED wyposażono w możliwość pracy wielu łańcuchów diod LED połączonych w topologii gwiazdy, sterowanych – UWAGA – niezależnie, przez ten sam mikrokontroler.

Podstawowy tryb pracy to tryb zgodny ze standardem WS2812. W tym przypadku mamy do czynienia z asynchronicznym interfejsem komunikacyjnym, w którym nie ma wyprowadzenia sygnału zegarowego, w związku z czym dane przesyłane przy jego użyciu muszą być w pewien sposób zakodowane, by możliwe stało się ich proste zdekodowanie i by zyskały one odporność na zakłócenia czy artefakty. Zastosowano tutaj mechanizmy dobrze znane z interfejsów bezprzewodowej transmisji danych stosowanych w torach podczerwieni, gdzie stany logiczne „1” i „0” zakodowane zostały długością impulsu. Dodatkowo wprowadzono tak zwany sygnał RESET (również zakodowany długością impulsu), który powoduje zresetowanie interfejsów komunikacyjnych sterowników diod LED i ich oczekiwanie na nowe dane.

Co ważne, pojedyncze bity danych zgrupowane w bajty przesyłane są w kolejności od bitu najstarszego (MSB) do najmłodszego (LSB), a każda dioda LED w łańcuchu oczekuje na 3 bajty danych odpowiedzialnych za składowe jej koloru – przesyłane w kolejności G, R, B. Ale skąd każda z diod w łańcuchu „wie”, które z przesyłanych danych użytecznych przeznaczone są właśnie dla niej, a nie dla innej? Zrealizowano to w bardzo prosty, acz skuteczny sposób. Każda z diod LED w łańcuchu po włączeniu zasilania (jak również po odebraniu sygnału RESET) oczekuje na 3 bajty danych przeznaczonych wyłącznie dla niej. Do tego czasu jej wyjściowy interfejs komunikacyjny (wyjście DOUT) jest „nieprzezroczysty” dla nadchodzących danych (a ściślej rzecz biorąc, jest „przezroczysty” wyłącznie dla sygnału RESET oraz innych trybów pracy). Po odebraniu wspomnianych 3 bajtów danych dioda ta staje się „przezroczysta” dla kolejnych nadchodzących danych, co znaczy, że retransmituje do kolejnych diod w łańcuchu. Biorąc pod uwagę, że dokładnie tak samo zachowuje się każda dioda w łańcuchu, dość szybko zdamy sobie sprawę, że kolejne dane użyteczne przesyłane przez tak skonstruowany interfejs komunikacyjny trafiają kolejno do następujących po sobie (w sensie elektrycznym) diod w łańcuchu. Tyle w kwestii trybu zgodnego z WS2812. Żadnego novum, ale najciekawsze nadejdzie za chwilę. Zastanówmy się: skoro diody ARGB Gen2 są podstawowo zgodne z WS2812 i realizują ich protokół komunikacyjny, to w jaki sposób „wymusić” na nich przejście do innych trybów pracy? Ano w podobny sposób, w jaki zakodowane zostały stany logiczne, czyli długością impulsu, a w zasadzie sekwencją impulsów o predefiniowanej i odpowiednio dobranej długości – tak by nie zostały zidentyfikowane przez diodę (diody) jako bity informacji.