codeLock - efektowny zamek kodowy

Postanowiłem zbudować prosty zamek kodowy, do którego kod użytkownika wprowadzać będziemy za pomocą elektronicznego pokrętła wydającego dźwięk „tykania”, charakterystyczny dla pokręteł kodowych wielkich sejfów bankowych, znanych chociażby z filmowych produkcji. Ponadto założyłem, że wyświetlane przez zamek kodowy cyfry przesuwać się będą w rytm obracania wspomnianego pokrętła, tak jakbyśmy używali cylindrycznego bębna z nadrukowanymi nań znakami (coś w rodzaju starych liczników w magnetofonach z lat 80.). Jak łatwo się domyślić, w roli wspomnianego wcześniej pokrętła zastosowałem prosty enkoder inkrementalny, zaś funkcję wyświetlacza, za pomocą którego udało się osiągnąć efekt animacji zmiany cyfr, pełni prosta matryca diod LED o organizacji 5×7 punktów. I właśnie na bazie powyższych założeń powstał projekt urządzenia codeLock, którego schemat pokazano na rysunku 1.

Rysunek 1. Schemat ideowy urządzenia codeLock

Jak widać, zaprojektowany system mikroprocesorowy jest bardzo prosty, a jego serce stanowi niewielki, ale bardzo nowoczesny mikrokontroler ATtiny1604 firmy Microchip (dawniej Atmel), taktowany wewnętrznym oscylatorem RC o częstotliwości 10 MHz i realizujący całą założoną funkcjonalność urządzenia. Mikrokontroler nasz steruje pracą szeregowego rejestru przesuwnego 74HC4094 (wyprowadzenia PA3/SCK→Clock, PA0/MOSI→Data), dzięki któremu realizuje obsługę matrycowego wyświetlacza LED w konfiguracji wspólnej anody (wyprowadzenia PA7…PA4, PA2 mikrokontrolera), obsługuje enkoder inkrementalny z wbudowanym przyciskiem (dzięki zastosowaniu przerwania od zmiany stanu pinów portu PORTB mikrokontrolera - w naszym przypadku pinu PB1), steruje pracą przekaźnika LOAD (poprzez prosty klucz tranzystorowy NPN) oraz odpowiedzialny jest za generowanie dźwięku poprzez wbudowany głośniczek SMD, co realizuje za pomocą wbudowanych w swoją strukturę układów czasowo-licznikowych: TCA0 (pracującego w trybie PWM) oraz TCB0 (pracującego w trybie Periodic Interrupt). Wybór mikrokontrolera ATtiny1604 oraz podłączonego do jego wyprowadzeń rejestru szeregowego 74HC4094 mógłby się wydawać dość wątpliwy, jeśli wziąć pod uwagę, że bez problemu dałoby się tu wybrać mikrokontroler o odpowiedniej liczbie portów wyjściowych, zamiast stosować procesor i rejestr przesuwny. To tylko pozory! Po pierwsze, nie chciałem stosować mikrokontrolera o większej liczbie (niepotrzebnych) wyprowadzeń, a co za tym idzie - o niewygodnej do lutowania dla amatora obudowie (TQFP32). Jeszcze istotniejszy jest jednak fakt, że zastosowanie rejestru przesuwnego 74HC4094 zdecydowanie upraszczało projekt obwodu drukowanego (tak, tak!); nie wspominając już o cenie układu tego rodzaju, wynoszącej około 1 zł. Co warto również zaznaczyć, do sterowania rejestru przesuwnego używany jest wbudowany w strukturę mikrokontrolera interfejs SPI, przez co jego obsługa stała się niezmiernie prosta i szybka (zegar SPISCK=5 MHz).

Wspomniane wcześniej wspólne anody wyświetlacza LED sterowane są poprzez proste klucze tranzystorowe T1…T5 (ze zintegrowanymi w ich strukturze rezystorami: bazowym i podciągającym), z uwagi na dość duże prądy o wartościach rzędu 35 mA (7×5 mA). Z kolei wspólne katody naszych elementów LED obsługiwane są przez wyprowadzenia rejestru przesuwnego i, jak już można się domyślić, do ich obsługi (i obsługi wspólnych anod) zastosowany został doskonale znany mechanizm multipleksowania. Jest to standardowe rozwiązanie problemu tego typu, a polega na sekwencyjnym sterowaniu kolejnych kolumn wyświetlacza LED, w którym przeprowadzane są kolejne i następujące po sobie poniższe operacje:

