The codegen generated code for all executors in all
dispatchers, which caused some weird bugs.
Also the definition of an executor was not generated
globally, this caused use after free errors when having
multiple priority levels.
652: Remove use of basepri register on thumbv8m.base r=AfoHT a=neonquill
The basepri register appears to be aviable on thumbv8m.main but not thumbv8m.base. At the very least, attempting to compile against a Cortex-M23 based Microchip ATSAML10E16A generates an error:
```
error[E0432]: unresolved import `cortex_m::register::basepri`
--> /Users/dwatson/.cargo/registry/src/github.com-1ecc6299db9ec823/cortex-m-rtic-1.1.3/src/export.rs:25:5
|
25 | use cortex_m::register::basepri;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `basepri` in `register`
```
I wasn't sure if it made more sense to replace the `armv7m` config flag with something related to basepri availability or to get closer to matching the cortex-m use of several architecture specific flags. In the end i chose to make the minimal change possible and just narrowed the existing `thumbv8m` check.
Context:
[cortex-m:src/register/mod.rs](4e90862520/src/register/mod.rs (L33)):
```
#[cfg(all(not(armv6m), not(armv8m_base)))]
pub mod basepri;
```
[cortex-m:build.rs](4e90862520/build.rs (L21)):
```
} else if target.starts_with("thumbv8m.base") {
println!("cargo:rustc-cfg=cortex_m");
println!("cargo:rustc-cfg=armv8m");
println!("cargo:rustc-cfg=armv8m_base");
```
Co-authored-by: David Watson <david@neonquill.com>
The basepri register appears to be aviable on thumbv8m.main but not
thumbv8m.base. At the very least, attempting to compile against a
Cortex-M23 based Microchip ATSAML10E16A generates an error:
```
error[E0432]: unresolved import `cortex_m::register::basepri`
--> /Users/dwatson/.cargo/registry/src/github.com-1ecc6299db9ec823/cortex-m-rtic-1.1.3/src/export.rs:25:5
|
25 | use cortex_m::register::basepri;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `basepri` in `register`
```
This is an attempt to account for the fact that thumbv8m.base (M23)
MCUs don't have the BASEPRI register but have more than 32
interrupts. This moves away from the architecture specific config
flags and switches to a more functional flag.
Make the mask size depend on the max interrupt id
Rather than assuming a fixed interrupt count of 32 this code uses an
array of u32 bitmasks to calculate the priority mask. The size of this
array is calculated at compile time based on the size of the largest
interrupt id being used in the target code. For thumbv6m this should
be equivalent to the previous version that used a single u32 mask. For
thumbv8m.base it will be larger depending on the interrupts used.
Don't write 0s to the ISER and ICER registers
Writing 0s to these registers is a no-op. Since these masks should be
calculated at compile time, this conditional should result in writes
being optimized out of the code.
Prevent panic on non-arm targets
Panicking on unknown targets was breaking things like the doc build on
linux. This change should only panic when building on unknown arm
targets.
653: Allow custom `link_section` attributes for late resources r=AfoHT a=vccggorski
This commit makes RTIC aware of user-provided `link_section` attributes,
letting user override default section mapping.
Co-authored-by: Gabriel Górski <gabriel.gorski@volvocars.com>
649: Bump rtic-syntax to v1.0.2 and fix Changelog r=korken89 a=AfoHT
Use the latest rtic-syntax, update the changelog with the last few undocumented releases
Co-authored-by: Henrik Tjäder <henrik@grepit.se>
645: fix ci: use SYST::PTR r=korken89 a=japaric
SYST::ptr has been deprecated in cortex-m v0.7.5
SYST::PTR is available since cortex-m v0.7.0
CI was failing due to a warning turned into an error by `deny(warnings)`
Co-authored-by: Jorge Aparicio <jorge.aparicio@ferrous-systems.com>
635: Masks take 3 r=AfoHT a=korken89
This solves the `MASKS` generation issue by having `rtic::export` do the feature gating.
Co-authored-by: Emil Fresk <emil.fresk@gmail.com>
589: Fine grained concurrency on thumbv6m (no BASEPRI). r=korken89 a=perlindgren
This is an experimental implementation of SRP based scheduling on the M0/M0+ (thumbv6m) architecture.
The aim is a (sub)-zero abstraction to the resource protection (locking mechanism).
Please try, but not merge yet, since its an early POC.
Co-authored-by: Per Lindgren <per.lindgren@ltu.se>
