fbpx

Może nie każdy wie, ale zegary czasu rzeczywistego, czyli RTC są tak dokładne, jak dokładne jest ich źródło taktowania. Najczęściej układy takie napędzane są częstotliwością 32,768 kHz. STM32 posiada wbudowany układ RTC jednak jego tyczy się dokładnie ta sama zasada, jeżeli chodzi o dokładność. Na ogół to, co oferuje STM32 jako wewnętrzny oscylator RC dla RTC nie jest najwyższej jakości i jest podatny na zmiany temperatury. Podpinając zewnętrzny rezonator kwarcowy również nie możemy zapewnić tego, że będzie on działał identycznie w każdej możliwej temperaturze. Czy jest jakieś rozwiązanie? Tak – kompensacja temperaturowa częstotliwości oscylatora.

Ale halo, halo! Można przecież skompensować różnice w częstotliwości ręcznie. Tak. Można dokonać tzw. kalibracji częstotliwości oscylatora. Jest to proces lekko skomplikowany i niedający gwarancji w każdych warunkach. Nie pomaga również stosowanie tanich rezonatorów kwarcowych. Ich charakterystyka błędu do temperatury wygląda tak (z dokumentacji RTC STM32F103):

Przy temperaturze otoczenia ok 0°C dokładność spada poniżej -20 ppm. Według kalkulatora błąd na tym poziomie daje opóźnienie 1,73 sekund/dzień, czyli 10,51 minut/rok. Komu chce się co miesiąc nastawiać zegar? Mniejszy problem jest, gdy układ RTC ma cały czas zbliżone warunki jak np. w mieszkaniu. Wtedy można ratować się kalibracją programową. Co, jeżeli znajduje się w urządzeniu zewnętrznym? Powiedzmy, że zamontowany jest zimową porą w infobudce z ogromnym, grzejącym się wyświetlaczem. W słoneczny zimowy dzień, gdy budka jest czynna temperatura w skrzyni elektroniki powiedzmy, że za dnia w skrajnym momencie ma 40ºC dając błąd na poziomie -10 ppm. Gdy zbliża się wieczór, układ schładza się powoli jadąc po charakterystyce w lewą stronę. Fajnie, bo błąd się przez jakiś czas zmniejsza. Niestety w nocy, gdy urządzenie jest uśpione temperatura spada do -5ºC i dokładność oscylatora wynosi -30 ppm. Czy jesteśmy w stanie idealnie kompensować programowo takie błędy? Pewnie możemy ale komu by się chciało…

Zwłaszcza wiedząc, że za niewielkie pieniądze można mieć układ RTC, który skompensuje takie błędy automatycznie. Jednym z takich precyzyjnych układów na rynku jest DS3231.

DS3231 – ekstremalnie dokładny RTC

Panie Mateuszu dokładny to znaczy jaki? Według dokumentacji jest to:

  • ±2 ppm dla temperatur 0 ÷ +40ºC
  • ±3,5 ppm dla temperatur -40 ÷ +85ºC

Wpisując 2 ppm w przytoczony wyżej kalkulator wychodzi, że DS3231 w ciągu roku spóźni się o… minutę. Codziennie będzie to 0,17 sekundy. Jest to do przeżycia? O wiele bardziej niż 10 minut rocznie! Jest to bardzo dobry wynik.

Jak to się dzieje, że jest taki dokładny? Otóż układ Maxim’a ma zintegrowany oscylator kwarcowy razem z kwarcem. Oscylator dodatkowo posiada temperaturową kompensację temperatury. Sprawia to, że producent ma pod kontrolą wszystkie najważniejsze komponenty, które decydują o dokładności. Dzięki kompensacji wyciska z nich swoiste maksimum czego efektem są te ±2 ppm. 

W Polsce dokładne testy kompensacji DS3231 przeprowadzał Mirek Kardaś. Pozwól, że ja nie będę popalał układu podłączonego do oscyloskopu 🙂

Najważniejsze rzeczy ze specyfikacji

