Mostly editorial review.

1 files changed, 11 insertions, 9 deletions

diff --git a/book/en/src/by-example/hardware_tasks.md b/book/en/src/by-example/hardware_tasks.md
index 7f8d3c6..2d405d3 100644
--- a/book/en/src/by-example/hardware_tasks.md
+++ b/book/en/src/by-example/hardware_tasks.md
@@ -1,24 +1,26 @@
 # Hardware tasks
 
-At its core RTIC is using the hardware interrupt controller ([ARM NVIC on cortex-m][NVIC])
-to perform scheduling and executing tasks, and all tasks except `#[init]` and `#[idle]`
+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.
-This also means that you can manually bind tasks 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.
+Hardware tasks are explicitly bound to interrupt handlers.
 
-All tasks bound to an explicit interrupt are *hardware tasks* since they
+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 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.
 
-Any available interrupt vector should work, but different hardware might have
-added special properties to select interrupt priority levels, such as the
+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 re-purposing interrupt vectors used internally by hardware features,
+Beware of using interrupt vectors that are used internally by hardware features;
 RTIC is unaware of such hardware specific details.
 
 [pacorhal]: https://docs.rust-embedded.org/book/start/registers.html