Artykuły

W poprzednim artykule opisałem zagadnienie zegarów RTC i przedstawiłem przykład: układ DS1302. Czas na nieco nowocześniejszy DS1307. Tutaj mamy już klasyczną magistralę I²C, więc potrzeba tylko dwóch linii do rozmów ze scalakiem. Pominę nieistotne dla nas dodatkowe wyjście, na którym może się pojawić jedna z częstotliwości do wyboru: 1 Hz, 4 lub 8 kHz albo częstotliwość kwarcu. Układ posiada 56 bajtów użytkownika, ale wymaga już pięciowoltowego standardu zasilania. Posiada też stały adres magistrali (dziesiętnie: 104), którego nie da się zmienić.

Czas najwyższy zająć się tak zwanymi zegarami RTC. O czym mowa? Do tej pory źródłem czasu w moich przykładach było samo Arduino i źródło to miało dwie wady: nie było zbyt dokładne i jak brakło prądu, to ustawienia zegara przepadały. Profesjonalnie robi się to inaczej.

RTC czyli Real Time Clock to układ scalony zaprojektowany tylko do jednego celu: bycia dokładnym zegarkiem, z własnym zasilaniem, zegarkiem tak oszczędnym, by wymiana baterii była konieczna jak najrzadziej. W praktyce baterie wystarczają na kilka lat i bardziej rozładowują się same z siebie niż z powodu podłączenia do obwodów zegara.

Nawiązując do serii artykułów o Arduino i sieci, nie pisałem o tym nic, bo sama funkcja wprost jest mało przydatna. Za to już nie wprost – znacznie bardziej. O czym mowa? Tajemnica siedzi w tej linii:

Od ukazania się serii artykułów o Arduino i pingach minęło nieco czasu. Jeden z czytelników słusznie zwrócił uwagę na to, że sytuacją awaryjną może być także zwiększenie opóźnień pingów ponad ustaloną wartość. I słusznie, bowiem sam miewam z tym problemy od czasu do czasu i pomaga wówczas rozłączenie się routera z linią – u mnie przynajmniej na 20 sekund. Uzupełnijmy więc nasz projekt o moduł wykrywania takich opóźnień.

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.