Oprócz dokładności mogą zainteresować Cię jeszcze inne rzeczy. Najważniejsze jest chyba to, jak układ łączy się z mikrokotrolerem. Interfejsem komunikacyjnym jest I²C więc prościzna. Oprócz pinów SDA i SCL nasz RTC ma jeszcze kilka innych wyjść.

Jak to bywa w układach zegarowych chcielibyśmy mieć możliwość podłączenia baterii dla podtrzymania pomiarów. Tutaj jest dedykowany pin, a wewnątrz obudowy znajduje się układ detekcji zaniku zasilania i automatycznego przełączenia na zasilanie bateryjne.

DS3231 ma dwa wyjścia zegarowe. Jedno jest to 32,768 kHz prosto ze wbudowanego oscylatora z kompensacją temperaturową i nazywa się 32kHz. Źródło to idealnie nadaje się do taktowania innych układów w trybie niskiego poboru mocy.

Jest jeszcze jedno wyjście zegarowe. Znajduje się ono na pinie z podwójną funkcją o nazwie INT/SQW. Tutaj jest możemy dostać jedną z czterech programowalnych częstotliwości: 1Hz, 1024 Hz, 4096 Hz lub 8192 Hz. Jest to odpowiednio podzielona częstotliwość oscylatora.

Drugą funkcją pinu INT/SQW jak wskazuje pierwszy człon nazwy są przerwania. Według dokumentacji przerwanie wystawiane jest wtedy, gdy aktywny jest alarm oraz nadejdzie jego czas. Czy ktoś używa alarmów?

Co ważne – obydwa wyjścia zegarowe są typu Open Drain. Trzeba założyć in rezystory podciągające, które na szczęście w gotowych modułach już są położone na PCB.

W jaki sposób przechowywany jest czas i data? Oczywiście znajdują się tutaj rejestry godziny, minut i sekund. Jeżeli chodzi o kalendarz to jest on w miarę rozbudowany. Oprócz roku, miesiąca i dnia jest jeszcze: dzień tygodnia, stulecie czy obsługa roku przestępnego.

Schemat i oprogramowanie

Dzisiaj skorzystam z płytki Nucleo z STM32F410RB którą otrzymałem od firmy Kamami, za co bardzo dziękuję! 🙂

Podłączenie modułu do Nucleo jest jak zwykle banalnie proste. Potrzebujesz podłączyć jedynie piny I²C oraz pin INT/SQW dla przerwania z RTC.

Do oprogramowania oczywiście skorzystałem z STM32CubeIDE w wersji 1.0.2. Biblioteki HAL F4 są w wersji 1.24.1. Jazda!

Mógłbym pokazać Ci klasyka, czyli chamskie i blokujące czytanie z RTC co jakiś czas w pętli main. Lepszym rozwiązaniem byłoby oczywiście czytanie w przerwaniu od RTC, które następuje co sekundę. Jednak takie chamskie, blokujące czytanie w przerwaniu też nie jest rozwiązaniem optymalnym…

Pamiętaj, że STM32 posiada takie coś, jak DMA którego jestem ogromnym fanem. Przecież nie musisz czekać bezczynnie, kiedy wykonuje się komunikacja po I²C. Zebraniem danych może zająć się właśnie DMA, a CPU wejdzie później do przekonwertowania BCD na DEC. Pokażę Ci porównanie pod koniec.

Konfiguracja i obsługa DMA pod RTC

Po pierwsze musisz skonfigurować interfejs I²C. Ja wybrałem I2C1. Wybierz prędkość interfejsu. Ja polecam 400 kHz, zwłaszcza że DS3231 obsługuje tryb Fast Mode. Jeżeli Twój mikrokontroler nie może pracować z takim zegarem, może być klasyczne 100 kHz. Piny, które wolisz. Ja ustawiłem na PB9 i PB8, ponieważ są wyprowadzone na złącze Arduino. Dzięki temu w piny Morpho mogę wpiąć się analizatorem stanów logicznych.

Kolejną rzeczą, jaką musisz ustawić jest DMA dla naszego interfejsu I2C1. Możesz zrobić to wygodnie z poziomu konfiguracji I²C. Ustaw DMA zarówno na odbiór, jak i nadawanie. 

