Autor: Dondu
Bateria zasila mikrokontroler - cz. 1
Bateria zasila mikrokontroler - cz. 2
Bateria zasila mikrokontroler - cz. 3
Na forum często spotykamy takie opinie osób budujących projekty zasilane baterią:
XXX napisał:
... tryby oszczędności niewiele tu pomogą.
... tryby oszczędności niewiele tu pomogą.
Poniżej przykład, co można osiągnąć za pomocą prostych zmian programowych.
Układ testowy
Inżynierowie ATMEL-a zbudowali układ testowy złożony z mikrokontrolera zasilanego z kondensatora, który wcześniej był załadowany ładunkiem z baterii, która jest podłączana tylko na okres ładowania kondensatora.
 |
| Źródło: ATMEL Corporation |
Program testowy
Inżynierowie ATMEL-a przygotowali program testowy, który składał się z:
- dokonanie pomiaru za pomocą ADC
- 1000 symulacji przetwarzania danych
- zamiana wyniku na znaki ASCII
- wysłanie danych za pomocą UART
- powrót do punkt 1
Taki program odzwierciedla średni poziom skomplikowania programów na mikrokontrolery, stąd stanowi wiarygodny punkt odniesienia do analizy otrzymanych wyników długości pracy na baterii.
Optymalizacja i rezultaty
Układ poddali kilku optymalizacjom tylko w zakresie programu:
- brak optymalizacji
- włączenie pull-up na nieużywanych pinach oraz wyłączenie nieużywanych wewnętrznych układów mikrokontrolera
- zmniejszenie prędkości zegara z 8MHz do 2 MHz
- użycie trybu pracy Power Save
- kalibracja zegara w celu zwiększenia prędkości transmisji danych
Osiągnęli następujące rezultaty:
 |
