Mikrokontrolery - Jak zacząć?

... czyli zbiór praktycznej wiedzy dot. mikrokontrolerów.

poniedziałek, 10 stycznia 2011

Bateria zasila mikrokontroler - cz. 1


Autor: Dondu


Bateria zasila mikrokontroler - cz. 1
Bateria zasila mikrokontroler - cz. 2
Bateria zasila mikrokontroler - cz. 3


27 razy dłużej?
A może 25 lat?
Jeżeli chcesz wydłużyć pracę swojego układu, aż 27 razy, albo dowiedzieć się, co zrobić by układ pracował 25lat na jednej baterii, to ten trzyczęściowy temat jest dla Ciebie!


Większość projektów robionych przez początkujących nie wymaga oszczędzania energii, gdyż są zasilane z sieci. Ale przychodzi moment, w którym zabierzesz się za projekt zasilany z baterii lub akumulatora, w którym będzie zależało Ci na długiej pracy układu.


Kompromis
Słowo na czerwono, ponieważ w tym temacie będzie się przewijać wielokrotnie, gdyż będziesz balansować na krawędzi wielu zjawisk związanych z Twoim układem. Nie ma jedynej słusznej drogi, która pozwoli Ci na zaoszczędzenie energii. Można to robić na wiele sposobów, ale każdy ma swoje zalety i wady z Twojego punktu widzenia.



Rozpatruję poniżej układ złożony z:
  • źródła zasilania
  • mikrokontrolera
  • programu
bez dodatkowych odbiorników energii np. diod LED, silników, itp.


Czytaj tekst w całości
Nie czytaj tekstu wyrywkowo, gdyż  kolejne zdania wynikają z poprzednich :-)



Nierozerwalny układ

Problem zasilania bateryjnego należy rozpatrywać z punktu widzenia całego układu (elektronika, zasilanie i program), a nie tylko z punktu widzenia poszczególnych jego elementów, gdyż będziesz dochodził do złych wniosków

Pytasz dlaczego? 

Na przykład patrząc TYLKO na dokumentację mikrokontrolera możesz dojść do wniosku, że pracując na największym możliwym zegarze wykonasz żadane działania szybko, po czym uśpisz mikrokontroler, więc zużyjesz najmniej energii z baterii, przez co będziesz mógł zasilać układ przez możliwie najdłuższy czas. Niestety, możesz być w błędzie! :-) 


1. Prąd zasilania pobierany przez mikrokontroler

Prąd pobierany przez pracujący mikrokontroler zależy od:
  • prędkości z jaką pracuje
  • napięcia zasilania
  • ilości włączonych wewnętrznych układów



1.1 Prędkość pracy mikrokontrolera

Patrzymy w dokumentację mikrokontrolera i stwierdzamy, że prędkość wpływa na pobór prądu:
  • wolna praca = mały prąd 
  • szybka praca = duży prąd


Przykład: Samochód jadący:
  • z małą prędkością zasysa paliwo z baku powoli
  • z dużą prędkością zasysa paliwo z baku szybko


Wniosek 1
Duża prędkość, to duży prąd.





1.2 Napięcie zasilania

Patrzymy w dokumentację mikrokontrolera i stwierdzamy, że przy tej samej prędkości:
  • niskie napięcie zasilania = mały prąd
  • wysokie napięcie zasilania = duży prąd






Wniosek 2
Im wyższe napięcie zasilania tym większy prąd.





1.3 Ilość włączonych wewnętrznych układów mikrokontrolera

Patrzymy w dokumentację mikrokontrolera i stwierdzamy, że niektóre układy są nam niepotrzebne i można je wyłączyć za pomocą konfiguracji lub przez program (bardzo indywidualne możliwości dla danego mikrokontrolera oraz Twojego projektu):
  • mało włączonych układów wewnętrznych = mały prąd
  • dużo włączonych układów wewnętrznych = duży prąd

Przykład: Samochód:
  • z wyłączoną klimatyzacją zużywa mniej paliwa 
  • z załączoną klimatyzacją zużywa więcej paliwa



Wniosek 3
Wyłączając zbędne układy zmniejszamy prąd.




A teraz pytanie: 

Co by było, gdyby w baku samochodu zamontować ogranicznik ilości paliwa, które w danej chwili może zostać z niego pobierane?

W przypadku, gdy jechałby z prędkością ekonomiczną i wyłączoną klimatyzacją prawdopodobnie wszystko działało, by prawidłowo. 

A co w przypadku szybkiej jazdy i włączonej klimatyzacji?
Silnik zacząłby działać nieprawidłowo z powodu zbyt małej ilości paliwa dostarczanego do niego w stosunku do zapotrzebowania.

Jaki z tego wniosek?


Wniosek 4
Źródło zasilania musi być odpowiednio wydajne prądowo.


Oznacza to, że cały układ jest nierozerwalnie związany ze źródłem zasilania. Zobaczmy więc jakie tutaj mamy ograniczenia i możliwości?



2. Bateria, akumulator

Każda bateria czy akumulator mają swoje parametry, które warunkują Twój projekt. Popatrz na przykładowy wykres charakterystyki baterii:




Co interesującego odczytałeś z wykresu głównego? Na przykład, że:
  • maksymalny okres pracy przy ciągłym poborze prądu 60µA to około 3,5 roku
  • maksymalny okres pracy przy ciągłym poborze prądu 60mA to zaledwie 10,5 godziny
  • przy większych prądach jest znaczący spadek napięcia
  • najwydajniej pracuje przy 2mA


A teraz rzućmy okiem na mały wykres:



A tutaj niespodzianka!
Przy nagłych poborach prądu następuje niepożądane zjawisko spadku napięcia nawet przez kilka sekund!

Inny przykład tego problemu:



I to jest te nasze ograniczenie zamontowane na baku paliwa, które ograniczając je może doprowadzać do jego nieprawidłowej pracy silnika, czyli w naszym przypadku mikrokontrolera.

Jest jeden z problemów układów mikrokontrolerów o dużym poborze prądu, zasilanych z baterii czy akumulatorów. Efekt ten ujawnia się jeszcze bardziej, gdy bateria jest bliska rozładowania.

Natomiast układy pracujący z małym poborem prądu problem ten odczuje znacznie później (czasami na wet liczony w latach).



Wniosek 5
Powolny wzrost napięcia przy dużym prądzie.





Temperatura

Następnym zjawiskiem jest, które może wpływać na Twój projekt jest temperatura w jakiej pracuje. To ważne tym bardziej, iż spadki napięcia dla dużych prądów są znacznie większe przy niskiej temperaturze, co może doprowadzać do nieprawidłowej pracy urządzenia w niskich temperaturach.


Dlatego jeżeli pracujesz na dolnej granicy napięcia zasilania mikrokontrolera i nie możesz jej przekroczyć w dół, to niestety musisz ograniczyć pobór prądu w niskich temperaturach. Przykład dla baterii w wykresu powyżej jeżeli:

  • mikrokontroler wymaga zasilania 3V
  • pracuje w temperaturze  -20°C 

to maks możesz uzyskać około 4mA.


Wniosek 6
Niska temperatura ogranicza prąd.


Przykładowa bateria: SL-360


3. Program

Pisanie programu dla układu, który ma oszczędzać energię, to niełatwe zadanie! Taki program musi być napisany zupełnie inaczej niż w przypadku nieograniczonego zasilania. Dlatego już od początku powinieneś pisać go w taki sposób, aby maksymalnie oszczędzać energię.

