Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
R
rtic_f4xx_nucleo
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Package registry
Model registry
Operate
Environments
Terraform modules
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
GitLab community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
Niklas Lundberg
rtic_f4xx_nucleo
Compare revisions
master to 1941bf50a0428929267c69d850c0bdbf95ca4fc2
Compare revisions
Changes are shown as if the
source
revision was being merged into the
target
revision.
Learn more about comparing revisions.
Source
inaule-6/rtic_f4xx_nucleo
Select target project
No results found
1941bf50a0428929267c69d850c0bdbf95ca4fc2
Select Git revision
Branches
master
rtic6
2 results
Swap
Target
pln/rtic_f4xx_nucleo
Select target project
pln/rtic_f4xx_nucleo
ironedde/rtic_f4xx_nucleo
inaule-6/rtic_f4xx_nucleo
rubenasplund/rtic_f4xx_nucleo
4 results
master
Select Git revision
Branches
master
rtic6
2 results
Show changes
Only incoming changes from source
Include changes to target since source was created
Compare
Commits on Source (4)
Finished exercises in main
· 1b747d6c
Blinningjr
authored
4 years ago
1b747d6c
rtt_timing c
· dcadd8fe
Blinningjr
authored
4 years ago
dcadd8fe
rtt_timing D
· 3ffc1980
Blinningjr
authored
4 years ago
3ffc1980
rtt_timing E
· 1941bf50
Blinningjr
authored
4 years ago
1941bf50
Expand all
Show whitespace changes
Inline
Side-by-side
Showing
4 changed files
.cargo/config
+2
-2
2 additions, 2 deletions
.cargo/config
examples/rtt_timing.rs
+74
-1
74 additions, 1 deletion
examples/rtt_timing.rs
rtt_timing.objdump
+2308
-0
2308 additions, 0 deletions
rtt_timing.objdump
src/main.rs
+90
-5
90 additions, 5 deletions
src/main.rs
with
2474 additions
and
8 deletions
.cargo/config
View file @
1941bf50
...
...
@@ -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
...
...
This diff is collapsed.
Click to expand it.
examples/rtt_timing.rs
View file @
1941bf50
...
...
@@ -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.
Click to expand it.
rtt_timing.objdump
0 → 100644
View file @
1941bf50
This diff is collapsed.
Click to expand it.
src/main.rs
View file @
1941bf50
...
...
@@ -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);
// }
//}
This diff is collapsed.
Click to expand it.