You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is only one user of this API, the mbed timer queue. It sets targets
a maximum of (2**32)//16*7 microseconds in the future. Assuming there are
no other timer events to be scheduled, after 3 instances of this at 5637s
uptime the 64-bit uptime gets wrapped.
Never modify the system uptime because that makes it unusable when the
64-bit uptime that should never wrap, unexpectedly does. With the uptime
proceeding as normal into large 64-bit values the 32-bit timestamp needs
special handling.
It's ambiguous what the 32-bit timestamp means because time advances while
the ticker functions are being called, so the 64-bit time could wrap
between calculating the next 32-bit timestamp and setting it as the target
time.
The only way to avoid this is to know for certain what the caller meant by
keeping track of the last 32-bit value that was read. This relies on there
only being caller but other mbed timer implementations already keep track
of the last call to us_ticker_read() to handle ambiguity in timestamp
values.
Track the last read of the full 64-bit time too, so that we can always
prepare the correct 64-bit time value. Avoid reading the current time
repeatedly because it could change between calls.
If the timestamp is in the near future it's possible that it has been set
too late and the time has been missed. Force a timer interrupt when this
happens.
0 commit comments