283: Include DWT enable in migration guide r=korken89 a=MabezDev
Makes note of the fact the DWT has to be enabled manually in rtfm 0.5.0; an easy one to miss considering debuggers generally enable the DWT automatically.
Co-authored-by: Scott Mabin <scott@mabez.dev>
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.
278: Cyccnt r=texitoi a=perlindgren
The subtractions in `elapsed` and `duration` may cause an overflow panic in debug mode. This is solved by using wrapping arithmetics.
Co-authored-by: Per Lindgren <per.lindgren@ltu.se>
275: fix CI r=perlindgren a=japaric
after caching was enabled binary install through the trust/install.sh script
stopped working (due to permissions?). This updates crate installation to use
`cargo-install` iff the requested version of a crate is not already installed
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
after caching was enabled binary install through the trust/install.sh script
stopped working (due to permissions?). This updates crate installation to use
`cargo-install` iff the requested version of a crate is not already installed
268: CI: replace compiletest-rs with trybuild r=japaric a=japaric
We use compiletest to run compile-fail tests but compiletest depends on compiler
internals so it breaks every now and then and requires nightly. With trybuild we
can also run compile-fail tests but it works on stable and it already has
reached version 1.0
270: Added struct de-structure-ing example in tips & tricks r=japaric a=korken89
As per last meeting, a bare-bones added that we can improve
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
Co-authored-by: Emil Fresk <emil.fresk@gmail.com>
this version is more or less fixed so new releases of Rust (stable or nightly
channel) are unlikely to break to build due to changes in diagnostic messages
We use compiletest to run compile-fail tests but compiletest depends on compiler
internals so it breaks every now and then and requires nightly. With trybuild we
can also run compile-fail tests but it works on stable and it already has
reached version 1.0
266: CI: build 0.4 docs from the v0.4.x branch r=korken89 a=japaric
instead of using a specific tag; this way documentation changes done to the
v0.4.x branch will show up on the site as soon as they land -- right now they
require publishing a new v0.4.x release on crates.io
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
instead of using a specific tag; this way documentation changes done to the
v0.4.x branch will show up on the site as soon as they land -- right now they
require publishing a new v0.4.x release on crates.io and manually updating the
`after-success.sh` build script on master
257: do not zero late resource memory on boot r=korken89 a=japaric
this is done using the `.uninit` linker section; this optimization was already
being applied to message buffers but I forgot to also apply it to late resources
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
255: more monotonic timer docs r=nils-grepit a=japaric
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
cc @jonas-schievink
(EDIT: yay, pull request number 0xFF)
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
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
252: critical sections book: each task gets its own context r=japaric a=chrysn
Fixing what was probably a copy-paste error; different tasks each have different types for their context.
Co-authored-by: chrysn <chrysn@fsfe.org>
254: v0.5.0 beta release r=texitoi a=japaric
this updates all the remaining references to japaric/cortex-m-rtfm, the Cargo metadata and copyright notice. After this PR the crates will be ready for beta release.
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
253: Fix matrix.to web link for the static room view. r=japaric a=tim-seoss
Fix the matrix.to link so that the room history can be viewed in
"Matrix-Static" by users who aren't registered on Matrix (e.g. for
previewing). Hopefully this will also get the room content into search
engines.
n.b. The new matrix.to URL uses the room name instead of the room ID,
because the ID didn't work with Matrix-Static, and the matrix.to README at:
https://github.com/matrix-org/matrix.to says...
"Note that linking to rooms by ID should only be used for rooms to which
the target user has been invited: these links cannot be assumed to work for
all visitors."
Co-authored-by: Tim Small <tim@seoss.co.uk>
Fix the matrix.to link so that the room history can be viewed in
"Matrix-Static" by users who aren't registered on Matrix (e.g. for
previewing). Hopefully this will also get the room content into search
engines.
n.b. The new matrix.to URL uses the room name instead of the room ID,
because the ID didn't work with Matrix-Static, and the matrix.to README at:
https://github.com/matrix-org/matrix.to says...
"Note that linking to rooms by ID should only be used for rooms to which
the target user has been invited: these links cannot be assumed to work for
all visitors."
