This commit fixes a ceiling bug where the ceiling of a ready queue will be
incorrectly computed. The analysis was not including the priority of the system
timer interrupt (`SysTick`) in the analysis resulting in a priority ceiling
lower than what's required for memory safety which led to data races.
The bug can be observed in the following program:
``` rust
#[rtfm::app(device = /* .. */)]
const APP: () = {
#[init]
fn init() {
// ..
}
#[task(priority = 2)]
fn foo(x: i32) {
// ..
}
#[task(priority = 1, spawn = [foo], schedule = [foo])]
fn bar() {
// ..
}
extern "C" {
fn EXTI0();
fn EXTI1();
}
};
```
Here the framework chooses a priority of `2` for the `SysTick` interrupt
(because it matches the priority of the `schedule`-able task `foo`).
Both `SysTick` and `bar::Spawn.foo` need to access the ready queue (which, in
this case, stores the messages sent to task `foo`) but the framework doesn't
account for the priority of `SysTick` (`2`) and chooses a priority ceiling of
`1` for the ready queue (because it matches the priority of task `bar` which can
spawn `foo`).
The result is that `bar::Spawn.foo` modifies the ready queue *without* a
critical section (because `bar`'s priority matches the priority ceiling of the
ready queue) which is wrong because `SysTick` (priority = `3`) can also modify
the ready queue.
170: check task priority at compile time r=TeXitoi a=japaric
before we were checking the priority at runtime. The compile time error message
when the priority is too high is kind of awful though.
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
This program was being accepted:
``` rust
#[task(
capacity = 1,
capacity = 2,
priority = 1,
priority = 2,
)]
fn foo() {}
```
now it will trigger a compiler error
closes#69
this doesn't change functionality per se but improves diagnostics in some cases. Some hard errors
have becomes warnings, for example: when `resources` is empty, or when `idle.path` is set to the
default `idle` path.
