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 > > > >