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. Graficzną prezentację dostępnych trybów pracy diod ARGB Gen2 pokazano na rysunku 1.

Rysunek 1. Graficzna prezentacja dostępnych trybów pracy diod ARGB Gen2

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. Na rysunku 2 pokazano przebiegi sygnałów interfejsu komunikacyjnego diody SK6112-RG-002 w trakcie transmisji bitu logicznej „1”, logicznego „0” i sygnału RESET.

Rysunek 2. Przebiegi sygnałów interfejsu komunikacyjnego diody SK6112-RG-002 w trakcie transmisji bitu logicznej „1”, logicznego „0” i sygnału RESET

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.

A zatem, by wejść w tryb konfiguracji diod ARGB Gen2, należy na magistralę danych przesłać sekwencję impulsów pokazaną na rysunku 3.

Rysunek 3. Sekwencja impulsów interfejsu komunikacyjnego diod ARGB Gen2 odpowiedzialna za wprowadzenie tych diod w tryb konfiguracji

Co ważne, powyższa sekwencja retransmitowana jest do kolejnych diod w łańcuchu (są dla niej niejako „przezroczyste”), przez co – po jej wysłaniu przez sterownik – wszystkie diody w tymże łańcuchu przechodzą w tryb konfiguracji. Następnie, po odczekaniu czasu sygnału RESET, sterownik powinien wysłać 3 bajty danych na każdą diodę LED, tak jak to miało miejsce w przypadku standardu WS2812, przy czym wspomniane 3 bajty danych nie zostaną przez każdą z nich zinterpretowane jako wartości RGB, tylko jako bajty konfiguracyjne. Ich znaczenie dla konfiguracji elementu LED, określone empirycznie, zebrano w tabeli 1.

Przejdźmy zatem do szczegółów. Pole pwmFreq odpowiada za częstotliwość sygnału PWM kontrolera diody ARGB Gen2 sterującego poszczególnymi strukturami LED RGB według poniższej specyfikacji: 0 → 1,178 kHz, 1 → 2,351 kHz, 2 → 9,431 kHz, 3 → 18,87 kHz. Ustawienie to wpływa na kompromis pomiędzy zjawiskiem migotania elementu LED a zakłóceniami EMI, jakie może generować.

Pole respType wpływa z kolei na rodzaj odpowiedzi, jaka jest wysyłana przez diodę ARGB Gen2 w trybie odczytu, o którym później. Jeśli ten bit ustawimy na wartość „1”, to dioda RGB Gen2 w trybie odczytu wyśle swój bit identyfikacyjny ID, przy czym wartość tego bitu zakodowana jest długością impulsu odpowiedzi według poniższej specyfikacji: impuls LO (10 μs) → bit „0”, impuls HI (40 μs) → bit „1”. Wartość bitu ID ustalana jest losowo na etapie produkcji, zaś jego obecność umożliwia fizyczną identyfikację łańcuchów LED w topologii gwiazdy. Z kolei, jeśli bit respType ustawimy na wartość „0”, to dioda ARGB Gen2 w trybie odczytu wyśle nam ustawienie sumarycznego prądu elementu LED, przy czym wartość tego prądu zakodowana jest, podobnie jak poprzednio, długością impulsu odpowiedzi według poniższej specyfikacji: impuls LO (10 μs) → 5 mA, impuls MID (20 μs) → 12 mA, impuls HI (40 μs) → 20 mA.

Pola fineG, fineR i fineB odpowiadają za dokładne dostrojenie prądu poszczególnych struktur R, G, B elementu LED (a więc także wzajemnych relacji pomiędzy nimi), dając możliwość korekty ustawień kolorów przezeń wyświetlanych. Maksymalne ustawienie, równe w tym przypadku 31, powoduje podwojenie prądu danej struktury LED.

Pola ovCurr odpowiadają za sumaryczny prąd diody ARGB Gen2. Ustawienie wszystkich pól ovCurr na wartość „1” powoduje zmniejszenie o połowę sumarycznego prądu tejże diody. Sprawia również, że w trybie odczytu ustawienia prądu takiej diody zmieniają się z wartości domyślnej MID (12 mA) na wartość LO (5 mA). Wszystkie inne kombinacje ustawień pól ovCurr nie przynoszą żadnego efektu, przy czym możliwe jest, że były to ustawienia charakterystyczne dla konkretnego elementu LED, gdyż trudno sensownie wytłumaczyć obecność 3 bitów konfiguracyjnych (a więc 8 możliwych ustawień) dla wprowadzenia 2 możliwych stanów pracy, niewyjaśniona pozostaje ponadto kwestia sposobu na przestawienie tego prądu na wartość HI (20 mA).

