Showing changes from revision #1 to #2:
Added | Removed | Changed
Entry | |
---|---|
R0 | Time error low word |
R1 | Time error high word |
R2 | Time span to apply correction over (centiseconds) |
R3 | Priority |
Exit | |
---|---|
- | All registers preserved |
The purpose of this call is to request a correction to be applied to the RTC.
R0 and R1 form a signed 64 bit integer giving the correction value to be applied (in units of centiseconds). R2 specifies the length of time to apply the correction over.
R3 is used to specify a priority value, with higher values indicating a higher priority.
The RTC module will only apply one correction at a time. If it is already performing a correction, and a new request is received at a lower priority level than the current correction, then the request will be rejected and an error will be returned.
The automatic synchronisation of the soft clock with the RTC is performed using a priority level of &1000000 – using a priority level lower than this is guaranteed to fail and therefore pointless. NetTime? uses a priority level of &2000000.
An error will also be returned if an attempt is made to exceed the limits of the 5 byte time format that RISC OS uses internally.
If a request is made to perform a small time correction, the module will skew the soft clock by adjusting the rate of the hardware timer that drives the 100Hz TickerV interrupt. The timer will remain close enough to its original frequency that software is unlikely to be able to determine that anything unusual is happening. Note that current versions of the module will not adjust the hardware RTC in this case.
If a request is made to perform a large time correction, the module will avoid skewing the hardware timer and will instead apply the time correction immediately, via the Territory_SetTime SWI. This will result in all software seeing a visible jump in the current time, with both the soft clock and hardware RTC updated to the new time.