Jeśli twój kod nie działa, ponieważ prędkość zegara zmniejsza się, brzmi to tak, jakbyś utrzymywał wszystkie przerwane źródła przy życiu (zagnieżdżone przerwy) podczas obsługi procedury przerwania. Z włączonymi przez cały czas wszystkimi przerwaniami, wyskoczysz z jakiegoś kodu i przejdziesz do przerwania wyższego rzędu, jeśli taki wystąpi, powracając do przerwania niższego rzędu, gdy zakończy się przerwa najwyższego rzędu.

Może to prowadzić do poważnych problemów z synchronizacją, jeśli priorytety przerwania nie są odpowiednio zarządzane, szczególnie w przypadku portów komunikacyjnych, takich jak karta SD UART &. Jeśli założymy, że GPIO jest podłączone na zewnątrz twojego pudełka, wtedy przerwy GPIO będą się zdarzać "na życzenie" w rejestratorze danych i nie można ich przewidzieć, więc utrzymywanie tych procedur bardzo krótkich jest korzystne.

Może to prowadzić do ustawienia maksymalnej szybkości przełączania GPIO dla tych zewnętrznych pinów, dzięki czemu kod pozostaje ważny (na przykład maksymalnie 100 Hz na dowolnym zewnętrznym pinie wejściowym i maksymalnie 2 kHz na wszystkich wejściach).

Jeśli chcesz zredukować prąd, pracujesz w trybie aktywnym z wyższą częstotliwością zegara, zmieniając kod tak, aby wszystkie procedury były sterowane zdarzeniami i przechodziły w tryb uśpienia lub oczekiwania na resztę czasu, aby zmniejszyć prąd zasilania. Kilka mikrokontrolerów ma bardzo niski prąd w trybach oczekiwania o 75% trybu aktywnego (wyłączony procesor, włączone urządzenia peryferyjne), ale większość zmniejsza prąd tylko o ~ 20-30% z trybu aktywnego.

Jeden lub dwóch mikro dostawców może nawet utrzymywać urządzenia peryferyjne w trybach głębokiego uśpienia z szybkim wybudzaniem, ale większość mikro zwykle wyłącza wszystkie urządzenia peryferyjne w trybie głębokiego uśpienia i zezwala tylko na GPIO, WDT, POR , BOR lub RTC, aby obudzić mikro.

Zakładając, że nie musisz tracić czasu na czekanie w swoim procesorze, całkowite zużycie (energii) przez rdzeń procesora będzie funkcją całkowitej liczby instrukcji, które musisz wykonać, a nie szybkości zegara przy które są wykonywane. Ilość energii zużywanej przez rdzeń procesora, który jest aktywny przez 10% czasu przy częstotliwości 24 MHz, będzie często z grubsza porównywalna z ilością energii zużywanej przez rdzeń procesora, który jest aktywny przez 20% czasu przy 12 MHz.

Jeśli chip ma programowalny wewnętrzny VDD i może działać tylko z wyższymi prędkościami przy wyższych ustawieniach VDD, użycie tych wyższych ustawień prawdopodobnie zwiększy zużycie energii na instrukcję niezależnie od szybkości, z jaką procesor faktycznie wykonuje te instrukcje . Dlatego podkręcenie procesora powyżej progu, który wymaga wyższego VDD, będzie miało znacznie lepszy wpływ na zużycie energii niż podkręcenie go do punktu tuż poniżej tego progu.

Moją rekomendacją byłoby ustalenie w przybliżeniu jakiej prędkości potrzebujesz, ustal na podstawie tego, jakie VDD i inne ustawienia będą potrzebne, i ustaw zegar procesora na tak szybki, jak to możliwe, biorąc pod uwagę te ograniczenia. Następnie, gdy już to zrobisz, skoncentruj się na tym, aby procesor był bezczynny przez jak najdłuższy czas.

Odpowiedź supercat jest prawie taka, jak bym zasugerował, ale sprawdź również swój obwód pod kątem innych konsumentów, którzy pobierają prąd, gdy nie są potrzebni.

• Jeśli są zewnętrzne układy scalone, zobacz jeśli zapewniają tryb wyłączenia (jednym z kandydatów jest twój UART: jeśli masz przesuwnik poziomu, może być możliwe wyłączenie go przynajmniej częściowo podczas snu).
• Dzielniki napięcia, podciągnięcia lub pull-downs, sprawdź wszystko. Składniki pasywne są często ignorowane, ponieważ „nic nie robią”, ale pobierają prąd.

Zakładając, że masz elementy zewnętrzne, są szanse, że pobierają one więcej prądu niż mikrokontroler nawet zanim zoptymalizujesz napięcie, częstotliwość i czas aktywności. Jeśli to tylko prototyp, zobacz, czy możesz go przeprojektować pod kątem zoptymalizowanego zużycia energii.

Przy cyklu pracy 10:90 przy 12 MHz, wtedy około 1,2 MHz powinno dać 100% cykl pracy bez marginesu błędu. Wybierz współczynnik bezpieczeństwa w ramach swojego poziomu komfortu i pomnóż go przez 1,2 MHz.

Jeśli 10:90 jest szacunkiem, możesz zwiększyć nieco moc wyjściową, gdy MCU się obudzi, i ponownie obniżyć tuż przed zaśnięciem. Następnie możesz znaleźć czas pracy za pomocą oscyloskopu lub DVM, który może mierzyć częstotliwość i cykl pracy. Dokonaj powyższej regulacji i zmierz ponownie. Powtarzaj, dopóki nie osiągnie Twojego cyklu pracy, zużycia energii lub innego celu.

Moją strategią z wyboru w przypadku tego typu aplikacji jest stworzenie kodu sterowanego zdarzeniami (lub asynchronicznego) i nie przejmowanie się zbytnio częstotliwością zegara. Jeśli sterujesz systemem z przerwaniami (na przykład za pomocą timerów lub urządzeń peryferyjnych), możesz obniżyć poziom mocy MCU do pewnego rodzaju ustawienia hibernacji jako domyślnej akcji i zrobić coś innego tylko dla przerwań. mają poziomy snu, które włączają / wyłączają pewne przerwania budzenia. MCU ARM Cortex z serii M mają również zaawansowane możliwości przerwań, które dobrze komponują się z oszczędnością energii.

Gdy kolejka zdarzeń jest pusta, wykonaj domyślną akcję: przejdź na jakiś czas w tryb niskiego poboru mocy, w ten sposób częstotliwość zegara nie jest ważna, ponieważ jesteś tylko zasilany i zużywasz moc kiedy masz cokolwiek do zrobienia.