Kolejnym, ciekawym rozszerzeniem funkcjonalności diod WS2812 w przypadku standardu ARGB Gen2 jest tryb odczytu, który umożliwia odczyt dwóch ustawień każdego z elementów LED w łańcuchu. Jest to bit identyfikacyjny ID lub wartość prądu diody. Tak jak wspomniano wcześniej: fakt, którą z wartości dioda LED wystawiać będzie na port komunikacyjny (jak zawsze kodując ją długością impulsu), zależeć będzie od wcześniejszej konfiguracji. Niemniej jednak, aby wejść w tryb odczytu, podobnie jak to miało miejsce w trybie konfiguracji, musimy zainicjować go odpowiednią sekwencją impulsów sterujących – pokazaną na rysunku 4.

Rysunek 4. Sekwencja impulsów interfejsu komunikacyjnego diod ARGB Gen2 odpowiedzialna za wprowadzenie tych diod w tryb odczytu

Po wyemitowaniu powyższej sekwencji sygnałów sterownik powinien zwolnić magistralę danych, ustawiając swój port komunikacyjny w tryb wejścia (Hi-Z) i – po odczekaniu 5 μs – rozpocząć odczytywanie impulsów sterujących, które z kolei powinny być wysyłane przez kolejne diody LED w łańcuchu. Dokładnie w tym samym czasie, gdy sterownik zwalnia magistralę danych (czyli po ostatnim zboczu opadającym sekwencji sygnałów z rysunku 4), pierwsza dioda LED w szeregu wykonuje jednocześnie dwie czynności:

• retransmituje otrzymaną sekwencję impulsów sterujących odpowiedzialną za przejście do trybu odczytu na swoje wyjście (DOUT), przekazując ją tym samym kolejnej diodzie w łańcuchu, po czym, po upływie 5 μs, ustawia wspomniane wyjście (DOUT) w tryb wejścia (Hi-Z), by być gotową na retransmisję odpowiedzi kolejnej diody w łańcuchu na swoje wejście (DIN) ustawione w tryb wyjścia,
• po upływie 5 μs ustawia wejście własnego interfejsu komunikacyjnego (DIN) w tryb wyjścia, by po kolejnych 10 μs przesłać impuls dodatni, którego długość zależy od typu oczekiwanej odpowiedzi (o czym pisałem wcześniej, omawiając znaczenie pola respType).

Po przesłaniu impulsu – jak wyżej – i odczekaniu pewnego czasu (wynikającego z okresu retransmisji), pierwsza z diod w łańcuchu przesyła na swoje wejście (DIN, nadal znajdujące się w trybie wyjścia) impuls dodatni, będący odpowiedzią drugiej diody w łańcuchu. Jako że powyższy scenariusz powtarza każdorazowo każda z diod w łańcuchu, to na wejściu pierwszej z diod (DIN, ustawionym nadal jako wyjście) otrzymujemy szereg impulsów stanowiących odpowiedzi kolejnych diod w łańcuchu, przy czym czas pomiędzy kolejnymi odpowiedziami wynosi 80 μs. Po retransmisji wszystkich odpowiedzi i braku aktywności na magistrali danych (>100 μs) każda z diod wychodzi z trybu odczytu, przyjmując domyślne ustawienia kierunków swojego interfejsu komunikacyjnego (pinów DIN i DOUT). Łatwo zauważyć, że dzięki tak wymyślnemu mechanizmowi – oprócz możliwości odczytania interesujących nas wartości odpowiedzi każdej z diod LED w łańcuchu – dostajemy również możliwość określenia liczby diod znajdujących się na magistrali danych. A teraz wisienka na torcie: tryb pracy w topologii gwiazdy, nazywany również multi-layer.

W tym trybie możliwe jest podłączenie wielu łańcuchów diod ARGB Gen2 do jednego sterownika (w topologii gwiazdy), ich niezależna konfiguracja, adresowanie oraz odczyt. Zrealizowano to w bardzo ciekawy i nietuzinkowy sposób. W przypadku pracy wielu łańcuchów diod LED – podłączonych w tym samym punkcie do wyjść sterownika magistrali (np. mikrokontrolera) – każda z pierwszych diod w łańcuchu przejmuje rolę bramki (gate), decydującej o ważności danych przesyłanych do łańcucha, na którym się znajduje – lub z niego odczytywanych (wszak mamy przecież do dyspozycji także tryb odczytu).

