rtic/examples/preemption.rs

68 lines
1.4 KiB
Rust
Raw Permalink Normal View History

2017-07-28 05:40:47 +02:00
//! Two tasks running at *different* priorities with access to the same resource
#![deny(unsafe_code)]
#![deny(warnings)]
#![no_std]
extern crate cortex_m_rtfm as rtfm;
extern crate stm32f103xx;
use rtfm::{app, Resource, Threshold};
app! {
device: stm32f103xx,
resources: {
static COUNTER: u64 = 0;
},
tasks: {
2017-07-28 05:40:47 +02:00
// The `SYS_TICK` task has higher priority than `TIM2`
SYS_TICK: {
path: sys_tick,
priority: 2,
resources: [COUNTER],
},
TIM2: {
path: tim2,
priority: 1,
resources: [COUNTER],
},
},
}
fn init(_p: init::Peripherals, _r: init::Resources) {
// ..
}
fn idle() -> ! {
loop {
rtfm::wfi();
}
}
fn sys_tick(_t: &mut Threshold, mut r: SYS_TICK::Resources) {
// ..
2017-07-28 05:40:47 +02:00
// This task can't be preempted by `tim2` so it has direct access to the
// resource data
2017-12-09 13:38:41 +01:00
*r.COUNTER += 1;
// ..
}
fn tim2(t: &mut Threshold, mut r: TIM2::Resources) {
// ..
2017-07-28 05:40:47 +02:00
// As this task runs at lower priority it needs a critical section to
// prevent `sys_tick` from preempting it while it modifies this resource
// data. The critical section is required to prevent data races which can
2017-07-29 07:34:00 +02:00
// lead to undefined behavior.
r.COUNTER.claim_mut(t, |counter, _t| {
// `claim_mut` creates a critical section
2017-12-09 13:38:41 +01:00
*counter += 1;
2017-07-29 07:34:00 +02:00
});
// ..
}