* fix included examples and markdown(book) fixes: #911 * fix footnote pre_init * more example link updates * Restore pool example name * Example: pool: Upgrade to heapless v0.8 * Example: pool: thumbv6 unsupported: wild cfg-if Experiment with multi-backend example contained in the example * Example: lm3s6965: Updated cargo.lock * Book: Use cargo xtask for by-example * Docs: Contributing: cargo xtask --------- Co-authored-by: Henrik Tjäder <henrik@tjaders.com>
1.7 KiB
Running tasks from RAM
The main goal of moving the specification of RTIC applications to attributes in RTIC v0.4.0 was to allow inter-operation with other attributes. For example, the link_section
attribute can be applied to tasks to place them in RAM; this can
improve performance in some cases.
IMPORTANT: In general, the
link_section
,export_name
andno_mangle
attributes are powerful but also easy to misuse. Incorrectly using any of these attributes can cause undefined behavior; you should always prefer to use safe, higher level attributes around them likecortex-m-rt
'sinterrupt
andexception
attributes.In the particular case of RAM functions there's no safe abstraction for it in
cortex-m-rt
v0.6.5 but there's an RFC for adding aramfunc
attribute in a future release.
The example below shows how to place the higher priority task, bar
, in RAM.
{{#include ../../../../../examples/lm3s6965/examples/ramfunc.rs}}
Running this program produces the expected output.
$ cargo xtask qemu --verbose --example ramfunc
{{#include ../../../../../ci/expected/lm3s6965/ramfunc.run}}
One can look at the output of cargo-nm
to confirm that bar
ended in RAM
(0x2000_0000
), whereas foo
ended in Flash (0x0000_0000
).
$ cargo nm --example ramfunc --release | grep ' foo::'
{{#include ../../../../../ci/expected/lm3s6965/ramfunc.run.grep.foo}}
$ cargo nm --example ramfunc --target thumbv7m-none-eabi --release | grep '*bar::'
{{#include ../../../../../ci/expected/lm3s6965/ramfunc.run.grep.bar}}