Jak często powinienem sprawdzać RTC?

11

Nie korzystałem jeszcze z RTC, więc nie jestem całkowicie pewien „normalnego” sposobu odczytywania zegara czasu rzeczywistego. Pomyślałem o kilku różnych podejściach, ale liczyłem na porady w tej sprawie.

Oto sposoby, w jakie do tej pory myślałem o czytaniu i wykorzystywaniu czasu:

Uzyskaj datę i godzinę przy włączaniu zasilania i zapisz w pamięci RAM, a następnie za pomocą przerwania czasowego zwiększaj wartości pamięci RAM co sekundę itp. Kod użyje wartości w pamięci RAM, ilekroć będzie potrzebować znać datę / czas.
Korzystając z przerwania timera, sprawdzaj RTC co sekundę i kopiuj otrzymaną datę i godzinę do pamięci RAM. Ponownie, kod używałby wtedy wartości w pamięci RAM, ilekroć potrzebował znać datę / godzinę.
Za każdym razem, gdy muszę znaleźć czas, zapytaj RTC i użyj jego odpowiedzi bezpośrednio.

Jakie byłoby najlepsze podejście?

microcontroller rtc

— użytkownik9993
źródło

15

Najlepszym podejściem jest takie, które spełnia Twoje wymagania przy minimalnym zużyciu zasobów. Ponieważ tak naprawdę nie znamy Twoich potrzeb, „najlepsze” ma dla nas bardzo małe znaczenie.

— Scott Seidman,

Wszystkie bardzo dobre odpowiedzi Nie mogę wybrać odpowiedzi!

— user9993,

23

Użyłbym czwartej opcji.

Większość układów RTC ma opcję wysyłania 1-sekundowego impulsu. Powinieneś podłączyć ten puls do wejścia umożliwiającego przerwanie w MCU.

Dostajesz czas z chipa raz na początku programu, a może odtąd od czasu do czasu - może raz na godzinę.
Sygnał przerwania wyzwala następnie procedurę przerwania w MCU, w której zwiększasz czas o jedną sekundę.

Taki układ zapewnia dokładność do sekundy RTC bez narzutu związanego z aktywnym czytaniem RTC.

— Majenko
źródło

5

Korzystając z tego podejścia, ważne jest, aby wiedzieć, które zbocze zegara reprezentuje przyrost, a także upewnić się, że wszelkie odczyty, które trwają podczas tego zbocza zegara, powinny zostać porzucone.

— supercat

Lub upewnij się, że odczyt jest wyzwalany tylko przez ISR - dostajesz sekundę na wykonanie odczytu przed uruchomieniem następnego ISR.

— Majenko,

Gdy tylko jest to możliwe, wolę ustawić zegary czasu rzeczywistego tak, aby działały szybciej niż jeden tik na sekundę i używać ich do pomiaru czasu zdarzeń ogólnego przeznaczenia, jeśli rozdzielczość RTC można ustawić wystarczająco dobrze, aby dopasować się do potrzeb dotyczących czasu zdarzenia; w związku z tym nie zawsze może wystąpić przerwa w każdym tiku RTC. Ponadto, ustawiając alarmy, często ważne jest, aby dokładnie wiedzieć, jaki jest czas RTC w momencie ustawiania alarmu, i odpytywać RTC, aby sprawdzić, czy poruszył się podczas ustawiania alarmu. Nie wiem, dlaczego 32-bitowi dostawcy układów nie oferują po prostu 47-bitowego licznika z możliwością odczytu albo ...

— supercat

... górne 32 bity lub dolne 31 plus stan wejścia zegara mają alarm, który można włączyć i wyłączyć w dowolnym momencie bez opóźnienia synchronizacji oraz rejestr alarmów, który można zapisać w dowolnym momencie, gdy alarm jest włączony wyłączone, z semantyką, że alarm występuje, jeśli wystąpi przyrost, gdy alarm jest włączony . Jeśli układ może zaakceptować asynchroniczne wybudzanie, a oprogramowanie w razie potrzeby dokładnie sprawdza odpytywanie, nie będzie wymagana żadna inna synchronizacja sprzętowa, a oprogramowanie nie będzie musiało obejść problemów spowodowanych przez inne formy synchronizacji sprzętowej.

— supercat

9

3. i 2. miejsce są bardziej opłacalne.

W większości przypadków używam trzeciego podejścia. Zaletą jest to, że nie muszę się martwić lustrzaniem RTC w pamięci RAM. Potencjalną wadą jest to, że zapytanie RTC przez magistralę szeregową wprowadza opóźnienie. Jeśli zapisujesz dane raz na sekundę, to opóźnienie prawdopodobnie nie będzie miało znaczenia.

