Migrating from v0.5.x to v1.0.0
This section describes how to upgrade from v0.5.x to v1.0.0 of the RTIC framework.
Cargo.toml
- version bump
Change the version of cortex-m-rtic
to "1.0.0"
.
mod
instead of const
With the support of attributes on modules the const APP
workaround is not needed.
Change
into
Now that a regular Rust module is used it means it is possible to have custom
user code within that module.
Additionally, it means that use
-statements for resources used in user
code must be moved inside mod app
, or be referred to with super
. For
example, change:
into
or
Move Dispatchers from extern "C"
to app arguments
Change
into
This works also for ram functions, see examples/ramfunc.rs
Resources structs - #[shared]
, #[local]
Previously the RTIC resources had to be in in a struct named exactly "Resources":
With RTIC v1.0.0 the resources structs are annotated similarly like
#[task]
, #[init]
, #[idle]
: with the attributes #[shared]
and #[local]
These structs can be freely named by the developer.
shared
and local
arguments in #[task]
s
In v1.0.0 resources are split between shared
resources and local
resources.
#[task]
, #[init]
and #[idle]
no longer have a resources
argument; they must now use the shared
and local
arguments.
In v0.5.x:
In v1.0.0:
Symmetric locks
Now RTIC utilizes symmetric locks, this means that the lock
method need
to be used for all shared
resource access.
In old code one could do the following as the high priority
task has exclusive access to the resource:
And with symmetric locks one needs to use locks in both tasks:
Note that the performance does not change thanks to LLVM's optimizations which optimizes away unnecessary locks.
Lock-free resource access
In RTIC 0.5 resources shared by tasks running at the same priority could be accessed without the lock
API.
This is still possible in 1.0: the #[shared]
resource must be annotated with the field-level #[lock_free]
attribute.
v0.5 code:
v1.0 code:
no static mut
transform
static mut
variables are no longer transformed to safe &'static mut
references.
Instead of that syntax, use the local
argument in #[init]
.
v0.5.x code:
v1.0.0 code:
Init always returns late resources
In order to make the API more symmetric the #[init]-task always returns a late resource.
From this:
to this:
Spawn from anywhere
With the new spawn/spawn_after/spawn_at interface,
old code requiring the context cx
for spawning such as:
Will now be written as:
Thus the requirement of having access to the context is dropped.
Note that the attributes spawn
/schedule
in the task definition are no longer needed.
Additions
Extern tasks
Both software and hardware tasks can now be defined external to the mod app
.
Previously this was possible only by implementing a trampoline calling out the task implementation.
See examples examples/extern_binds.rs
and examples/extern_spawn.rs
.
This enables breaking apps into multiple files.