Hi,
Some microcontrollers from NXP include a RTC module (which is not a true RTC chip). This module has a 32 bit counter that counts once per second to keep track the time even when the main power supply is absent. The company ST does the same with its uC.
In order to keep track of the time in the format we're used to, we need to convert the integer value of the counter to day/month/year, hh:mm:ss. In a console program it's too easy because of the library functions in <time.h>.
I'm wondering whether we can use such library in order to convert seconds to calendar/time, as mentioned, in our projects. I understand we need to provide somehow to the library the integer seconds from our uC when our system boots up.
I haven't found the time.c file in the MCUXpresso installation. Looking inside this file (if it exists) I might figure out how to inject my counter (I hope so). Has someone tried to use time.h and time.c module in tiny uC (LPC11U68, for example)?
There's always the option to code our own algorithms in case what I'm asking is not possible, or even worst, to use an external I2C chip. Any hints?
Thanks!!!
Hi, Javier,
We have similar function in SDK package, the 32 bits RTC counter value can be converted to year,month,day, hour, minute and second.
I attach the rtc.c fsl_rtc.c and fsl_rtc.h here, the fsl_rtc.c is rtc driver.
You can download sdk package from the link:
MCUXpresso SDK | Software Development for Kinetis, LPC, and i.MX MCUs | NXP
The attached file is based on LPC55S69 sdk package.
Hope it can help you
BR
XiangJun Rong
Hi XiangJun ,
Thanks for the information. I am trying to get an RTC working on a MKV58F1M0xxx24 (not sure it has one, though -- can't find it in the docs).
I included your files and tried compiling my project. There are lots of compilation errors. Among others, the following are undeclared:
RTC_CTRL_ALARMDPD_EN_MASK
RTC_CTRL_WAKEDPD_EN_MASK
RTC_CTRL_ALARM1HZ_MASK
RTC_CTRL_WAKE1KHZ_MASK
etc.
Also, the core datatype RTC_Type is not defined.
Am I missing a header file somewhere?
Thanks again,
Robert
Hi, thank you for your prompt answer. I didn't see any attached file, so I guess it's embedded in the link you provided. I'll check it out ASAP.
Meanwhile, I can tell I found my way to get around this issue. I adapted the more general conversions algorithms from here (by Howard Hinnant) to an embedded chip (LPC11U68). I'll will post them, again, ASAP and I'll will also post my answer here.