Clock calendar implementation on RTC

LeafLabs Garden » Community » The Garden

Clock calendar implementation on RTC

(152 posts) (17 voices)

Started 1 year ago by howrupravin
Latest reply from bubulindo

« Previous 1…678…11 Next »

dugggg
Member

Hi, just spent the morning implementing RTC on my Olimexino-STM32. Thanks everyone for all the work you did to make this pretty darn easy! Special thanks go to bubulindo for putting it all in one easy place up on github.com.

One thing I noticed---this just happening to be the last day of the month---was that tm_mon seems to want to range from 0-11, not 1-12. I verified this by setting the date to the last seconds of each of the 12 months and then watching each midnight transition.

Could someone else please independently verify or refute this?

Posted 1 year ago #
dugggg
Member

Possibly major snag: on the Olimexino at least, the built-in RTC seems to halt during CPU resets/reboots and sketch loads. I was hoping that as long as power remained applied to the CPU (via the Olimexino's attached LiPO battery), timekeeping would not be affected...

Posted 1 year ago #
bubulindo
Member

@ duggg

"One thing I noticed---this just happening to be the last day of the month---was that tm_mon seems to want to range from 0-11, not 1-12. I verified this by setting the date to the last seconds of each of the 12 months and then watching each midnight transition."

I used time.h from standard C library, hence the 0-11 as you can see here. http://www.cplusplus.com/reference/clibrary/ctime/tm/

I seem to remember that the counters would be reset in either the constructor or the clock selection. I can have a look at that later on to see if that is still being used in the github version.

Posted 1 year ago #
dugggg
Member

Bubulindo, thanks for the quick reply, I had later done a man page on gmtime() and also saw there confirmation of the 0-11 usage.

As for the mysterious RTC slowdown, tomorrow I will do a hardware check and verify that the 32 kHz crystal is operating properly. The Olimexino schematic says its case is supposed to be grounded; that is not true on my particular board.

Posted 1 year ago #
dugggg
Member

The crystal checks out fine, but the Olimexino implementation still loses a few seconds whenever the board is reset or a new program is loaded---which is totally unacceptable for a RTC.

Higwoshy mentioned that his install worked much better--did his fixes make it into the github version?

Posted 1 year ago #
bubulindo
Member

No, I haven't made any changes to the github version. I also didn't see any indication of changes to correct this. :\

how are you checking the time by the way? With the USB communication?

Posted 1 year ago #
dugggg
Member

Good news, it seems that when rt.attachSecondsInterrupt is used with the Olimexino (even with an empty handler) the RTC does NOT lose time with every reset or reload---just every now and then. Now, even when the board is repeatedly reset or the reset button is held down, the loss is negligible enough that it's probably not be an issue worth worrying about---especially if some kind of "seconds reset" fudge code is implemented to periodically get the RTC in sync with the real world.

Posted 1 year ago #
dugggg
Member

Yes, using USB right now, but only writing 20 bytes at the top of each second. The actual project will use a 3.3V LCD which needs to be correct to a few seconds---and it appears we have that accuracy now. That interrupt call made all the difference.

Posted 1 year ago #
bubulindo
Member

"Good news, it seems that when rt.attachSecondsInterrupt is used with the Olimexino (even with an empty handler) the RTC does NOT lose time with every reset or reload"

That is an undocumented feature of the code. :\

Posted 1 year ago #
dugggg
Member

More good news! Behavior is identical with or without the call to rt.attachSecondsInterrupt. It was late last night when I published my "discovery" which really was just the result of sloppy testing. There remains a small but measurable time loss during each bootload cycle that appears proportional to the size of the program being loaded. It may well be a quirk with the STM32/board we can do nothing about. In any case, it is easily handled with fudge code.

Posted 1 year ago #
bubulindo
Member

It may have to do with the startup code.

One thing I didn't anticipate would be the need to have the RTC always running while we change programs, etc... So, even though you don't change the clock status, you still run the configuration code while the clock is running.

I can try to go through the code and datasheet again to see if this can be avoided.

Can someone with a knowledge about the bootloader comment about the possibility of the bootloader corrupting the time count?

Posted 1 year ago #
dugggg
Member

I have confirmed that another Olimexino owner also reports the time loss during reload. Don't know if it affects Maple owners as well.

But, putting things in perspective, the inexpensive 32768 Hz crystal probably loses more time in a day than it would during a dozen reloads. Users may put in code to manually compensate for any clock drift anyway---so under normal use, the small loss is not the "major snag" I implied it was in an earlier post. The RTC sure beats having to completely re-enter the time after each boot!

Thanks again for all the work done here. It'll be a great addition to libmaple.

Posted 1 year ago #
Roma
Member

RTC is working on Olimexino.

But after replace rcc.h and rcc.c compiler do not fount delay() function. Why ?

<BUILD>/OLIMEXINO_TEST.cpp:89: error: 'millis' was not declared in this scope
<BUILD>/OLIMEXINO_TEST.cpp:89: error: 'delay' was not declared in this scope

Posted 1 year ago #
Roma
Member

I found:

After replace original rcc.c and rcc.h your should change in wirish_time.h

from

#ifndef _TIME_H_
#define _TIME_H_

to

#ifndef _WIRISH_TIME_H_
#define _WIRISH_TIME_H_

All is working.

P.S. Sorry for my English.

Posted 1 year ago #
tfcroft4
Member

I have used the MapleRTC library on a Olimexino board. Using the External 32khz crystal I am getting a gain of 12 seconds a day. How have others fared?

Thanks

TF

Posted 8 months ago #

RSS feed for this topic

« Previous 1…678…11 Next »

Reply »

You must log in to post.