From 6dddd14d73c615a7d6e4ae0b715d2013ba830e4a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edvin=20=C3=85kerfeldt?= <Edvin Åkerfeldt>
Date: Thu, 3 Dec 2020 18:25:56 +0100
Subject: [PATCH] timing_resources, Q14 & Q15, file all done

---
 examples/timing_resources.rs | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/examples/timing_resources.rs b/examples/timing_resources.rs
index 3d89b14..95ae1a8 100644
--- a/examples/timing_resources.rs
+++ b/examples/timing_resources.rs
@@ -322,6 +322,10 @@ It was safe because exti0 had the highest priority of the tasks accessing the re
 // Motivate your answer (not just a number).
 //
 // [Your answer here]
+/*
+Ignoring the breakpoints in the function we're left with the locking/unlocking of the resource and entering/leaving the task.
+Acording to the table this would take approx. 650+1522+260+170 = 2602 cycles (best case).
+*/
 //
 // Notice, the Rust implementation is significantly faster than the C code version
 // of Real-Time For the Masses back in 2013.
@@ -332,3 +336,6 @@ It was safe because exti0 had the highest priority of the tasks accessing the re
 // (Hint, what possible optimization can safely be applied by RTIC + Rust + LLVM.)
 //
 // [Your answer here]
+/*
+Because all optimization techniques from LLVM can be applied on the RTIC generated code without worries of anything breaking.
+*/
-- 
GitLab