Aby jednak możliwa stała się taka selektywna wymiana danych pomiędzy sterownikiem a wybranym łańcuchem LED, niezbędne są mechanizmy adresujące, a dotychczasowe tryby pracy takowych nie udostępniają. Jak więc rozwiązano ten problem? Wprowadzono dodatkowy tryb pracy, nazywany trybem rozkazów sterujących. Ale jak wejść w ten tryb? Podobnie jak to miało miejsce w trybie konfiguracji, musimy zainicjować go odpowiednią sekwencją impulsów sterujących, którą pokazano na rysunku 5.

Rysunek 5. Sekwencja impulsów interfejsu komunikacyjnego diod ARGB Gen2 odpowiedzialna za wprowadzenie tychże diod w tryb rozkazów sterujących

Co ważne i oczywiste, powyższa sekwencja sygnałów odbierana jest jednocześnie przez pierwsze diody w poszczególnych łańcuchach, przez co – po jej wysłaniu przez sterownik – każda ze wspomnianych diod przejmuje rolę bramki. Wynika z tego, że tym razem nie jest ona również dostępna dla pozostałych diod w danym łańcuchu – z wyjątkiem wspomnianej bramki. W dalszym kroku, po wyemitowaniu powyższej sekwencji, należy wysłać jeden bajt danych, stanowiący rozkaz sterujący (z opcjonalnym adresem umieszczonym na 4 najmłodszych bitach) – przy czym sposób jego transmisji jest identyczny, jak to miało miejsce w przypadku standardu WS2812. Dalej, w przypadku wybranych rozkazów sterujących, oczekiwana może być odpowiedź bramki, która polega na wygenerowaniu przez nią dodatniego impulsu (60 μs) na magistrali danych, w czasie od 10 μs do 60 μs, licząc od końca transmisji rozkazu. Takie działanie sprawia, że – podobnie jak to miało miejsce w trybie odczytu – po wyemitowaniu powyższej sekwencji sygnałów sterownik powinien zwolnić magistralę danych, ustawiając swój port komunikacyjny w tryb wejścia (Hi-Z). Następnie musi rozpocząć odczytywanie impulsu odpowiedzi, który z kolei powinien być wysyłany przez bramkę (pamiętajmy: tylko dla wybranych rozkazów). Listę dostępnych rozkazów wraz z opisem ich znaczenia dla protokołu ARGB Gen2 pokazano w tabeli 2.

Znamy już listę rozkazów, w związku z czym zastanówmy się, jak powinna wyglądać procedura inicjalizująca opisany system w celu jego dalszej obsługi. Jak łatwo się domyślić, należy rozpocząć od odszukania wszystkich łańcuchów LED i nadania im unikalnych adresów. Procedura taka powinna składać się z następujących kroków:

• wysłania rozkazu RESET_ADDRESS (0x20), by zresetować potencjalne, wcześniejsze przydzielenie adresów dla łańcuchów LED,
• wysłania rozkazu ASSIGN_ADDRESS (0x10) z adresem 0x01 w celu przydzielenia go pierwszemu, przypadkowo wybranemu łańcuchowi LED,
• odczytania odpowiedzi łańcucha LED (w zasadzie jego bramki) w celu potwierdzenia skutecznego przydzielenia adresu 0x01.

Operację powyższą powtarzamy dla wszystkich obecnych na magistrali łańcuchów LED połączonych w topologii gwiazdy, przez co – po jej wykonaniu – każdy z tychże łańcuchów (maksymalnie 15) otrzyma unikalny adres. Ale jak działa ten mechanizm z punktu widzenia każdego z łańcuchów LED? Otóż: każdy z nich (a w zasadzie jego bramka) po otrzymaniu takiego rozkazu odczekuje przypadkowy czas z zakresu pomiędzy 10 μs a 60 μs, testując nieustannie stan magistrali. Jeśli magistrala nadal pozostaje w stanie niskim, oznacza to, że żaden inny łańcuch nie przejął jeszcze tego adresu, w związku z czym bieżący łańcuch (a w zasadzie jego bramka) wysyła impuls odpowiedzi (stan wysoki o czasie trwania 60 μs), przyjmując wysłany adres jako swój. Taka procedura arbitrażu umożliwia bezkolizyjne przydzielenie adresu wszystkim łańcuchom LED na magistrali. Co oczywiste, żaden już zaadresowany łańcuch nie bierze udziału w tym mechanizmie, przez co możliwość potencjalnej kolizji znacznie się zmniejsza. Dodatkowo, jeśli mamy taką potrzebę, obecność zaadresowanego łańcucha LED na magistrali danych możemy sprawdzić poniższą sekwencją rozkazów:

• wysyłamy rozkaz PING_ADDRESS (0x30) z adresem 0x01 w celu sprawdzenia obecności łańcucha o adresie 0x01 na magistrali danych,
• odczytujemy impuls odpowiedzi potwierdzający wspomnianą obecność.

Ponadto możemy aktywować wybrany łańcuch LED rozkazem ACTIVATE_ADDRESS (0x40) z przykładowym adresem 0x01, a następnie przesłać do niego chociażby zestaw danych RGB w celu organoleptycznej weryfikacji udanego przydzielenia adresu. Co ważne, w jednym czasie aktywny może być wyłącznie jeden łańcuch LED, w związku z czym aktywacja kolejnego łańcucha LED dezaktywuje każdy inny, który był dotychczas aktywny. Jak widzicie, zastosowany mechanizm adresacji i następnej aktywacji wybranego łańcucha LED pozwala na selektywne oraz niezależne sterowanie każdym z nich, pracującym w topologii gwiazdy. Przyznacie, że jest to bardzo nowatorskie i ciekawe rozwiązanie, znacznie poszerzające funkcjonalność typowego interfejsu WS2812. Uważny Czytelnik dostrzeże prawdopodobnie pewną niedoskonałość takiego rozwiązania, a mianowicie brak możliwości fizycznej identyfikacji wybranego łańcucha LED bez organoleptycznej weryfikacji. Możemy wszak zaadresować je indywidualnie, lecz tak naprawdę nie jesteśmy w stanie stwierdzić z wyprzedzeniem, który z adresów zostanie przypisany konkretnemu (w sensie fizycznym) łańcuchowi. Na szczęście możemy się ratować jedną z możliwości interfejsu – a mianowicie możliwością odczytu pola ID każdej z diod w łańcuchu, które to pole konfigurowane jest wartością losową w procesie produkcji. Po przeprowadzeniu odczytu wszystkich pól ID diod LED danego łańcucha LED dysponujemy wtedy n-bitowym numerem ID tegoż łańcucha. Co prawda istnieje pewne prawdopodobieństwo, że dwa łańcuchy LED (zwłaszcza złożone z niewielkiej liczby diod) dysponować będą identycznym n-bitowym numerem ID, lecz wydaje się ono akceptowalne. Opisana powyżej procedura powinna składać się z następujących kroków:

• wysłania słowa konfiguracyjnego 0x002000 do wszystkich diod LED w wybranym łańcuchu LED (wcześniej aktywowanym rozkazem 0x40) – w celu konfiguracji rodzaju odpowiedzi wysyłanej przez diody z tegoż łańcucha (respType = 1),
• uruchomienia trybu odczytu i następującego po nim odczytania pól ID wszystkich diod LED łańcucha,
• połączenia otrzymanych wartości pól ID w celu określenia n-bitowego numeru ID.

W powyższy sposób możemy powiązać przydzielony (w procesie arbitrażu) logiczny adres łańcucha z jego adresem fizycznym, otrzymanym poprzez połączenie pól ID, ale i tutaj mamy pewien problem. Wynika on z faktu, że element LED w żaden sposób nie jest fizycznie identyfikowany (np. w postaci nadrukowanego opisu) przydzieloną na etapie produkcji wartością pola ID, przez co – w moim przekonaniu – identyfikacja, jak powyżej, niewiele zmienia. Tak czy inaczej, zarówno autor wspomnianego na początku opracowania, jak i ja na etapie prób nie znaleźliśmy innej, stuprocentowo pewnej drogi do fizycznej identyfikacji łańcuchów LED (a więc i urządzeń w nie wyposażonych). Zapewne wynika to z braków w dostępie do dokumentacji producenta lub, co też możliwe, nie było niezbędne w sensie wymagań protokołu. Na tym zakończę (mam nadzieję – interesujący) wywód dotyczący bardzo ciekawych komponentów, jakimi niewątpliwie są diody ARGB Gen2.

Za miesiąc przyjrzymy się szczegółom praktycznej implementacji opisanego powyżej protokołu na bazie bardzo prostego sterownika mikroprocesorowego. Co ważne, jako że diody ARGB Gen2 wymagają dość restrykcyjnych zależności czasowych (podobnie zresztą, jak diody WS2812), prezentowane w kolejnej części artykułu rozwiązanie zakłada dość wysoką częstotliwość taktowania mikrokontrolera, równą 20 MHz. Należy uwzględnić to ograniczenie przy przenoszeniu opisanych rozwiązań na inne platformy.

Robert Wołgajew, EP