fprime
fprime copied to clipboard
IntervalTimer shouldn't directly use OS clock
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.
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.
We should think about adding Time to the OS API.
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.
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.
We had some more discussion about this offline. I think we concluded the following:
- 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.
- 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.