bare4_3

examples/rtic_bare4.rs

@@ -108,7 +108,7 @@ const APP: () = {
 //    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 )
 //
-//      Because you can get undefined behaviour
+//      Because you can get undefined behaviour.
 //
 //    Commit your answers (bare4_2)
 //
@@ -121,7 +121,7 @@ const APP: () = {
 //
 //    Why is it important that ordering of volatile operations are ensured by the compiler?
 //
-//    ** your answer here **
+//      Because you can get race conditions when you have multiple read and writes to the same registers
 //
 //    Give an example in the above code, where reordering might make things go horribly wrong
 //    (hint, accessing a peripheral not being powered...)
@@ -131,6 +131,8 @@ const APP: () = {
 //    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 you have read and write operations to the same register, as in line 62-63 and
+//      66-67, there would be a problem if the compiler swapped the operations around, as
+//      there wouldn't be any data to write if it hasn't been read yet.
 //
 //    Commit your answers (bare4_3)