From 9817a47ac7cd068f45151cd097fdf7f238b1c679 Mon Sep 17 00:00:00 2001
From: Anton <anton.frappe@outlook.com>
Date: Wed, 3 Mar 2021 18:28:02 +0100
Subject: [PATCH] bare4_3
---
examples/rtic_bare4.rs | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/examples/rtic_bare4.rs b/examples/rtic_bare4.rs
index 9f7f176..b60b04e 100644
--- a/examples/rtic_bare4.rs
+++ b/examples/rtic_bare4.rs
@@ -35,8 +35,8 @@ use address::*;
#[inline(always)]
fn read_u32(addr: u32) -> u32 {
- //unsafe { core::ptr::read_volatile(addr as *const _) }
- core::ptr::read_volatile(addr as *const _);
+ unsafe { core::ptr::read_volatile(addr as *const _) }
+ //core::ptr::read_volatile(addr as *const _);
}
#[inline(always)]
@@ -119,16 +119,21 @@ const APP: () = {
//
// Why is it important that ordering of volatile operations are ensured by the compiler?
//
-// ** your answer here **
+// Since you are accessing memory outside of the aqusition of rust
+// the ordering is very important.
//
// Give an example in the above code, where reordering might make things go horribly wrong
// (hint, accessing a peripheral not being powered...)
//
-// ** your answer here **
+// If the write instruction on line 65 before the read instruction on line 64
+// The word on address GPIOA_MODER would look completely different since r is no longer a copy
+// with modifications for the word you are writing to.
+// Or if one of the writes for PA5 happens before any of the initialization writes to RCC_AHB1ENR or BPIOA_MODER.
//
// Without the non-reordering property of `write_volatile/read_volatile` could that happen in theory
// (argue from the point of data dependencies).
//
-// ** your answer here **
+// Since the PA5 write does not depend on anything from the initialization in software point of view,
+// Theoretically it could happen.
//
// Commit your answers (bare4_3)
--
GitLab