eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaBiblioteka standardowa time.h i mikrokontrolery › Re: Biblioteka standardowa time.h i mikrokontrolery
  • Path: news-archive.icm.edu.pl!news.icm.edu.pl!news.nask.pl!news.nask.org.pl!news.unit
    0.net!border1.nntp.ams1.giganews.com!nntp.giganews.com!newsfeed.xs4all.nl!newsf
    eed8.news.xs4all.nl!85.12.16.69.MISMATCH!peer02.ams1!peer.ams1.xlned.com!news.x
    lned.com!peer01.fr7!futter-mich.highwinds-media.com!news.highwinds-media.com!ne
    wsfeed.neostrada.pl!unt-exc-02.news.neostrada.pl!unt-spo-a-01.news.neostrada.pl
    !news.neostrada.pl.POSTED!not-for-mail
    Subject: Re: Biblioteka standardowa time.h i mikrokontrolery
    Newsgroups: pl.misc.elektronika
    References: <5b98d6f0$0$669$65785112@news.neostrada.pl>
    From: Atlantis <m...@w...pl>
    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: Thu, 13 Sep 2018 07:46:46 +0200
    User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
    Thunderbird/52.9.1
    MIME-Version: 1.0
    In-Reply-To: <5b98d6f0$0$669$65785112@news.neostrada.pl>
    Content-Type: text/plain; charset=utf-8
    Content-Language: pl
    Content-Transfer-Encoding: 8bit
    Lines: 48
    Message-ID: <5b99f9c7$0$675$65785112@news.neostrada.pl>
    Organization: Telekomunikacja Polska
    NNTP-Posting-Host: 31.0.70.130
    X-Trace: 1536817607 unt-rea-a-01.news.neostrada.pl 675 31.0.70.130:6991
    X-Complaints-To: a...@n...neostrada.pl
    X-Received-Bytes: 5840
    X-Received-Body-CRC: 3287064581
    Xref: news-archive.icm.edu.pl pl.misc.elektronika:736531
    [ ukryj nagłówki ]

    Hmm... Wygląda na to, że problem leży głębiej i dotyczy raczej RTC
    (ewentualnie funkcji bibliotecznych odpowiedzialnych za odczytywanie
    czasy), niż biblioteki standardowej time.h.

    Zgodnie z sugestiami, które tu padły, zastąpiłem usunąłem swoją własną
    wersje funkcji time() i napisałem własną wersję _gettimeofday.

    int _gettimeofday (struct timeval* tp, struct timezone* tzp) {
    RTC_TimeTypeDef timeStruct;
    RTC_DateTypeDef dateStruct;
    struct tm dstTime;

    HAL_RTC_GetTime(&hrtc, &timeStruct, RTC_FORMAT_BIN);
    HAL_RTC_GetDate(&hrtc, &dateStruct, RTC_FORMAT_BIN);
    dstTime.tm_hour = timeStruct.Hours;
    dstTime.tm_min = timeStruct.Minutes;
    dstTime.tm_sec = timeStruct.Seconds;
    dstTime.tm_year = dateStruct.Year + 100;
    dstTime.tm_mon = dateStruct.Month - 1;
    dstTime.tm_mday = dateStruct.Date;

    if (tp) {
    tp->tv_sec = mktime(&dsttime);
    tp->tv_usec = 0;
    }

    if (tzp) {
    tzp->tz_minuteswest = 0;
    tzp->tz_dsttime = 0;
    }

    return 0;
    }

    Następnie w pętli głównej usunąłem gmtime(), zamiast tego wyświetlając
    na LCD aktualna wartość zwracaną przez time(). Efekt był dość...
    Dziwny... Mianowicie liczba złożona z dwóch ostatnich cyfr faktycznie
    zwiększała swoją wartość o jeden co sekundę. Natomiast trzecia, czwarta
    i piata cyfra od końca co chwilę zmieniała swoją wartść "tam i z
    powrotem" - raz było 500 z czymś, potem ponad 600, potem znów 500 z
    czymś i tak dalej...

    Postanowiłem więc zrobić eksperyment i stworzyłem zmienną uint32_t _rtc,
    która była zwiększana o 1 w przerwaniu alarmu RTC. Podpiąłem ją do
    funkcji _gettimeofday i problem zniknął.

    Ktoś wie gdzie może leżeć przyczyna takiego zachowania? Co robię nie tak
    czytając RTC? Przykład u góry.

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: