From 329c50224891651bd8935d9ee0b19a9a7c5c5ec9 Mon Sep 17 00:00:00 2001
From: DevDoggo <devdoggo@protonmail.com>
Date: Wed, 23 May 2018 01:02:19 +0200
Subject: [PATCH] Done!
---
examples/bare4.rs | 27 ++++++++++++++++++++++-----
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/examples/bare4.rs b/examples/bare4.rs
index 66090d8..363f184 100644
--- a/examples/bare4.rs
+++ b/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)
--
GitLab