From 03000f574829b9a7beb87bcd14e315754f6bf06c Mon Sep 17 00:00:00 2001
From: sheepwall <a.sve@live.se>
Date: Fri, 8 Mar 2019 20:34:09 +0100
Subject: [PATCH] bare4_3
---
examples/bare4.rs | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/examples/bare4.rs b/examples/bare4.rs
index a585031..7ef8898 100644
--- a/examples/bare4.rs
+++ b/examples/bare4.rs
@@ -121,17 +121,23 @@ fn main() -> ! {
//
// Why is it important that ordering of volatile operations are ensured by the compiler?
//
-// ** If read/write instructions are reordered, the consequences are undefined, since peripherals
-// depend on the contents of registers that are read from/written to. **
+// ** If read/write instructions are reordered, the consequences are undefined, since
+// what was intended to be read might not be there. And since peripherals' configurations
+// depend on the contents of registers that are read from/written to, configurations might
+// go wrong. **
//
// 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 **
+// ** We set port A to general purpose output mode. There is undefined, unintended behaviour
+// if we write to the port bits without enabling it. **
//
// Without the non-reording proprety of `write_volatile/read_volatile` could that happen in theory
// (argue from the point of data dependencies).
//
-// ** your answer here **
+// ** If we read from a register to apply a mask on it, it most probably needs to remain that value
+// before writing the masked value to it, otherwise the masked value is not accurate. If read/writes
+// are reordered during many reads and writes (e.g. during configuration), the configuration might end
+// up faulty. **
//
// Commit your answers (bare4_3)
--
GitLab