Wskazówkowy zegar diodowy

[TPReal]

Zrobiłem ostatnio mały projekt z Raspberry Pi i diodami RGB.

Sprzęt

Dwa pierścienie po 24 diody (ten i ten) nakleiłem na okrągły kawałek kartonu, na środek dałem pojedynczą diodę (tę) a po przeciwnej stronie przykleiłem Raspberry Pi Zero WH (akurat miałem wersję z wlutowanymi złączami, co w tej sytuacji tylko utrudniało). Znalazłem informację, że piny +5V w Pi są połączone bezpośrednio do zasilania, więc można z nich bezpiecznie ciągnąć duży prąd, więc zasiliłem z nich diody, a jednego pinu użyłem do ich sterowania (diody WS2811 łączy się szeregowo i steruje dowolną ich ilością z pojedynczego pinu protokołem podobnym do 1-wire). Teoretycznie pin sterujący powinien pracować z napięciem 5V, a nie 3.3V, ale w praktyce nie zauważyłem żadnych problemów z tym związanych.

Zegar miał z założenia wisieć w sypialni i być użyteczny również do sprawdzania czasu w nocy, więc potrzebowałem elementu światłoczułego żeby dostosowywać jasność diod. I to nie jednobitowego (ciemno/jasno), tylko "analogowego". Akurat nie miałem odpowiedniego modułu, więc użyłem konstrukcji z kondensatorem i rezystorami, jak na schemacie (na zdjęciu fotorezystor jest po lewej stronie, przy kablu). Logika sprawdzania poziomu światła jest następująca:

• Ustawiam pin na output, stan niski.
• Zajmuję się innymi rzeczami, na przykład sterowaniem diodami, w tym czasie kondensator się rozładowuje (nie całkiem do zera, bo rezystory działają jako dzielnik napięcia).
• W chwili t0 ustawiam pin na input (bez pull up/down).
• W pętli odczytuję jego stan. Najpierw stan jest niski, ale po chwili gdy kondensator się naładuje do około 1.5V na pinie pojawia się stan wysoki, wtedy przerywam pętlę.
• Sprawdzam ile czasu minęło od t0.

Czasy, które otrzymuję, wahają się od około 40μs gdy jest bardzo jasno do nawet ponad 100ms w zupełnej ciemności (nie czekam dłużej niż te 100ms, stwierdzam po prostu, że jest zupełnie ciemno). Nie wątpię, że ten układ mógłby być zrobiony lepiej, bardziej liniowo, z mniejszą liczbą elementów (na przykład pewnie dałoby się wykorzystać rezystory pull up i pull down z Pi), ale ten działa dobrze i skutecznie.

Jak mówiłem, wymóg był taki, że ma się to nadawać do ciemnego pokoju, więc w zupełnej ciemności ma świecić bardzo słabo, tak żeby nie razić i nie rozświetlać pokoju. Okazało się, że nawet na minimalnej jasności te diody są znacznie za jasne, więc przykryłem je dwiema warstwami papieru z bloku technicznego i jeszcze kawałkiem materiału, i dopiero wtedy jasność jest mniej więcej taka, jak potrzeba, chociaż szczerze mówiąc rozważam dodanie trzeciej warstwy papieru.

Niestety trudno zrobić ładne zdjęcie tych diod, zawsze wyglądają inaczej niż w rzeczywistości, na przykład mają jakby mocniejsze halo naokoło siebie i wydają się prześwietlone. Na zdjęciach jest godzina około 6:26, na tym dziennym akurat sekundnik zasłonił wskazówkę minutową. W trybie nocnym sekundnik jest wyłączony, podobnie jak niebieskie "kreski" naokoło tarczy.

A następnie zdarzył się cud, po prostu trudno w to uwierzyć, ale kupowałem coś na allegro i przeglądając inne przedmioty sprzedającego trafiłem na tarczę ze starego zegara w kształcie pierścienia o dokładnie odpowiedniej średnicy wewnętrznej, z dokładnością do jakichś 2mm. Powiem szczerze, teraz bez tej tarczy zegar wygląda mi dość łyso i nieciekawie. Po prostu przeznaczenie

Oprogramowanie

Program napisany jest w języku Rust. To był mój pierwszy program w tym języku, wybrałem go bo mnie zaciekawił i chciałem się go nauczyć, oraz ponieważ Ruby, w którym robiłem poprzednie projekty na Pi, okazał się trochę za wolny na sterowanie diod RGB - objaśnienie poniżej. (Tak w ogóle - polecam Rusta, bardzo przyjemny, chociaż ma pewien próg wejścia. Utwierdził mnie tym bardziej w moim i tak już silnym postanowieniu nie tykać więcej C++ jeśli tylko nie trzeba.)

