From a38117f8a5f2b7b6d3637e19197153d19ea21df7 Mon Sep 17 00:00:00 2001
From: Per Lindgren <per.lindgren@ltu.se>
Date: Wed, 11 Nov 2020 22:53:01 +0100
Subject: [PATCH] rtt_timing
---
examples/rtt_timing.rs | 30 +++++++++++++++++++++++++-----
1 file changed, 25 insertions(+), 5 deletions(-)
diff --git a/examples/rtt_timing.rs b/examples/rtt_timing.rs
index 7f0c575..dd647ff 100644
--- a/examples/rtt_timing.rs
+++ b/examples/rtt_timing.rs
@@ -307,13 +307,33 @@ fn timed_loop() -> (u32, u32) {
// handler by `panic_halt`, but besides that it should still
// measure time (debugging in gdb of `timed_loop` must still work).
//
+// > cargo size
+//
+// [Your answer here]
+//
+// I was able to get down to:
+// cargo size --example rtt_timing --release --features nightly
+// Compiling app v0.1.0 (/home/pln/courses/e7020e/app)
+// Finished release [optimized + debuginfo] target(s) in 0.32s
+// text data bss dec hex filename
+// 660 0 0 660 294 rtt_timing
+// Try beat that...
// ------------------------------------------------------------------------
// Summary:
// What are the learning outcomes.
//
-// - Rust generates really bad code in debug build.
-// - Rust generates really, really, really good code in release build.
-// Zero-cost abstractions are for real.
+// - You have confirmed that RTIC is extremely light weight
+// (zero-cost in release build).
+// Applications can be be less than 1k flash.
+//
+// - You have seen that RTIC applications are easy to trace using RTT
+// If more details are required, you have learned to use gdb.
+//
+// - You have confirmed that Rust generates:
+// really, really, bad code in debug build.
+// really, really, really good code in release build.
//
-// - RTIC is extremely light weight (zero-cost in release build).
-// - RTIC applications are easy to
+// - You have setup timing measurements which are
+// Cycle accurate (0.000 000 01s at 100MHz).
+// Consistent (down to a single clock cycle).
+// Predictable (you got what you expected right?)
--
GitLab