Do podglądu danych z RTC skonfiguruj jeszcze klasycznie UART2, który jest wyprowadzony na USB ST-Linka. Ja pozostawiam standardowe wartości, czyli 115200 8n1.

Będziesz jeszcze potrzebował pinu do obsługi przerwania od układu DS3231. Możesz ustawić dowolny GPIO na funkcję GPIO_EXTI. U mnie wybór padł na pin PA9. Nazwij go DS3231_INT i ustaw reakcję na zbocze opadające. Tak naprawdę nie ma znaczenia, na które ustawisz 🙂 Ważne, aby na jedno z dwóch, aby niepotrzebnie nie czytać dwukrotnie tej samej godziny. Pamiętaj również o włączeniu przerwania od właściwego EXTI w CubeMX!

Zegar możesz ustawić domyślny 84 MHz, jeżeli generowałeś projekt “z płytki”, a nie po wyborze MCU. Jeżeli masz inaczej, to wklep 84 w miejsce HCLK, abyśmy mieli spójne projekty. Po tak skonfigurowanym projekcie możesz go zapisać i wygenerować kod. Pamiętaj też o zaznaczeniu generowanie oddzielnych plików dla każdego z peryferium.

Kod

Przygotowałem prostą bibliotekę dla DS3231. Nie jest to majstersztyk, który obsługuje każdą funkcję układu. Pominąłem w niej alarmy oraz odczyt temperatury układu (skoro jest kompensacja temperaturowa to i jest możliwość pomiaru temperatury). Myślę, że najważniejsze i najbardziej użytecznie jest i tak czytanie godziny i daty. 

Interesować Cię będzie jeden lub dwa define’y. Są to #define DS3231_USE_DMA#define DS3231_ADDRESS (0x68<<1). Pierwszy, jeżeli jest odkomentowany, wybiera funkcję do czytania z RTC przez DMA. Jeżeli jest zakomentowany, będzie działał z klasycznymi, blokującymi.

Drugi define natomiast jest adresem układu. Moduł bez zworek ma adres 0x68. Jeżeli masz lub położyłeś zworki, będziesz musiał zmienić tę linijkę według swojego adresu.

Przejdźmy do funkcji, które Cię interesują. Pierwszą z nich jest oczywiście inicjalizacja.

void DS3231_Init(I2C_HandleTypeDef *hi2c);

Podajesz w niej handler do wybranego interfejsu I²C. Wewnątrz inicjalizacji wstawiłem funkcje ustawiające przebieg o częstotliwości 1 Hz na wyjściu SQW oraz wyłączam wyjście 32 kHz.

Kolejną ważną funkcją jest ustawianie zegara.

void DS3231_SetDateTime(RTCDateTime *DateTime);

Jako argument podaje się wskaźnik do przygotowanej wcześniej struktury RTCDateTime, która jest zdefiniowana w bibliotece DS3231.

typedef struct
{
	uint16_t Year;
	uint8_t Month;
	uint8_t Day;
	uint8_t Hour;
	uint8_t Minute;
	uint8_t Second;
	uint8_t DayOfWeek;
}RTCDateTime;

Ostatnim ważnym elementem jest odebranie danych z RTC i przekonwertowanie ich do struktury RTCDateTime. W zależności od tego, jaki rodzaj obsługi układu wybierzesz będziesz miał do wyboru w przypadku blokującej/przerwań:

void DS3231_GetDateTime(RTCDateTime *DateTime);

Ta funkcja pobierze przez I²C dane oraz wrzuci je do zmiennej spod wskaźnika *DateTime.

No i najważniejsze z perspektywy obsługi przez DMA. Funkcje odbierające dane oraz wrzucające je do struktury.

void DS3231_ReceiveDateTimeDMA(void);
void DS3231_CalculateDateTime(RTCDateTime *DateTime);

Dlaczego dwie? Już tłumaczę.

Odbiór DMA

Funkcję DS3231_ReceiveDateTimeDMA wykorzystałem w przerwaniu EXTI, które generuje układ RTC dzięki sygnałowi 1 Hz na wyjściu SQW. Jej zadaniem jest wystartowanie odbioru z DS3231 przez DMA wszystkich danych dotyczących godziny i daty. Na szczęście producenci układów RTC umieszczają te dane jedna za drugą.

