Book: Major rework for RTIC v2

1 files changed, 9 insertions, 21 deletions

diff --git a/book/en/src/by-example/hardware_tasks.md b/book/en/src/by-example/hardware_tasks.md
index 2d405d3..e3e51ac 100644
--- a/book/en/src/by-example/hardware_tasks.md
+++ b/book/en/src/by-example/hardware_tasks.md
@@ -1,39 +1,27 @@
 # Hardware tasks
 
-At its core RTIC is using a hardware interrupt controller ([ARM NVIC on cortex-m][NVIC])
-to schedule and start execution of tasks. All tasks except `pre-init`, `#[init]` and `#[idle]`
-run as interrupt handlers.
+At its core RTIC is using the hardware interrupt controller ([ARM NVIC on cortex-m][NVIC]) to perform scheduling and executing tasks, and all (*hardware*) tasks except `#[init]` and `#[idle]` run as interrupt handlers. This also means that you can manually bind tasks to interrupt handlers.
 
-Hardware tasks are explicitly bound to interrupt handlers.
+To bind an interrupt use the `#[task]` attribute argument `binds = InterruptName`. This task becomes the interrupt handler for this hardware interrupt vector.
 
-To bind a task to an interrupt, use the `#[task]` attribute argument `binds = InterruptName`.
-This task then becomes the interrupt handler for this hardware interrupt vector.
+All tasks bound to an explicit interrupt are *hardware tasks* since they start execution in reaction to a hardware event (interrupt).
 
-All tasks bound to an explicit interrupt are called *hardware tasks* since they
-start execution in reaction to a hardware event.
+Specifying a non-existing interrupt name will cause a compilation error. The interrupt names are commonly defined by [PAC or HAL][pacorhal] crates.
 
-Specifying a non-existing interrupt name will cause a compilation error. The interrupt names
-are commonly defined by [PAC or HAL][pacorhal] crates.
+Any available interrupt vector should work, but different hardware might have added special properties to select interrupt priority levels, such as the [nRF “softdevice”](https://github.com/rtic-rs/cortex-m-rtic/issues/434).
 
-Any available interrupt vector should work. Specific devices may bind
-specific interrupt priorities to specific interrupt vectors outside
-user code control. See for example the 
-[nRF “softdevice”](https://github.com/rtic-rs/cortex-m-rtic/issues/434).
-
-Beware of using interrupt vectors that are used internally by hardware features;
-RTIC is unaware of such hardware specific details.
+Beware of re-purposing interrupt vectors used internally by hardware features, RTIC is unaware of such hardware specific details.
 
 [pacorhal]: https://docs.rust-embedded.org/book/start/registers.html
 [NVIC]: https://developer.arm.com/documentation/100166/0001/Nested-Vectored-Interrupt-Controller/NVIC-functional-description/NVIC-interrupts
 
-The example below demonstrates the use of the `#[task(binds = InterruptName)]` attribute to declare a
-hardware task bound to an interrupt handler.
+The example below demonstrates the use of the `#[task(binds = InterruptName)]` attribute to declare a hardware task bound to an interrupt handler. In the example the interrupt triggering task execution is manually pended (`rtic::pend(Interrupt::UART0)`). However, in the typical case, interrupts are pended by the hardware peripheral. RTIC does not interfere with mechanisms for clearing peripheral interrupts, so any hardware specific implementation is completely up to the implementer.
 
 ``` rust
-{{#include ../../../../examples/hardware.rs}}
+{{#include ../../../../rtic/examples/hardware.rs}}
 ```
 
 ``` console
 $ cargo run --target thumbv7m-none-eabi --example hardware
-{{#include ../../../../ci/expected/hardware.run}}
+{{#include ../../../../rtic/ci/expected/hardware.run}}
 ```