edited ch 4

mdbook/src/04-meet-your-hardware/README.md

@@ -26,7 +26,7 @@ black squares sitting on the side of the board with the USB port. The MCU is
 what runs your code. You might sometimes read about "programming a board", when
 in reality what we are doing is programming the MCU that is installed on the board.
 
-If you happen to be interested in a more in detail description of the board you
+If you happen to be interested in a more detailed description of the board you
 can checkout the [micro:bit website](https://tech.microbit.org/hardware/).
 
 Since the MCU is so important, let's take a closer look at the one sitting on our board.

mdbook/src/04-meet-your-hardware/microbit-v2.md

@@ -1,12 +1,11 @@
 # Nordic nRF52833 (the "nRF52", micro:bit v2)
 
 Our MCU has 73 tiny metal **pins** sitting right underneath it (it's a so called [aQFN73] chip).
-These pins are connected to **traces**, the little "roads" that act as the wires connecting components
-together on the board. The MCU can dynamically alter the electrical properties
-of the pins. This works similar to a light switch altering how electrical
-current flows through a circuit. By enabling or disabling electrical current to
-flow through a specific pin, an LED attached to that pin (via the traces) can
-be turned on and off.
+These pins are connected to **traces**, the little "roads" that act as the wires connecting
+components together on the board. The MCU can dynamically alter the electrical properties of the
+pins. This works similarly to a light switch, altering how electrical current flows through a
+circuit. By enabling or disabling electrical current to flow through a specific pin, an LED attached
+to that pin (via the traces) can be turned on and off.
 
 Each manufacturer uses a different part numbering scheme, but many will allow you to
 determine information about a component simply by looking at the part number. Looking at our
@@ -34,8 +33,8 @@ short for radio frequency.  If we search through the documentation of the chip l
 - The `A0` is the build code, indicating the hardware version (`A`) as well as the product configuration (`0`)
 - The `2024AL` is a tracking code, hence it might differ on your chip
 
-The product specification does of course contain a lot more useful information about
-the chip, for example that it is based on an ARM® Cortex™-M4 32-bit processor.
+The product specification does of course contain a lot more useful information about the chip: for
+example, that the chip is an ARM® Cortex™-M4 32-bit processor.
 
 
 ## Arm? Cortex-M4?

mdbook/src/04-meet-your-hardware/terminology.md

@@ -1,40 +1,38 @@
 # Rust Embedded terminology
-Before we dive into programming the micro:bit let's have a quick look
-at the libraries and terminology that will be important for all the
-future chapters.
+
+Before we dive into programming the micro:bit let's have a quick look at the libraries and
+terminology that will be important for all the future chapters.
 
 ## Abstraction layers
-For any fully supported microcontroller/board with a microcontroller
-you will usually hear the following terms being used for their levels
-of abstraction:
+
+For any fully supported microcontroller/board with a microcontroller, you will usually hear the
+following terms being used for their levels of abstraction:
 
 ### Peripheral Access Crate (PAC)
-The job of the PAC is to provide a safe (ish) direct interface to the
-peripherals of the chip, allowing you to configure
-every last bit however you want (of course also in wrong ways). Usually
-you only ever have to deal with the PAC if either the layers that are
-higher up don't fulfill your needs or when you are developing them.
-The PAC we are (implicitly) going to use is either the one for the [nRF52]
-or for the [nRF51].
-
-### The Hardware Abstraction Layer (HAL)
-The job of the HAL is to build up on top of
-the chip's PAC and provide an abstraction that is actually usable for
-someone who does not know about all the special behaviour of this chip.
-Usually they abstract whole peripherals away into single structs that can
-for example be used to send data around via the peripheral. We are
-going to use the [nRF52-hal] or the [nRF51-hal] respectively.
-
-### The Board Support Crate (historically called Board Support Package, or BSP)
-The job of the BSP is to abstract a whole board
-(such as the micro:bit) away at once. That means it has to provide
-abstractions to use both the microcontroller as well as the sensors,
-LEDs etc. that might be present on the board. Quite often (especially
-with custom-made boards) you will just be working with a HAL for the
-chip and build the drivers for the sensors either yourself or
-search for them on crates.io. Luckily for us though, the micro:bit
-does actually have a [BSP] so we are going to use that on top of our
-HAL as well.
+
+The job of the PAC is to provide a safe (ish) direct interface to the peripherals of the chip,
+allowing you to configure every last bit however you want (of course also in wrong ways). Usually
+you only ever have to deal with the PAC if either the layers that are higher up don't fulfill your
+needs or when you are developing higher-level code for them.  Unsurprisingly, the PAC we are (mostly
+implicitly) going to use is for the [nRF52].
+
+### Hardware Abstraction Layer (HAL)
+
+The job of the HAL is to build up on top of the chip's PAC and provide an abstraction that is
+actually usable for someone who does not know about all the special behaviour of this chip.  Usually
+a HAL abstracts whole peripherals away into single structs that can, for example, be used to send
+data around via the peripheral. We are going to use the [nRF52-hal].
+
+### Board Support Crate (BSP)
+
+(In non-Rust situations this is usually called the Board Support Package, hence the acronym.)
+
+The job of the BSP is to abstract a whole board (such as the micro:bit) away at once. That means it
+has to provide abstractions to use both the microcontroller as well as the sensors, LEDs etc. that
+might be present on the board. Quite often (especially with custom-made boards) no pre-built BSP
+will be available. Instead you will be working with a HAL for the chip and build the drivers for the
+sensors either yourself or search for them on `crates.io`. Luckily for us though, the micro:bit does
+have a [BSP], so we are going to use that on top of our HAL as well.
 
 [nrF52]: https://crates.io/crates/nrf52833-pac
 [nrF52-hal]: https://crates.io/crates/nrf52833-hal
@@ -49,22 +47,21 @@ The idea behind [`embedded-hal`] is to provide a set of traits that
 describe behaviour which is usually shared across all implementations
 of a specific peripheral in all the HALs. For example one would always
 expect to have functions that are capable of turning the power on a pin
-either on or off. For example to switch an LED on and off on the board.
-This allows us to write a driver for, say a temperature sensor, that
-can be used on any chip for which an implementation of the [`embedded-hal`] traits exists,
-simply by writing the driver in such a way that it only relies on the
-[`embedded-hal`] traits. Drivers that are written in such a way are called
-platform agnostic and luckily for us most of the drivers on crates.io
-are actually platform agnostic.
+either on or off: to switch an LED on and off on the board or whatever.
+
+`embedded-hal` allows us to write a driver for some piece of hardware, for example a temperature
+sensor, that can be used on any chip for which an implementation of the [`embedded-hal`] traits
+exists. This is accomplished by writing the driver in such a way that it only relies on the
+[`embedded-hal`] traits. Drivers that are written in such a way are called *platform-agnostic.*
+Luckily for us, the drivers we will be getting from `crates.io` are almost all platform agnostic.
 
 [`embedded-hal`]: https://crates.io/crates/embedded-hal
 
 
 ## Further reading
 
-If you want to learn more about these levels of abstraction, Franz Skarman,
-a.k.a. [TheZoq2], held a talk about this topic during Oxidize 2020, called
-[An Overview of the Embedded Rust Ecosystem].
+If you want to learn more about these levels of abstraction, Franz Skarman (a.k.a. [TheZoq2]) held a
+talk about this topic during Oxidize 2020: [An Overview of the Embedded Rust Ecosystem].
 
 [TheZoq2]: https://github.com/TheZoq2/
 [An Overview of the Embedded Rust Ecosystem]: https://www.youtube.com/watch?v=vLYit_HHPaY