Gdy odbiór się zakończy, zostanie wywołane przerwanie od zakończenia odbioru DMA. Tam właśnie wsadziłem funkcję DS3231_CalculateDateTime rozpakowującą odebrane dane na wartości godziny i daty. 

To tyle filozofii 🙂 Jak te funkcje wykorzystać w przerwaniach? Musisz nadpisać domyślne funkcje _weak, które posiadają biblioteki HAL. Ja zrobiłem to w pliku main i wygląda to następująco:

/* USER CODE BEGIN 4 */
void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)
{
  if(GPIO_Pin == DS3231_INT_Pin)
  {
    DS3231_ReceiveDateTimeDMA();
  }
}

void HAL_I2C_MemRxCpltCallback(I2C_HandleTypeDef *hi2c)
{
  DS3231_CalculateDateTime(&r);
}
/* USER CODE END 4 */

I to tyle! Prawda, że proste?

Efekty działania, prędkości

Jeżeli czytasz mnie nie pierwszy raz to wiesz, że lubię sprawdzić czasy wykonywania się kodu, a zwłaszcza czas pracy samego CPU. Tym razem również nie odpuszczę!

Na pierwszy ogień pokażę Ci jak wygląda blokujący odbiór danych z DS3231. Najpierw 100 kHz.

i 400 kHz

Hmm… 920 µs i 237 µs. Patrząc, że kod ten wykonuje się dokładnie co sekundę, można łatwo policzyć, że odczyt przy 100 kHz zajmuje 0,92% czasu procesora, a dla 400 kHz jedyne 0,23%. Kurde, Salamon czego Ty jeszcze chcesz od tego?

Zauważ, że CPU oczekuje bezczynnie na odebranie danych z I²C. To oznacza, że jest jeszcze niewielkie pole do poprawy i to dzięki DMA. Efekt mojego kodu z DMA prezentuje się tak:

100 kHz400kHzTeraz są dwa krótsze odcinki w których jest potrzeba, aby użyć CPU. Pierwszy to zlecenie odbioru DMA, drugi to sama konwersja BCD do DEC i przypisanie do zmiennej strukturalnej. Aby policzyć czas zajęcia CPU, trzeba je zsumować co jest zadaniem prostym. Tak oto dla 100 kHz suma to 301 µs, a dla 400 kHz jedyne 85 µs. W przeliczeniu na % czasu procesora to odpowiednio 0,3% i 0,08%.

W obu przypadkach mamy do czynienia z około 3-krotnym zyskiem. Może być? Myślę, że tak 🙂 Taka operacja, jak odczytanie godziny powinna być jak najmniej obciążająca dla systemu. Ten w końcu musi zajmować się poważniejszymi rzeczami.

Podsumowanie

Mam nadzieję, że jeżeli nie byłeś to, choć przekonałeś się do wysokiej dokładności zegara RTC, jakim jest DS3231. Choć mam wrażenie, że przydałoby się jeszcze jakieś porównanie do innych układów jeżeli chodzi o dokładność pomiaru czasu. Mam już pewien pomysł 🙂

Przyznaj też, że dałem Ci kolejny powód na to, aby korzystać z DMA. Nawet w tak – jakby się wydawało – banalnych sytuacjach warto to robić.

A Ty co myślisz o takim RTC? Warto taki kupić? O dziwo moduły czasami są tańsze niż inne, mniej dokładne układy, które potrzebują jeszcze kilku komponentów wokół. Sprawdź moduły RTC u mnie sklepie. Kupując u mnie, wspierasz rozwój bloga oraz dostajesz super naklejkę np. na laptopa 😉

Pełny projekt wraz z biblioteką znajdziesz jak zwykle na moim GitHubie: link

Jeśli zauważyłeś jakiś błąd, nie zgadzasz się z czymś, chciałbyś coś dodać istotnego lub po prostu uważasz, że chciałbyś podyskutować na ten temat, napisz komentarz. Pamiętaj, że dyskusja ma być kulturalna i zgodna z zasadami języka polskiego.

