390: Spawn and schedule from anywhere r=AfoHT a=korken89
This PR moves RTIC to the spawn and schedule from anywhere syntax.
Notable changes:
* We do no longer support non-`Send` types.
* Some extra code is generated as any task may spawn/schedule any task. However Rust/LLVM does a great job optimizing away non used instantiations (no real code-size difference observed).
* Worst case priority inversion has increased, but it is now predictable.
Upsides:
* With this we should be able to support async/await.
* RTIC tasks can now be callbacks (spawned and scheduled).
* RTIC tasks can be stored.
Needs the following PR to land first: https://github.com/rtic-rs/rtic-syntax/pull/34
The following now works:
```rust
#[rtic::app(device = lm3s6965, monotonic = rtic::cyccnt::CYCCNT)]
mod app {
#[init]
fn init(mut cx: init::Context) -> init::LateResources {
// Init stuff...
// New spawn syntax
foo::spawn().unwrap();
// New schedule syntax
bar::schedule(now + 4_000_000.cycles()).unwrap();
init::LateResources {}
}
#[task]
fn foo(_: foo::Context) {}
#[task]
fn bar(_: bar::Context) {}
extern "C" {
fn SSI0();
}
}
```
Co-authored-by: Per Lindgren <per.lindgren@ltu.se>
Co-authored-by: Emil Fresk <emil.fresk@gmail.com>
395: Made relation between priority and number explicit r=korken89 a=diondokter
When quickly reading through the priorities chapter, I couldn't find in which order the priorities were, so I assumed it was the same as in the hardware.
In the cortex-m hardware, interrupts with the **lower** priority number will preempt the other interrupts.
RTIC does the reverse, so I think it's good to be more explicit about it.
Co-authored-by: Dion Dokter <diondokter@gmail.com>
371: task_local and lock_free r=korken89 a=AfoHT
Getting this going to test with GHA
For further discussion see https://github.com/rtic-rs/rfcs/issues/30
Co-authored-by: Per <Per Lindgren>
Co-authored-by: Henrik Tjäder <henrik@tjaders.com>
When quickly reading through the priorities chapter, I couldn't find in which order the priorities were, so I assumed it was the same as in the hardware.
In the cortex-m hardware, interrupts with the **lower** priority number will preempt the other interrupts.
RTIC does the reverse, so I think it's good to be more explicit about it.
394: Detect if the rt flag is defined in the PAC/HAL r=AfoHT a=korken89
This stops RTIC applications from compiling if one has forgotten to set the `rt` flag in the PAC/HAL.
The error:
```
error[E0433]: failed to resolve: could not find `interrupt` in `you_must_enable_the_rt_feature_for_the_pac_in_your_cargo_toml`
--> src/main.rs:8:1
|
8 | #[rtic::app(device = stm32l4xx_hal::pac)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ could not find `interrupt` in `you_must_enable_the_rt_feature_for_the_pac_in_your_cargo_toml`
|
= note: this error originates in an attribute macro (in Nightly builds, run with -Z macro-backtrace for more info)
```
Co-authored-by: Emil Fresk <emil.fresk@gmail.com>
392: device path must be absolute; clarify r=AfoHT a=dcarosone
feel free to nitpick path terminology
Co-authored-by: Daniel Carosone <Daniel.Carosone@gmail.com>
