Fixed this.

examples/rtic_bare4.rs

@@ -36,7 +36,6 @@ 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 _)
 }
 
 #[inline(always)]
@@ -83,7 +82,7 @@ const APP: () = {
 //
 // 1.  Did you enjoy the blinking?
 //
-//    ** your answer here **
+//    Yeah
 //
 //    Now lookup the data-sheets, and read each section referred,
 //    6.3.11, 8.4.1, 8.4.7
@@ -100,12 +99,20 @@ const APP: () = {
 //
 //    What was the error message and explain why.
 //
-//    ** your answer here **
+    /*
+    error[E0133]: call to unsafe function is unsafe and requires unsafe function or block
+    --> examples\rtic_bare4.rs:39:5
+    |
+    39 |     core::ptr::read_volatile(addr as *const _)
+    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ call to unsafe function
+    |
+    = note: consult the function's documentation for information on how to avoid undefined behavior
+    */
 //
 //    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 **
+//    It is not safe. You create a copy of a register without using borrow checking so Rust consider it unsafe.
 //
 //    Commit your answers (bare4_2)
 //
@@ -118,16 +125,18 @@ const APP: () = {
 //
 //    Why is it important that ordering of volatile operations are ensured by the compiler?
 //
-//    ** your answer here **
+//    Because we are messing around with the registers and the stack in a specific way and want it to behave exactly the way we specified.
+//    Thats the whole point with volatile operations.
 //
 //    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 **
+//    When we specify a specific address we really mean that address and want to know that we get exactly that address and nothing else.
+//    Line 44 and 38 is places where it could be really bad if the compiler assumes something else.
 //
 //    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 **
+//    We write/read from some unwanted address and get/set the wrong information. This could lead to unwanted behaviors and is not very good.
 //
 //    Commit your answers (bare4_3)