From a33a71e322e3b7c462ba8c907d7e80c41c10edb1 Mon Sep 17 00:00:00 2001
From: rubenasplund <ruben.asplund@hotmail.com>
Date: Sat, 5 Dec 2020 16:19:12 +0100
Subject: [PATCH] Updated timing_resources
---
examples/timing_resources.rs | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/examples/timing_resources.rs b/examples/timing_resources.rs
index b55f2ee..ecd1f96 100644
--- a/examples/timing_resources.rs
+++ b/examples/timing_resources.rs
@@ -269,13 +269,18 @@ const APP: () = {
//
// You find a comparison to a typical threaded counterpart `freeRTOS` in Table 1.
//
-// Give a rough estimate based on this info how long the complete task `uart1`,
+// Give a rough estimate based on this info how long the complete task `exti1`,
// would take to execute if written in FreeRTOS. (Include the context switch, to higher
// priority task, the mutex lock/unlock in both "threads".)
//
// Motivate your answer (not just a number).
//
// [Your answer here]
+// Job latency and job overhead for both exti0 and exti2: 2* (650 + 1522)
+// Lock and unlock in exti1 260 + 170
+// Critical section in the lock 40
+// Memory job 462 * 2 (It changes the resources 2 times, one time in exti0 and exti1 each.)
+// Result: 2* (650 + 1522)+260 + 170+40+462 * 2 = 5738 cycles
//
// Notice, the Rust implementation is significantly faster than the C code version
// of Real-Time For the Masses back in 2013.
@@ -283,6 +288,10 @@ const APP: () = {
// Why do you think RTIC + Rust + LLVM can do a better job than hand written
// C code + Macros + gcc?
//
-// (Hint, what possible optimization can safely be applied.)
+// (Hint, what possible optimization can safely be applied by RTIC + Rust + LLVM.)
//
// [Your answer here]
+// Rust with RTIC does not have threads which means it is not switching task as often as in C.
+// When there are fewer switches between tasks, the need for locks is less.
+// There are no need for memory managment in rust compared to C.
+//
--
GitLab