-
Notifications
You must be signed in to change notification settings - Fork 302
Newlib - Clean up gettimeofday() #51
Comments
As you just mentioned in #43, there is the possibility of a custom callback. Is this callback replacing the original handler? Because if it is, then I see no clean way of repeatedly increasing a 64-bit integer. Else, there could be problems if this would be done in a custom handler (in case there can only be one of them). (just throwing in some ideas) |
The custom callbacks do not affect the system interrupt code. The callback code is executed as soon as the interrupt handler is finished. |
So, you are planning to have the system interrupt triggered by the RTC to count up a 64-bit integer and have the gettimeofday (and possible other functions) return an accurate time based on that integer and the time saved by the hardware? |
Yes, that is correct. |
Then you could have some memory location (which is by default initialized to 0) which is used by all time functions to save the hardware time to (on first access just compare if it is zero) and in all of these functions just copy the hardwaretime into a register and add the counter. |
Preferably you could write one function (similar to |
If you update the hardware time with this setup, you would just have to overwrite that memorylocation where the hardwaretime is saved in the firstplace with 0. Then all time functions would update automagically. |
Please note that this would assume that the RTC interrupt only happens once per second, if an application needs a different interval and wants to use the RTC for that, the whole thing would break. |
Have the RTC interrupt increment a 64-bit value every second.
On the first call to gettimeofday() check this value.
If the value is less than 946684800 (2000/1/1 00:00:00) then we have an invalid date.
gettimeofday() can then call the RTC hardware and calculate the real epoch time.
gettimeofday() will then update the OS timer.
The text was updated successfully, but these errors were encountered: