Skip to content
Snippets Groups Projects
Commit 764a05f7 authored by Per Lindgren's avatar Per Lindgren
Browse files

timing_resources

parent 37c7b33b
No related branches found
No related tags found
No related merge requests found
Show whitespace changes
Inline Side-by-side
examples/timing_resources.rs
+ 188
− 45
View file @ 764a05f7
//! examples/timing_resources.rs
// #![deny(unsafe_code)]
// #![deny(warnings)]
#![deny(warnings)]
#![no_main]
#![no_std]
use core::ptr::read_volatile;
use cortex_m::{asm, peripheral::DWT};
use panic_halt as _;
use stm32f4::stm32f411;
......@@ -13,8 +12,10 @@ use stm32f4::stm32f411;
#[rtic::app(device = stm32f411)]
const APP: () = {
struct Resources {
// A resource
dwt: DWT,
#[init(0)]
shared: u64, // non atomic data
}
#[init]
......@@ -22,27 +23,32 @@ const APP: () = {
// Initialize (enable) the monotonic timer (CYCCNT)
cx.core.DCB.enable_trace();
cx.core.DWT.enable_cycle_counter();
rtic::pend(stm32f411::Interrupt::EXTI1);
init::LateResources { dwt: cx.core.DWT }
}
#[idle(resources = [dwt])]
fn idle(mut cx: idle::Context) -> ! {
#[task(binds = EXTI0, resources = [shared], priority = 2)]
fn exti0(cx: exti0::Context) {
asm::bkpt();
*cx.resources.shared += 1;
}
#[task(binds = EXTI1, resources = [dwt, shared], priority = 1)]
fn exti1(mut cx: exti1::Context) {
unsafe { cx.resources.dwt.cyccnt.write(0) };
asm::bkpt();
rtic::pend(stm32f411::Interrupt::EXTI0);
asm::bkpt();
loop {
continue;
}
}
#[task(binds = EXTI0)]
fn exti0(_cx: exti0::Context) {
cx.resources.shared.lock(|shared| {
// asm::bkpt();
*shared += 1;
// asm::bkpt();
});
asm::bkpt();
}
};
// Now we are going to have a look at the scheduling of RTIC tasks
// Now we are going to have a look at the resource management of RTIC.
//
// First create an objdump file:
// > cargo objdump --example timing_resources --release --features nightly -- --disassemble > timing_resources.objdump
......@@ -52,34 +58,35 @@ const APP: () = {
// You should find something like:
//
// 08000232 <EXTI0>:
// 8000232: 00 be bkpt #0
// 8000234: 00 20 movs r0, #0
// 8000236: 80 f3 11 88 msr basepri, r0
// 800023a: 70 47 bx lr
// 8000232: 40 f2 00 01 movw r1, #0
// 8000236: ef f3 11 80 mrs r0, basepri
// 800023a: 00 be bkpt #0
// 800023c: c2 f2 00 01 movt r1, #8192
// 8000240: d1 e9 00 23 ldrd r2, r3, [r1]
// 8000244: 01 32 adds r2, #1
// 8000246: 43 f1 00 03 adc r3, r3, #0
// 800024a: c1 e9 00 23 strd r2, r3, [r1]
// 800024e: 80 f3 11 88 msr basepri, r0
// 8000252: 70 47 bx lr
//
// Explain what is happening here in your own words.
//
// The application triggers the `exti0` task from `idle`, let's see
// how that pans out.
// [Your code here]
//
// > cargo run --example timing_resources --release --features nightly
// Then continue to the first breakpoint instruction:
// (gdb) c
// timing_resources::idle (cx=...) at examples/timing_resources.rs:32
// 32 asm::bkpt();
// Program
// received signal SIGTRAP, Trace/breakpoint trap.
// timing_resources::exti1 (cx=...) at examples/timing_resources.rs:39
// 39 asm::bkpt();
//
// (gdb) x 0xe0001004
// 0
//
// Here we see, that we have successfully set the cycle counter to zero.
// The `rtic::pend(stm32f411::Interrupt::EXTI0)` "emulates" the
// arrival/triggering of an external interrupt associated with
// the `exti0` task.
// 2
//
// (gdb) c
// timing_resources::APP::EXTI0 () at examples/timing_resources.rs:13
// 13 #[rtic::app(device = stm32f411)]
//
// Since `exti0` has a default prio = 1, it will preempt `idle` (at prio = 0),
// and the debugger breaks in the `exti0` task.
// received signal SIGTRAP, Trace/breakpoint trap.
// rtic::export::run<closure-0> (priority=2, f=...) at /home/pln/.cargo/registry/src/github.com-1ecc6299db9ec823/cortex-m-rtic-0.5.5/src/export.rs:38
//
// (gdb) x 0xe0001004
//
......@@ -92,9 +99,6 @@ const APP: () = {
// You should see that we hit the breakpoint in `exti0`, and
// that the code complies to the objdump EXTI disassembly.
//
// Confer to the document:
// https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/beginner-guide-on-interrupt-latency-and-interrupt-latency-of-the-arm-cortex-m-processors
//
// What was the software latency observed to enter the task?
//
// [Your answer here]
......@@ -103,20 +107,159 @@ const APP: () = {
//
// [Your answer here]
//
// The debugger reports that the breakpoint was hit in the `run<closure>`.
// The reason is that the RTIC implements the actual interrupt handler,
// from within it calls a function `run` taking the user task as a function.
//
// (Functions in Rust can be seen as closures without captured variables.)
//
// Now we can continue to measure the round trip time.
//
// (gdb) c
// timing_resources::idle (cx=...) at examples/timing_resources.rs:34
// 34 asm::bkpt();
//
// received signal SIGTRAP, Trace/breakpoint trap.
// timing_resources::exti1 (cx=...) at examples/timing_resources.rs:41
// 41 asm::bkpt();
//
// (gdb) x 0xe0001004
//
// [Your answer here]
//
// You should have a total execution time in the range of 30-40 cycles.
//
// Explain the reason (for this case) that resource access in
// `exti0` was safe without locking the resource.
//
// [Your answer here]
//
// In `exti1` we also access `shared` but this time through a lock.
//
// (gdb) disassemble
// => 0x08000270 <+28>: bkpt 0x0000
// 0x08000272 <+30>: msr BASEPRI, r0
// 0x08000276 <+34>: movw r0, #0
// 0x0800027a <+38>: movt r0, #8192 ; 0x2000
// 0x0800027e <+42>: ldrd r2, r3, [r0]
// 0x08000282 <+46>: adds r2, #1
// 0x08000284 <+48>: adc.w r3, r3, #0
// 0x08000288 <+52>: strd r2, r3, [r0]
// 0x0800028c <+56>: movs r0, #240 ; 0xf0
// 0x0800028e <+58>: msr BASEPRI, r0
// 0x08000292 <+62>: bkpt 0x0000
// 0x08000294 <+64>: msr BASEPRI, r1
// 0x08000298 <+68>: bx lr
//
// We can now execute the code to the next breakpoint to get the
// execution time of the lock.
//
// (gdb) c
// timing_resources::idle (cx=...) at examples/timing_resources.rs:36
// 36 asm::bkpt();
//
// (gdb) x 0xe0001004
//
// [Your answer here]
//
// Calculate the total time (in cycles), for this section of code.
//
// [Your answer here]
//
// You should get a value around 15 cycles.
//
// Now look at the "critical section", i.e., how many cycles
// are the lock held?
// To this end you need to insert `asm::bkpt()` on entry and exit
// inside the closure.
//
// cx.resources.shared.lock(|shared| {
// asm::bkpt();
// *shared += 1;
// asm::bkpt();
// });
//
// Change the code, and compile it from withing gdb
//
// If you debug in vscode, just Shift-F5 to terminate session, and F5 to start debugging.
//
// If debugging in terminal you may recompile without exiting the debug session:
//
// (gdb) shell cargo build --example timing_resources --release --features nightly
// Compiling app v0.1.0 (/home/pln/courses/e7020e/app)
// Finished release [optimized + debuginfo] target(s) in 0.32s
//
// and load the newly compiled executable:
// (gdb) load
// ...
// Transfer rate: 1 KB/sec, 406 bytes/write.
//
// Now you can continue until you hit the first breakpoint in the lock closure.
//
// (gdb) c
//
// received signal SIGTRAP, Trace/breakpoint trap.
// timing_resources::exti1::{{closure}} (shared=<optimized out>) at examples/timing_resources.rs:43
// 43 asm::bkpt();
//
// (gdb) x 0xe0001004
//
// [Your answer here]
//
// (gdb) c
//
// received signal SIGTRAP, Trace/breakpoint trap.
// timing_resources::exti1::{{closure}} (shared=0x20000000 <timing_resources::APP::shared>) at examples/timing_resources.rs:45
// 45 asm::bkpt();
//
// (gdb) x 0xe0001004
//
// [Your answer here]
//
// Looking at the EXTI0 (exti0) code, we see two additional
// instructions used to restore the BASEPRI register.
// This OH will be removed in next release of RTIC.
// So we can conclude RTIC to have a 2-cycle OH (in this case).
// (In the general case, as we will see later restoring BASEPRI
// is actually necessary so its just this corner case that is
// sub-optimal.)
// From a real-time perspective the critical section infers
// blocking (of higher priority tasks).
//
// How many clock cycles is the blocking?
//
// [Your answer here]
//
// Finally continue out of the closure.
//
// (gdb) c
// received signal SIGTRAP, Trace/breakpoint trap.
// timing_resources::exti1 (cx=...) at examples/timing_resources.rs:47
//
// (gdb) x 0xe0001004
//
// [Your answer here]
//
// This is the total execution time of.
//
// - pending a task `exti0` for execution
// - preempt `exti1`
// - inside `exti0` safely access and update a shared (non atomic) resource.
// - returning to `exti1`
// - inside `exti1` safely access and update a shared (non atomic) resource
//
// Notice here, the breakpoints infer some OH and may disable
// some potential LLVM optimizations, so we obtain a "safe" (pessimistic) estimate.
//
// http://www.diva-portal.se/smash/get/diva2:1005680/FULLTEXT01.pdf
//
// You find a comparison to a typical threaded counterpart `freeRTOS` in Table 1.
//
// Give a rough estimate based on this info how long the complete task `uart1`,
// would take to execute if written in FreeRTOS. (Include the context switch, to higher
// prio task, the mutex lock/unlock in both "threads".)
//
// Motivate your answer (not just a number).
//
// [Your answer here]
//
// Notice, the Rust implementation is significantly faster than the C code version
// of Real-Time For the Masses back in 2013.
//
// Why do you think RTIC + Rust + LLVM can do a better job than hand written
// C code + Macros + gcc?
//
// (Hint, what possible optimization can safely be applied.)
//
// [Your answer here]
examples/timing_resources2.rs deleted 100644 → 0
+ 0
− 253
View file @ 37c7b33b
//! examples/timing_resources.rs
// #![deny(unsafe_code)]
#![deny(warnings)]
#![no_main]
#![no_std]
use cortex_m::peripheral::DWT;
//use cortex_m::{asm, peripheral::DWT};
use panic_halt as _;
use stm32f4::stm32f411;
#[rtic::app(device = stm32f411)]
const APP: () = {
struct Resources {
dwt: DWT,
#[init(0)]
shared: u64, // non atomic data
}
#[init]
fn init(mut cx: init::Context) -> init::LateResources {
// Initialize (enable) the monotonic timer (CYCCNT)
cx.core.DCB.enable_trace();
cx.core.DWT.enable_cycle_counter();
init::LateResources { dwt: cx.core.DWT }
}
#[idle(resources = [shared])]
fn idle(_cx: idle::Context) -> ! {
// unsafe { cx.resources.dwt.cyccnt.write(0) };
// // asm::bkpt();
// rtic::pend(stm32f411::Interrupt::EXTI0);
// // asm::bkpt();
// cx.resources.shared.lock(|shared| {
// // asm::bkpt();
// *shared += 1;
// // asm::bkpt();
// });
// asm::bkpt();
loop {
continue;
}
}
#[task(binds = EXTI0, resources = [shared], priority = 2)]
fn exti0(cx: exti0::Context) {
// asm::bkpt();
*cx.resources.shared += 1;
}
#[task(binds = EXTI1, resources = [dwt, shared], priority = 1)]
fn exti1(mut cx: exti1::Context) {
unsafe { cx.resources.dwt.cyccnt.write(0) };
// asm::bkpt();
rtic::pend(stm32f411::Interrupt::EXTI0);
// asm::bkpt();
cx.resources.shared.lock(|shared| {
// asm::bkpt();
*shared += 1;
// asm::bkpt();
});
// asm::bkpt();
}
};
// Now we are going to have a look at the resource management of RTIC.
//
// First create an objdump file:
// > cargo objdump --example timing_resources --release --features nightly -- --disassemble > timing_resources.objdump
//
// Lookup the EXTI0 symbol (RTIC binds the exti0 task to the interrupt vector).
//
// You should find something like:
//
// 080002b6 <EXTI0>:
// 80002b6: 40 f2 00 00 movw r0, #0
// 80002ba: 00 be bkpt #0
// 80002bc: c2 f2 00 00 movt r0, #8192
// 80002c0: d0 e9 00 12 ldrd r1, r2, [r0]
// 80002c4: 01 31 adds r1, #1
// 80002c6: 42 f1 00 02 adc r2, r2, #0
// 80002ca: c0 e9 00 12 strd r1, r2, [r0]
// 80002ce: 00 20 movs r0, #0
// 80002d0: 80 f3 11 88 msr basepri, r0
// 80002d4: 70 47 bx lr
//
// Explain what is happening here in your own words.
//
// [Your code here]
//
// > cargo run --example timing_resources --release --features nightly
// Then continue to the first breakpoint instruction:
// (gdb) c
// timing_resources::idle (cx=...) at examples/timing_resources.rs:32
// 32 asm::bkpt();
//
// (gdb) x 0xe0001004
// 0
//
// (gdb) c
// timing_resources::exti0 (cx=...) at examples/timing_resources.rs:44
// 44 asm::bkpt();
//
// (gdb) x 0xe0001004
//
// [Your answer here]
//
// (gdb) disassemble
//
// [Your answer here]
//
// You should see that we hit the breakpoint in `exti0`, and
// that the code complies to the objdump EXTI disassembly.
//
// What was the software latency observed to enter the task?
//
// [Your answer here]
//
// Does RTIC infer any overhead?
//
// [Your answer here]
//
// Now we can continue to measure the round trip time.
//
// (gdb) c
//
// (gdb) x 0xe0001004
// timing_resources::idle (cx=...) at examples/timing_resources.rs:34
// 34 asm::bkpt();
//
// [Your answer here]
//
// You should have a total execution time in the range of 30 cycles.
//
// Explain the reason (for this case) that resource access in
// `exti0` was safe without locking the resource.
//
// [Your answer here]
//
// In `idle` we also access `shared` but this time through a lock.
//
// (gdb) disassemble
// => 0x0800026e <+26>: bkpt 0x0000
// 0x08000270 <+28>: ldrb r2, [r0, #0]
// 0x08000272 <+30>: cbz r2, 0x800028c <timing_resources::idle+56>
// 0x08000274 <+32>: movw r0, #0
// 0x08000278 <+36>: movt r0, #8192 ; 0x2000
// 0x0800027c <+40>: ldrd r1, r2, [r0]
// 0x08000280 <+44>: adds r1, #1
// 0x08000282 <+46>: adc.w r2, r2, #0
// 0x08000286 <+50>: strd r1, r2, [r0]
// 0x0800028a <+54>: b.n 0x80002b2 <timing_resources::idle+94>
// 0x0800028c <+56>: movs r2, #1
// 0x0800028e <+58>: movw r12, #0
// 0x08000292 <+62>: strb r2, [r0, #0]
// 0x08000294 <+64>: movs r2, #240 ; 0xf0
// 0x08000296 <+66>: msr BASEPRI, r2
// 0x0800029a <+70>: movt r12, #8192 ; 0x2000
// 0x0800029e <+74>: ldrd r3, r2, [r12]
// 0x080002a2 <+78>: adds r3, #1
// 0x080002a4 <+80>: adc.w r2, r2, #0
// 0x080002a8 <+84>: strd r3, r2, [r12]
// 0x080002ac <+88>: msr BASEPRI, r1
// 0x080002b0 <+92>: strb r1, [r0, #0]
// 0x080002b2 <+94>: bkpt 0x0000
//
// We can now execute the code to the next breakpoint to get the
// execution time of the lock.
//
// (gdb) c
// timing_resources::idle (cx=...) at examples/timing_resources.rs:36
// 36 asm::bkpt();
//
// (gdb) x 0xe0001004
//
// [Your answer here]
//
// Calculate the total time (in cycles), for this section of code.
//
// [Your answer here]
//
// You should get a value around 25 cycles.
//
// Now look at the "critical section", i.e., how many cycles
// are the lock held?
// To this end you need to insert `asm::bkpt()` on entry and exit
// inside the closure.
//
// cx.resources.shared.lock(|shared| {
// asm::bkpt();
// *shared += 1;
// asm::bkpt();
// });
//
// Change the code, and compile it from withing gdb
// (gdb) shell cargo build --example timing_resources --release --features nightly
// Compiling app v0.1.0 (/home/pln/courses/e7020e/app)
// Finished release [optimized + debuginfo] target(s) in 0.32s
//
// and load the newly compiled executable:
// (gdb) load
// ...
// Transfer rate: 1 KB/sec, 406 bytes/write.
//
// Now you can continue until you hit the first breakpoint in the lock closure.
//
// (gdb) c
// rtic::export::lock<u64,(),closure-0> (ptr=<optimized out>, priority=0x2000ffef, ceiling=1, nvic_prio_bits=4, f=...) at /home/pln/.cargo/registry/src/github.com-1ecc6299db9ec823/cortex-m-0.6.4/src/asm.rs:11
// 11 () => unsafe { llvm_asm!("bkpt" :::: "volatile") },
//
// (gdb) x 0xe0001004
//
// [Your answer here]
//
// (gdb) c
// rtic::export::lock<u64,(),closure-0> (ptr=<optimized out>, priority=0x2000ffef, ceiling=1, nvic_prio_bits=4, f=...) at /home/pln/.cargo/registry/src/github.com-1ecc6299db9ec823/cortex-m-0.6.4/src/asm.rs:11
// 11 () => unsafe { llvm_asm!("bkpt" :::: "volatile") },
//
// (gdb) x 0xe0001004
//
// [Your answer here]
//
// From a real-time perspective the critical section infers
// blocking (of higher priority tasks).
//
// How many clock cycles is the blocking?
//
// [Your answer here]
//
// Finally continue out of the closure.
//
// (gdb) c
// timing_resources::idle (cx=...) at examples/timing_resources.rs:40
// 40 asm::bkpt();
//
// (gdb) x 0xe0001004
//
// [Your answer here]
//
// This is the total execution time of.
//
// - pending a task `exti` for execution
// - preempt `idle`
// - inside `exti` safely access and update a shared (non atomic resource).
// - returning to `idle`
// - safely access and update a shared (non atomic) resource
//
// Notice here, the breakpoints infer some OH and may disable
// some potential LLVM optimizations.
//
//
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment