cFE Time subsystem has calls to OS functions that do not exist for non-default configurations

[skliper]

In the cFE Time subsystem, there are a couple of calls to functions that do not exist: OS_GetLocalMET and OS_SetLocalMET. These calls are conditionally compiled by a configuration parameter, and probably not used often.

Note: GSFC's MMS FSW uses these functions and had to provide them.

[skliper]

Imported from trac issue 92. Created by sstrege on 2015-08-27T14:12:19, last modified: 2019-07-03T12:58:32

[skliper]

Trac comment by jphickey on 2015-08-31 11:50:01:

See also #78

[skliper]

Trac comment by glimes on 2015-09-02 13:05:01:

It is perhaps telling that the ONLY mentions of these two
functions (that I can find) are in the specific places in
CFE_TIME that are commented as interacting with a hardware
register.

I rather expected to find an "extern" function prototype
either in OSAL or in PSP to nail down this external API.

As with #78 this is contingent on a configuration option,
and the calls for these look like this:

{{{
/*
** Maintain virtual MET as count read from h/w MET register...
*/
#if (CFE_TIME_CFG_VIRTUAL != TRUE)
OS_GetLocalMET(&CFE_TIME_TaskData.VirtualMET);
#endif
}}}

(The other two call sites are similar)

I suspect that fixing this is something that actually happens
over in the PSP area. Do we need a ticket in CFE_PSP to track?

[skliper]

Trac comment by sstrege on 2016-08-26 14:08:10:

This points to a much larger issue of the need to overhaul Time Services. This is a feature all missions/projects have been living with unaffected. This ticket has been deferred as it is not a high priority.

[skliper]

Trac comment by glimes on 2016-10-18 15:07:03:

Remove my name from many tickets (where it was applied by default), so others can tell that there are tickets that need some attention.

[skliper]

Trac comment by jhageman on 2019-04-01 09:41:37:

CCB 3/27/2019 - discussed removing unimplemented configuration options. Assigning to Alan for review.

Edit - fixed CCB date typo

[skliper]

Trac comment by acudmore on 2019-04-03 11:12:40:

For the Dellingr Cubesat, we had CFE_TIME_CFG_VIRTUAL set to false, so I had to implement OS_GetLocalMET and OS_SetLocalMET.

I would like to do a survey of recent missions and find out if any other users needed these functions.

If we decide these functions are necessary for some users, I would recommend moving them to PSP functions, since mission time hardware is not a generic OS function.

However, before adding any PSP functions, we may want to take a step back and consider simplifying the TIME subsystem.

[skliper]

Trac comment by jhageman on 2019-06-24 15:53:01:

Related to [cfs_psp:71], pending TIME subsystem design review

[skliper]

Trac comment by jhageman on 2019-07-03 12:58:32:

Moved unfinished 6.7.0 tickets to next release

[skliper]

Related to #302

[mlouielu]

Hi @skliper, so in your scenario, the flight board has another specific high-resolution clock for the MET, not only the the one such as clock_gettime in Linux?

[skliper]

HI @mlouielu - Yes. Frequently timing requirements are such that hardware is involved, both for internal time keeping and time management across a system.