Artykuły

My, elektronicy, najbardziej lubimy bajery. A w mikroelektronice, gdzie podstawę urządzeń stanowią mikrokontrolery, bajery nie kosztują nic poza dodatkową pracą nad programem. I coś takiego spróbujemy teraz wdrożyć do naszego nowo powstałego budzika. Nie wiem jak wy, ale ja nie lubię tych mrugających dwukropków. Byłoby ładniej, gdyby rozjarzały się jakoś płynnie. Dlatego – jak pisałem wcześniej, dwukropek podłączyłem do pinu wspierającego PWM, mającego możliwość wystawiania zmiennego przebiegu, dającego zmienną jasność diody. Zróbmy więc z tego pożytek.

Czas omówić dość już skomplikowany szkic, który gościł w poprzednim artykule, wstępnie tylko przedstawiony. A więc...

Czas zamienić zegar w budzik. Jak się można łatwo domyślić, potrzebne będą:

• Dodatkowy zestaw zmiennych, w których będzie siedzieć czas alarmu.

• Jakiś wskaźnik jego aktywności.

• Emiter pisków.

• Sposób regulacji takiego już bardziej rozbudowanego zegara.

Zacznijmy więc od rozmnożenia zmiennych oraz deklaracji portów dodatkowej diody świecącej i piszczka. Ten ostatni siedzi sobie na płytce edukacyjnej TME, więc go zaraz zatrudnimy. W tym momencie nadszedł czas na pewną refleksję. Podczas rozbudowywania aplikacji bywa, że nasze dobre pomysły stają się niedobre. Nie dlatego, że takimi były od początku, a z powodu takiego, że pewne rzeczy w nowym kontekście lepiej robić inaczej. Coś takiego przytrafiło się i tutaj, więc wykorzystam to na chwałę edukacji. Chodzi o traktowanie danych związanych przechowywaniem informacji o czasie.

Skoro mamy już działający na przerwaniach zegar, trzeba stworzyć jakąś wirtualną śrubkę do jego… może nie nakręcania, ale regulacji. Tak na marginesie, gdy młody człowiek słyszy „nakręcić zegarek”, myśli raczej o próbie wzbudzenia w zegarku jakiejś manii, co brzmi co najmniej dziwnie. Acz sformułowanie „nakręcić się na coś” weszło do codzienności, zaś nakręcanie zegarów z niej wyszło.

Przypomnę, że kontynuujemy temat rozpoczęty w poprzednim artykule. Na początek chciałbym rzec słówko o pewnej pułapce przerwań. Jak wiadomo, wpada się tutaj cyklicznie – u mnie co dwie i pół milisekundy. Należy bezwzględnie zadbać o to, by program siedzący wewnątrz wyrabiał się w czasie krótszym i to znacznie, bo po pierwsze – musi pozostać rezerwa na obsługę głównej pętli, po drugie – zegarek napędzany jest licznikiem wejść w przerwaniach, więc jeśli któreś zostaną pominięte, licznik będzie pracował wolniej i zegar będzie się spóźniał. Wykluczone są na przykład jakiekolwiek pętle opóźniające w obsłudze przerwań, a także rozbudowane warunki, których wykonywanie trwałoby zbyt długo, choćby wejścia w nie odbywały się regularnie.

Zegar (na razie bez budzika jeszcze), przedstawiony w poprzednim artykule, jako idea testowa jest w porządku, ale zegar z tego – choć działa – jest kiepski, o czym świadczy choćby obsługa klawiatury. To jest ten moment, gdy trzeba sobie powiedzieć: czas sięgnąć po przerwania. Zapewne zaraz dałoby się znaleźć jakąś bibliotekę multipleksującą, lecz ja tym razem chcę, co tylko możliwe uczynić na piechotę. Tak naprawdę zbuduję kopię widocznego powyżej zegara sprzed 30 lat, który pracował jeszcze na Z80, a potem – na 8051. Oba były napisane w asemblerze i dzisiejszy szkic będzie pracował nieco w duchu tamtych czasów, przede wszystkim bazując na prostych skokach, warunkach i liczbach ośmiobitowych. Z różnego rodzaju zegarami problem nie polega na złożoności oprogramowania, a raczej na stworzeniu użytecznego interfejsu. Każdy to wie, kto za każdym razem ustawiał godzinę budzenia, klikając w nieskończoność w jakieś niekontaktujące przyciski oprogramowane fatalnie i nieergonomicznie.

Zegary, budziki, stopery i wszelkie wariacje na ten temat, zawsze były ulubionym projektem młodych elektroników, bo wdzięcznym w uruchamianiu, umiarkowanie skomplikowanym i przede wszystkim użytecznym – zwłaszcza jeśli zapewnimy zegarkowi kilka funkcji niedostępnych w pokładowym czasomierzu smartfona czy sprzętowym odpowiedniku ze sklepu. Dlatego najbliższych artykułach będziemy się zajmować się takim urządzeniem, ale w kilku odmianach i z udziałem różnych elementów wykonawczych, za każdym razem dogłębnie analizując każdy krok naszych działań.

A jednak nie wszystko – choć w poprzednim artykule napisałem: to już wszystko. Płytka edukacyjna TME zawiera wyświetlacz, więc grzechem byłoby go nie wykorzystać. Postanowiłem poświęcić jeszcze chwilę i przerzucić część komunikatów na niego, ponieważ docelowo urządzenie będzie pracowało samodzielnie, a wizualizacja danych w postaci napisów zamiast światełek jest bardziej atrakcyjna. Światełka zresztą zostawimy.

„Zobacz przez kamerkę czy jest miejsce przed domem!” – a figa, nie ma połączenia. Klimy też nie włączymy zdalnie ani pieca, bo apka się nie łączy. Coś się popsuło i statystycznie najczęściej „coś” naprawia się za pomocą wyciągnięcia wtyczki z kontaktu, policzenia do dwudziestu i wsadzenia jej ponownie. Przynajmniej ja tak robię od 30 lat, na szczęście coraz rzadziej.

Nowe Arduino nie ma już nic wspólnego z ośmiobitowcem klasy Atari, którym było gdy powstawało. Sieć i moc (bo do sieci trzeba mocy) towarzyszy mu od jakiegoś czasu, a nowa wersja Uno ma na pokładzie dwa kontrolery – „arduinowy”, ale już trzydziestodwubitowy ARM Cortex M4 i wspierający go głównie sieciowo, jeszcze potężniejszy ESP32-S3. O nowym Arduino pisałem jakiś czas temu i dziś zajmiemy się siecią właśnie, zaledwie tytułem wstępu, ale – już w kolejnych artykułach – w tworząc jak najbardziej użyteczne, choć nadal proste urządzenie.