// Device specific peripherals
let _device: lm3s6965::Peripherals = cx.device;
// Locals in `init` have 'static lifetime
let _x: &'static mut u32 = cx.local.x;
// Access to the critical section token,
// to indicate that this is a critical seciton
let _cs_token: bare_metal::CriticalSection = cx.cs;
hprintln!("init").unwrap();
debug::exit(debug::EXIT_SUCCESS);
(Shared {}, Local {}, init::Monotonics())
}
}
Пример init использует устройство lm3s6965. Не забудьте настроить аргумент device в атрибуте макроса app так, чтобы он соответствовал пути к PAC-крейту, если он отличается, а также добавить перифериб и другие аргументы если необходимо. Несмотря на то, что в программе могут использоваться псевдонимы типов, здесь необходимо указать полный путь (из корня крейта). Для многих устройств, есть общий подход в крейтах реализации HAL (с псевдонимом hal) и крейтах поддержки отладочных плат реекспортиорвать PAC как pac, что приводит нас к образцу, аналогичному приведенному ниже:
#![allow(unused)]
fn main() {
use abcd123_hal as hal;
//...
#[rtic::app(device = crate::hal::pac, peripherals = true, monotonic = rtic::cyccnt::CYCCNT)]
mod app { /*...*/ }
}
Пример init также зависит от крейта panic-semihosting:
$ cargo add panic-semihosting
5. Соберите его, загрузите в микроконтроллер и запустите.
$ # ПРИМЕЧАНИЕ: Я раскомментировал опцию `runner` в `.cargo/config`
$ cargo run
init
Советы и хитрости
Обобщенное программирование (Generics)
Все объекты, предоставляющие ресурысы реализуют трейт rtic::Mutex. Если ресурс не реализует его, можно обернуть его в новый тип rtic::Exclusive, который реализует трейт Mutex. С помощью этого нового типа можно написать обобщенную функцию, которая работает с обобщенным ресурсом и вызывать его из различных задач, чтобы производить однотипные операции над похожим множеством ресурсов. Вот один такой пример:
#![allow(unused)]
fn main() {
//! examples/generics.rs
#![deny(unsafe_code)]
#![deny(warnings)]
#![no_main]
#![no_std]
use cortex_m_semihosting::hprintln;
use panic_semihosting as _;
use rtic::Mutex;
#[rtic::app(device = lm3s6965)]
mod app {
use cortex_m_semihosting::{debug, hprintln};
use lm3s6965::Interrupt;
#[shared]
struct Shared {
shared: u32,
}
#[local]
struct Local {}
#[init]
fn init(_: init::Context) -> (Shared, Local, init::Monotonics) {
rtic::pend(Interrupt::UART0);
rtic::pend(Interrupt::UART1);
(Shared { shared: 0 }, Local {}, init::Monotonics())
}
#[task(binds = UART0, shared = [shared], local = [state: u32 = 0])]
fn uart0(c: uart0::Context) {
hprintln!("UART0(STATE = {})", *c.local.state).unwrap();
// second argument has type `shared::shared`
super::advance(c.local.state, c.shared.shared);
rtic::pend(Interrupt::UART1);
debug::exit(debug::EXIT_SUCCESS);
}
#[task(binds = UART1, priority = 2, shared = [shared], local = [state: u32 = 0])]
fn uart1(c: uart1::Context) {
hprintln!("UART1(STATE = {})", *c.local.state).unwrap();
// second argument has type `shared::shared`
super::advance(c.local.state, c.shared.shared);
}
}
// the second parameter is generic: it can be any type that implements the `Mutex` trait
fn advance(state: &mut u32, mut shared: impl Mutex) {
*state += 1;
let (old, new) = shared.lock(|shared: &mut u32| {
let old = *shared;
*shared += *state;
(old, *shared)
});
hprintln!("shared: {} -> {}", old, new).unwrap();
}
}
$ cargo run --example generics
UART1(STATE = 0)
shared: 0 -> 1
UART0(STATE = 0)
shared: 1 -> 2
UART1(STATE = 1)
shared: 2 -> 4
Условная компиляция
Вы можете использовать условную компиляцию (#[cfg]) на ресурсах (полях структуры #[resources] struct Resources) и задачах (элементах fn). Эффект использования атрибутов #[cfg] в том, что ресурс/ задача будут не доступны в соответствующих структурах Context если условие не выполняется.
В примере ниже выводится сообщение каждый раз, когда вызывается задача foo, но только если программы скомпилирова с профилем dev.
#![allow(unused)]
fn main() {
{{#include ../../../../examples/cfg.rs}}
}
$ cargo run --example cfg --release
$ cargo run --example cfg
foo has been called 1 time
foo has been called 2 times
Запуск задач из ОЗУ
Главной целью переноса описания программы на RTIC в атрибуты в RTIC v0.4.x была возможность взаимодействия с другими атрибутами. Напримерe, атрибут link_section можно применять к задачам, чтобы разместить их в ОЗУ; это может улучшить производительность в некоторых случаях.
ВАЖНО: Обычно атрибуты link_section, export_name и no_mangle очень мощные, но их легко использовать неправильно. Неверное использование любого из этих атрибутов может вызвать неопределенное поведение; Вам следует всегда предпочитать использование безопасных, высокоуровневых атрибутов вместо них, таких как атрибуты interrupt и exception из cortex-m-rt.
В особых функций, размещаемых в ОЗУ нет безопасной абстракции в cortex-m-rt v0.6.5 но создано RFC для добавления атрибута ramfunc в будущем релизе.
В примере ниже показано как разместить высокоприоритетную задачу bar в ОЗУ.
#![allow(unused)]
fn main() {
//! examples/ramfunc.rs
#![deny(unsafe_code)]
#![deny(warnings)]
#![no_main]
#![no_std]
use panic_semihosting as _;
#[rtic::app(
device = lm3s6965,
dispatchers = [
UART0,
#[link_section = ".data.UART1"]
UART1
])
]