• wyłączamy wszystkie wspólne anody (a tym samym wszystkie elementy LED),
• na port wspólnych katod wystawiamy (poprzez rejestr przesuwny) „wzór” do wyświetlenia (aktywny stan „0”),
• załączamy wybraną wspólną anodę (aktywny stan „0”), wyświetlając tym samym wcześniejszy „wzór” na wybranej kolumnie diod LED,
• powtarzamy powyższy proces dla kolejnych wspólnych anod.

Opisany proces, wykonywany dostatecznie szybko (w naszym wypadku 60 razy na sekundę dla każdej wspólnej anody), pozwala na obsłużenie 35 elementów LED (diod reprezentujących wyświetlaną treść), przy udziale wyłącznie 7 wyprowadzeń mikrokontrolera. Prawda, że proste? A jakie efektywne! Już teraz uprzedzę Czytelników, że użyty w tym celu zostanie układ czasowo-licznikowy RTC wbudowany w strukturę mikrokontrolera, który pracował będzie w trybie Periodic Interrupt i wywoływał stosowne przerwanie systemowe (od przepełnienia) 300 razy na sekundę (czyli 60 razy dla każdej wspólnej anody), obsługując właściwy mechanizm multipleksowania. Ale wróćmy do schematu ideowego naszego urządzenia, gdyż kilka niezbędnych słów komentarza wymaga blok generujący dźwięk. Jak działa ten mechanizm? Jak już wspomniałem wcześniej, do generowania dźwięku zaprzęgnięto dwa układy czasowo licznikowe: TCA0 pracujący w trybie PWM oraz TCB0 pracujący w trybie Periodic Interrupt. Timer TCA0 generuje na wyprowadzeniu PB2 (WO2) mikrokontrolera 8-bitowy przebieg PWM, którego wypełnienie zależne jest od wartości jego rejestru porównania CMP2.

Przebieg ten przechodzi następnie przez prosty filtr dolnoprzepustowy R4/C6 o częstotliwości odcięcia około 4 kHz, na którego wyjściu otrzymujemy sygnał DC proporcjonalny do wypełnienia zasilającego filtr przebiegu PWM. W ten prosty sposób realizujemy książkowy przykład najprostszego przetwornika DAC. Nie ma on, co prawda, zbyt wyszukanych parametrów, gdyż nie mamy możliwości większego odstrojenia się pasmem częstotliwości przebiegu PWM od pasma użytecznego sygnału (bez utraty jego rozdzielczości), ale do naszych zastosowań w zupełności wystarczy. Tak przetworzony sygnał PWM wchodzi na wejście prostej końcówki mocy, zbudowanej na bazie popularnego układu wzmacniacza audio małej mocy (pod postacią TDA2822D produkcji firmy STMicroelectronics w jego typowej aplikacji), przy czym, co łatwo zauważyć, użyty został jedynie jeden ze wzmacniaczy wbudowanych w strukturę tego stereofonicznego układu, gdyż nie zależy nam na zwiększaniu mocy sygnału audio (np. z zastosowaniem układu mostkowego wzmacniaczy). Sygnał wyjściowy układu TDA2822D trafia, po odcięciu składowej stałej (kondensator C9), na miniaturowy głośniczek SMD. Ale jak generowany jest sam dźwięk? Za ten etap odpowiada drugi układ czasowo-licznikowy, mianowicie TCB0. Układ ten, pracujący w trybie Periodic Interrupt, wywołuje stosowne przerwanie sprzętowe (8000 razy na sekundę), które ładuje z pamięci flash mikrokontrolera kolejne wartości spróbkowanego wcześniej sygnału dźwiękowego do rejestru porównania licznika TCA0 (CMP2BUF), powodując stosowne zmiany napięcia na wyjściu filtra R4/C6. Wspominane powyżej próbki dźwiękowe zostały wcześniej zdigitalizowane (a następnie zapisane w pamięci Flash) z częstotliwością próbkowania 8 kHz i rozdzielczością 8-bitów, co zapewne wyjaśni Czytelnikom konfigurację obu timerów.

Tyle kwestii funkcjonalnych - przejdźmy zatem do zagadnień implementacyjnych. Mam świadomość, że nie jest to rocket science ani rozwiązanie na wskroś uniwersalne, ale chciałem pokazać Czytelnikom, jak w efektywny i efektowny sposób ogarnąć tego rodzaju zagadnienie programistyczne, czyniąc sam proces programowania niezmiernie przyjemnym. Nieskromnie powiem, że w moim przekonaniu właśnie w ten przejrzysty sposób powinno się konstruować moduły obsługi danych peryferiów, gdyż jakakolwiek modyfikacja sprowadza się wtedy do kosmetycznych i prostych do wykonania zmian.

Na początek plik nagłówkowy mechanizmu multipleksowania, który pokazano na listingu 1, a dzięki któremu porządkujemy późniejszy kod źródłowy, czyniąc go bardzo czytelnym - i jednocześnie upraszczając proces wprowadzania potencjalnych zmian. Plik ten definiuje główne ustawienia sprzętowe oraz wprowadza niezbędne zmienne.

Jak widać, w ramach pliku nagłówkowego zadeklarowano szereg zmiennych globalnych (typu volatile - z uwagi na ich wykorzystanie zarówno w programie głównym, jak i funkcji ISR). Przechowują one treść wyświetlaną na wyświetlaczu LED, a także upraszczają proces jej aktualizacji. Niemniej jednak już na tym etapie musimy zdefiniować kilka stałych opisujących wzorce znaków oraz upraszczające dostęp do portów sterujących, gdyż zależy nam na tym, by nasza procedura obsługi przerwania - multipleksująca wyświetlacz - była jak najkrótsza. Definicje, o których mowa, pokazano na listingu 2.

Jak widać, wszystkie spośród definicji omówionych powyżej zostały umieszczone w pamięci RAM mikrokontrolera. Jest to pewnego rodzaju „marnotrawstwo”, gdyż stałe te z powodzeniem można (a może nawet wypada?) umieścić w pamięci Flash mikrokontrolera, aby nie marnować cennej pamięci RAM, zwłaszcza że wartości tych stałych nasz kompilator i tak musi umieścić, a następnie odczytać z tejże pamięci Flash na starcie programu obsługi aplikacji (bo niby skąd miałby wziąć te wartości, by podstawić pod odpowiednie tablice?). Dokładnie tak postępowałem dotychczas, pisząc oprogramowanie embedded, jednak dostęp do pamięci Flash jest nieco wolniejszy niż odczyt stałych z pamięci RAM (dokładnie 5 taktów zegara zamiast 2). W związku z tym zdecydowałem się na powyższe rozwiązanie, zwłaszcza że wykorzystanie pamięci RAM w naszej aplikacji utrzymuje się na poziomie 20%. Niby niewielki przyrost szybkości, ale jednak mierzalny. Skądinąd jest to zgodne z podejściem twórców Androida, scharakteryzowane w zdaniu: „dlaczego nieużywana pamięć RAM ma leżeć odłogiem”? Abstrahując już od celowości i sensowności takiego postępowania, brnijmy dalej. Pora na przedstawienie funkcji konfigurującej zarówno mechanizm multipleksowania, jak i niezbędne ustawienia sprzętowe, której ciało pokazano na listingu 3.

Dalej, na listingu 4 przedstawiono z kolei funkcję obsługi przerwania od przepełnienia licznika RTC, odpowiedzialną za realizację mechanizmu multipleksowania wyświetlacza LED.

I na sam koniec, na listingach 5 i 6 przedstawiono dwie proste funkcje narzędziowe odpowiedzialne za konfigurację interfejsu SPI mikrokontrolera oraz za przesłanie bajtu danych do rejestru przesuwnego.

Prawda, że proste? Niemniej jednak warto choćby na chwilę zastanowić się nad znaczeniem nieopisanej wcześniej zmiennej readyForUpdate. Jest to zmienna, która funkcji głównej aplikacji użytkownika wskazuje moment atomowej aktualizacji zmiennych volatile procedury obsługi przerwania mechanizmu multipleksowania. Potrzeba wprowadzenia takiej zmiennej wynikała z konieczności synchronizacji chwili aktualizacji zmiennych, dokonywanej w aplikacji głównej, z pracą funkcji multipleksującej wyświetlacz LED - tak by nie występowało zjawisko „mieszania” zawartości zmiennych z kolejnych przebiegów funkcji multipleksującej. Aktualizacja, o której mowa powyżej, następuje po pełnym cyklu multipleksu dla całego wyświetlacza LED. I tutaj brakuje nam jeszcze jednej funkcji, mianowicie wyświetlającej stosowny wzorzec znaku na elemencie LED, której ciało pokazano na listingu 7.

Jak widać, funkcja przyjmuje argument przesunięcia w pionie wzorca znaku o liczbę zdefiniowanych pikseli obrazu (w zakresie 0…8), co zostanie użyte w mechanizmie animacji zmian wyświetlanych cyfr, o czym pisałem na wstępie. Tyle, jeśli chodzi o funkcje obsługi wyświetlacza LED. Przejdźmy teraz do grupy funkcji odpowiedzialnych za generowanie dźwięku. Zacznijmy jak zwykle od pliku nagłówkowego, pokazanego na listingu 8, dzięki któremu porządkujemy późniejszy kod źródłowy (czyniąc go bardzo czytelnym, a jednocześnie upraszczając proces wprowadzania zmian). Plik ten zarówno definiuje główne ustawienia sprzętowe, jak i wprowadza niezbędne zmienne.

Dalej, na listingu 9 zaprezentowano funkcję konfigurującą timer TCA0 jako generator przebiegu PWM, zaś na listingu 10 - funkcję konfigurującą timer TCB0, będący podstawą czasu mechanizmu generowania dźwięku.

Następnie, na listingu 11, uwidoczniono ciało funkcji obsługi przerwania timera TCB0 pracującego w trybie Periodic Interrupt, odpowiedzialną za wysyłanie próbek dźwięku na port mikrokontrolera obsługujący głośnik SMD.

Jak widać, funkcja pobiera kolejne próbki sygnału z tablicy (Tada[], Tick[] lub Error[]) zapisanej w pamięci Flash mikrokontrolera (z uwagi na jej rozmiar). Z myślą o bardziej dociekliwych Czytelnikach dodam, że 3 zdigitalizowane i bardzo krótkie próbki dźwięku zajmują prawie 10 kB wspomnianej pamięci Flash - i to mimo faktu, że są 8-bitowe oraz, oględnie mówiąc, nie grzeszą jakością. Na szczęście w naszym zastosowaniu niedogodność ta pozostaje właściwie bez większego znaczenia. I na koniec, na listingu 12 przedstawiono funkcję inicjującą proces odtwarzania dźwięku.

Tyle w kwestiach implementacyjnych. Przejdźmy zatem do schematu montażowego naszego urządzenia, pokazanego na rysunku 2.

Rysunek 2. Schemat montażowy urządzenia codeLock (a - strona TOP, b - strona BOTTOM)

