213: Adds cargo-generate to installation instructions r=jamesmunns a=rubberduck203
Fixes#186
Related to 753d71ac, which added instructions close to use in the qemu
page, this commit adds the information directly to install where it's
less likely to be overlooked.
Co-authored-by: Christopher J. McClellan <cmcclellan@pillartechnology.com>
After discussions with someone who had re-used material without attribution, we agreed it would be useful to make the licence terms more prominent to those reading the rendered book (as opposed to browsing the Github repo).
Fixes#186
Related to 753d71ac, which added instructions close to use in the qemu
page, this commit adds the information directly to install where it's
less likely to be overlooked.
The next section in the book is the "Getting Started", not the already
seen section Hardware in the same chapter.
Signed-off-by: Antonio Gutierrez <chibby0ne@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>
`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)
The 'apt' binary has appeared in apt 1.0 back in 2014 and has been
ever since the recommended tool to install packages on Debian based
systems. It makes little sense to recommend using 'apt-get' instead
of 'apt' when even the current Debian oldstable - jessie - has apt
>=1.0.9.8 and the Ubuntu 14.04 LTS - trusty - has apt
>=1.0.1ubuntu1.
Signed-off-by: Eddy Petrișor <eddy.petrisor@gmail.com>
74: edits to the introduction chapter r=jamesmunns a=japaric
see individual commit messages for details
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
its content is pretty similar to the 2018 edition and we want to reader to be
familiar with the 2018 edition so it's best to direct them to that version of
the Rust book
67: Attempt to describe OpenOCD r=japaric a=adamgreen
This is my attempt to implement the OpenOCD TODO item in the 'Tooling'
section of Chapter 1.
I did move the OpenOCD section so that it comes after GDB since I
thought it made more sense to describe it after the user has already
been introduced to GDB as a debugger since it is OpenOCD which bridges
the gap between GDB and the ST-Link debugger hardware.
Feedback welcome!
Co-authored-by: Adam Green <adamgreen@users.noreply.github.com>
