Thanks Chris/Will
This is how i did it.
*For setting the time i used mktime and tm struct like this*
// Set time
struct tm t;
    time_t t_of_day;
    t.tm_year = 2018-1900;
    t.tm_mon = 11;           // Month, 0 - jan
    t.tm_mday = 28;          // Day of the month
    t.tm_hour = 19;
    t.tm_min = 23;
    t.tm_sec = 42;
    t.tm_isdst = -1;        // Is DST on? 1 = yes, 0 = no, -1 = unknown
    t_of_day = mktime(&t);
struct os_timeval set_time = {(int64_t)t_of_day, 0};
struct os_timezone IST = { -330, 0 };
os_settimeofday(&set_time,&IST);


*and for getting the time i used os_gettimeofday to get the epoch time and
converted to string using ctime and sscanf into a custom struct.*
struct time_string { char wday[4]; char month[4]; char mday[3]; char
hour[3]; char min[3]; char sec[3]; char year[5]; };

        time_t epoch;
struct time_string now_ascii;
struct os_timeval time;
struct os_timezone tz;
os_gettimeofday(&time, &tz);
epoch = time.tv_sec;
sscanf(ctime(&epoch),"%s %s %s %s%*c%s%*c%s
%s",now_ascii.wday,now_ascii.month,now_ascii.mday,now_ascii.hour,now_ascii.min,now_ascii.sec,now_ascii.year);


On Fri, Dec 28, 2018 at 2:34 AM will sanfilippo <wi...@runtime.io> wrote:

> My reply was definitely a bit confusing based on Chris’s reply. He is
> correct and if you use those API to set/get time of day what I was saying
> you need to do in firmware is already done for you.
>
> Hopefully that clears up any confusion.
>
>
> > On Dec 27, 2018, at 9:21 AM, will sanfilippo <wi...@runtime.io> wrote:
> >
> > The nrf52x “RTC” is probably the worst-named peripheral I have come
> across in my 25+ years of writing firmware :-) It is not a RTC. It is just
> a timer that runs off a 32KHz crystal so is not what you are looking for.
> You will certainly need to use a timer to help keep track of “real-time”
> but you will have to do that in firmware (if you see what I am getting at
> here). Unless someone else has a better idea, you will have to do something
> like this:
> >
> > 1) Start up a timer (you can use the RTC timer for this as it is low
> power).
> > 2) When your device receives “real-time” you read the current RTC
> counter and remember it
> > 3) When you want time in the future you need to read the current RTC
> counter and subtract it from the stored value. You then calculate the
> amount of time that has passed and update real-time accordingly.
> >
> > Will
> >
> > PS You have to be careful about timer roll-over and dealing with that
> but that should be easy.
> >
> >> On Dec 27, 2018, at 8:57 AM, Christopher Collins <ch...@runtime.io>
> wrote:
> >>
> >> Hi Rohit,
> >>
> >> On Wed, Dec 26, 2018 at 11:55:56PM +0530, Rohit Gujarathi wrote:
> >>> Hi Everyone,
> >>>
> >>> I wanted to make a desktop clock using mynewt and am stuck at setting
> the
> >>> time. I read the os_timeval part but How do i set time in mynewt and
> >>> display it human form? I am using the nrf52840 which has a RTC, how
> can i
> >>> use that? has anyone used the __DATE__ and __TIME__ macro?
> >>
> >> The __DATE__ and __TIME__ macros are useful when you need to know when a
> >> program was built.  Since you are interested in the actual real time
> >> (independent of the build time), these macros won't help you.
> >>
> >> I would look at the following two functions:
> >>
> >>   os_gettimeofday()
> >>   (
> http://mynewt.apache.org/latest/os/core_os/time/os_time.html#c.os_gettimeofday
> )
> >>
> >>   os_settimeofday()
> >>   (
> http://mynewt.apache.org/latest/os/core_os/time/os_time.html#c.os_settimeofday
> )
> >>
> >> When the device boots up, set its time using `os_settimeofday()`.  To
> >> display the current time, call `os_gettimeofday()` and convert the
> >> result to a human readable format.
> >>
> >> These functions deal in UNIX time, i.e., seconds since 1970/01/01.
> >> I'm afraid converting this number to a human readable format is not
> >> trivial due to pesky human factors such as time zones, leap years, etc.
> >> Luckily, these functions use the POSIX time data structures, so there
> >> should be a lot of free code avialable online that does this conversion.
> >>
> >> I am not very familiar with the nRF52 RTC.  Maybe others who are more
> >> knowledgable can chime in.
> >>
> >> Chris
> >
>
>

Reply via email to