Do wysterowania diod trzeba nadać na pinie sterującym sekwencję 24 bitów RGB dla każdej diody po kolei, protokołem przypominającym 1-wire. Polega to na tym, że nadanie każdego bitu trwa 1.25μs i polega na ustawieniu pinu w stan wysoki, a następnie w stan niski, przy czym jeśli nadaję bit 0 to stan wysoki ma trwać około 300ns, a jeśli bit 1, to ma trwać około 700ns. Dioda działa tak, że pierwsze 24 bity odczytuje i zapamiętuje dla siebie, a wszystkie dalsze sygnały wysyła do kolejnych diod, więc naprawdę można w ten sposób wysterować dowolnie wiele diod z jednego pinu, tyle że wysłanie pełnego stanu będzie trwało dłużej gdy diod jest więcej. Wreszcie stan niski przez 50μs oznacza, że sekwencja się zakończyła. Szczerze mówiąc jestem pod wielkim wrażeniem prostoty tego protokołu.

Tak szybka zmiana stanów pinu mogłaby być trudna nawet w Ruście, ale znalazłem gdzieś w internecie opis innego podejścia, i je zastosowałem. Ustawiam PWM (wbudowany w BCM2835) w tryb serializera, w którym przez pin wysyłane są konkretne podane przeze mnie bity. Ustawiam częstotliwość na trzy razy wyższą, a więc 2.4MHz (=1/1.25μs*3), i żeby wysłać bit 0, wysyłam sekwencję trzech bitów 100, a żeby wysłać bit 1, wysyłam sekwencję 110. Dane do serializera w BCM2835 ładuje się przez FIFO o pojemności chyba 16 słów po 4 bajty, więc najpierw przygotowuję całą sekwencję do wysłania, już przerobioną na ten 1-wire, a potem w pętli czekam aż FIFO jest not full i wpisuję kolejne słowo. I właśnie tego nie dawało się zrobić w Rubym - był za wolny, i pomiędzy nadanymi słowami pojawiały się przerwy, a przerwa 50μs powoduje przerwanie sekwencji. Mógłbym być może pocisnąć tę drogę dalej, nie używać biblioteki, którą miałem, tylko bardziej bezpośredniego dostępu do rejestrów BCM2835, ale zamiast tego uznałem to za pretekst do nauczenia się Rusta, i dobrze wyszło.

Sama logika ustalania pozycji wskazówek jest dość prosta. Wskazówki przesuwają się płynnie, to znaczy sekundnik tak jakby pełznie, stopniowo rozświetlając kolejną diodę i wygaszając ostatnią, pozostałe wskazówki, gdy mają się przesunąć, również wykonują stopniową tranzycję Oczywiście zegar nie pokazuje dokładnej minuty, okręgi mają po 24 diody, więc każda pozycja długiej wskazówki odpowiada okresowi 2.5 minut, co zazwyczaj zupełnie wystarcza. Stan diod obliczam i wysyłam w pętli, czekając 50ms pomiędzy powtórzeniami, więc ruch jest płynny. Oczywiście nie wtedy, gdy jest ciemno, i diody świecą z minimalną jasnością - wtedy przejścia siłą rzeczy są skokowe.

Ze światłomierzem z telefonu naszkicowałem zależność ilości światła od wartości wpisanej na diodę (nawet w miarę liniowy), potem przyjąłem, że percepcja jasności jest mniej więcej wykładnicza, potem wykonałem jeszcze dużo różnych operacji na wartości odczytanej z tego mojego układu pomiaru światła (bardzo nieliniowego), z pewną ilością magicznych stałych, i o dziwo uzyskałem dość dobry rezultat. Zegar wydaje się zwykle świecić w sam raz tak jak trzeba.

Problemy z wywłaszczaniem

Od początku miałem następujący problem: co któryś wysłany stan diod wyświetlał się błędnie. Wyglądało to jakby występowały zakłócenia obrazu, jakby na przykład był obrócony w inną stronę, albo kolory były w ogóle nie takie, jak trzeba. Takie zakłócenia pojawiały się nawet kilka razy na minutę, i zaraz następna wysłana klatka je korygowała, ale wyglądało to źle i drażniąco. Z użyciem mojej pokazywaczki Hantek ustaliłem, że taka uszkodzona sekwencja dla diod ma po prostu gdzieś w środku przerwę, trwającą na przykład 120μs. To powoduje, że reszta sekwencji jest traktowana jako nowa sekwencja, więc wyświetla się nie na tych diodach, na których powinna. Po dalszych badaniach doszedłem do wniosku, że czasami nawet w Ruście pętla ładująca dane do FIFO okazuje się za wolna.

Pierwsze co zrobiłem, to zmieniłem logikę tej konwersji na 1-wire tak, żeby granica pomiędzy nadawanymi słowami była jednocześnie granicą pomiędzy logicznymi nadawanymi bajtami. Innymi słowy, każdy bajt kodowany jest w postaci 24 bitów złożonych z trójek 100 lub 110, a pozostałe 8 bitów słowa wypełniam zerami (protokół nie ma z tym problemu, pewnie mógłbym też kodować każdy bit na 4 bitach). Dzięki temu jeśli nawet zdarzy się uszkodzona ramka, to uszkodzenie może polegać na tym, że zapalą się inne diody i na inne kolory, ale z tą samą siłą, z którą miały się oryginalnie palić. Dzięki temu uszkodzone ramki są znacznie mniej drażniące. Wcześniej słowo daję, że przynajmniej z 5 razy pomyślałem że coś mi iskrzy, gdy nagle któraś dioda w uszkodzonej ramce zaświeciła bardzo jasno.

No ale to nie jest prawdziwe rozwiązanie. Domyśliłem się, że przyczyną problemu są po prostu wywłaszczenia. Raspberry Pi OS nie jest systemem czasu rzeczywistego i nie mam żadnej gwarancji, że mój program będzie miał spokój w czasie wysyłania sekwencji. To, co zastosowałem poza tym, to uruchomienie mojego programu tak:

chrt --fifo 99 clock

To zmienia jakieś scheduling policy i teoretycznie powinno zapobiegać wywłaszczaniu. O ile widzę w /proc to wywłaszczeń faktycznie jest dużo mniej, ale nie zero, natomiast zegar działa praktycznie dobrze. Uszkodzone ramki zdarzają się bardzo rzadko, myślę że raz na godzinę lub rzadziej. Wolałbym gdyby tak nie było, ale mogę to zaakceptować.

Innym możliwym rozwiązaniem byłoby sprawdzanie czy "gap occurred", bo teoretycznie PWM wystawia taką informację, ale w praktyce chyba coś tam nie działa dobrze, bo zwykle ten bit nie jest ustawiony, nawet gdy widzę na oscyloskopie że przecież occurred. Jeszcze inne to przydzielenie dedykowanego rdzenia procesora do tego procesu, tyle że Pi Zero ma tylko jeden rdzeń... Można by też oczywiście dodać mikroprocesor, wysyłać do niego dane po SPI, a on sterowalny diodami, ale tego jakoś nie chciało mi się zrobić.

Jeżeli ktoś z czytelników ma jakiś inny pomysł na poprawienie tego, to chętnie posłucham

Możliwy dalszy rozwój

Zegar mógłby oczywiście wyświetlać jeszcze jakieś inne obracające się tęcze, animacje, buźki i wodotryski. Mam trochę poczucia, że on nie wykorzystuje w pełni potencjału diod RGB. Tylko że póki co nie mam jasnej idei co konkretnie chciałbym tam wyświetlić i kiedy, więc to pozostaje póki co w sferze luźnych planów.

Edytowano Listopad 1, 2020 przez TPReal

[Treker (Damian Szymański)]

@TPReal dzięki za opis kolejnego ciekawie projektu - już zatwierdzony, więc jest od teraz widoczny publicznie

[KHX]

Projekt fajny, swoją drogą super, że używasz mniej popularnych języków, w rpi ruby, tutaj rust, ciekawy pomysł :D

 

[TPReal]

@KHX Bo Ruby to jest w ogóle świetny język  chociaż jak widać nie równie świetny do wszystkiego. A Rust chyba powoli przestaje być "mniej popularny".

Taką mam obserwację: program w Ruście wykonuje się oczywiście dużo szybciej, ale za to kompiluje się masę czasu, i w rezultacie iteracje polegające na małej zmianie w kodzie i uruchomieniu robi się duużo szybciej w Rubym. Potem trochę to poprawiłem bo ogarnąłem cross-kompilację i kompiluję dla Pi Zero na innym urządzeniu, ale nadal iteracje programu w Rubym są znacznie szybsze.