Jak widać, zaprojektowano bardzo zgrabną, dwustronną, niewielką płytkę drukowaną ze zdecydowaną przewagą elementów SMD umieszczonych po obu stronach laminatu. Montaż urządzenia rozpoczynamy od warstwy TOP, na której w pierwszej kolejności przylutowujemy wszystkie półprzewodniki, w tym wyświetlacz LED. Proces ten najłatwiej wykonać przy użyciu stacji lutowniczej na gorące powietrze (tzw. Hot-Air) i odpowiednich stopów lutowniczych. Jeśli jednak nie dysponujemy tego rodzaju sprzętem, można również zastosować metodę z wykorzystaniem typowej stacji lutowniczej. Najprostszym sposobem montażu elementów o tak dużym zagęszczeniu wyprowadzeń, niewymagającym jednocześnie posiadania specjalistycznego sprzętu, jest użycie zwykłej stacji lutowniczej, dobrej jakości cyny z odpowiednią ilością topnika oraz dość cienkiej plecionki rozlutowniczej, która umożliwi usunięcie nadmiaru cyny spomiędzy wyprowadzeń układów. Należy przy tym uważać, by nie uszkodzić termicznie tego rodzaju elementów. Następnie lutujemy elementy bierne, po czym przechodzimy na warstwę BOTTOM. Tutaj, podobnie jak poprzednio, montaż rozpoczynamy od przylutowania wszystkich półprzewodników (w tym układów scalonych), po czym montujemy pozostałe elementy bierne, następnie głośniczek SMD oraz przekaźnik. W tym momencie wracamy na warstwę TOP, gdzie przylutowujemy enkoder SMD. To etap, na którym urządzenie gotowe jest do uruchomienia. Na fotografii 1 pokazano zmontowane urządzenie codeLock od strony warstwy TOP, zaś na fotografii 2 - od strony warstwy BOTTOM.

Fotografia 1. Zmontowane urządzenie codeLock od strony warstwy TOP

Fotografia 2. Zmontowane urządzenie codeLock od strony warstwy BOTTOM

Omówmy jeszcze kwestię obsługi naszego urządzenia. Tu sprawa jest niezmiernie prosta. W chwili bezczynności i oczekiwania na rozpoczęcie wprowadzania kodu urządzenie wyświetla znak „↔” (ale w pionie). Pokręcanie osią enkodera powoduje stosowną zmianę cyfr na wyświetlaczu LED, okraszoną bardzo efektowną animacją (przekręcania się „bębna” z cyframi), z towarzyszącym jej dźwiękiem tykania. Wciśnięcie ośki enkodera powoduje z kolei zatwierdzenie bieżącej cyfry i przejście do kolejnego kroku, który wygląda dokładnie tak samo. Wprowadzenie 4 cyfr kodu inicjuje jego sprawdzenie i - w przypadku zgodności z zapamiętanym - powoduje chwilowe pokazanie znaku „+” (okraszone specjalnym efektem dźwiękowym „ding”) oraz załączenie przekaźnika LOAD, po czym urządzenie przechodzi do stanu wyjściowego, czyli do początku wprowadzania kodu użytkownika (wyświetlając znak „↔” (w pionie)). Z kolei, jeśli wprowadzony kod nie zgadza się z kodem użytkownika, urządzenie pokaże znak „–”, po czym odtworzy dźwięk błędu i przejdzie, jak poprzednio, do początku wprowadzania tegoż kodu (wyświetlając znak „↔” (w pionie)). Tutaj nasuwa się pytanie: w jaki sposób wprowadzamy kod użytkownika, który ma zostać zapamiętany przez urządzenie (a następnie sprawdzany)? Również bardzo prosto. Jest to możliwe wyłącznie podczas włączania urządzenia. Jeśli podczas rozruchu wciśnięty będzie przycisk enkodera, układ przejdzie do trybu wprowadzania kodu użytkownika. Sam proces wprowadzania tego kodu wygląda dokładnie tak samo, jak normalna obsługa urządzenia, podczas której oczekuje ono na wpisanie kolejnych 4 cyfr kodu, ale z małym wyjątkiem. Otóż, podczas normalnego użytkowania urządzenia, czyli podczas wpisywania kodu do sprawdzenia, mikrokontroler odlicza czas bezczynności użytkownika (10 s), po upływie którego kasowane są wszystkie podane dotąd cyfry i proces wprowadzania startuje od nowa. W przypadku trybu wprowadzania kodu użytkownika wspomniany czas bezczynności nie ma zastosowania, w związku z czym urządzenie nie przejdzie do normalnego trybu pracy, dopóki nie zostanie wpisany cały kod użytkownika (4 cyfry). Po zakończeniu tej czynności nowy kod zapamiętany zostanie w pamięci EEPROM mikrokontrolera, zaś urządzenie przejdzie do trybu normalnego.

Robert Wołgajew, EP