277: TimerQueue.dequeue: don't set SYST reload to 0 r=korken89 a=mpasternacki
ARM Architecture Reference Manual says: "Setting SYST_RVR to zero has the effect of disabling the SysTick counter independently of the counter enable bit."
If Monotonic's ratio is less than one, the timeout calculations
can compute zero if next task is scheduled after current instant, but
before next timer tick. This results in disabling SYST and freezing the
timer queue.
The division by ratio's denominator rounds downward and the dequeue
condition is `if instant < now`. If ratio is small enough, this results
in unnecessary interrupts:
Let's say `instant - now` is 99 and ratio is 1/25. Then, `dur` will
equal 3 and the next tick will happen at `now + 75`. In the next
interrupt, `instant > now` and additional tick needs to be scheduled
(which doesn't happen, because now `instant - now` is less than 25, so
reload will be set to 0 and timer queue will stop). Adding one to
computed duration will prevent both freezing and additional interrupts.
When ratio is 1 or close, timer queue code overhead will prevent this
from happening. I am working with a chip where CPU is clocked at 600MHz
and SysTick is 100kHz and the freeze happens quite often.
Co-authored-by: Maciej Pasternacki <maciej@3ofcoins.net>
ARM Architecture Reference Manual says: "Setting SYST_RVR to zero has the effect of disabling the SysTick counter independently of the counter enable bit."
If Monotonic's ratio is less than one, the timeout calculations
can compute zero if next task is scheduled after current instant, but
before next timer tick. This results in disabling SYST and freezing the
timer queue.
originally the type was made `!Send` because it loses its meaning when
send from one core to another but that was an incorrect use of the `Send`
bound (the send operation makes the value incorrect but that doesn't cause
memory unsafety on its own). So later the type was (explicitly) made `Send`
again resulting in a convoluted implementation -- this commit simplifies things.
covers
- initialization and configuration of the timer; this is now a responsibility of
the application author
- correctness of `Monotonic::now()` in `#[init]`
- safety of `Monotonic::reset()`
closes#251
with the upcoming version of heapless we are able to initialize all internal
queues in const context removing the need for late initialization
this commit also removes the "nightly" feature because all the optimization
provided by it are now enabled by default
This commit:
- Implements RFC 147: "all functions must be safe"
- Implements RFC 155: "explicit Context parameter"
- Implements the pending breaking change #141: reject assign syntax in `init`
(which was used to initialize late resources)
- Refactors code generation to make it more readable -- there are no more random
identifiers in the output -- and align it with the book description of RTFM
internals.
- Makes the framework hard depend on `core::mem::MaybeUninit` and thus will
require nightly until that API is stabilized.
- Fixes a ceiling analysis bug where the priority of the system timer was not
considered in the analysis.
- Shrinks the size of all the internal queues by turning `AtomicUsize` indices
into `AtomicU8`s.
- Removes the integration with `owned_singleton`.
153: add "nightly" feature; replace hint::unreachable_unchecked with a panic r=korken89 a=japaric
this implements the action plan described in #149
to give you a sense of the overhead of this change: it has increased the binary
size of some of our examples by up to 10% but this is mainly from pulling in a
panic handler that does formatting
r? @korken89
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
