fprime icon indicating copy to clipboard operation
fprime copied to clipboard

IntervalTimer shouldn't directly use OS clock

Open Joshua-Anderson opened this issue 3 years ago • 5 comments

F´ Version all
Affected Component OS


Rationale

Right now, the IntervalTimer class directly uses the system clock to track the duration between start and stop. It should use the spacecraft time that F' provides. This will likely require some rearchitecting because currently spacecraft time is currently provided via a port call. Because ports cannot be called outside of a component, we need to provide some way for standalone classes like the IntervalTimer to access the spacecraft time.

Joshua-Anderson avatar Jul 22 '21 20:07 Joshua-Anderson

The way to do this is to have a function call API for getting the time, and to implement the Time component in terms of that function call. Doing this would also make the Time component system independent, so we wouldn't need different component implementations for Linux time, etc. The system-specific part would go below the function call layer.

bocchino avatar Aug 01 '21 23:08 bocchino

We should think about adding Time to the OS API.

bocchino avatar Aug 01 '21 23:08 bocchino

IntervalTimer is an Os class. It's meant to provide a raw time for getting differences. On *nix, it uses the system clock, but on other platforms like VxWorks it uses whatever API makes sense for the platform. I think the current approach is correct.

timcanham avatar Aug 02 '21 02:08 timcanham

I think I agree with @timcanham here. On my ATmega baremetal platform, we used a twos complement subtraction on a 16 bit timer to implement this interface.

SterlingPeet avatar Sep 01 '21 01:09 SterlingPeet

We had some more discussion about this offline. I think we concluded the following:

  1. We need to support separate implementations for relative time and for absolute time, for the reasons stated by Tim and Sterling, i.e., relative time has a more efficient implementation on some platforms.
  2. Right now the relative time interface is intertwined with IntervalTimer and the absolute time interface is intertwined with Fw::Time (or any other component or library that provides the time). It seems useful to separate the relative and absolute time interfaces into separate functions. In that case a. One could stub out these functions to force specific simulated timings in unit tests, while still running all the other code (e.g., the timer part) that depends on the time interface. b. One could have multiple uses of the same time implementation, e.g., a Time component and a C-style library function that both use the same implementation for absolute time. This is useful for interoperating with external libraries that need to get the time.

bocchino avatar Sep 01 '21 15:09 bocchino