Mikrokontroler w głębokim uśpieniu pobiera nawet 1000× mniej prądu niż w trybie aktywnym — różnica między pojedynczymi µA a dziesiątkami mA. W praktyce decyduje, czy urządzenie IoT działa na jednym ogniwie 3 tygodnie czy 3 lata.

W Exa22 budżet energetyczny liczymy, zanim powstanie pierwszy wiersz kodu aplikacji — bo to architektura zasilania, nie optymalizacja na końcu, decyduje o żywotności urządzenia.

Budżet energetyczny przed pierwszym wierszem kodu

Wybór trybu uśpienia (sleep / stop / standby) decyduje, które peryferia zostają zasilone, a które gasimy. Duty cycling i bramkowanie zegarów peryferiów skracają czas, w którym CPU w ogóle pracuje, a dobór źródeł wybudzania — RTC, przerwanie GPIO, watchdog — sprawia, że rdzeń budzi się tylko wtedy, gdy naprawdę musi.

// wersja z podstawowego RTC
HAL_PWR_EnterSTOPMode(PWR_LOWPOWERREGULATOR_ON);
RTC_SetAlarm(&hrtc, WAKEUP_5MIN);

// pobór w tym trybie: ok 1.2 µA
// koszt: brak natychmiastowej reakcji na zdarzenia zewnętrzne

Mierzymy realnie, nie z noty katalogowej

Pobór profilujemy sprzętowo (np. Nordic PPK2, oscyloskop z bocznikiem) i z pojemności ogniwa wyliczamy spodziewaną żywotność. Dzięki temu „3 lata na jednym ogniwie” to liczba z pomiaru, a nie obietnica z prezentacji.

Rodziny MCU pod baterię: STM32L, nRF52, ESP32 — dobierane do profilu poboru.

Tryby uśpienia: sleep / stop / standby — świadomie, nie domyślnie.

Źródła wybudzania: RTC, przerwanie GPIO, watchdog.

Udostępnij

Michał Kozień

Embedded / firmware · exa22

Projektuje firmware dla urządzeń medycznych, lotniczych i IoT. Specjalizacja: ARM, STM32, ESP32, low-power.