[stm32L031] Jak najmniejszy pobór prądu i zliczanie impulsów

Witajcie,

Z nowym rokiem nowe wyzwania
Zwracam się do Was z pytaniem, czy moja koncepcja jest słuszna...
Otóż, potrzebuję zbudować urządzenie, które będzie zasilane bateryjnie (docelowo 2xAA), które ma tylko zliczać impulsy zewnętrzne w ciągu każdej godziny działania urządzenia. Po odliczeniu godziny ma te informacje przesłać po rs485 dalej.Tych impulsów może być od kilku na godzinę do nawet 10tyś/godzinę. Czas trwania impulsu to ok. 10ms.
Do zrealizowania zadania wybrałem procesor stm32l031 ze względu na dobry stosunek cena/możliwości/energooszczędność.
Po zapoznaniu z DS wymyśliłem, że procesor będzie pracował w trybie "Stop mode with RTC" ponieważ:
- pobiera 0,4uA
- LSE/LSI działają
-procesor można obudzić z trybu zatrzymania za pomocą dowolnej linii EXTI
- układ wyposażony jest w LowPowerTimer, który to działa w tym trybie i może być taktowany z LSE


Do taktowania LSE użyję kwarca zewnętrznego 32,768kHz i podam go na LPTIM. Reszta peryferiów będzie pracowała z MSI RC na np. 1.049MHz. Układ po inicjalizacji przejdzie w tryb STOP mode, jednocześnie LPTIM będzie odliczał 1s (docelowo do 3600). W czasie odliczania pełnej godziny będę zliczał przychodzące przerwania zewnętrzne.

CubeMX teoretycznie pozwala na taką kombinację:



Czy taka koncepcja ma szansę zadziałać prawidłowo?
Pytam, bo już zaczynam mieć wątpliwości, czy LPTIM to dobry wybór. W CubeMX jest bardzo uboga lista ustawień tego timera:



Nie ma tu choćby ustawienia wartości do przeładowania ARR jak w innych timerach:

LPTIM ma przecież:

Cytat:

External clock source over LPTIM input (working with no LP oscillator running,
used by Pulse Counter application)

Wydaje się to dużo lepszą opcją niż budzenie co przerwanie. Impulsy taktują timer, cały układ jest wyłączony, co godzinę budzisz układ przez RTC, odczytujesz licznik timera, odejmujesz od poprzednio odczytanej wartości, zapisujesz sobie odczytaną wartość na następny raz, wysyłasz wynik przez RS-485.

Freddie Chopin napisał:

LPTIM ma przecież:

Cytat:

External clock source over LPTIM input (working with no LP oscillator running,
used by Pulse Counter application)

Wydaje się to dużo lepszą opcją niż budzenie co przerwanie. Impulsy taktują timer, cały układ jest wyłączony, co godzinę budzisz układ przez RTC, odczytujesz licznik timera, odejmujesz od poprzednio odczytanej wartości, zapisujesz sobie odczytaną wartość na następny raz, wysyłasz wynik przez RS-485.

Freddie - w sumie to takie oczywiste, że brak mi słów dlaczego ja na to nie wpadłem...
Dzięki za naprowadzenie. Zabieram się za pisanie kodu...

Marek_Skalski napisał:

Zamiast alarmu z RTC, możesz też wykorzystać WakeUp Timer taktowany co sekundę, który przeładowujesz stałą wartością, w odróżnieniu od alarmu, który musisz aktualizować co godzinę.

Dziękuję za kolejną wskazówkę. Muszę zapoznać się ze wszystkimi funkcjami RTC

Marek_Skalski napisał:

Nawet jeżeli pojawi się 10000 impulsów na godzinę, to nie będzie przepełnienia licznika, więc pomiar będzie prawidłowy, a układ będzie pobierał minimalną ilość energii.

Przepełnienie licznika to nie problem - przerwanie od przepełnienia załatwi tą sprawę.

Obawiam się, że RS485 będzie pobierał ze 100 razy więcej prądu niż mikrokontroler.

BlueDraco napisał:

Obawiam się, że RS485 będzie pobierał ze 100 razy więcej prądu niż mikrokontroler.

Planuję sterować zasilaniem rs'a i włączać go tylko na czas wysłania danych.

Jeden z wątków, któremu radośnie się kibicuje, rozwija się, przepływają i kumulują się informacje.

Mam pytanie, jest STM32L031 w formie płytki? Pobieżnie szukając nie znalazłem.
Ja z tych nie lutujących VLSI.

