Done!

examples/bare4.rs

@@ -27,8 +27,8 @@ 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 _)
+    unsafe { core::ptr::read_volatile(addr as *const _) }
+      //core::ptr::read_volatile(addr as *const _)
 }
 
 #[inline(always)]
@@ -45,14 +45,13 @@ fn wait(i: u32) {
 }
 
 fn main() {
-    // 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
 
+
+
     // and alter the data output through the BSRR register
     // this is more efficient as the read register is not needed.
 
@@ -61,6 +60,10 @@ fn main() {
         write_u32(GPIOA_BSRR, 1 << 5); // set bit, output hight (turn on led)
         wait(10_000);
 
+        // power on GPIOA
+        let r = read_u32(RCC_AHB1ENR); // read
+        write_u32(RCC_AHB1ENR, r | 1); // set enable
+        
         // set PA5 low
         write_u32(GPIOA_BSRR, 1 << (5 + 16)); // clear bit, output low (turn off led)
         wait(10_000);
@@ -123,14 +126,28 @@ fn main() {
 // as data dependencies are preserved.
 //
 // why is important that ordering of volatile operations are ensured by the compiler?
+//  
+//  >> For example, if you wish to read before writing, then it shouldn't write
+//      a new value before you read! 
+//      This could make a lamp never turn on/off etc.
 // ** your answer here **
 //
 // give an example in the above code, where reordering might make things go horribly wrong
 // (hint, accessing a peripheral not being powered...)
+//
+//  >> Powering On the LED before it has been enabled results in no action taking place,
+//      which for other software could be crucial, perhaps having something work in the wrong
+//      order.
 // ** your answer here **
 //
 // without the non-reording proprety of `write_volatile/read_volatile` could that happen in theory
 // (argue from the point of data dependencies)
+//
+//  >> You could set values correctly in the code, 
+//      but during compile, the values become different.
+//      This could be something like XOR:ing two different registers for a 3rd.
+//      If one is incorrect due to re-ordering, the XOR will do wrong and the program
+//      may act non-accordingly!
 // ** your answer here **
 //
 // commit your answers (bare4_3)