153: Update exceptions.md r=korken89 a=flip111
> You'll see that a load operation (ldr r0, [r0] ) caused the exception and that the value of the register r0 was 0x3fff_fffe at that time.
You can not see the value of the register from the disassembly. Therefor:
> This value matches the r0 field of ExceptionFrame.
`This` points to nothing. Nothing "matches". With the information given in the book the value can _only_ be seen in the ExceptionFrame.
Co-authored-by: flip111 <flip101@gmail.com>
142: Update qemu.md r=korken89 a=flip111
Add link to qemu wiki. As proof and also interested reader can see other architectures too.
151: Update exceptions.md r=korken89 a=flip111
that it's marked with `* *` already makes it have special significance. Let's link to an explanation
Co-authored-by: flip111 <flip101@gmail.com>
133: Update no-std.md r=korken89 a=flip111
* There is no high level OS this means there are no primitives <-- this is wrong because there can be primitives without high level OS otherwise it wouldn't be a "primitive"
* Using jargon "bare metal" without explaining it
* By marking our code with `no_std` we indicate that our code is capable of running in such an environment. <-- this wording makes it so that using `no_std` is the only requirement of having runnable code.
* Dynamic memory allocation can not be used --> not true, use crate (like described lower in the text)
135: Update install.md r=korken89 a=flip111
`For bandwidth and disk usage concerns the default installation only supports native compilation.`
I like what the default installation is doing, not downloading toolchains i don't need. Let's do the same for the book. At the same time, because the reader is just getting into embedded for rust, it's cool to see which toolchains for which CPU cores are already available. This gives a good feeling of control (which toolchain i can choose) and possibilities (many to choose from)
Co-authored-by: flip111 <flip101@gmail.com>
150: Update panicking.md r=therealprof a=flip111
non-standard program sounds like it wouldn't be a normal program
Co-authored-by: flip111 <flip101@gmail.com>
`For bandwidth and disk usage concerns the default installation only supports native compilation.`
I like what the default installation is doing, not downloading toolchains i don't need. Let's do the same for the book. At the same time, because the reader is just getting into embedded for rust, it's cool to see which toolchains for which CPU cores are already available. This gives a good feeling of control (which toolchain i can choose) and possibilities (many to choose from)
* There is no high level OS this means there are no primitives <-- this is wrong because there can be primitives without high level OS otherwise it wouldn't be a "primitive"
* Using jargon "bare metal" without explaining it
* By marking our code with `no_std` we indicate that our code is capable of running in such an environment. <-- this wording makes it so that using `no_std` is the only requirement of having runnable code.
* Dynamic memory allocation can not be used --> not true, use crate (like described lower in the text)
128: Fix typos in c-tips r=adamgreig a=krepl
Just some little typo fixes in "Tips for embedded C developers"
Co-authored-by: krepl <36075613+krepl@users.noreply.github.com>
120: Fix for links not pointing to correct documentation r=jamesmunns a=shellwirt
As #107 showed, there are some links pointing to the rendered docs, this pull attempts to fix that.
Co-authored-by: shellwirt <shellwirt@protonmail.com>
116: Fix typos in interrupts r=adamgreig a=tomoyuki-nakabayashi
Hi all. First of all, I want to provide my respect for this book. It's really awesome!
I'm now translating this book into Japanese to deliver this book to more people.
I found some typos in interrupts section and fixed them.
Thanks!
Co-authored-by: tomoyuki-nakabayashi <tomo.wait.for.it.yuki@gmail.com>
112: Align runner example with current quickstart template r=korken89 a=rubberduck203
Co-authored-by: Christopher J. McClellan <chris.mcclellan203@gmail.com>
105: Make sure QEMU debug::exit() call is not active r=korken89 a=maxekman
This left me hanging for a bit (literally). I ended up with no print and just getting stuck in the hard fault handler when hitting ctrl-c in GDB.
Co-authored-by: Max Ekman <max@looplab.se>