JacekCz napisał:

Mam pytanie, jest STM32L031 w formie płytki? Pobieżnie szukając nie znalazłem.

Zależnie od tego jaki dokładnie model wybierzesz, są też wersje w przyjaznych obudowach - LQFP 48 (STM32L031C), TSSOP 20 (STM32L031F), LQFP 32 (STM32L031K - niektóre), czy UFQFPN 28 lub 32 (STM32L031G i niektóre STM32L031K). Jakby ktoś chciał napisać, że UFQFPN to jakaś masakra bez nóżek, to chciałbym naprawdę zachęcić do spróbowania - obudowę tą lutuje się łatwiej niż QFP czy cokolwiek innego z gęsto umieszczonymi nóżkami! Jedyny ból jest taki, że jeśli obudowa ma thermalpada to albo trzeba go olać, albo trzeba mieć hot-aira i pastę, albo może ktoś jest w stanie coś wycudować żeby go przylutować grotem i zwykłą cyną <:

Da się kupić malutką płytkę Nucleo-32 z tym układem - http://www.st.com/content/st_com/en/products/...val-tools/stm32-mcu-nucleo/nucleo-l031k6.html

Wracam do tematu

Na chwilę obecną mam uruchomiony LPTIMER i RTC. Wszystko pięknie mi działa - w trybie STOP timer zlicza impulsy zewnętrzne, RTC wybudza rdzeń po zadanym czasie.
Po wybudzeniu odczytuję z rejestru CNT timera liczbę zliczonych impulsów - i tutaj pojawia się mój problem. Chciałbym po odczycie, wyzerować rejestr CNT.
Rejestr CNT jest tylko do odczytu, jak można go wyzerować? Przeglądnąłem RM i nie znalazłem bezpośrednio informacji nt. ustawienie którego parametru LPTIMERA zeruje rejestr CNT.
Naprowadzicie gdzie znaleźć taką informację?

Marek_Skalski napisał:

Masz 2 możliwości.
- Zresetować licznik jako peryferium i ponownie go skonfigurować. Wtedy CNT przyjmuje wartość 0x0000, ale może zgubić przychodzący impuls.
- Nic nie resetować, tylko wyznaczyć różnicę miedzy wskazaniami - wykonać odejmowanie stanu aktualnego od stanu poprzedniego i ewentualnie skorygować wartość o limit przepełnienia.

Dzięki za szybką odpowiedź. Niestety, ale tak podejrzewałem, że tylko ponowna inicjalizacja zresetuje mi CNT...
Nie chcę przeliczać poprzez odejmowanie wartości poprzedniej, bo to mocno skomplikuje program. Musiałbym uwzględniać przepełnienia itp.
Spróbuję resetować licznik.

No fakt, 3 linijki więcej to poważna komplikacja...

korteksik napisał:

Nie chcę przeliczać poprzez odejmowanie wartości poprzedniej, bo to mocno skomplikuje program. Musiałbym uwzględniać przepełnienia itp.