5/5 - (7 votes)

Podobne artykuły

.

18 komentarzy

Piotr · 18/07/2023 o 13:09

Jeszcze jedna informacja: układ DS3231 ma rejestr o nazwie Aging Offset, który ma służyć do korekty częstotliwości oscylatora po zestarzeniu się kwarcu (?). Jest tam wpisana wartość 0, a może być od -128 do 127.Według dokumentacji, korekta polega na dołączeniu (albo odłączeniu dla wartości ujemnych) dodatkowej pojemności do rezonatora. Powoduje to zmianę częstotliwości o 0.1 ppm na każdą jednostkę tego rejestru w temperaturze 25 stopni. Korekta ma większy efekt w temperaturach innych niż 25 stopni. Zmieniłem wartość Aging Offset w zegarze DS3231 który spieszył się 36 milisekund na dobę z zera na 4. Po jednej dobie zegar spieszy się 12 milisekund, czyli pomogło. Ale wykres zależności korekty od Aging Offset i temperatury jest dosyć skomplikowany według dokumentacji – nie wiem, czy przy innych temperaturach nie będzie gorzej.
Teraz zegarek DS3231 + GPS działa na Arduino Uno ze standardowym wyświetlaczem niebieskim 2×16 znaków “LCD shield”. Poskładam jeszcze jeden podobny zegarek, ale na STM32 BlackPill, DS3231, GPS i z wyświetlaczem matrycowym LED 64*8 punktów (osiem modułów 8×8 ze sterownikami MAX7219). Odbiornika DCF77 chyba tam nie będzie, bo podczas testów nie udało mi się ani razu uzyskać sensownej informacji o czasie. A na początek chciałem tylko wykryć pojedynczy impuls 100 ms albo 200 ms. Zamiast tego dostaję chaotyczny przebieg (szum?), z którego nic nie wynika. Rozważałem jeszcze użycie modułu GSM do synchronizacji czasu w pomieszczeniach, gdzie niedostępny jest GPS. Ale to chyba nie ma sensu – nie ma gwarancji dokładności odebranego czasu i nawet nie jestem pewny, czy dałoby się to zrobić “za darmo”, to znaczy bez konieczności rejestrowania numeru i logowania się do sieci.

Piotr · 18/07/2023 o 01:37

Ciąg dalszy informacji o zegarze. Jeden zegar z DS3231 (ale bez GPS) zrobiłem już dawno temu, w październiku 2014 roku. Zrobiłem, ustawiłem dokładnie i zostawiłem na półce. Na dziewięć lat. Wczoraj włączyłem go ponownie (bateryjne jest tylko podtrzymywanie czasu w DS3231, reszta wymaga zasilania zewnętrznego). Zegar wciąż działał, po 9 latach – bez wymiany baterii 2032 w module DS3231. Porównałem wskazanie czasu. Okazało się, że zegar spieszy się o 32 sekundy.W ciągu dziewięciu lat! To oznacza niedokładność rzędu 10 milisekund dziennie. Ustawiłem ten moduł DS3231 w nowym zegarku z GPSem. Przełożyłem z powrotem do starego zegara, porównałem czas z wyświetlanym przez time.is i było idealnie. Włączyłem stary zegar ponownie dzisiaj (po niecałej dobie) i okazało się, że spieszy się pół sekundy! Jak to możliwe? Taki błąd powinien pojawić się dopiero po 50 dobach, a nie po jednej. Nie wiem, dlaczego tak się stało.
Pojawił się problem przy odczycie czasu z modułu GPS. Okazuje się, że po starcie i synchronizacji czasu z satelitami (co objawia się pojawieniem się sygnału 1 Hz na wyjściu PPS i wysyłaniem informacji o czasie), podawany czas wyprzedza właściwy czas UTC o 3 sekundy. Dopiero po kilku minutach czas jest właściwy. Przy czym nie zmienia się taktowanie sekund, sygnał PPS cały czas ma 1 Hz..Te trzy sekundy to wina trzech sekund przestępnych, które wprowadzono od roku 2011 (z którego prawdopodobnie pochodzi projekt odbiornika). Informacja o tych sekundach jest przekazywana, ale dopiero po długim czasie. I nie wiem jeszcze, jak odróżnić czas z korektą od czasu bez korekty.

