.cargo/config

@@ -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

examples/rtt_timing.rs

@@ -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

src/main.rs

@@ -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);
+//    }
+//}