No (;

difference = (new < previous ? 0xffff + 1 : 0) + new - previous; // 0xffff - max wartość timera, dla niektórych liczników może to być 0xffffffff

Komplikacja nie z tej ziemi <:

Wszystko fajnie, ale jeśli założymy, że układ ma pracować non-stop, to do jakich wartości zmiennych dojdziemy uwzględniając przepełnienia licznika po przekroczeniu zakresu?

Problem rozwiązałem resetując licznik i ponownie go inicjalizując - działa w 100%
Ale dziękuję za sugestie

Mam jeszcze chyba inny problem, ale muszę się upewnić że jest powtarzalny - jeśli nie znajdę rozwiązania, to jeszcze w tym wątku go opiszę.

Tymczasem dziękuję za pomoc!

korteksik napisał:

Wszystko fajnie, ale jeśli założymy, że układ ma pracować non-stop, to do jakich wartości zmiennych dojdziemy uwzględniając przepełnienia licznika po przekroczeniu zakresu?

No ale Ty masz zapisywać poprzednią wartość rejestru licznika - nie dojdzie więc nigdy do wartości większej niż 0xffff / 0xffffffff. Naprawdę nie ma tu problemu o którym myślisz.

Chyba nie rozumiem...
Załóżmy, że co godzinę lptim zaliczać będzie 20 tyś impulsów. W czwartej godzinie nastąpi przepełnienie, bo smarycznie przekroczę zakres 0xffff. Oczywiście mogę sobie zliczać przepełnienia i liczyć wszystko wg podanego wzoru. Tylko mi nie pasuje jakim cudem nie przekroczę zakresu nie resetujac cnt licznika.

Ale jaka wielkość Cię interesuje? Różnica między dwoma odczytami?Naprawdę nie wiem gdzie masz problem - chyba po prostu się zafixowałeś na problemie który nie istnieje.

Załóżmy że licznik sobie odczytujesz co 10000 cykli. W momencie odczytu masz więc wartości 0, 10000, 20000, 30000, 40000, 50000, 60000, [PRZEPEŁNIENIE], 4464, 14464, 24464, ... Po każdym odczycie i po obliczeniach zapisujesz sobie wartość którą właśnie odczytałeś w zmiennej `previous`. Przy każdym odczycie masz więc zarówno wartość aktualną, jak i `previous` - czyli to co było w CNT poprzednio.

Tak więc gdy odczytujesz licznik i ma on wartość 40000, to w `previous` jest 30000, gdy w CNT jest 60000, to w `previous` jest 50000, a gdy odczytałeś 4464, to w `previous jest 60000.

Magiczny wzór na różnicę (poprzednio się pomyliłem o jeden):

difference = (new < previous ? 0x10000 : 0) + new - previous;

Dla 3 przypadków które wymieniłem powyżej będziesz miał więc:
difference = (new < previous ? 0x10000 : 0) + new - previous = (40000 < 30000 ? 0x10000 : 0) + 40000 - 30000 = (false ? 0x10000 : 0) + 10000 = 0 + 10000 = 10000
difference = (new < previous ? 0x10000 : 0) + new - previous = (60000 < 50000 ? 0x10000 : 0) + 60000 - 50000 = (false ? 0x10000 : 0) + 10000 = 0 + 10000 = 10000
difference = (new < previous ? 0x10000 : 0) + new - previous = (4464 < 60000 ? 0x10000 : 0) + 4464 - 60000 = (true ? 0x10000 : 0) + (-55536) = 0x10000 + (-55536) = 10000

Może więc Ty wytłumacz gdzie tu widzisz problem, bo jak dla mnie to działa w nieskończoność jeśli tylko miedzy dwoma odczytami jest max jedno przepełnienie (Twój kod z resetami ma zresztą podobne ograniczenie, bo nie może być żadnych przepełnień).

Freddie Chopin napisał:

Może więc Ty wytłumacz gdzie tu widzisz problem, bo jak dla mnie to działa w nieskończoność jeśli tylko miedzy dwoma odczytami jest max jedno przepełnienie (Twój kod z resetami ma zresztą podobne ograniczenie, bo nie może być żadnych przepełnień).

Ok, przekonałeś mnie, że to zadziała. Ale tak jak napisałeś - pod warunkiem, że będzie tylko jedno przepełnienie.

Nie zgodzę się jednak, że rozwiązanie z resetem timera i inicjalizacją ponowną jest gorsze (dla mnie przynajmniej prostsze). Czemu? - Bo zliczam na wszelki wypadek przepełnienia w przerwaniu, dodaję zawartość odczytaną z CNT i mam wynik. Po odczycie mam wyzerowany CNT , zeruję zmienną przepełnień - i tak w kółko.

Na chwilę obecną tak działa i jest OK. Pobór prądu w czasie uśpienia mam na poziomie 1,19uA z włączonym LPTIMERem i RTC - czyli osiągnąłem to co chciałem.

Ale oczywiście jestem wdzięczny za pomoc i naprowadzenie na prawidłowe myślenie

Piotrus_999 napisał:

Chyba trochę uprościłeś.

No dobra - warunek jest taki, że pomiędzy kolejnymi odczytami nie może upłynąć więcej niż max jeden pełny okres timera, może być max jedno przepełnienie (;

Z testowaniem flagi przepełnienia można by niby wykombinować więcej, ale tu pojawiają się bardzo nieprzyjemne sytuacje brzegowe:
- jeśli odczytujesz najpierw CNT a potem flagę - jeśli odczytałeś 0xffff i flagę przepełnienia, to nie wiesz czy przepełnienie nastąpiło przed czy po odczycie z CNT;
- jeśli odczytujesz najpierw flagę a potem CNT - jeśli odczytałeś że nie było przepełnienia i 0, to nie wiesz czy na pewno nie było przepełnienia pomiędzy tymi dwoma odczytami;

Oczywiście i to da się wyeliminować (lub ewentualnie zignorować, tracąc minimalnie dokładność), ale tutaj zaczyna się to robić nadmiernie problematyczne już faktycznie, zwłaszcza jeśli jest założenie że odczyty będą "wystarczająco często".

korteksik napisał:

Nie zgodzę się jednak, że rozwiązanie z resetem timera i inicjalizacją ponowną jest gorsze (dla mnie przynajmniej prostsze). Czemu? - Bo zliczam na wszelki wypadek przepełnienia w przerwaniu, dodaję zawartość odczytaną z CNT i mam wynik. Po odczycie mam wyzerowany CNT , zeruję zmienną przepełnień - i tak w kółko.

Możemy się tak spierać, niemniej jednak:
1. rozwiązanie z resetem timera ma potencjał zgubienia impulsu/impulsów i nic z tym nie zrobisz;
2. rozwiązanie z resetem timera zajmuje więcej kodu źródłowego i trwa dłużej;
3. rozwiązanie z resetem timera jest bardziej skomplikowane niż ekstremalnie prosty warunek i dodatkowa zmienna;
4. rozwiązanie opisane przez Ciebie wymaga przerwania;

Freddie Chopin napisał:

Możemy się tak spierać, niemniej jednak:
1. rozwiązanie z resetem timera ma potencjał zgubienia impulsu/impulsów i nic z tym nie zrobisz;
2. rozwiązanie z resetem timera zajmuje więcej kodu źródłowego i trwa dłużej;
3. rozwiązanie z resetem timera jest bardziej skomplikowane niż ekstremalnie prosty warunek i dodatkowa zmienna;
4. rozwiązanie opisane przez Ciebie wymaga przerwania;

Zgadzam się w pełni

Generalnie cieszę się, że dzięki Waszym wskazówkom udało mi się uruchomić układ tak jak chciałem.
Zmierzę tylko jaki czas potrzebny na przeinicjalizowanie timera - ale jak na razie nie zgubił żadnego impulsu - a podaję mu 25 tyś imp/h.

korteksik napisał:

Zmierzę tylko jaki czas potrzebny na przeinicjalizowanie timera - ale jak na razie nie zgubił żadnego impulsu - a podaję mu 25 tyś imp/h.

Nie zmierzysz tego i nic z tego nie wywnioskujesz. Jeśli z impulsem trafisz dokładnie w ten moment w którym timer jest chwilowo zresetowany lub wyłączony, to nie zostanie on zarejestrowany. Możesz sobie co najwyżej wyliczyć prawdopodobieństwo że tak będzie, które oczywiście jest niezerowe (;

Cytat:

Nie zmierzysz tego i nic z tego nie wywnioskujesz. (;

Wydaje mi się, że jeśli po resecie timera ustawię sobie jakiś pin a po zakończonej inicjalizacji go zresetuję to analizatorem zmierzę ten czas - przynajmniej tak mi się wydaje. Chyba, że znowu czegoś nie wiem?

Źle się wyraziłem. Ten czas jest niezerowy ale to że jest o kilka rzędów wielkości mniejszy niż czas pomiędzy Twoimi impulsami jest bez znaczenia i wcale nie oznacza że nigdy nic nie zgubisz - tak jak pisałem, tutaj chodzi o prawdopodobieństwo że impuls przyjdzie akurat wtedy gdy Twój timer nie działa (bo go resetujesz lub ponownie inicjalizujesz). Prawdopodobieństwo to oczywiście jest dosyć małe, ale generalnie jeśli wyjdzie Ci jakiś ułamek, to spokojnie możesz sobie założyć że dokładnie taki ułamek impulsów zostanie zgubiony przez Twój algorytm. Jeśli nie jest to dla Ciebie problemem to oczywiście spoko, niemniej jednak akurat to jest problem który sam sobie stworzyłeś (;

Przyznaję rację, że liczenie i zastosowanie metody Freddiego działa rewelacyjnie!
Dzięki
W zasadzie wszystko działa tak jak zostało założone, ale...

Chciałbym Was zapytać o jeden mały problem - z którym sobie poradziłem - ale może można łatwiej...

Otóż, przy każdym przepełnieniu (to akurat rozumiem) oraz przy pierwszym zliczonym impulsie LPTIM wskakuje w obsługę swojego przerwania LPTIM1_IRQHandler. Problem w tym, że wybudza to procesor i wysyła mi po uarcie zliczone impulsy. Problem rozwiązałem ustawiając flagę w przerwaniu RTC i w mainie sprawdzam, czy wybudzenie jest od RTC czy LPTIM.
Czy jest jakieś lepsze rozwiązanie?