Piotr · 16/07/2023 o 00:59

To jest wątek sprzed trzech lat, ale może ktoś to jeszcze przeczyta. Właśnie sobie robię taki zegarek z DS3231 (gotowy moduł z pamięcią) z założeniem, że ma wyświetlać czas z dokładnością i rozdzielczością 1/10 sekundy. Poskładałem to na razie z pięciu części: Arduino Uno, LCD shield (2×16 znaków i kilka klawiszy), moduł DS3231, moduł GPS z wyjściem PPS oraz odbiornik DCF77. Jak już będzie wszystko sprawdzone, wymienię LCD na duży wyświetlacz LED (albo podłączę dodatkowo). Działa to tak, że głównym wzorcem czasu jest DS3231. Na życzenie użytkownika wykonywana jest synchronizacja z czasem GPS. Procedura czeka na impuls PPS z GPS (zbocze narastające), odbiera komunikat czasu z GPS, dodaje jedną sekundę do odebranego czasu, czeka na następny impuls PPS i ustawia zegar DS3231. Uwaga: sekundy w DS3231 przełączają się na opadającym zboczu sygnału SQW, więc nie jest obojętne, na jakie zbocze reagujemy (jak napisane jest wyżej w tekście). Zapis sekund do DS3231 powoduje synchronizację momentu zmiany sekund. Możliwe jest też sprawdzenie różnicy czasu między GPS a DS3231. Według testów, mój egzemplarz spóźnia się 36 milisekund na dobę (dosyć dokładnie tyle w kolejnych dniach). Czas na wyjściu PPS z GPS jest bardzo dokładny – według dokumentacji 40 nanosekund. Różnicę wskazań GPS i DS3231 mierzę funkcją millis() z Arduino, tak więc dokładność nie jest zbyt duża. Ale wystarczająca, żeby wykryć stale rosnące odchylenie 36 milisekund na dobę. W Arduino mam włączone przerwania 40 Hz (timer1), żeby odliczać dziesiąte części sekundy. Podczas przerwania bada się zmianę stanu SQW i jeśli zmienił się z 1 na 0, zeruje się licznik czterdziestych części sekundy. Odbiornik DCF77 jest podłączony, ale na razie nieużywany. Sygnał DCF77 jest dosyć niestabilny. Poza tym, nadajnik jest 1000 kilometrów stąd – wprowadza to opóźnienie ok.3 milisekund. To jednak można skorygować znając pozycję z GPS. Sygnał DCF77 miałby być używany, jeśli przez dłuższy czas nie zostanie wykonana korekta GPS. Niestety odbiór GPS wymaga wyniesienia całego zegara na otwartą przestrzeń – co jest niewygodne, jeśli miałby np. wisieć na ścianie. DCF77 mógłby być odbierany również w pomieszczeniu. Docelowy wyświetlacz LED ma być niemigający (bez multipleksowania), żeby dało się np. nagrywać filmy z wysokim fps i dokładnie oznaczać czas. To będzie trochę niestandardowe, bo wszystkie moduły wyświetlaczy LED są multipleksowane. Może będzie to oddzielny układ sprzętowy z własnym licznikiem do 1000 i wyświetlaniem milisekund. Czy ktoś robił coś podobnego?

Daniel · 06/03/2021 o 18:08

