Niski pobór mocy a oprogramowanie
| TechnikaWiele aplikacji mikrokontrolerów to zasilane z baterii układy elektroniczne o wyjątkowo niskim poborze mocy. Dzięki innowacyjnym trybom ograniczonego poboru mocy, inteligentnym analogowym układom peryferyjnym, bramkowaniu sygnałów zegarowych, skalowaniu napięcia zasilającego, co chwilę udaje się pobić kolejny rekord związany z niskim zużyciem energii. Jednak bez skutecznie działającego i dobrze zaprojektowanego oprogramowania firmware nie ma możliwości wykorzystania pełni funkcjonalności, jakie zapewniają wspomniane techniki redukcji poboru mocy.
W miarę jak na rynku mikrokontrolerów pojawiają się nowe rozwiązania o coraz mniejszym poborze mocy, ostateczną granicę oszczędności energetycznej systemów coraz częściej będzie stanowić oprogramowanie, które będzie umożliwiać lub nie maksymalne wykorzystanie trybów oszczędnościowych.
Podstawową sprawą dobrej konstrukcji jest taka konstrukcja algorytmu, aby procesor jak najdłużej przebywał w stanie głębokiej redukcji mocy. W sprzęcie, takim jak wykrywacze dymu, piloty do telewizorów czy czujniki ruchu sterujące światłem zainstalowane w wielu garażach, tryb czuwania trwa przez 90-99,9% czasu.
Tak długie, licząc procentowo, przebywanie w czasie uśpienia, oczekiwania, oszczędzania energii lub innym trybie z szerokiego katalogu funkcji oszczędnościowych jest możliwe dzięki temu, że mikrokontroler oraz jego urządzenia peryferyjne, np. przetworniki analogowo-cyfrowe, timery i moduły komunikacji szeregowej, mogą być zasilane przez różne źródła taktowania i sygnału zegarowego.
Co więcej, układy peryferyjne są w stanie działać bez nadzoru procesora, umożliwiając jego wyłączenie i redukcję całkowitego zużycia energii elektrycznej. Przykładem jest 16-bitowy mikrokontroler MSP430 firmy Texas Instruments. Układ ten może pobierać próbki od przetworników analogowo-cyfrowych, zliczać przy użyciu timerów, generować sygnały PWM i wykonywać inne operacje przy wyłączonym procesorze.
Oznacza to, że przetworniki analogowo-cyfrowe mogą próbkować sygnał, timery mogą zliczać impulsy, a moduły komunikacji szeregowej mogą przesyłać dane w trybie oszczędzania energii, bez konieczności interwencji ze strony procesora i wybudzania go ze stanu uśpienia. Kolejnym ważnym krokiem jest analiza dokumentacji mikrokontrolera.
Mając do przeanalizowania około stu stron dokumentacji, projektanci zazwyczaj wyszukują wartości dotyczące aktualnego poboru mocy w różnych trybach pracy. Pobór prądu w trybie aktywnym może wynieść od 100 do 500 μA/MHz. Natomiast w przypadku trybu oszczędnego z wyłączonym procesorem - wartość ta może zejść nawet poniżej 1 μA.
Chociaż wartości te robią wrażenie, projektant powinien spojrzeć także na kod, aby upewnić się, że taki poziom oszczędności energii jest faktycznie możliwy, czy będzie możliwe szybkie wprowadzanie procesora i wybudzanie go z uśpienia i ewentualnie skorzystanie z wielu podobnych trybów pośrednich, niezapewniających głębokiej redukcji mocy, ale charakteryzujących się np. niewielką wymaganą aktywnością układów peryferyjnych.
Programiści powinni brać pod uwagę wykorzystanie trybu oszczędzania energii, jeśli tworzone przez nich oprogramowanie wykonuje jedną z przykładowych poniższych operacji.
Oczekiwanie na upłynięcie określonego czasu
Dotyczy działania, w którym wykonywane są operacje okresowe, np. w przypadku wykrywacza dymu, gdzie odczyt czujnika odbywa się przez część sekundy co kilka minut. Aby procesor nie działał w trybie aktywnym przez 100% czasu, wykonując niepotrzebnie cykle, należy utworzyć kod umożliwiający wykorzystanie elastycznych trybów oszczędzania energii i inteligentnych timerów generujących przerwania. Poniżej znajduje się przykładowy pseudokod.
Testowanie flagi
Urządzenia wyposażone w mikrokontrolery muszą niejednokrotnie czekać na ukończenie zadania przed kontynuowaniem operacji. Może to być oczekiwanie na ustalenie napięcia odniesienia, stabilizację położenia styków przełącznika albo ukończenie konwersji przez przetwornik analogowo-cyfrowy.
Kolejnym przykładem jest oczekiwanie na zmianę stanu lub statusu. Analizując przykład pilota do telewizora lub światła uruchamianego przez czujnik ruchu - urządzenia te zazwyczaj pracują w trybie czuwania do momentu zmiany stanu - naciśnięcia przycisku na pilocie lub pojawienia się samochodu przed czujnikiem podczerwieni.
Jednym ze sposobów na zidentyfikowanie zmiany statusu jest ciągłe sprawdzanie zmiennej przechowującej stan czujnika. Niemniej zamiast nieustannie odczytywać flagę, mikrokontroler powinien wykorzystać możliwości zintegrowanych urządzeń peryferyjnych, które mogą działać bez procesora. W tym wypadku istnieje możliwość wykorzystania portów GPIO z obsługą przerwań w celu wybudzenia mikrokontrolera z trybu niskiego poboru mocy.
Pokazuje to pseudokod znajdujący się z prawej strony. W tym przypadku mikrokontroler może obciążyć większą liczbą zadań wbudowane układy peryferyjne zamiast wykorzystywać oprogramowanie do nieustannego sprawdzania statusu różnych flag. Ponownie, układ może wykonać więcej operacji, pozostając w trybie oszczędzania energii przez dłuższy okres i przechodząc w tryb aktywny, gdy moc procesora jest faktycznie potrzebna.
Skala oszczędności energii uzyskiwana w ten sposób zależy od tego, na jak długo można uśpić procesor między kolejnymi wybudzeniami oraz od poborów prądu przez układ w każdym stanie. Niemniej są to znaczące oszczędności, skłaniające do stosowania takich technik przy każdej okazji, gdy trzeba poczekać.
Powyższe przykłady zilustrowały jedynie dwa najbardziej powszechne obszary wykorzystania energooszczędnego trybu oczekiwania, jednak takich obszarów jest więcej. Dlatego należy zawsze przeanalizować kod pod kątem operacji, które układy peryferyjne mikrokontrolera mogą wykonać bez procesora i momentów oczekiwania.
W przypadku mikrokontrolerów MSP430 firmy TI, aby ułatwić identyfikowanie obszarów, w których możliwe jest wprowadzenie ulepszeń, można wykorzystać narzędzie do analizy kodu ULP Advisor. Analizuje ono kod wprowadzony przez projektanta wiersz po wierszu i wyświetla wskazówki odnośnie do zwiększenia efektywności programu mikrokontrolera.
Adrian Fernandez
Texas Instruments
www.ti.com