bare4_3

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)