| Źródło: ATMEL Corporation |
Układ testowy zasilany z naładowanego kondensatora został poddany pomiarowi czasu jego działania.
Bez optymalizacji układ pracował zaledwie 8 sekund. Po kolei zastosowano cztery optymalizacje i końcowy efekt, to 217 sekund ! Mało?
Rezultat:
Czas pracy został wydłużony ponad 27 razy! Teraz wyobraź sobie, że Twoje urządzenie bez optymalizacji pracuje np. przez 1 miesiąc, a po tak prostych optymalizacjach 27 miesięcy (ponad 2 lata).
Albo inaczej: O ile mniejszą baterię możesz zastosować przy tym samym czasie pracy urządzenia!
Warto próbować? No to zobacz jak to zrobili inżynierowie ATMEL-a:
Cały eksperyment został opisany w dokumencie: AVR4013: picoPower Basics
Ubocznym zyskiem było zwiększenie prędkości przesyłu danych z 19.2kbps do 115.2kbps, pomimo zmniejszenia zegara z 8MHz do 1.87MHz (po kalibracji).
Czytaj następne
- Bateria zasila mikrokontroler - cz. 1
- Bateria zasila mikrokontroler - cz. 2
- Bateria zasila mikrokontroler - cz. 3
No jestem zaskoczony!
OdpowiedzUsuńdzięki za uwzględnienie mojego poprzedniego komentarza.
OdpowiedzUsuń"Ubocznym zyskiem było zwiększenie prędkości przesyłu danych z 19.2kbps do 115.2kbps, pomimo zmniejszenia zegara z 8MHz do 1.87MHz (po kalibracji)."
Tu wciąż nie o to chodzi. Wg mnie to nie był uboczny zysk, tylko celowe działanie. Oni najpierw celowo chcieli zmienić baudrate z 19200 na 115200, ale żeby dla 115200 mieć niską stopę błędu dobrali clock 1,87 MHz, bo dla tej częstotliwości da się tak ustalić odpowiednią wartość BAUD w baudrate generatorze, żeby uzyskać prawie dokładnie 115200. W datasheetach do zwykłych Atmeg jest zawsze na końcu działu o usarcie fajna tabelka z wartościami "error rates" dla poszczególnych baudrate'ów i częstotliwości głównego zegara. To o to chodzi.
Rozumiem, że nie chciałeś publikować mojego poprzedniego komentarza. W każdym razie dzięki, za uwzględnienie mojego wyjaśnienia.
Ja nie jestem cyborgiem z nieograniczonym czasem :D
OdpowiedzUsuństąd opóźnienia w publikacji komentarzy i odpowiedzi. Dlatego proszę o więcej cierpliwości.
Twój poprzedni komentarz, o którym piszesz powyżej, zamieściłeś w poprzedniej części tego artykułu, a konkretnie tutaj.
Ale bardzo dobrze, że kolejny komentarz umieszczasz w tej części artykułu, ponieważ Twoje uwagi właśnie tej części dotyczą (cz.2).
Konkretnie dotyczą punktu 5 na filmiku , który w nocie oznaczony jest numerem 5.5.
Masz rację, że sformułowanie w artykule nie do końca odzwierciedla treść noty Atmela i filmu. Poprawię je jeszcze dzisiaj.
Potwierdzam, że w tym punkcie najważniejszym celem było przyspieszenie transmisji danych, by skrócić czas pracy mikrokontrolera.
Natomiast dodatkowy zyskiem w tym punkcie, jest fakt zmniejszenia zużycia energii także poprzez zmniejszenie prędkości zegara. O tym w nocie (w punkcie 5.5) już nie napisano, ale taki zysk występuje.
Ale warto wyjaśnić dlaczego zwiększenie prędkości transmisji danych dało tak duży zysk na stratach energii?
Dzieje się tak dlatego, że w przykładzie z noty do sprawdzania, czy dana została wysłana, zastosowano pulling flagi UDRE0:
while(!(UCSR0A & (1<<UDRE0)));
czyli metody, w której mikrokontroler cały czas pracuje i czeka, aż USART zakończy wysyłać daną.
To bardzo nieefektywna metoda w przypadku projektów, które wymagają oszczędzania energii.
Gdyby natomiast zastosowano przerwania i w trakcie wysyłania danych mikrokontroler był uśpiony, to rezultaty eksperymentu byłyby inne, a zysk ze zwiększenia prędkości transmisji danych byłby niewielki.
Ja zrealizowałbym to zadanie od początku z wykorzystaniem przerwań, ale wtedy eksperyment ten w punkcie zwiększenie prędkości transmisji, nie dawałby tak znakomitych rezultatów w oszczędności energii.
Dlatego sądzę, że inżynier przeprowadzający ten pokaz, specjalnie używał pulling'u, by efekt był większy. Bardzo dobrze, że tak zrobił, bo przy okazji pokazuje to tym którzy boją się przerwań i stosują pulling, jak mają postępować.
Reasumując:
1. Punkt 5 realizuje przykład oszczędności na zużyciu energii poprzez przede wszystkim przyspieszenie transmisji do 115200 (szybko wysłać i uśpić uC jak szybko się da), ale przede wszystkim w przypadku stosowania pulling'u, a dodatkowo występuje oszczędność energii wynikająca z jeszcze niższej częstotliwości zegara taktującego mikrokontroler.
2. Nie należy stosować pulling'u tylko przerwania. Ograniczy to zużycie energii jeszcze bardziej.
BTW: Dla niektórych osób było zadziwiające, jak jest możliwe zmniejszenie częstotliwości zegara uC przy jednoczesnym zwiększeniu szybkości transmisji? No właśnie tak, jak w tym dokumencie Atmela i tabelce w datasheet, o której piszesz :D
"To bardzo nieefektywna metoda w przypadku projektów, które wymagają oszczędzania energii.
OdpowiedzUsuńGdyby natomiast zastosowano przerwania i w trakcie wysyłania danych mikrokontroler był uśpiony, to rezultaty eksperymentu byłyby inne, a zysk ze zwiększenia prędkości transmisji danych byłby niewielki."
Oj Dondu, znowu błąd. Rozważmy przykład dla uC ATmega128. Nawet jeśli realizujesz transmisję przerwaniowo, nie możesz uśpić CPU, bo w każdym trybie innym niż IDLE USART nie będzie działał i nie będzie też mógł wybudzić procka. Przerwaniowa transmisja przyda się co prawda, gdy już po wyzwoleniu wysyłania naszego buforka danych chcemy wykonać jeszcze jakieś operacje. Przy przerwaniowej realizacji możemy je wstawić w główny wątek i tylko co jakiś czas przerwanie od usarta będzie go wywłaszczać i "wypychać" kolejny znak ramki. Tylko wtedy jest zysk. I zgadzam się z tym, żeby wszystko co się da zawsze realizować przerwaniowo a zyskany czas CPU wykorzystywać na inne operacje.
Ale uśpić uC na czas wysyłania ramki nie możesz. Dlatego właśnie zysk z przyspieszenia baudrate'u jest i to wyraźny - mniej czasu spędzone w trybie IDLE.
My apologies, Już się poprawiam, bo napisałem bzdurę w poprzednio wysłanym komentarzu.
OdpowiedzUsuńMożna uśpić uC, ale w tryb IDLE (pomylił mi się wcześniej tryb IDLE z trybem bez jakiegokolwiek uśpienia), ale jest to najlżejszy tryb, w którym działa zegar peryferiów i działa wybudzanie np. przez usarta. W trybie tym pobór prądu jest tez znacząco większy niż np. w Power Save czy Power Down (odwołuję się tu do trybów obecnych w ośmiobitowych uC Atmela), bo w nich główny zegar CPU oraz prawie wszystkie peryferia są zatrzymane.
Reszta komentarza się zgadza, tzn. zwiększenie baudrate'u transmisji szeregowej owocuje skróceniem czasu przebywania w trybie IDLE (jeśli zrealizujemy transmisję przerwaniowo i po wysłaniu każdego znaku uC będzie wprowadzany w tryb IDLE), dzięki czemu można szybciej wprowadzić uC w głębszy tryb uśpienia (pewnie w większości przypadków będzie to Power Save i wybudzanie przerwaniem od RTC).
Podsumowując - tak, jak piszesz, inżynierowie Atmela mogli dodatkowo zrealizować wysyłanie ramki w sposób przerwaniowy i usypiać CPU po wyzwoleniu wysyłania każdego znaku, ale wg mnie główna oszczędność energii wciąż bierze się z tego, że po zwiększeniu baudrate'u można szybciej i na dłużej wprowadzać CPU w głęboki tryb uśpienia.
Proszę nie zarzucaj mi błędu gdy go nie popełniam, a w dodatku sam podajesz tryb, w którym takowe uśpienie jest możliwe bez szkody dla transmisji danych. Nigdzie nie napisałem, że ma to być Power Down, czy Power Save. Od tego jest odpowiedni tryby IDLE.
OdpowiedzUsuńI nie pisałem o wysyłaniu ramki w uśpieniu tylko danej. Proszę czytaj dokładnie.
Ponieważ mój komentarz po dodaniu ostatniego zdania wylądował pod Twoim, stąd dodam jedynie dla tych, którzy będą czytać, że zawsze trzeba eksperymentować i wybrać najlepsze możliwe rozwiązanie, o czym wspominam w artykule o baterii oraz w komentarzach do niego :-)
OdpowiedzUsuńTworzenie projektu dla urządzenia zasilanego z baterii gdy chcemy zmaksymalizować okres jego działania, to relatywnie skomplikowane zadanie zarówno od strony sprzętowej jak i programowej. Ja osobiście uwielbiam takie projekty, bo zmuszają do kombinowania wszelkimi możliwymi sposobami.
"Ja osobiście uwielbiam takie projekty, bo zmuszają do kombinowania wszelkimi możliwymi sposobami."
OdpowiedzUsuńZgadzam się, bardzo wdzięczne są takie zadania, tym bardziej, że trzeba też b. mocno uważać na pobór prądu przez wszystko, co jest wokół uC.
Mnie ciekawi co zrobić w układzie który zasila bateria z resyztorem podłączonym do nogi "reset" mikrokontrolera?
OdpowiedzUsuńDobre pytanie :-)
OdpowiedzUsuńSą dwa wyjścia:
1. Wyłączyć funkcję RESET danego pinu w Fusebitach, o ile się da w mikrokontrolerze, i o ile można to zrobić w danym urządzeniu, gdzie zastosowano ten mikrokontroler.
2. Zastosować rezystor o większej wartości np. 100k. Wtedy dla napięcia np. 3,3V prąd strat na rezystorze będzie wynosił około 33uA (mikroamperów). Można pokusić się o jeszcze większą wartość rezystora, ale wtedy jest większe prawdopodobieństwo, że ewentualne zakłócenia mogą powodować reset.
Zaraz zaraz. Coś mi się tutaj nie zgadza.
UsuńBo kto powiedział że do pinu reset wpływa prąd równy 3.3V/100k=33uA. Byłoby tak wówczas gdyby pin reset od środka procka był przyziemiony a przecież podejrzewam że jest on podpięty do modułu przerwań. Dokumentacja mówi że jest bufory wejściowy i wyjściowy skojarzony z tym pinem jest wyłączony wówczas gdy pin reset jest resetem. Priorytet przerwania - największy. Nie mierzyłem tego prądu ale podejrzewam że jest on dużo mniejszy niż piszecie bo wg mnie wchodzi w grę impedancja wejściowa modułu przerwań która podejrzewam że jest na tyle mała że ten prąd jest rzędy wielkości mniejszy niż piszecie.
Zrobiłem przed momentem próbę ale na procku zasilanym +5V gdzie do pinu reset podpięty mam zewnętrzny opornik 10k podciągnięty do tego +5V. Pobiera 138uA a to znaczy że jest to dużo mniej od oczekiwanego z prawa Ohma 5/10k=0.5mA.
UsuńWnioski:
Po odłączeniu od pinu reset procka (pin wisi w powietrzu) procek się nie resetuje - dokumentacja do np. AtTiny24A na stronie 38 (figure 8-1) pisze że wewnątrz i tak na resecie zabudowano rezystor podciągający.
A zatem jednym z wniosków jest wywalenie zewnętrznego podciągania na resecie a podłączenie tylko guzika.
Zobaczcie se też wykres zależności prądu płynącego przez wewnętrzny rezystor podciągający od częstotliwości i napięcia zasilania np. na stronie 190 dla procka AtTiny24A.
Jeśli ktoś istotnie chce wyeliminować ten pobór prądu to tak jak napisał Dondu musi kurcze włączyć fusa RSTDSBL i zrobić z tego alternatywną funkcję. A i tak nie wiadomo czy wyeliminuje ten prąd o którym mowa : ja obstawiam że może być ciężko.
Wszystko to o czym pisałem powyżej dotyczy trybów innych niż power down i standby (czyli dotyczy to trybów active i idle). Dla trybu power down jest tak że
Usuńzewnętrzne podciąganie pinu reset a nawet domyślnie włączone podciąganie wewnętrzne pinu reset nie mają wpływu na pobór prądu w trybie power down!! W trybie Idle jest już inaczej i chcąc w trybie idle uzyskać najlepsze wyniki należy między innymi pozbyć się zewnętrznego podciągania pinu reset a i tak przez wewnętrzne podciąganie (domyślnie na resecie załączone jeśli "reset jest resetem") będzie ssał prąd (ale to tylko moje podejrzenia). Można oczywiście wyeliminować funkcję reset poprzez ustawienie RSTDSBL ale nie wiem czy wpłynie to korzystnie na pobór prądu.
Ciekaw jestem czy ktoś z Was próbował sprawdzić jaki wpływ ma załączenie RSTDSBL na pobór prądu w trybie Idle albo Active. Jeśli ktoś takie testy będzie robić musi pamiętać oczywiście o tym że jeśli zaprogramuje RSTDSBL to już niskonapięciowym programatorem nie będzie mógł reprogramować procka.
Uprzejmie proszę o wyniki testów jak już ktoś takie testy zrobi to niech się pochwali podobnie jak ja uczyniłem. Dzięki z góry. Pozdrowienia dla wszystkich pozytywnie zakręconych :D
Dziękuję za drobiazgową analizę i zwrócenie uwagi :-)
UsuńFaktycznie moja uwaga w komentarzu powyżej dot. punktu 2 tj. dodania rezystora 100k jest nieprawidłowa co opisujesz, a ja podsumuję:
W sytuacji, gdy pin Reset jest włączony, w jego strukturze jest włączony specjalny układ filtru dolnoprzepustowego. Należy więc przyjmować to co producent opisał w nocie AVR042. Wskazuje on tam, że w momencie, gdy funkcja pinu Reset jest włączona oznacza to jednocześnie, że jest włączony wewnętrzny filtr RC z rezystorem pull-up o wartości podanej w dokumentacji mikrokontrolera. W przypadku ATmega8 szukamy parametru Rrst i znajdujemy, że ten rezystor ma wartość w dość szerokim przedziale 30-80kΩ. Dodanie więc zewnętrznego rezystora 100k oznacza połączenie równoległe, co de facto oznacza mniejszą wypadkową rezystancję.
Niestety brak informacji o wartości kondensatora w tym filtrze, ale za to jest informacja, że można dodać zewnętrzny kondensator, by zwiększyć stałą czasową filtru RC zmniejszając podatność urządzenia na zakłócenia.
Ale tutaj pojawiają się problemy dot. programowania tak przygotowanego układu (wprowadzone filtrem RC opóźnienie na pinie Reset może uniemożliwić programowanie). Dlatego każdy przypadek (projekt) należy indywidualnie rozpatrywać, bo inaczej zaprojektujemy urządzenie zasilane z malutkiej baterii sterujące malutką diodą, które ma pracować 10 lat, a inaczej urządzenie sterujące przekaźnikami i silnikami w dodatku w silnie zakłóconym otoczeniu. W pierwszym przypadku z rezystora możemy zrezygnować, a w drugim koniecznie dołożyć (+ jeszcze kondensator by filtr RC stworzyć) lub zamiast niego umieścić jumper i zworkę do Vcc lub wręcz RESET wyłączyć, by zabezpieczyć się na 100% przed przypadkowym resetem mikrokontrolera.
Podobnie z przypadkiem, gdy urządzenie jest prototypem, który wymaga ciągłych zmian programu, a inaczej urządzenie seryjne, które raz zaprogramowane i niewykorzystujące pinu Reset pozwala na wyłączenie tej funkcji.
Natomiast początkującym polecamy dodawanie tego rezystora, by ograniczyć ilość możliwych problemów podczas nauki, bo już wielokrotnie przekonaliśmy się, że nawet takie drobiazgi są przyczyną ich niepowodzeń, bo ścieżka była długa i indukował się impuls z cewki przekaźnika. głośnika, itp. Należy pamiętać, że polecamy zgodnie z producentem rezystor większy od 4,7k lub nawet 10k (ze względu na programatory), a wewnętrzny pull-up pinu reset ma 30-80k.
Reasumując, w zależności od założeń projektowych urządzenia i jego przeznaczenia, ten problem można/należy rozwiązywać na różne sposoby.
---------
RSTDSBL - zapisałem na listę by taki test wykonać - lista niestety jest baaardzo długa :-)
Słuchajcie, wycofuję się ze wszystkich stwierdzeń które napisałem powyżej ponieważ się pomyliłem. Prąd o którym pisałem że wpływa do pinu reset był mierzony przy podpiętym programatorze. Po wypięciu jest zerowy, nic tam nie wpływa.
UsuńZ początku myślałem że tam ciągle do tego reseta wpływa jakiś prąd więc podjąłem ten temat właśnie ze względu na optymalizację poboru prądu.
Kolega Dondu super to opisał, nic dodać nic ująć.
Teraz praktycznie nie ma tematu - no chyba że rzeczywiście komuś zależy na tym aby optymalizować zużycie tylko na "chwile resetowania" - wówczas te rozważania mają w ogóle sens.
Jeśli chodzi o "test" to oczywiście bezsensem byłoby wobec powyższego tego robić taki test. To chyba tyle. Przepraszam jeśli kogoś w błąd wprowadziłem (szczególnie tych początkujących), na przyszłość najpierw dłużej pomyślę a potem będę pisał posty na stronce.
Po pierwsze każdy popełnia błędy, a po drugie Twoje wątpliwości pozwoliły na doprecyzowanie mojego komentarza dot. rezystora 100k. :-)
UsuńHaha, no w sumie masz rację :) Ale przeprosić musiałem - bo mogłem wprowadzić niektórych w błąd. I skreśl proszę z listy ten test, jeśli w ogóle go wpisałeś na swoją listę... ;) Bo wcale bym się nie zdziwił jeśli nie wpisałeś... ;)
UsuńPozdrawiam i życzę miłego dnia.
Wpisałem, ale nie skreślę :-)
UsuńWzajemnie!
:-)
Ciekawe informacje, człowiek to się uczy jednak całe życie :)
OdpowiedzUsuń