eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaBiblioteka standardowa time.h i mikrokontrolery › Biblioteka standardowa time.h i mikrokontrolery
  • Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed2.atman.pl!newsfeed.atman.pl!go
    blin2!goblin1!goblin.stu.neva.ru!newsfeed.neostrada.pl!unt-exc-02.news.neostrad
    a.pl!unt-spo-a-01.news.neostrada.pl!news.neostrada.pl.POSTED!not-for-mail
    Newsgroups: pl.misc.elektronika
    X-Mozilla-News-Host: news://news.neostrada.pl:119
    From: Atlantis <m...@w...pl>
    Subject: Biblioteka standardowa time.h i mikrokontrolery
    Openpgp: preference=signencrypt
    Autocrypt: addr=m...@w...pl; keydata=
    xsFNBFnwJM0BEADds36pFsxrdHt82V36BjgzSYKNGSe0UNgExPg5WXZyoaseq6GegEfpbUsP
    t8T6omrLRDGHzfwitGO8TLO/Oz1GrwSyUTbJ1sqr8aAhYamw3JHwcx4mmJ+nFkrKD03ZoQuF
    TaHb1zENE8WB7l3Wwl3oJVEGuyN0LOJFmKb/fOZPBnCX1XoUhY6cHbQ/93LInouWmQtZl3Hi
    1IWRWJ6n8qD6XhOA5RcF14hBkc8cM2Fw2wIxoHmby2vyYhWEwd/4EtBK2tjsnPL1PwQjBpa9
    FnQH134rOv331chMZomz/hEsKY+UZjCDCnDquEEzDfJJHz7kR3+V08iNL8Z/AIHBg0JQbWei
    So3GcpgwMBBTvFE0hXcI+RAYphCEBpK67o5zAvqi9mYLGxczEIl0ahDXFNQmqjb2h5xULbdk
    P/gBbyaUUylHqJ9Nl8zJkivoi+8Zs+9W2Wa/oRhcNYEQub8rmT6CXHKDG+li5qXILRR6KZLg
    nHfGGZeICyHrIuxA/0GT0DlMId4rFRcgVQ5RWWu2vS7X4VeHDvWtCaqWUHH4sc6XkSW7ZZU4
    7ID2RB82XSwhr+14Cp2SOBe2A301M0JUuVNxirBsvlGJwdB7iKl74BwKsMZAGD7AgECrgeyP
    STFDSUkuhGp6BOoCO8oectISHrkEvivsn6xXakjyBN82bum6jwARAQABzSRNYXJlayBXacSZ
    Y2VrIDxtYXJla3cxOTg2QGdtYWlsLmNvbT7CwX4EEwECACgFAlnwJM0CGwMFCQPCZwAGCwkI
    BwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEAcixloyhBQTfjUQAKzjMxPMmgBDX5+z3dRxasPi
    2iVHa0tam8435heVvkkW0vZteXjZY9mdzkPHJU77mYknO1i3mxvYO+8qw78/ELqm7kC9MAOZ
    JcCkah7wQbRkYH+NyqnFemmFtqvN6rjnNz4GBA+oddHuRfL3XzUCKbB8dmXVs6fUn3mL60i9
    /pUkelk1qEZlO19s0YbEqoR/0QqSjtbwv76T7Pob79mBH+oDPk9T75r1Gh28TkMu3EhIe+He
    HvZuvf9JmRXokDrVmeztdXcclKLRMVKreJZqmGQhD2Kw3ez8GS/kIfsUpXXbFiUOVGOxsEOZ
    EmHirxvr7NP6R347DU2wI64pzsbtJTW/yLxDq+GMJ7s1LkNjCsH1kCfuPh2Lzs6CNdTmXlXb
    5FuBaIx9tPvOffnwwJFDq63ERmPn4ja67dtJ7VV4ZT2tMGb6h1QFyCoc29Kw6e/JvnJsqysT
    Ov2K5McGJF5gUWKIkxT7IoPXvyWYLqinQLyImXbubz1jQqwY2/Nxn5/5esY4QzY/kVTIIHKy
    12szGc7/TrwnhlEyv2tAO6q8ap/TDeW8dLUjhgabzLZ3GT0BPnL1N4f8At1dkEto/p3CL/LS
    vw8Vtn8V8J/Y6h9zvkJeWMNhPYKUKuDw9RjBMhaTXFhiwc1lK3ySwhxXpNcbtdRpwMGzOlHT
    ABMEgEzimRCFzsFNBFnwJM0BEADNw+0vXHWmpIro/VwfM5eBvA13MmTwhDWPG1s/Zq4CuRfF
    bgG0shqLZke9YnVtwVa/xIcXkaoD2VP3E1+17NvxOHMFFhxil7ASyI/sp9MsEZ0vmYDpO3Q8
    TYOAMbbJ18sHImz/y81y6+xwLIrclkxe9RDE5vR2rri+IbntGaXjDLOKckuGwguwTa3w+PNW
    +jpN0i1p2Dqt78LTpsXSInxdsxQacvJPMcHxuF+KeM4w/EyH7rbeqsHd1+t6FQP8hS7odKG4
    WguFIR3nvh+3JXcps0sjMGulIZv7LrzqZBDVzfTknWaIIc6Av1Rkm26jj1c+2YkIWFI0YVez
    wVskWXOq1v3Nn15WBZQ1F2PRlCdysE8YRa5zCrb9AKaItlSULhvdYbzE9Vbqny7P6ufi0Lo5
    H/gh3+Z8ifv3lwIeh5Nc2dzehyaAR41LfarggSt2lwHDw7j5m8aNuLbG5FAuGA0XNsk4KUFL
    WfT5vU7sYKkmX6exdzHuiosZP7r6RVhOb75lcqwhn7f9Jz2KdnyfJA9J5ryKtBdP5sSjnVHQ
    KDKtjmiFXOyu4Hc09FCGAayTy4czqPohnslLIj4EC8f97Gcoc/wd6CUd1TSmifHNkYLeeooq
    y37n+edry95mmlnH6T4MtICe1eVUZaM7Pf8birPZIZaGPvLSa+JIYPCP4Ir2OQARAQABwsFl
    BBgBAgAPBQJZ8CTNAhsMBQkDwmcAAAoJEAcixloyhBQTcr4P/R/4mRWZF20GZXYNpbtvB8RK
    ygTf4LSOnawrxIh8tUq6svM6Dzmf4WCKKQcEe3IxH50YSMbfAb5Cgg5XYbv5SnKbBZsqHBkH
    UB2tfcfX1acxkciMPVweLg1Vk0FiKqLh8GF9HI4kx3XT4zkENZT04eFEBNYLXYU8+6SxTPgj
    awA14PVVH6JtuQOrDEpSCKKQAyV2bCCIOXk0KohSEzy+jdLY9fHIz5y/ptDHk0nDNDAvs7o6
    gHsn9Hb9QOw+k3+/k7NHseE7bJfhCeh+1RJqJ8/z2leKCQ6oCVPeUF+Ew+N58nh7daKXOBAP
    PPVLxKdukbEjcF/ImiPJezFVi+ccVZdk5YWvoLYszLzedWjsXveFl1bZKw+w0RV6h+vvNoN4
    3dL2AHp/LAy1DiutK4qqZ7qhlqQlwesavr5B6XmyyJdP256PmGSZT0GaIbom4avwR3Nxexen
    b3pOwcxM++qAtgCWVebJFjGh2NIZunoq1WeyL1jBRpRnPZZK3/dmSRoEas+1c12nOHOoPHh8
    GLdXRWYhGApjvyD2puJYt10JfeA636RPBVdTiGxAHKlma6mno5kNxUzNxLMygz/Rl7dXXy08
    70N9CxkFS1hhaYkadyseTQRcMNEbnQKlYreKtDSqgZLf+ZrgeajCx1yQ+cltRdXiXevd5mJf
    AdKy5TQxdS7G
    Date: Wed, 12 Sep 2018 11:05:52 +0200
    User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
    Thunderbird/52.9.1
    MIME-Version: 1.0
    Content-Type: text/plain; charset=utf-8
    Content-Language: pl
    Content-Transfer-Encoding: 8bit
    Lines: 58
    Message-ID: <5b98d6f0$0$669$65785112@news.neostrada.pl>
    Organization: Telekomunikacja Polska
    NNTP-Posting-Host: 37.248.165.15
    X-Trace: 1536743153 unt-rea-a-01.news.neostrada.pl 669 37.248.165.15:7901
    X-Complaints-To: a...@n...neostrada.pl
    Xref: news-archive.icm.edu.pl pl.misc.elektronika:736481
    [ ukryj nagłówki ]

    Może ktoś z was będzie miał jakiś pomysł, bo od paru dni nie mogę dojść
    do tego, co robię nie tak. Sytuacja wygląda następująco.

    Środowisko: Płytka NUCLEO-L031K6, programowana za pomocą IDE
    AtollicSTUDIO. Projekt generowany narzędziem STM32CubeMX.

    Software: Biblioteka do obsługi DCF77, przeportowana z Arduino. Do tego
    biblioteka sterująca wyświetlaczem od Nokii, przeportowana z AVR.
    Obydwie zdają się działać prawidłowo.

    DCF odczytuje w przerwaniu impulsy z modułu i sprawdza poprawność ramek.
    Kontrolowane jest m.in. to, czy odebrany czas nie różni się za bardzo od
    systemowego zegara. Jeśli mamy do czynienia z taką sytuacją, konieczne
    jest odebranie dwóch prawidłowych ramek, jedna po drugiej. Oryginał
    korzystał w tym celu z jakiejś arduinowej biblioteki, ja przerobiłem to
    na standardowe time.h, podkładając wszędzie gdzie trzeba wywołania
    time(NULL).

    Oczywiście zdefiniowałem w kodzie swoją własną funkcję time(), która
    czyta systemowy RTC, wypełnia pobranymi wartościami strukturę struct tm,
    a następnie przy pomocy mktime() generuje timestamt time_t.

    Sam moduł RTC jest obsługiwany za pomocą bibliotek HAL. Po odebraniu
    nowej ramki zegar jest ustawiany wartościami uzyskanymi za pośrednictwem
    gmtime().

    I teraz przechodząc do sedna sprawy: na początku wszystko zdaje się
    działać prawidłowo. Po starcie układu zegar zaczyna odliczać w górę, a
    jego aktualną wartość wyświetla się na LCD. Jeśli pojawią się
    odpowiednie warunki propagacyjne, DCF zaczyna dobierać ramki i
    przestawia zegar. Dodatkowo na LCD wyrzucam też info o czasie ostatniej
    poprawnej synchronizacji. Potrafi to działać prawidłowo przez kilka
    godzin, aż w końcu coś się wysypuje. Na przykład wczoraj około 20.00 UTC
    zegar stwierdził, że jest 4.00 UTC następnego dnia. Żeby było ciekawiej,
    kolejne ramki DCF były nadal odbierane, a na ekranie pojawiała się
    informacja o udanych synchronizacjach, oznaczonych prawidłowym czasem (!).

    Kilka rzeczy nie daje mi spokoju:
    - Dokładność tej anomalii - obserwowałem ją kilka razy i OIDP zawsze
    było to osiem godzin do przodu. Nie chodzi więc o odebranie jakimś cudem
    błędnej ramki.
    - Przygotowana przeze mnie funkcje time() najwyraźniej zwraca cały czas
    prawidłowego timestampa, bo inaczej kolejne synchronizacje nie
    dochodziłyby do skutku. Program stwierdziłby rozjechanie się RTC z
    odbieranym czasem, czekając na dwie poprawne ramki. Wtedy ustawiłby
    zegar i wszystko wróciłoby do normy. Tak się jednak nie dzieje. Po
    pojawieniu się anomalia pozostaje na stałe.

    W chwili obecnej do pobierania czasu z RTC używam kombinacji time() i
    gmtime(), a uzyskane wartości ze struktury wyrzucam na ekran. Po udanej
    synchronizacji odebrany czas z DCF jest zapisywany do zmiennej i również
    trafia na ekran za pośrednictwem gmtime().

    Ktoś ma jakiś pomysł, co mogę robić nie tak? Może time.h w przypadku
    mikrokontrolerów wymaga jakiegoś przygotowania (poza podstawieniem
    własnej funkcji time())? W jaki sposób chociażby definiuje się w niej
    strefę czasową. Pod Linuksem ustawiało się zmienna środowiskową. A na
    małym mikrokontrolerze?

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: