• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 973 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/LAUNCHXL-CC1310: I am confused about time functions...

Jan Ingwer Baer
Expert 1205 points

Part Number: LAUNCHXL-CC1310

Tool/software: TI-RTOS

I have experimented a little bit with setting the RTC and getting the time back.

Setting RTC with clock_settime() gives different results for clock_gettime() and time() :

/* 
 * set Clock from GPS
 */
fill_tm_from_GPS( &tmGPS )

gpsTime = mktime( &tmGPS );
gpsTimespec.tv_sec = gpsTime;
clock_settime( CLOCK_REALTIME, &gpsTimespec );

/*
 * get time back
 */
clock_gettime( CLOCK_REALTIME, &rtcTimespec );
ctime( &(rtcTimespec.nv_sec) ); // result is OK : Mon May 27 06:58:44 2019
rtcTime = time(NULL);
ctime( &rtcTime );              // result is garbage : Mon Apr 20 00:30:28 1953

Alternative i have tried to det se RTC with  Seconds_set( gpsTime ). The Result is the same.

If i include the 'TI-timeoffset ' (= 2208988800) in Seconds_set( gpsTime -2208988800 ) the result is reverse.

clock_gettime() gives garbage, time() gives right result.

Is this by design, or is it a bug in the libraries?

Software versions:

  • CCS : 9.0.1.00004 
  • SDK : SimpleLink CC13x0 SDK : 3.10.0.11
  • Compiler : ti-cgt-arm_18.12.2.LTS

  • 0
    TI__Guru 58425 points

    Hi Jan,

    It is not clear what you actually do when you call "clock_settime" and "clock_gettime", maybe you could elaborate on this?

    As for Seconds_set(), this does not impact the RTC in any way, it sets the offset value store within the Seconds module and added to the time when requested. 

  • 0 in reply to IUsedToBeARealPerson (M-W)
    Expert 1205 points
    For my application i need the time from RTC to schedule some activities at fixed times.
    To have a reliable time the RTC is synchronized once a day with time from GPS.

    My observation show that clock_settime() and Seconds_set() have the same result.
    clock_settime() calls Seconds_set() if clockId is CLOCK_REALTIME.

    My problem is that clock_gettime() and time() gives different results.
    As far as i understand the description of the time.h-header in different locations (POSIX, Linux-Man, ...) should give the same results. But with TI-RTOS the results are not the same.

    That is why i asked about it. Is it a bug in TI-RTOS/Simplelink-SDK or is it by design. And if it is by design, why?
  • 0 in reply to Jan Ingwer Baer
    TI__Guru 58425 points

    Hi Jan,

    As you point out, the POSIX "clock" is basically wrapping the TI-RTOS "Seconds" module and you should see the exact same behavior if you use clock_gettime() and Seconds_getTime().

    As noted in the TI-RTOS API documentation, the "time()" function generated returns the number of seconds since 1900. Are you accounting from this in your assumptions?

    Note: For TI codegen tools, time() returns the number of seconds since 1900. The generated time() function takes this into account, and adds the number of seconds from 1900 to 1970 to the value returned by Seconds_get(). This allows functions such as localtime() to work correctly with TI tools.

  • 0 in reply to IUsedToBeARealPerson (M-W)
    Expert 1205 points
    Hi M-W,

    you point out that TI uses two different definitions of time:

    TI-Epoch starting 1900:
    - time(), mktime(), localtime(), gmtime()

    Unix-/POSIX-Epoch starting 1970:
    - clock_gettime(), clock_settime, Seconds_get(), Seconds_set()

    This is really confusing, but i think i got it now: If i want to use one of the xxtime()-functions with the result of clock_gettime() i have to add the TI-epoch-offset.

    Best regards

    Jan