bare4

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)