From 6b7eff1b3ef6fb7839c89c578b2a14ea5db27d25 Mon Sep 17 00:00:00 2001
From: Grumme2 <agh@live.se>
Date: Fri, 17 Apr 2020 15:03:38 +0200
Subject: [PATCH] bare 4_3
---
examples/bare4.rs | 24 +++++++++++++++++++++---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/examples/bare4.rs b/examples/bare4.rs
index 5186bc9..cf488f2 100644
--- a/examples/bare4.rs
+++ b/examples/bare4.rs
@@ -116,13 +116,15 @@ fn main() -> ! {
//
// error: aborting due to previous error
//
-// Reading adresses is not safe so it panics
+// read_voliatile is a unsafe so it panics
//
// Digging a bit deeper, why do you think `read_volatile` is declared `unsafe`.
// (https://doc.rust-lang.org/core/ptr/fn.read_volatile.html, for some food for thought )
//
// ** your answer here **
-//
+//
+// because rust cant guarantee to know whats on the memmory address
+//
// Commit your answers (bare4_2)
//
// 3. Volatile read/writes are explicit *volatile operations* in Rust, while in C they
@@ -135,15 +137,31 @@ fn main() -> ! {
// Why is it important that ordering of volatile operations are ensured by the compiler?
//
// ** your answer here **
+//
+// because volatile just reads the momory address so if it is done in the wrong order it
+// might read values that are wrong and the use them.
//
// 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 **
-//
+//
+// // power on GPIOA
+// let r = read_u32(RCC_AHB1ENR); // read
+// write_u32(RCC_AHB1ENR, r | 1); // set enable
+//
+// //configure PA5 as output
+// let r = read_u32(GPIOA_MODER) & !(0b11 << (5 * 2)); // read and mask
+// write_u32(GPIOA_MODER, r | 0b01 << (5 * 2)); // set output mode
+//
+// if poweron giopa would happen after the config it could cause problems
+//
// 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 **
+//
+// its important that they are non-reordering because otherwise if a write_volitile is dependent on data from a read_volitile
+// and its reorderd it would not have all the relevent data it needs.
//
// Commit your answers (bare4_3)
--
GitLab