1. “Czy ktoś używa alarmów”, że co?? To chyba jest najlepsze w tym układzie, że może wygenerować przerwanie o zadanej porze (co minutę, godzinę, codziennie, raz na tydzień/miesiąc) :).
2. Druga fajna funkcjonalność (warto zaznaczyć) – ten układ może być zasilany z bateryjki cały czas, nie tylko do potrzymywania awaryjnego, Vcc w ogóle nie trzeba podłączać :). Możemy ustawić więc czas tylko raz, a później tylko co godzinę/dzień wybudzać się przerwaniem, sprawdzić datę/godzinę, zapisać jakiś pomiar i dalej iść spać – bez bawienia się we włączanie/wyłączanie Vcc, ani obaw że czas się nam rozjedzie :).
3. Drobne ostrzeżenie odnośnie tego modułu, którego używasz :). Ten moduł (ZS-042) ma Vcc podłączone do “chamskiego” ładowania bateryjki przez zwykły rezystor. Możemy jako bateryjkę podłączyć akumulatorek i go ładować. Jeżeli jednak chcemy użyć bateryjki CR-2032 tylko na wypadek awarii, a do tego zasilać Vcc 5V cały czas – bateryjka 3V będzie dostawać ciągle 5V (minus dioda) z zasilania. Ludki na sieci donoszą, że te bateryjki im “puchną” :). Żeby temu zaradzić – polecają tę ścieżkę na płytce przeciąć (łatwiej może wylutować diodę lub ten rezystor 200).

    Daniel · 07/03/2021 o 12:23

    Mały update. Układ działa pięknie, ale ten moduł (ZS-042) nie jest przystosowany do pracy na samej bateryjce (choć sam chipset DS-3231 na to pozwala). Można uruchomić bez podłączania VCC, ale trzeba sobie zrobić pullup na SDA/SCA/SQW (co kto używa) – a że te piny mają już pullupy do VCC na module, prąd przez nie “przecieka” (świeci LED i cała idea low-power się sypie)… Pomogło dopiero wylutowanie całego 4-paku rezystorów robiących pullup na płytce :). Działa pięknie!

    Mateusz Salamon · 14/03/2021 o 19:52

    1. No dobra, masz rację 😀 W bateryjnych urządzeniach to jest niezastąpione do budzenia raz na X lat 😉
    2. O! Tego nie doczytałem. Fajny bajerek.
    2. Heh, to nie pierwszy moduł z baterią, gdzie jest taki problem 😀

Lucjan · 12/02/2021 o 22:20

Panie Mateuszu
W wolnej chwili mógłby Pan sprawdzić czy w Pana kodzie nie ma błędu?
https://github.com/lamik/DS3231_RTC_STM32_HAL/blob/master/Src/DS3231.c
linia 172 użycie “void”

    Mateusz Salamon · 13/02/2021 o 09:27

    TAk, to jest błąd kopiowania z nagłówka funkcji 😀

Michał · 28/05/2020 o 12:31

Pytanie, dlaczego przy określaniu godziny dokonałeś koniunkcji 0x3F, możesz powiedzieć czemu to ma służyć ;D?

    Mateusz Salamon · 28/05/2020 o 12:39

    W której linijce bo nie wiem czego szukać? 😀

SaS · 06/04/2020 o 11:01

Sprawdziłem dokładność “żółtych” modułów DS3231. To badziewie! Odchyłka od deklarowanych 2ppm przekroczona prawie dwa razy! Można to skorygować rejestrem ADJ ale kto ma preycyjny licznik czasu? Dla porównania sprawdziłem oryginalny DS3231, odchyłka 0,5ppm. To tłumaczy dlaczego oryginalny układ kosztuje ok 20-25zł a moduł z eeprom, baterią, 6-7zł. “Żółte” moduły to zabawki!!!

    Mateusz Salamon · 08/04/2020 o 19:28

    No niestety wszystko co z Chin jest podejrzane 🙂 Ciekawe czy to są podróby czy jakieś spady produkcyjne…

    Przemek · 21/03/2021 o 00:06

    Potwierdzam. Testowałem kilka takich układów sprowadzonych z Chin. W większości przypadku mają co najmniej 5x wiekszy błąd wskazań. Analogicznie jest z układami DS1302 i DS1307 tylko że one zamiast 20 min/rok dały mi ok 97 min/rok odchyłki. W każdym razie do celów prywatnych (hobbistycznych) gdzie można raz na kilka miesięcy skorygować zegar to polecam takie układy. Mnie one w zupełności wystarczają.

SaS · 25/03/2020 o 08:48

Pytasz “Czy ktoś używa alarmów?”. Używam jak chce wybudzić CPU o określonej godzinie.

Dodaj komentarz

Avatar placeholder

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *