Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Fri, 14 Aug 2009 10:53:09 -0500

Hi Babak,

On Friday 14 August 2009 05:31:55 Kalantari Babak wrote:
>
> I have a question regarding the vxWorks time driver of generalTime
> (drvDevVWTime.c) which we use in EPICS 3.14.8 and mv2304/mv5500.

We don't use that here, so there's not be much I can say about it...

> Shouldn't the VWTime (for systems with vxWorks OS) be always available
> even if it is not synced? (It could at least be set to EPICS epoch.)
> Is it also like this in 3.14.10 after changes in generalTime?

This is the code from osiClockTime.c in R3.14.11 which deals with this case:

/* Time Provider Routine */

static int ClockTimeGetCurrent(epicsTimeStamp *pDest)
{
    struct timespec clockNow;

    /* If a Hi-Res clock is available and works, use it */
    #ifdef CLOCK_REALTIME_HR
        clock_gettime(CLOCK_REALTIME_HR, &clockNow) &&
    #endif
    clock_gettime(CLOCK_REALTIME, &clockNow);

    if (!ClockTimePvt.synchronized &&
        clockNow.tv_sec < POSIX_TIME_AT_EPICS_EPOCH) {
        clockNow.tv_sec = POSIX_TIME_AT_EPICS_EPOCH + 86400;
        clockNow.tv_nsec = 0;
        clock_settime(CLOCK_REALTIME, &clockNow);
        errlogPrintf("WARNING: OS Clock time was read before being set.\n"
            "Using 1990-01-02 00:00:00.000000 UTC\n");
    }

    epicsTimeFromTimespec(pDest, &clockNow);
    return 0;
}

Thus if still unsynchronized it will print a warning message the first time 
you try and read it and set the clock to 1990-01-02T00:00:00.0Z which is 
guaranteed to be after the EPICS epoch no matter what timezone you're in.

> The other issue is RTC:
> It seems that vxWorks clockLib (clock_gettime, clock_settime, ...) does
> not make use of on-board RTC. If I call clock_gettime() after a soft
> reboot it always starts from 0 while the RTC should run at least as long
> as there is power. Wouldn't it be better to use RTC to maintain time
> sources like VWTime?

Not by default since vxWorks runs on boards that don't have an RTC, and we 
also want things to continue working even if the RTC battery dies.  However 
the nice thing about the plugin architecture we now have is that you can 
write a time provider plugin that knows how to access the RTC for your 
particular board, and your vxWorks clock will then get synchronized to the 
RTC if you do this.

Note that there is no standard RTC interface in the vxWorks BSPs, so you will 
probably have to write a different one for each CPU board.  This code can be 
as clever as you like, including synchronizing the RTC to higher priority NTP 
sources and even measuring how good the RTC is and correcting for a measured 
slow or fast oscillator.

HTH,

- Andrew
-- 
The best FOSS code is written to be read by other humans -- Harold Welte

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System