405: Updated migration guide with symmetric locks and new spawn r=AfoHT a=korken89
406: book.toml/by-example/app r=korken89 a=perlindgren
Book update
Co-authored-by: Emil Fresk <emil.fresk@gmail.com>
Co-authored-by: Per Lindgren <per.lindgren@ltu.se>
402: Extern task r=AfoHT a=perlindgren
Allows hardware and software task to be externally declared.
CI test, don't merge yet (squash needed).
Co-authored-by: Per Lindgren <per.lindgren@ltu.se>
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>
