Commit 329c5022 authored by DevDoggo's avatar DevDoggo

Done!

parent ee56513f
......@@ -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)
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment