mirror of
https://github.com/rtic-rs/rtic.git
synced 2025-12-19 14:25:18 +01:00
Merge #368
368: Mod over const r=korken89 a=AfoHT Related [RFC](https://github.com/rtic-rs/rfcs/pull/34) Dependent on [rtic-syntax-PR30](https://github.com/rtic-rs/rtic-syntax/pull/30) ~~Currently using my own dev-branch~~ Co-authored-by: Henrik Tjäder <henrik@tjaders.com>
This commit is contained in:
commit
dbf9a7f298
77 changed files with 638 additions and 333 deletions
|
|
@ -7,7 +7,7 @@ This is the smallest possible RTIC application:
|
|||
```
|
||||
|
||||
All RTIC applications use the [`app`] attribute (`#[app(..)]`). This attribute
|
||||
must be applied to a `const` item that contains items. The `app` attribute has
|
||||
must be applied to a `mod`-item. The `app` attribute has
|
||||
a mandatory `device` argument that takes a *path* as a value. This path must
|
||||
point to a *peripheral access crate* (PAC) generated using [`svd2rust`]
|
||||
**v0.14.x** or newer. The `app` attribute will expand into a suitable entry
|
||||
|
|
@ -17,16 +17,9 @@ point so it's not required to use the [`cortex_m_rt::entry`] attribute.
|
|||
[`svd2rust`]: https://crates.io/crates/svd2rust
|
||||
[`cortex_m_rt::entry`]: ../../../api/cortex_m_rt_macros/attr.entry.html
|
||||
|
||||
> **ASIDE**: Some of you may be wondering why we are using a `const` item as a
|
||||
> module and not a proper `mod` item. The reason is that using attributes on
|
||||
> modules requires a feature gate, which requires a nightly toolchain. To make
|
||||
> RTIC work on stable we use the `const` item instead. When more parts of macros
|
||||
> 1.2 are stabilized we'll move from a `const` item to a `mod` item and
|
||||
> eventually to a crate level attribute (`#![app]`).
|
||||
|
||||
## `init`
|
||||
|
||||
Within the pseudo-module the `app` attribute expects to find an initialization
|
||||
Within the `app` module the attribute expects to find an initialization
|
||||
function marked with the `init` attribute. This function must have signature
|
||||
`fn(init::Context) [-> init::LateResources]` (the return type is not always
|
||||
required).
|
||||
|
|
@ -62,7 +55,7 @@ $ cargo run --example init
|
|||
## `idle`
|
||||
|
||||
A function marked with the `idle` attribute can optionally appear in the
|
||||
pseudo-module. This function is used as the special *idle task* and must have
|
||||
module. This function is used as the special *idle task* and must have
|
||||
signature `fn(idle::Context) - > !`.
|
||||
|
||||
When present, the runtime will execute the `idle` task after `init`. Unlike
|
||||
|
|
|
|||
|
|
@ -4,11 +4,13 @@ The framework provides an abstraction to share data between any of the contexts
|
|||
we saw in the previous section (task handlers, `init` and `idle`): resources.
|
||||
|
||||
Resources are data visible only to functions declared within the `#[app]`
|
||||
pseudo-module. The framework gives the user complete control over which context
|
||||
module. The framework gives the user complete control over which context
|
||||
can access which resource.
|
||||
|
||||
All resources are declared as a single `struct` within the `#[app]`
|
||||
pseudo-module. Each field in the structure corresponds to a different resource.
|
||||
module. Each field in the structure corresponds to a different resource.
|
||||
The `struct` must be annotated with the following attribute: `#[resources]`.
|
||||
|
||||
Resources can optionally be given an initial value using the `#[init]`
|
||||
attribute. Resources that are not given an initial value are referred to as
|
||||
*late* resources and are covered in more detail in a follow-up section in this
|
||||
|
|
|
|||
|
|
@ -95,7 +95,7 @@ following snippet:
|
|||
|
||||
``` rust
|
||||
#[rtic::app(..)]
|
||||
const APP: () = {
|
||||
mod app {
|
||||
#[init(spawn = [foo, bar])]
|
||||
fn init(cx: init::Context) {
|
||||
cx.spawn.foo().unwrap();
|
||||
|
|
@ -116,5 +116,5 @@ const APP: () = {
|
|||
fn bar(cx: bar::Context, payload: i32) {
|
||||
// ..
|
||||
}
|
||||
};
|
||||
}
|
||||
```
|
||||
|
|
|
|||
|
|
@ -143,7 +143,7 @@ $ tail target/rtic-expansion.rs
|
|||
|
||||
``` rust
|
||||
#[doc = r" Implementation details"]
|
||||
const APP: () = {
|
||||
mod app {
|
||||
#[doc = r" Always include the device crate which contains the vector table"]
|
||||
use lm3s6965 as _;
|
||||
#[no_mangle]
|
||||
|
|
@ -156,7 +156,7 @@ const APP: () = {
|
|||
rtic::export::wfi()
|
||||
}
|
||||
}
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
Or, you can use the [`cargo-expand`] sub-command. This sub-command will expand
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Types, Send and Sync
|
||||
|
||||
Every function within the `APP` pseudo-module has a `Context` structure as its
|
||||
Every function within the `app` module has a `Context` structure as its
|
||||
first parameter. All the fields of these structures have predictable,
|
||||
non-anonymous types so you can write plain functions that take them as arguments.
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue