Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found
Select Git revision
  • master
  • rtic6
2 results

Target

Select target project
  • pln/rtic_f4xx_nucleo
  • ironedde/rtic_f4xx_nucleo
  • inaule-6/rtic_f4xx_nucleo
  • rubenasplund/rtic_f4xx_nucleo
4 results
Select Git revision
  • master
  • rtic6
2 results
Show changes
Commits on Source (4)
......@@ -6,9 +6,9 @@
# uncomment ONE of these three option to make `cargo run` start a GDB session
# which option to pick depends on your system
# runner = "arm-none-eabi-gdb -q -x openocd.gdb"
# runner = "gdb-multiarch -q -x openocd.gdb"
runner = "gdb-multiarch -q -x openocd.gdb"
# runner = "gdb -q -x openocd.gdb"
runner = "probe-run --chip STM32F411RETx"
# runner = "probe-run --chip STM32F411RETx"
rustflags = [
# This is needed if your flash or ram addresses are not aligned to 0x10000 in memory.x
......
......@@ -60,37 +60,57 @@ fn timed_loop() -> (u32, u32) {
// ------------------------------------------------------------------------
// Exercises:
//
// start 2987, end 4793139, diff 4790152
//
// A.1) What is the cycle count for the loop?
// > cargo run --example rtt_timing
//
// [Your answer here]
// 2987
//
// A.2) How many cycles per iteration?
//
// [Your answer here]
// 4790152
//
// A.3) Why do we need a wrapping subtraction?
//
// [Your answer here]
// If end value has wrapped around then start > end. Thus we need to wrap around when we subtract so we get the correct difference value.
//
// ------------------------------------------------------------------------
// Now try a release (optimized build, see `Cargo.toml` for build options).
// B.1) What is the cycle count for the loop?
// > cargo run --example rtt_timing --release
//
// start 30305915, end 30375916, diff 70001
//
// [Your answer here]
// 30305915
//
// B.2) How many cycles per iteration?
//
// [Your answer here]
// 70001
//
// What is the speedup (A/B)?
//
// [Your answer here]
// 4790152 / 70001 = 68.4297652891
//
//
// Why do you think it differs that much?
//
// [Your answer here]
// I think that the optimizer removes the for loop:
// for _ in 0..10000 {
// asm::nop();
// }
// Thus the end variable is set right after the start variable. This makes the time difference very
// small. But it is not near 10000 time faster because the function DWT::get_cycle_count() is much
// slower at getting the cycle count then it is to run one iteration of the loop.
//
//
//
// ------------------------------------------------------------------------
// In the loop there is just a single assembly instruction (nop).
......@@ -112,15 +132,20 @@ fn timed_loop() -> (u32, u32) {
// C.1) What is the cycle count for the loop?
// > cargo run --example rtt_timing --release --features nightly
//
// start 1356808538, end 1356848539, diff 40001
//
// [Your answer here]
// 1356808538
//
// C.2) How many cycles per iteration?
//
// [Your answer here]
// 40001
//
// What is the speedup (A/C)?
//
// [Your answer here]
// 4790152 / 40001 = 119.75080623
//
// ------------------------------------------------------------------------
// D) Now lets have a closer look at the generated assembly.
......@@ -131,6 +156,17 @@ fn timed_loop() -> (u32, u32) {
//
// [Assembly for function `timed_loop` here]
//
// 08000232 <timed_loop>:
// 8000232: movw r1, #4100
// 8000236: movw r2, #10000
// 800023a: movt r1, #57344
// 800023e: ldr r0, [r1]
// 8000240: subs r2, #1
// 8000242: nop
// 8000244: bne #-8 <timed_loop+0xe>
// 8000246: ldr r1, [r1]
// 8000248: bx lr
//
// Locate the loop body, and verify that it makes sense
// based on the information from the technical documentation:
//
......@@ -198,11 +234,45 @@ fn timed_loop() -> (u32, u32) {
// https://developer.arm.com/documentation/ddi0439/b/Data-Watchpoint-and-Trace-Unit/DWT-Programmers-Model
//
// [Your answer here]
// No, there is no function call. The two following line loads in the loaction of the cycle count,
// which is always updated. Thus r1 holds the location of the cycle counter.
// 0x08000232 <+0>: movw r1, #4100 ; 0x1004
// 0x0800023a <+8>: movt r1, #57344 ; 0xe000
// Then the two following lines loads in the current cycle value for start(r0) and end(r1).
// 0x0800023e <+12>: ldr r0, [r1, #0]
// 0x08000246 <+20>: ldr r1, [r1, #0]
//
//
// Now check your answer by dumping the registers
// (gdb) info registers
//
// [Register dump here]
// (gdb) info registers
// r0 0x80000000 -2147483648
// r1 0xe0001004 -536866812
// r2 0x2710 10000
// r3 0xa 10
// r4 0x20000000 536870912
// r5 0x20000430 536871984
// r6 0x0 0
// r7 0x2000ffe8 536936424
// r8 0x0 0
// r9 0x0 0
// r10 0x0 0
// r11 0x0 0
// r12 0x1 1
// sp 0x2000ff98 0x2000ff98
// lr 0x8000373 134218611
// pc 0x800023e 0x800023e <rtt_timing::timed_loop+12>
// xPSR 0x81000000 -2130706432
// fpscr 0x0 0
// msp 0x2000ff98 0x2000ff98
// psp 0x0 0x0
// primask 0x1 1
// basepri 0x0 0
// faultmask 0x0 0
// control 0x0 0
//
//
// We can now set a breakpoint exactly at the `nop`.
//
......@@ -228,6 +298,7 @@ fn timed_loop() -> (u32, u32) {
// (gdb) x 0xe0001004
//
// [Your answer here]
// 0x31de3cd8
//
// Now, let's execute one iteration:
// (gdb) continue
......@@ -235,10 +306,12 @@ fn timed_loop() -> (u32, u32) {
// What is now the current value of the cycle counter?
//
// [Your answer here]
// 0x31de3cdc
//
// By how much does the cycle counter increase for each iteration?
//
// [Your answer here]
// 4
//
// ------------------------------------------------------------------------
// F) Reseting the cycle counter
......
This diff is collapsed.
......@@ -21,10 +21,10 @@ const APP: () = {
#[idle]
fn idle(_cx: idle::Context) -> ! {
rprintln!("idle");
// panic!("panic");
loop {
continue;
}
panic!("panic");
// loop {
// continue;
// }
}
};
......@@ -51,6 +51,7 @@ const APP: () = {
// at /home/pln/.cargo/registry/src/github.com-1ecc6299db9ec823/cortex-m-rt-0.6.13/src/lib.rs:526
//
// Make sure you got the expected output
// Awnser: Yes, got the expected output.
//
// C) Panic tracing
// Rust is designed for reliability, with the aim to deliver memory safety
......@@ -64,6 +65,30 @@ const APP: () = {
// What is the output?
//
// [Your answer here]
// Compiling app v0.1.0 (/home/niklas/Desktop/D7020E/rtic_f4xx_nucleo)
// error: unreachable expression
// --> src/main.rs:25:9
// |
// 24 | panic!("panic");
// | ---------------- any code following this expression is unreachable
// 25 | / loop {
// 26 | | continue;
// 27 | | }
// | |_________^ unreachable expression
// |
// note: the lint level is defined here
// --> src/main.rs:4:9
// |
// 4 | #![deny(warnings)]
// | ^^^^^^^^
// = note: `#[deny(unreachable_code)]` implied by `#[deny(warnings)]`
//
// error: aborting due to previous error
//
// error: could not compile `app`
//
// To learn more, run the command again with --verbose.
//
//
// D) Panic halt
// Tracing is nice during development, but requires a debugger attached
......@@ -77,12 +102,37 @@ const APP: () = {
// What is the output?
//
// [Your answer here]
// Compiling app v0.1.0 (/home/niklas/Desktop/D7020E/rtic_f4xx_nucleo)
// Finished dev [unoptimized + debuginfo] target(s) in 0.68s
// Running `probe-run --chip STM32F411RETx target/thumbv7em-none-eabi/debug/app`
// (HOST) INFO flashing program (10.53 KiB)
// (HOST) INFO success!
//────────────────────────────────────────────────────────────────────────────────
//init
//idle
//
//
// Now press Ctrl-C
//
// What is the output?
//
// [Your answer here]
//^Cstack backtrace:
// 0: core::sync::atomic::compiler_fence
// at /home/niklas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/sync/atomic.rs:2644
// 1: rust_begin_unwind
// at /home/niklas/.cargo/registry/src/github.com-1ecc6299db9ec823/panic-halt-0.2.0/src/lib.rs:33
// 2: core::panicking::panic_fmt
// at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/panicking.rs:85
// 3: core::panicking::panic
// at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/panicking.rs:50
// 4: app::idle
// at src/main.rs:24
// 5: main
// at src/main.rs:13
// 6: Reset
// at /home/niklas/.cargo/registry/src/github.com-1ecc6299db9ec823/cortex-m-rt-0.6.13/src/lib.rs:526
//
//
// E) Find the source
// Figure out how to find the source of `panic_halt`, and look at the implementation.
......@@ -92,3 +142,38 @@ const APP: () = {
//
// Paste the implementation here
// [Your answer here]
////! Set the panicking behavior to halt
////!
////! This crate contains an implementation of `panic_fmt` that simply halt in an infinite loop.
////!
////! # Usage
////!
////! ``` ignore
////! #![no_std]
////!
////! extern crate panic_halt;
////!
////! fn main() {
////! panic!("argument is ignored");
////! }
////! ```
////!
////! # Breakable symbols
////!
////! With the panic handler being `#[inline(never)]` the symbol `rust_begin_unwind` will be
////! available to place a breakpoint on to halt when a panic is happening.
//
//#![deny(missing_docs)]
//#![deny(warnings)]
//#![no_std]
//
//use core::panic::PanicInfo;
//use core::sync::atomic::{self, Ordering};
//
//#[inline(never)]
//#[panic_handler]
//fn panic(_info: &PanicInfo) -> ! {
// loop {
// atomic::compiler_fence(Ordering::SeqCst);
// }
//}