flip111

i can't move this issue forward on my own at the moment

Ah i understand now why the naming of the section once i start reading the next section "Now, there are a couple of problems with the approach above.". Even so...

Didn't want to open another issue for this. About https://rust-embedded.github.io/book/peripherals/a-first-attempt.html#volatile-accesses > Now, the problem is that compilers are clever. This is strange to read. First the write lays out 4...

> As the driver author This reads strange because "driver" can also be a person. suggestion: as the author of the code (a driver) controller this hardware. It's longer but...

Didn't want to create a separate issue for this one either https://rust-embedded.github.io/book/peripherals/a-first-attempt.html#the-rusty-wrapper > We need to wrap this struct up into a higher-layer API that is safe for our users...

Hi sorry for the tone. It's been already a lot of work even doing the review. I didn't put the extra effort in thinking about how it would come across....

So as i'm thinking about what to do with this issue ... i realize all sections of Chapter 4 `Static Guarantees` are written as an exploring/investigation style. As an exploration...

Following writings in book are also different with observations while stepping through gdb

I can not move this issue forward on my own because i need more background knowledge what is important to tell about these debugging steps.

Some resources: Allocators that don't need std https://github.com/Nemo157/embrio-rs/ https://josh.robsonchase.com/embedded-executor-2/ https://github.com/japaric/no-std-async-experiments taken from: https://github.com/rust-embedded/wg/issues/23 Interesting read: http://blog.japaric.io/brave-new-io/#async-hal https://www.bobbin.io/ https://docs.rs/embedded-hal/0.2.2/embedded_hal/