- liczba przegródek: 16,
- maksymalna liczba dziennych dawek: 5,
- źródło napięcia zasilającego: bateria alkaliczna typu AAA,
- prąd pobierany ze źródła zasilania (maksymalny/tryb uśpienia): 55 mA/80 μA (szczegóły w tekście artykułu).
Przystępując do prac konstrukcyjnych, zdefiniowałem pewne, kluczowe założenia, które prezentują się następująco:
- Urządzenie będzie miało fizyczne "przegródki" (16 sztuk oznaczonych od "A" do "P"), w które będzie można włożyć przyjmowane leki (całą, dzienną dawkę);
- Przegródki, o których mowa powyżej, będą podświetlane w przypadku, gdy zachodzi konieczność przyjęcia stosownego leku;
- Kolor podświetlenia zależny będzie od liczby potencjalnie pominiętych dawek, a mianowicie: niebieski dla jednej dawki, zielony dla dwóch dawek i czerwony dla 3…5 dawek;
- Urządzenie będzie miało wyświetlacz graficzny o niskim poborze mocy, przy udziale którego (i współistniejących przycisków funkcyjnych) będzie można je skonfigurować;
- Konfiguracja, o której mowa, będzie niezależna dla każdej "przegródki" (oznaczonej od "A" do "P"), a obejmować będzie następujące ustawienia:
- aktywność "przegródki" (gdyż można ją wstępnie skonfigurować, ale na obecną chwilę nie aktywować),
- dzienną liczbę dawek leku (1…5),
- godziny przyjmowania leku (dowolne z zakresu 0…23),
- dni tygodnia przyjmowania leku,
- Konieczność przyjęcia leku sygnalizowana będzie dodatkowo przez wbudowany buzzer piezoelektryczny;
- Urządzenie standardowo pracować będzie w stanie uśpienia, ograniczając moc pobieraną ze źródła zasilania, zaś jego wybudzenie następować będzie na skutek użycia klawisza funkcyjnego (UP) lub poprzez nadejście zdarzenia konieczności przyjęcia leku;
- Urządzenie będzie automatycznie przechodzić w stan uśpienia po czasie 30 sekund bezczynności i nieobecności żadnych alarmów;
- Każde przyjęcie leku wymuszone pojawieniem się alarmu wymagać będzie potwierdzenia na ekranie głównym graficznego interfejsu użytkownika, które to potwierdzenie wyłączy alarm dźwiękowy oraz wygasi stosowną diodę LED podświetlenia przegródki (w przypadku pominięcia wielu dawek leku konieczne będzie potwierdzenie wszystkich zaległych alarmów);
- Urządzenie wyposażone będzie w zegar czasu rzeczywistego RTC;
- Wszystkie aktywne (czyli niepotwierdzone) alarmy będą automatycznie kasowane o północy. Do czasu skasowania alarmów urządzenie nie przejdzie w stan uśpienia;
- Do zasilania urządzenia przewidziano jedną baterię typu AAA.
To tyle, jeśli chodzi o założenia. Prawda, że zapowiada się ciekawie? A będzie jeszcze ciekawiej, gdyż do projektu urządzenia dołączony zostanie projekt obudowy dla "przegródek" wykonany w aplikacji do modelowania 3D a przeznaczony do wydrukowania na drukarce 3D. Zaczynajmy!
Budowa i działanie
Na rysunku 1 pokazano schemat ideowy urządzenia e-Nurse. Jak widać, zaprojektowano bardzo prosty system mikroprocesorowy, którego sercem jest niewielki mikrokontroler firmy Microchip (dawniej Atmel) pod postacią układu ATtiny84 taktowany wewnętrznym oscylatorem o częstotliwości 8 MHz.
Zastosowanie tak wysokiej, jak na tego rodzaju mikrokontroler, częstotliwości taktowania jest niejako w sprzeczności z potrzebą zachowania energooszczędności urządzenia, ale jest konieczne ze względu na fakt, że mikrokontroler nasz steruje pracą grupy 16 adresowalnych diod LED RGB, których specyfikacja interfejsu komunikacyjnego narzuca bardzo restrykcyjne wymogi czasowe. Niemniej jednak, i o czym wspomniałem wcześniej, urządzenie nasze standardowo przebywa w trybie uśpienia, przez co tak wysoka częstotliwość taktowania nie jest, aż tak "dokuczliwa".
Wróćmy zatem do schematu. Poza wspomnianymi diodami LED mikrokontroler steruje pracą zegara czasu rzeczywistego pod postacią układu MCP7940N produkcji firmy Microchip dokonuje tego dzięki programowej realizacji interfejsu I²C oraz realizuje obsługę graficznego, refleksyjnego wyświetlacza LCD o rozdzielczości 128×64 piksele wyposażonego w sterownik ekranu ST7565R firmy Sitronix, z którym komunikacja odbywa się dzięki programowej realizacji interfejsu SPI.
Uważny Czytelnik dostrzeże z pewnością, że interfejs komunikacyjny diod LED RGB podłączony został do jednego z wyprowadzeń interfejsu komunikacyjnego naszego wyświetlacza LCD (dokładnie do wyprowadzenia RS, czyli Data/Command), przez co sygnały sterujące pracą wyświetlacza mogłyby potencjalnie wpływać na stan diod LED i na odwrót. Generalnie mogłoby się tak dziać, ale interfejs diod celowo podłączono do wyprowadzenia RS, a nie żadnego innego wyprowadzenia w ramach interfejsu wyświetlacza LCD, gdyż przebiegi czasowe na nim występujące (chodzi głownie o czasy trwania stanu wysokiego) są na tyle powolne (co najmniej rząd wielkości większe), że nie zostaną rozpoznane przez logikę diody jako "ważne" dane, co najwyżej zostaną rozpoznane jako sygnał RESET, a to z kolei nie zaburza działania całego systemu.
Niemniej jednak zastanowicie się zapewne, dlaczego w ogóle powiązano te interfejsy? Odpowiedź jest bajecznie prosta… gdyż zabrakło wolnych wyprowadzeń mikrokontrolera. Oczywiście można by zastosować mikrokontroler o większej liczbie wyprowadzeń, ale po co, skoro problem można rozwiązać w ten prosty sposób?
Wróćmy zatem do samego wyświetlacza. Zastosowałem typ refleksyjny o bardzo dobrej widoczności w świetle słonecznym, lecz pozbawiony podświetlenia, gdyż zależało mi na oszczędności energii. Poza wspomnianymi peryferiami mikrokontroler nasz odpowiada za obsługę 4 przycisków funkcyjnych umownie oznaczonych jako UP, DOWN, NEXT i PREV, wykorzystując w tym celu przerwanie od porównania licznika Timer0 (wyzwalane 100 razy na sekundę), przez co możliwa stała się detekcja krótkiego i długiego naciśnięcia przycisku bez blokowania programu obsługi aplikacji, oraz odpowiada za obsługę wspomnianego wcześniej buzzera piezoelektrycznego.
Warto już w tej chwili pochylić się nad wspomnianym buzzerem. Uważny Czytelnik dostrzeże na pewno, że podłączono go do portu RESET mikrokontrolera i jak się zapewne domyślacie, nie bez powodu. A powód był znów tak samo trywialny, zwyczajnie nie miałem już wolnych portów, do których mógłbym podłączyć ten element, więc wybrałem ostatni, dostępny port…RESET.
Użycie wyprowadzenia RESET jako zwykłego portu I/O umożliwia nam stosowny bit konfiguracyjny dostępny w przestrzeni fuse-bitów (dokładnie bit RSTDISBL). Niestety ustawienie tegoż bitu (a dokładnie jego wyzerowanie) uniemożliwia dalsze programowanie mikrokontrolera z użyciem zwykłego programatora szeregowego, a jedyną możliwością w takim stanie rzeczy jest wykorzystanie programatora HV (wysokonapięciowego). Niesie to za sobą konsekwencję w postaci odpowiedniej kolejności programowania.
Otóż, i czego zapewne się domyślacie, w pierwszym kroku należy zaprogramować pamięć flash mikrokontrolera, a dopiero później ustawić bity konfiguracyjne. Brak ustawienia bitu RSTDISBL uniemożliwi obsługę buzzera piezoelektrycznego, co czasami może być wręcz pożądane (na przykład w przypadku, gdy nie planujemy używać tego rodzaju sygnalizacji). Z kolei, aby w ogóle móc zaprogramować mikrokontroler, konieczny jest demontaż buzzera (a przynajmniej odłączenie jego wyprowadzenia podłączonego do sygnału RESET), gdyż obecny na tej linii będzie zwierał sygnał RESET do masy zasilania, uniemożliwiając start programu obsługi aplikacji. Właśnie na ten problem natknąłem się, uruchamiając urządzenie i choć wydawał się oczywisty, to nie tak łatwo na początku było skojarzyć niezaprzeczalne fakty.
Wracając jeszcze do schematu urządzenia, wspomnieć należy o podtrzymaniu (choć niewielkim) zasilania zegara czasu rzeczywistego w postaci kondensatora C5 i diody D1, które zapewniają mu podtrzymanie zasilania na czas wymiany baterii zasilającej urządzenie.
To byłoby tyle w kwestii sprzętu, ale poruszę jeszcze kwestię zastosowanych diod LED. Jako że założyłem, że każda z "przegródek" będzie podświetlana diodą LED, która może zmieniać kolor, konieczne było zastosowanie elementów typu RGB. W tym miejscu stanąłem przed wyzwaniem wyboru odpowiednich elementów wykonawczych, a więc sterownika diod LED, jak i samych diod. Jak wiemy, aby płynnie sterować kolorem diody LED typu RGB, należy zastosować 3-kanałowy sterownik PWM. Wynika z tego, że skoro przewiduję zastosowanie 16 elementów tego typu, to liczba niezbędnych kanałów wzrasta nam do 48. Trudno wyobrazić sobie mikrokontroler, który sprostałby tym wymaganiom, a jeszcze trudniej wyobrazić sobie projekt płytki drukowanej o niewielkiej wielkości, na której upakowalibyśmy tyle odrębnych ścieżek. Co oczywiste, można byłoby zastosować jakiegoś rodzaju sterowanie matrycowe, by ograniczyć liczbę koniecznych połączeń, ale biorąc pod uwagę liczbę wymaganych kanałów PWM i oczekiwaną rozdzielczość takiego sygnału (8 bitów), trudno mi sobie wyobrazić efektywne sterowanie bez użycia dość dużych prądów, by uzyskać wynikową jasność na akceptowalnym poziomie. Zresztą nawet w takim przypadku nie rozwiązujemy problemu ze skomplikowaniem rysunku obwodu drukowanego. Pat? Otóż nie.
Adresowalne diody LED RGB
Dość szybko zdałem sobie sprawę, że jedynym sensownym rozwiązaniem tego rodzaju problemu konstrukcyjnego będzie zastosowanie adresowalnych diod LED RGB, których konstrukcja pozwala na uniknięcie wszystkich wspomnianych problemów. Diody takie, oprócz wyprowadzeń zasilających, wyposażone są w jakiś szeregowy interfejs komunikacyjny, przy użyciu którego dokonujemy ustawień koloru jej świecenia. Interfejs, o którym mowa, zaimplementowany jest w taki sposób (zarówno w kwestii sprzętowej, jak i logicznej), że diody, takie połączone w łańcuchy, mogą być indywidualnie adresowane, a co za tym idzie, każda z nich ma niezależne sterowanie. Sam przebieg PWM niezbędny do regulacji koloru jej świecenia generowany jest sprzętowo dzięki sterownikowi zabudowanemu "na pokładzie" takiego elementu.
Przejdźmy zatem do konkretów. Pierwszą myślą, jaka przyszła mi w tym czasie do głowy, było zastosowanie bardzo popularnych i tanich elementów tego typu pod postacią diod z rodziny WS2811/WS2812. I właśnie tak zrobiłem, stosując diody typu WS2812B-V5 produkcji firmy Worldsemi, które mają tę dodatkową zaletę, że nie wymagają stosowania kondensatorów odsprzęgających zasilanie. Diody te produkowane są w niewielkich 4-wyprowadzeniowych obudowach SMD typu 5050 o wymiarach 5×5 mm, które idealnie wpisują się w założenia naszego projektu. Dioda tego rodzaju wyposażona jest w 4 wyprowadzenia:
- wyprowadzenia zasilające: GND i VCC,
- wejście asynchronicznego interfejsu komunikacyjnego DIN,
- wyjście asynchronicznego interfejsu komunikacyjnego DOUT.
Wygląd obudowy diody typu WS2812B-V5 z zaznaczeniem nazw wyprowadzeń pokazano na rysunku 2. Jak zapewne się domyślacie, diody typu WS2812B-V5 łączy się w łańcuchy, łącząc wyjścia interfejsu komunikacyjnego diody bieżącej z wejściami interfejsu komunikacyjnego diody kolejnej i tak dalej.
Wejście interfejsu komunikacyjnego diody pierwszej, co oczywiste, łączy się z wyjściem tegoż interfejsu w mikrokontrolerze, zaś sama konstrukcja ramek danych i sposób działania sterownika "zabudowanego" w strukturze diody zapewnia odpowiednią synchronizację transmisji i niezbędne adresowanie.
Zacznijmy więc od podstaw. Jak już wspomniałem, mamy do czynienia z interfejsem asynchronicznym, gdzie nie ma wyprowadzenia sygnału zegarowego, w związku z czym dane przesyłane przy jego użyciu muszą być w pewien sposób zakodowane, by możliwe stało się ich proste zdekodowanie i by były one odporne na zakłócenia i artefakty. W rozwiązaniu firmy Worldsemi zastosowano mechanizmy dobrze znane z interfejsów bezprzewodowej transmisji danych, stosowanych w torach podczerwieni, gdzie stany logiczne "1" i "0" zakodowane zostały długością impulsu. Dodatkowo wprowadzono tak zwany sygnał RESET (również zakodowany długością impulsu), który powoduje zresetowanie interfejsów komunikacyjnych sterowników diod LED i ich oczekiwanie na nowe dane. Na rysunku 3 pokazano przebiegi sygnałów interfejsu komunikacyjnego diody WS2812B-V5 w trakcie transmisji bitu logicznej "1", logicznego "0" i sygnału RESET.
Co ważne, pojedyncze bity danych zgrupowane w bajty danych przesyłane są w kolejności od bitu najstarszego (MSB) do najmłodszego (LSB), a każda dioda LED w łańcuchu oczekuje na 3 bajty danych odpowiedzialnych za składowe jej koloru przesyłane w kolejności G, R, B.
W tym miejscu zapewne zadacie sobie pytanie, skąd każda z diod w łańcuchu "wie", które z przesyłanych danych użytecznych przeznaczone są właśnie dla niej, a nie dla innej? Zrealizowano to w bardzo prosty, acz skuteczny sposób. Każda z diod LED w łańcuchu po włączeniu zasilania (jak również po odebraniu sygnału RESET) oczekuje na 3 bajty danych przeznaczonych wyłącznie dla niej. Do tego czasu jej wyjściowy interfejs komunikacyjny (wyjście DOUT) jest "nieprzezroczysty" dla nadchodzących danych (a dokładnie rzecz biorąc, jest "przezroczysty" wyłącznie dla sygnału RESET). Po odebraniu wspomnianych 3 bajtów danych dioda ta staje się "przezroczysta" dla kolejnych nadchodzących danych, co znaczy ni mniej, ni więcej, że retransmituje je do kolejnych diod w łańcuchu (z małym opóźnieniem rzędu 300 ns). Biorąc pod uwagę, że dokładnie tak samo zachowuje się każda dioda w łańcuchu, dość szybko zdamy sobie sprawę, że kolejne dane użyteczne przesyłane przez tak skonstruowany interfejs komunikacyjny trafiają kolejno do następujących po sobie (w sensie elektrycznym) diod w łańcuchu.
Skuteczne i zarazem genialne w swojej prostocie, nieprawdaż? Niemniej jednak, co widać na rysunku 4 prezentującym kompletną ramkę transmisji łańcucha diod tego typu, przyjęty sposób transmisji stanowiący podstawę "adresowania" poszczególnych diod LED w łańcuchu powoduje, że nie da się "zaadresować" (czyli przesłać do niej danych) na przykład diody czwartej w łańcuchu bez przesłania wcześniejszych (i zdawałoby się niepotrzebnych w tym momencie) danych dla diody trzeciej, drugiej i pierwszej. Mimo tego ograniczenia jest to rozwiązanie bardzo wygodne i chętnie stosowane przez producentów wszelkiego rodzaju peryferiów o takim przeznaczeniu.
Zasilanie i pobór prądu
I na tym zakończyłbym opis naszych ciekawych diod LED, gdyby nie jeden szczegół, który kompletnie demoluje założenia projektowe urządzenia, a wynika z niekompletności dokumentacji producenta (!). Otóż, jak pamiętacie, urządzenie e-Nurse standardowo, gdy nie ma żadnych aktywnych alarmów, przebywać będzie w trybie uśpienia o niskim poborze energii, podczas którego diody te pozostają wyłączone (wygaszone). Wszystko wydaje się OK, nieprawdaż? Gdyby właśnie nie ten "szczegół", którym producent peryferium specjalnie się "chwali" (w sumie nic dziwnego, gdyż nie jest to powód do dumy).
Otóż dioda LED tego rodzaju, nawet jak jest wygaszona pobiera ze źródła zasilania bardzo duży (jak na jej stan pracy) prąd rzędu aż 0,7 mA, co przy 16 zastosowanych diodach daje nam aż 10 mA! I to w stanie czuwania!
Tak duży prąd zniweczyłby korzyść z wprowadzania systemu mikroprocesorowego (i pozostałych peryferiów) w stan uśpienia, dla którego prąd spoczynkowy jest kilkaset razy mniejszy. Taki prąd dość szybko rozładowałby baterię AAA będącą źródłem napięcia zasilającego urządzenie. Jak poradzić sobie z takim nieoczekiwanym problemem? Postanowiłem wyłączać zasilanie diod LED w stanie uśpienia systemu za pomocą dodatkowego tranzystora MOSFET. Skuteczne a zarazem proste! Jedyny minus, że po włączeniu zasilania należy odczekać pewien (znowu brak o tym mowy w dokumentacji) czas niezbędny na "rozruch" interfejsu komunikacyjnego diody i dopiero po tym czasie można nawiązać z nią komunikację. Proste? Tyle, jeśli chodzi o szczegóły dotyczące naszych podstawowych elementów wykonawczych zaangażowanych w projekt urządzenia e-Nurse.
Kilka słów uwagi muszę poświęcić jeszcze sekcji zasilania. Jako że założyłem, że do zasilania urządzenia zastosowana będzie zwykła i tania bateria AAA o napięciu znamionowym 1,5 V (najlepiej alkaliczna z uwagi na jej pojemność), konieczne było użycie nowoczesnej przetwornicy step-up, która podwyższy napięcie ogniwa do minimum 3,7 V wymaganych dla diod LED i będzie odznaczać się niewielkim prądem spoczynkowym, by nie obciążać dodatkowo źródła zasilania w przypadku uśpienia systemu mikroprocesorowego. Co więcej, zastosowany rodzaj wyświetlacza wymaga z kolei napięcia zasilania 3,3 V, co spowodowało konieczność wykorzystania niewielkiego stabilizatora LDO obniżającego napięcie 3,7 V do poziomu 3,3 V cechującego się, jak poprzednio, niewielkim prądem spoczynkowym.
W związku z tym wybrano nowoczesne elementy SMD z oferty firmy Microchip, a mianowicie przetwornicę DC/DC typu MCP1640T-I/CHY (standardowy prąd spoczynkowy 19 μA i napięcie wejściowe od 0,65 V) oraz stabilizator LDO typu MCP1700T-3302E/TT (prąd spoczynkowy 1,6 μA). Bez problemu możemy też zastosować wersję stabilizatora o napięciu wyjściowym 3,0 V.
Na koniec opisu naszego urządzenia nie sposób nie poruszyć problematyki zużycia energii naszego systemu mikroprocesorowego, a co za tym idzie, żywotności zastosowanego źródła napięcia zasilania w postaci baterii AAA o przeciętnej pojemności w granicach 1300 mAh. Aby ocenić, jak długo urządzenie e-Nurse pracować będzie na pojedynczej baterii AAA, należy poczynić pewne założenia, jak również zastanowić się, z jakich etapów składa się cykl jego pracy i jakiej wielkości prądy pobiera wtedy ze źródła napięcia zasilającego.
Przystępując do obliczeń, założono, że urządzenie e-Nurse będzie alarmowało użytkownika o konieczności przyjęcia leku 5 razy na dobę, zaś czas tego alarmu, czyli okres od wystąpienia alarmu do skasowania go przez użytkownika, będzie każdorazowo wynosił 15 minut. Założono ponadto, że alarmy, o których mowa powyżej, wystąpią każdorazowo dla połowy dostępnych przegródek (slotów), co pociąga za sobą zapalenie 8 diod LED, zaś powrót urządzenia do stanu czuwania (po skasowaniu tychże alarmów) następował będzie automatycznie po upływie 30 sekund bezczynności po stronie użytkownika.
W związku z założeniami poczynionymi powyżej wyodrębniono następujące stany pracy urządzenia i odpowiadające im prądy pobierane ze źródła napięcia zasilania:
- Stan alarmowania trwający 75 minut (5×15 minut), podczas którego diody LED zapalone są jedynie przez okres 1/7 długości tegoż stanu (gdyż takie jest wypełnienie sygnału sterującego ich miganiem) i pobierają wtedy ze źródła napięcia zasilania prąd o wartości 55 mA;
- Stan bezczynności systemu mikroprocesorowego, na który składa się 6/7 okresu stanu alarmowania (czyli około 64 minut, wtedy, gdy diody nie świecą) oraz 2,5 minuty bezczynności (5×30 sekund) przed przejściem systemu w stan uśpienia, podczas którego prąd pobierany ze źródła napięcia zasilania wynosi około 10,5 mA;
- Stan uśpienia, który trwa z dużym przybliżeniem 22,75 h/dobę i podczas którego pobierany jest prąd rzędu 80 μA (większość tego prądu to prąd spoczynkowy przetwornicy, stabilizatora oraz prąd pobierany przez logikę wyświetlacza LCD).
Przy założeniach jak wyżej otrzymano teoretyczny, 57-dniowy czas pracy na pojedynczej baterii AAA, co wydaje się wartością satysfakcjonującą, biorąc pod uwagę użyteczność urządzenia. Tyle w kwestii schematu, w związku z czym przejdźmy do zagadnień implementacyjnych, które ograniczają się do obsługi diod LED RGB.
CKSEL3...0: 0010
SUT1...0: 10
CKDIV8: 1
CKOUT: 1
DWEN: 1
EESAVE: 0
RSTDISBL: 0(*)
(*): szczegóły w tekście artykułu
Kolejna częsć opisu zostanie zaprezentowana za miesiąc. Omówimy wtedy działanie programu sterującego oraz montaż i obsługę urządzenia.
Robert Wołgajew, EP
- R1, R2: 4,7 kΩ (miniaturowy 1/8 W, raster 0,2")
- R3: 976 kΩ 1% (SMD0805)
- R4: 470 kΩ 1% (SMD0805)
- C1, C2: 100 nF (THT, raster 0,1")
- C3, C4: 12 pF (THT, raster 0,1")
- C5: 1 μF (THT, raster 0,1")
- C6…C8: 10 μF X7R (SMD0805)
- C9…C17: 1 μF (THT, raster 0,1")
- D1: BAT85 (DO34-7)
- U1: MCP7940N-I/P (DIL8)
- U2: ATtiny84 (DIL14)
- U3: MCP1640T-I/CHY (SOT23-6)
- U4: MCP1700T-3302E/TT (SOT23)
- LED1…LED16: dioda adresowalna LED RGB typu WS2812B-V5 (SMD5050/PLCC4)
- LCD: wyświetlacz graficzny typu LCD-AG-C128064CF-FGN NO/-E6 (rozdzielczość 128×64, sterownik ST7565R)
- BUZZ: buzzer piezoelektryczny z wbudowanym generatorem (raster 0,3")
- BATT: gniazdo baterii AAA typu KEYSTONE 1021
- L1: dławik drutowy SMD 4.7 μH typu WLPN303015M4R7PB (SMD 3×3 mm)
- Q1: rezonator kwarcowy zegarkowy 32768 Hz
- PREV, NEXT, UP, DOWN: microswitch TACT (wysokość 13 mm)