Samo usypianie procesora w wolnych chwilach daje już wiele oszczędności. Ale pole do popisu jest tutaj OGROMNE! Oto parę istotnych zasad:
  1. po włączeniu zasilania ustaw, co trzeba i uśpij mikrokontroler,
  2. wykorzystuj przerwania timery, komparatory i inne wewnętrzne układy,
  3. wszystko co się da opieraj o przerwania,
  4. nigdy nie wykorzystuj funkcji opóźniających delay(), itp.
  5. nigdy nie czekaj w pętlach na ustawienie jakiejś flagi np. odbioru danej,
  6. wykorzystuj maksymalny tryb snu jaki jest możliwy w danej chwili,
  7. wyłączaj zbędne w danym momencie układy wewnętrzne,
  8. zmniejszaj prędkość mikrokontrolera, gdy to tylko możliwe,



Wniosek 7
Program od początku pisany inaczej.



Nie zapominaj o pozostałych elementach

Wyżej opisany układ został przeze mnie ograniczony do baterii, mikrokontrolera i programu. Ale często układy zasilane baterią mają jeszcze inna elementy "na pokładzie" jak LCD, bluetooth, itp., które także są pożeraczami energii. Nie zapominaj o tym, by ująć ich prądy zasilające do bilansu, by nie spotkało Cię rozczarowanie, że cały układ pracuje krótko na zasilaniu bateryjnym.




Czy można wierzyć dokumentacji ?

XXX napisał:
Nanoampery ?! To niemożliwe!


W internecie możesz znaleźć wiele opinii, że dokumentacje podają zaniżone wartości prądów mikrokontrolerów w stanie uśpienia.

Wynikają one w większości z dokonywania pomiarów w innych warunkach niż podane w dokumentacji mikrokontrolerów, co ma w szczególności znaczenie przy ich wartościach mierzonych w nA.

Z mojego doświadczenia z mikrokontrolerami firm Atmel i Microchip wynika, że dane te są prawdziwe i bez problemu osiągalne w warunkach domowych.



Podsumowanie cz. 1

I tutaj wracam do tego, co napisałem na początku. Nie ma jedynie słusznej drogi i tylko Ty wiesz na jakie kompromisy możesz się zgodzić, budując swój projekt. 
  • każdy projekt jest inny i trzeba się zastanowić jakie kompromisy są możliwe
  • jeżeli budujesz układ zasilany z baterii z reguły musi mieć specyficzną budowę
  • program pisany od początku pod kątem oszczędzania energii
  • maksymalne osiągi to żmudna i ciężka praca, ale efekt będzie znakomity!

W bardzo specyficznych przypadkach może się jednak okazać, że praca na szybszym zegarze jest bardziej ekonomiczna niż na wolniejszym, ale to są wyjątki od ogólnej reguły przedstawionej powyżej.




Czytaj następne




Oceń artykuł.
Wasze opinie są dla nas ważne, gdyż pozwalają dopracować poszczególne artykuły.
Pozdrawiamy, Autorzy
Ten artykuł oceniam na:

7 komentarzy:

  1. "W bardzo specyficznych przypadkach może się jednak okazać, że praca na szybszym zegarze jest bardziej ekonomiczna niż na wolniejszym, ale to są wyjątki od ogólnej reguły przedstawionej powyżej"

    Dondu, dodałbym informację o tym, jakie to warunki, bo z tego się często korzysta. Przychodzi mi do głowy np. jedna typowa sytuacja: musimy cyklicznie wysyłać dane po rs'ie; nasz program przygotował już bufor danych do wysłania protokołem uart i tak właściwie wystarczy to wysłać i można iść spać. Wysyłamy więc 1. bajt, włączamy odpowiednie przerwanie od uarta i czekamy na przerwanie. W przerwaniach konsekwentnie wysyłamy kolejne znaki aż do ostatniego, po ostatnim usypiamy w "power down" i czekamy na wybudzenie przez rtc.
    W tym wypadku jak najwolniejszy zegar CPU nie musi być korzystny. Tu najlepiej jest wysyłać dane z jak największym baudrate'em rs'a (wysyłanie ramki trwa krócej, krótszy czas między przerwaniami od rs'a, sumaryczny czas włączenia modułu uart będzie krótszy) i trzeba dobrać taki zegar CPU, żeby ten baudrate dało się uzyskać (z dobrą dokładnością). Inna sprawa, że krócej wtedy trwa obsługa przerwań, czyli sumaryczny czas spędzony w trybie aktywnym jest krótszy (wykonana liczba instrukcji CPU będzie taka sama, ale ciągły pobór prądu przez peryferia będzie trwał krócej). Generalnie F_CPU trzeba dobrać doświadczalnie a w uC, które umożliwiają zmianę częstotliwości w trakcie pracy (np XMEGA) można się pokusić o kombinowanie ze zmianą F_CPU przed wykonywaniem pewnych zadań (np. praca na pełnym obrotach, gdy jesteśmy zasilani z zasilacza, a gdy wykryjemy zasilanie z baterii, przełączamy się na wolniejszy zegar i gdy tylko można usypiamy CPU w najmocniejszy możliwy w danym momencie tryb).

    OdpowiedzUsuń
  2. Każdy przypadek jest specyficzny i także Twój dlatego zawsze trzeba sprawdzać rezultaty eksperymentalnie.

    Inżynierowie Atmela pokazali przykład jak to robić, zmniejszając prędkość mikrokontrolera jednocześnie uzyskali:
    - zmniejszenie poboru prądu (dłuższy czas pracy na baterii),
    - zwiększenie prędkość transmisji (!).

    Zobacz drugą część artykułu: Bateria zasila mikrokontroler - cz. 2

    To właśnie pokazuje, że trzeba kombinować, i że nawet w takich przypadkach jak opisany przez Ciebie, zmniejszenie prędkości zegara może (nie musi) dać zarówno dłuższy czas pracy na baterii (mniejsze zużycie energii) jak i nawet zwiększenie szybkości transmisji danych, czyli coś przeciwnego niż opisujesz.

    Dlatego niczego nie należy zakładać z góry, tylko testować, testować ... testować. :-)

    OdpowiedzUsuń
  3. "Inżynierowie Atmela pokazali przykład jak to robić, zmniejszając prędkość mikrokontrolera jednocześnie uzyskali:
    - zmniejszenie poboru prądu (dłuższy czas pracy na baterii),
    - zwiększenie prędkość transmisji (!)."

    Oj Dondu, wprowadzasz ludzi w duży błąd, oni nie "uzyskali jednocześnie". Zmniejszenie clocka samo w sobie nie pociąga zwiększenia baudrate'u, wydaje mi się, że źle zrozumiałeś dokument ATMELa.
    Znam ten dokument, dlatego dziwiło mnie, że tak napisałeś. Inżynierowie ATMELA napisali:
    "Another approach to reduce power consumption is to reduce the time spent in active
    mode.
    In this application, the CPU is active while waiting for the UART transmission to end.
    We will calibrate the oscillator to a frequency that allows a higher baud rate on the
    UART to reduce the time spent in active mode"

    co oznacza, że ręcznie zwiększyli baudrate (właśnie po to, żeby CPU spędzał mniej czasu w trybie aktywnym), ale żeby "error rate" dla 115200bps był odpowiednio mały, zmienili częstotliwość oscylatora RC z 8MHz na 7.3728MHz, co po podziale przez 4 dało im 1.8432MHz zamiast wcześniejszych 2MHz. Zmniejszyli nieznacznie zegar, to prawda, ale tylko po to, żeby móc z większą dokładnością ustalić baudrate rs'a.

    "zmniejszenie prędkości zegara może (nie musi) dać zarówno dłuższy czas pracy na baterii (mniejsze zużycie energii) jak i nawet zwiększenie szybkości transmisji danych"
    Łączysz rzeczy, które same w sobie nie są powiązane.
    Mało tego, gdy zmniejszymy F_CPU np. z 8MHz na 2MHz nie ruszając przy tym np. baudrate generatora od uarta, to nie ma opcji, baudrate musi zmaleć.

    OdpowiedzUsuń
  4. "W bardzo specyficznych przypadkach może się jednak okazać, że praca na szybszym zegarze jest bardziej ekonomiczna niż na wolniejszym, ale to są wyjątki od ogólnej reguły przedstawionej powyżej."
    Bardzo rzadko opłaca się praca z niskim zegarem co zresztą wynika załączonego fragmentu dokumentacji:
    31k instrukcji / sekundę - 80 uA
    4000k instrukcji / sekundę - 1500 uA

    Oszczędzanie baterii wymaga, żeby uC głównie spał - wtedy pobierany prąd jest podobny, interesuje nas koszt pracy:

    Zakładamy, że na cykl pracy wykonujemy 1000 instrukcji, zużyjemy więc:
    1/31 * 80uA * 1s = 2.58uAs
    1/4000 * 1500uA * 1s = 0.375uAs
    (uAs - mikroamperosekunda, albo mikrokulomb)
    Czyli szybszy zegar pozwala na obniżenie zużycia energii w czasie pracy prawie 7 razy!

    Jeszcze lepiej gdy uC pozwala na łatwą zmianę zegara. Np na ARMie reagującym na zdarzenia zewnętrzne przychodzące po łączu szeregowym energooszczędnym rozwiązaniem okazała się praca z zegarem 24MHz i spanie z zegarem 96kHz pozwalającym na asynchroniczne odbieranie transmisji 9600bps.

    OdpowiedzUsuń
  5. cyt. "Czyli szybszy zegar pozwala na obniżenie zużycia energii w czasie pracy prawie 7 razy!"

    Rozpatrujesz pracę mikrokontrolera w oderwaniu od całego układu, na co zwracam w szczególności uwagę już na samym początku tego artykułu w punkcie: NIEROZERWALNY UKŁAD.

    Rozpatrywanie silnika w oderwaniu od pozostałej części samochodu jest podstawowym błędem przy analizowaniu tego wzajemnego powiązania.

    Ten sam silnik zastosowany w samochodzie sportowym oraz dostawczym będzie łącznie z całym pojazdem miały zupełnie inne właściwości.


    Warto zapoznać się z drugą częścią tego artykułu, gdzie opisany jest przykład realnego projektu oraz sposobu minimalizacji zużycie tak cennej energii . Jednym z tych kroków jest zmniejszenie prędkości zegara:

    Bateria zasila mikrokontroler - cz. 2

    Dlatego podkreślam jeszcze raz, że układ jest nierozerwalną całością i trzeba eksperymentować z całością układu, a nie tylko na sucho liczyć sam mikrokontroler.

    OdpowiedzUsuń
  6. Ze wszystkim tutaj się zgadzam, po za użyciem słowa "prędkość". Prędkość jest wektorem. Autorze, można jedynie stwierdzić, że "uc działa z szybkością" - szybkość to skalar. Częstotliwość taktowania przyrównywana do prędkości (szybkości) NIE MA zwrotu ani kierunku. Proszę na przyszłość pamiętać, gdyż myślę, że każdy fizyk który to czyta (a w gronie osób "lubiących to" jest 5 moich kolegów fizyków i ja w dodatku) chwyta się za głowę.

    OdpowiedzUsuń
  7. :D
    Dziękuję za słuszny wykład z fizyki. Poprawki oczywiście naniosę, by fizykom rąk nie fatygować i włosów trochę oszczędzić. Pozdrawiam!

    OdpowiedzUsuń

Działy
Działy dodatkowe
Inne
O blogu




Dzisiaj
--> za darmo!!! <--
1. USBasp
2. microBOARD M8


Napisz artykuł
--> i wygraj nagrodę. <--


Co nowego na blogu?
Śledź naszego Facebook-a



Co nowego na blogu?
Śledź nas na Google+

/* 20140911 Wyłączona prawa kolumna */
  • 00

    dni

  • 00

    godzin

  • :
  • 00

    minut

  • :
  • 00

    sekund

Nie czekaj do ostatniego dnia!
Jakość opisu projektu także jest istotna (pkt 9.2 regulaminu).

Sponsorzy:

Zapamiętaj ten artykuł w moim prywatnym spisie treści.