Drugie podejście też jest dobre. Utrzymanie zegara lustrzanego może powodować błąd pomiaru czasu, jeśli urządzenie działa przez długi czas. Zegar lustrzany może dryfować poza RTC. Jeśli czytasz RTC regularnie, dryf nie będzie się kumulował.
Jednak odradzałbym wykonywanie komunikacji szeregowej w samej procedurze obsługi przerwań (ISR). Ustaw flagę w ISR i wykonaj komunikację szeregową w main ().

ps We wszystkich przypadkach korzystałem z DS1307.

— Nick Alexeev
źródło

6

Niektóre RTC (np. MC68HC68T1 [co prawda prawie nikt już nie powinien używać]) wstrzymują swoje wewnętrzne liczenie podczas odczytu, aby dać spójną odpowiedź. Należy je czytać tak rzadko, jak to możliwe , aby zminimalizować zakłócenia. Odczytaj je raz, a następnie użyj przerwań timera, aby zaktualizować wartość czasu przechowywaną w pamięci RAM MCU.

— Ignacio Vazquez-Abrams
źródło

Takie projekty oszałamiają umysł. Po odczytach, które występują podczas przyrostu, dane losowe byłyby łatwym problemem. Posiadanie odczytów powoduje, że pomijane są liczniki, to problem, którego nie można obejść inaczej niż poprzez zaakceptowanie utraconych liczników.

— supercat

2

Najwyraźniej podwójne buforowanie jest czymś, o czym niektórzy ludzie nie myślą przy projektowaniu układów.

— Ignacio Vazquez-Abrams,

Jeśli kod sprawdza podczas odpytywania, aby upewnić się, że wartość się nie zmieniła, nie ma potrzeby podwójnego buforowania. W przypadku zegara czasu rzeczywistego wbudowanego w układ takie odpytywanie z powtarzaniem do braku zmian będzie działać, nawet jeśli przerwanie próbuje odczytać kod RTC w tym samym czasie, co robi kod linii głównej. Niektóre projekty podwójnie buforowane utrudniają pisanie kodu linii głównej i kodu przerwania, które mogą bezpiecznie współistnieć, i nigdy nie widziałem takiego, który naprawdę uważałbym za „pomocny”.

— supercat

5

Zakładam, że RTC jest albo oddzielnym układem z własnym kryształem, albo modułem zintegrowanym z twoim mikrokontrolerem, który znowu ma oddzielne źródło czasu (takie jak kryształ 32 kHz) niż główny zegar. A źródło czasu dla RTC jest dokładniejsze niż źródło dla mikrokontrolera.

Aby określić, jak często trzeba czytać RTC, musisz dowiedzieć się, jaki maksymalny błąd może mieć Twój główny zegar. Na przykład, jeśli główny kryształ jest określony na 20 ppm, to tyle samo, co 0,002%. Tak więc zegar oparty tylko na głównym źródle zegara może dryfować 0,00002 * 3600 * 24 = 1,728 sekundy dziennie.

Więc jeśli czytasz RTC tylko dwa razy dziennie i pomiędzy zwiększaniem czasu raz na sekundę za pomocą przerwania timera, nigdy nie będziesz wyłączony dłużej niż sekundę - nigdy nie będziesz wyłączony dłużej niż sekundę w porównaniu do RTC.

Jeśli, jak wcześniej zakładałem, twój RTC jest albo oddzielnym układem z własnym kryształem, albo modułem zintegrowanym z twoim mikrokontrolerem, nie oznacza to, że jest poprawny. RTC może również mieć błąd. Na przykład, jeśli używa kryształu 32 kHz z tolerancją 5 ppm (które są nieco nieco droższe niż 10 ppm), może być wyłączony o 0,43 sekundy dziennie - lub 13 sekund miesięcznie.

Aby obejść ten problem, musisz nastroić RTC, w którym zapisujesz współczynnik korekty z powrotem do rejestru. W ten sposób można praktycznie zerować błąd. Ale oczywiście musisz mieć trzecie źródło zewnętrznego zegara, które będzie służyć jako odniesienie podczas strojenia. Bardzo dokładne odniesienie w USA jest linia 60 Hz AC, który gwarantuje się dokładnie 60 * 60 * 60 * 24 (5,184,000) cykli w ciągu 24 godzin między kolejnymi midnights. Aby było to przydatne, musisz mieć czas na całe 24 godziny, ponieważ 60 Hz może dryfować między północą.

Innym doskonałym odniesieniem czasowym byłoby użycie GPS (dokładność 10 ns), gdyby ktoś miał już sprzęt GPS w swoim projekcie.

Jeśli zamiast tego czasy RTC pochodzą z zewnętrznego źródła, takiego jak czas sieci komórkowej (połączenie AT + CCLK?) Lub z sieciowego serwera czasu korzystającego z NTP, możesz użyć wartości RTC w takiej postaci, w jakiej jest, ponieważ nie będzie można niczego dostroić .

— tcrosley
źródło