From c2a1448d1febce334c59550ec6455cafcfa2a400 Mon Sep 17 00:00:00 2001
From: 97gushan <97gustavh@gmail.com>
Date: Wed, 1 Apr 2020 09:42:50 +0200
Subject: [PATCH] bare4
---
examples/bare4.rs | 24 +++++++++++++++++-------
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/examples/bare4.rs b/examples/bare4.rs
index 07ce483..d5bcd3c 100644
--- a/examples/bare4.rs
+++ b/examples/bare4.rs
@@ -37,7 +37,7 @@ 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 _)
+ // core::ptr::read_volatile(addr as *const _)
}
#[inline(always)]
@@ -84,7 +84,7 @@ fn main() -> ! {
//
// 1. Did you enjoy the blinking?
//
-// ** your answer here **
+// yes
//
// Now lookup the data-sheets, and read each section referred,
// 6.3.11, 8.4.1, 8.4.7
@@ -101,12 +101,14 @@ fn main() -> ! {
//
// What was the error message and explain why.
//
-// ** your answer here **
+// call to unsafe function is unsafe and requires unsafe function or block
+// read_volatile is an unsafe function and must thus be called inside a block of code declared unsafe
//
// 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 **
+// read_volatile is declared unsafe because behavior is undefined if the memory is not valid for reads or
+// not properluy aligned according to the documentation
//
// Commit your answers (bare4_2)
//
@@ -119,16 +121,24 @@ fn main() -> ! {
//
// Why is it important that ordering of volatile operations are ensured by the compiler?
//
-// ** your answer here **
+// If read/write operations are reordered undefined behavior will occur, for example
+// might changes in order change how a peripheral is configured and thus change the behavior of that peripheral
//
// 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 **
+// as the example in this files show if the seoncd read would switch place with the second
+// write the setting of the output mode would be wrongly configured and the output would not work as intended
+
+ // // 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
//
// 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 **
+// when configuring a peripheral if you read from a register and you want to apply a mask
+// to it, if a change happens in the register between the read and the write of the mask
+// the configuration can break and the peripheral not work
//
// Commit your answers (bare4_3)
--
GitLab