- napięcie zasilania: 5 V (DC),
- maksymalny prąd obciążenia (bez podłączonych diod LED): 70 mA,
- zakres mierzonych temperatur: 0...125°C,
- rozdzielczość pomiaru temperatury: 1°C,
- dokładność pomiaru temperatury: ±0,5°C,
- zakres ustawień temperatur: 0...180°C,
- rozdzielczość ustawień temperatur: 10°C,
- zgodność ze standardami (nazw własnych użyto wyłącznie w celu identyfikacji produktu): Asus Aura Sync, Gigabyte RGB Fusion Ready, MSI Mystic Light Sync, ASRock Polychrome Sync.
Oprogramowanie mikrokontrolera
Plik nagłówkowy, definiuje główne ustawienia sprzętowe, a także wprowadza niezbędne typy danych – w tym configType, który upraszcza późniejszą konfigurację diod LED. Dalej, kod funkcji inicjalizacyjnej interfejsu komunikacyjnego, którego wyłącznym zadaniem jest ustawienie kierunku portu danych i jego stanu spoczynkowego (0).
Z kolei ciała funkcji odpowiedzialnych za przesłanie jednego bitu danych (0 lub 1), przy udziale wspomnianego wcześniej interfejsu komunikacyjnego. Warto zauważyć, że stosowne funkcje zdefiniowano, używając atrybutu __always_inline__, który instruuje kompilator, by ZAWSZE wstawiał w miejscu wywołania rozwinięcie funkcji, nie zaś skok do jej ciała. Jest to o tyle istotne, że operujemy na dość rygorystycznych timingach (rzędu setek nanosekund). W takiej sytuacji – przy częstotliwości taktowania mikrokontrolera równej 20 MHz (okres 50 ns) – jakiekolwiek niepotrzebne (z punktu widzenia programisty, nie kompilatora) wykonanie rozkazu asemblera może rozłożyć całą transmisję danych, całkowicie uniemożliwiając sterowanie wspomnianymi elementami.
Skoro mamy już funkcje umożliwiające przesłanie jednego bitu informacji, pora na funkcję (także odpowiednio zadeklarowaną), umożliwiającą przesłanie kompletnego bajtu danych za pomocą interfejsu ARGB Gen2. W dalszej kolejności, by uprościć zapis danych do adresowalnych diod LED RGB, przewidziano funkcję pozwalającą na przesłanie kompletnej informacji o kolorze tejże diody LED.
Na razie wszystko wydaje się proste, gdyż mamy do czynienia z funkcjami niczym nieróżniącymi się od specyfikacji dobrze znanych diod WS2812. To prawda – wspomniałem przecież na wstępie, że diody ARGB Gen2 są wstecznie zgodne ze specyfikacją elementów WS2812, dlatego mogą być obsługiwane przez sterowniki starego typu. Przejdźmy zatem do zagadnień nieco bardziej skomplikowanych. Ciało funkcji pozwalającej na policzenie elementów LED znajdujących się na magistrali i korzystającej z trybu odczytu protokołu ARGB Gen2. Dalej, widnieje z kolei ciało funkcji pozwalającej na konfigurację diod LED typu ARGB Gen2.
Co ważne, aby stosowną konfigurację przeprowadzić w sposób szybki i łatwy, najlepiej użyć zmiennej typu configType (będącej argumentem wywołania funkcji) i predefiniowanych w pliku nagłówkowym stałych. Należy również podkreślić, że prezentowana funkcja zakłada wysłanie takiej samej konfiguracji do wszystkich diod LED na magistrali, co zwykle okaże się najbardziej pożądane. Kluczowa funkcja interfejsu ARGB Gen2, stosowana w przypadku pracy magistrali danych w topologii gwiazdy – jej zadaniem jest wysłanie rozkazu sterującego (oraz opcjonalny odbiór odpowiedzi).
Przejdźmy teraz do założeń aplikacyjnych sterownika argbController. Przyznam szczerze, że pomysł (choć bardziej pasuje mi tu słowo „zapotrzebowanie”) na ten projekt podsunął mi mój kolega Andrzej. Używając różnego rodzaju podzespołów PC (w tym wyposażonych w podświetlenie ARGB Gen2), zauważył on brak systemu, który w zależności od wyników pomiaru temperatury sterowałby kolorem tego rodzaju podświetlenia. Istnieją co prawda systemy pozwalające zarządzać bogactwem różnych efektów RGB (np. Asus Aura Sync, Gigabyte RGB-Fusion Ready, MSI Mystic Light Sync czy ASRock Polychrome Sync), lecz nie oferują one tak pożądanej, a jednocześnie prostej funkcjonalności, jak zmiana koloru podświetlenia na skutek zmian temperatury elementu monitorowanego. Łatwo wyobrazić sobie zastosowanie takiego systemu do monitorowania stanu radiatora procesora PC lub temperatury wewnątrz obudowy typu desktop: w ramach pełnionej funkcji zmieniałby on (w sposób sugestywny) kolor podświetlenia wentylatora, dając bezpośrednią informację na temat kondycji urządzenia. To oczywiście tylko jedno z wielu możliwych zastosowań, gdyż nic nie każe nam ograniczać się do sprzętu z branży PC.
Sercem urządzenia jest mikrokontroler ATtiny804, taktowany wewnętrznym oscylatorem o częstotliwości równej 20 MHz i odpowiedzialny za realizację całej założonej funkcjonalności urządzenia.
Jako element pomiarowy (termometr) zastosowano scalony, cyfrowy i bardzo dobrze znany element typu DS18B20 produkcji Maxim Integrated, którego obsługę zrealizowano przy użyciu programowej implementacji magistrali 1-Wire. Wybór tego elementu z szerokiej palety dostępnych termometrów scalonych podyktowany był jego dużą dostępnością i niską ceną. Co więcej: w handlu znaleźć możemy gotowe moduły w formie wodoszczelnych sond pomiarowych, odpornych na warunki zewnętrzne, z zatopionym wewnątrz układem DS18B20, przez co wybór ten stał się jeszcze bardziej oczywisty. Ponadto mikrokontroler nasz obsługuje jednocyfrowy, 7-segmentowy wyświetlacz LED oraz dwa przyciski funkcyjne, oznaczone jako UP i DOWN, które stanowią elementarną wersję interfejsu użytkownika. W konstrukcji układu przewidziano również złącza goldpin przeznaczone do podłączenia wentylatorów (lub innych urządzeń), wyposażonych w interfejs ARGB Gen2 zasilany napięciem 5 V. Zastosowano 2 typy złączy w różnej konfiguracji sygnałów wyjściowych, typowych dla płyt głównych ASUS/ASROCK/MSI lub GIGABYTE. Do zasilania sterownika napięciem 5 V przewidziano z kolei typowe gniazdo MOLEX, stosowane w komputerach klasy PC, gdyż kable tego rodzaju – wyposażone we wtyki żeńskie – znajdują się w każdym komputerze typu desktop (i służą m.in. do zasilania napędów). Do obsługi przycisków funkcyjnych oraz programowej eliminacji drgania styków zastosowano przerwanie od przepełnienia timera TCB0 wbudowanego w strukturę mikrokontrolera, więc możliwa stała się również detekcja krótkiego i długiego naciśnięcia przycisków – bez blokowania programu obsługi aplikacji.