Update these

book/en/src/SUMMARY.md

@@ -7,7 +7,7 @@
 - [Starting a new project](./starting_a_project.md)
 - [RTIC by example](./by-example.md)
   - [The `app`](./by-example/app.md)
-  - [Hardware tasks & `pend`](./by-example/hardware_tasks.md)
+  - [Hardware tasks](./by-example/hardware_tasks.md)
   - [Software tasks & `spawn`](./by-example/software_tasks.md)
   - [Resources](./by-example/resources.md)
   - [The init task](./by-example/app_init.md)

book/en/src/by-example/app.md

@@ -2,7 +2,9 @@
 
 ## Requirements on the `app` attribute
 
-All RTIC applications use the [`app`] attribute (`#[app(..)]`). This attribute only applies to a `mod`-item containing the RTIC application. The `app` attribute has a mandatory `device` argument that takes a *path* as a value. This must be a full path pointing to a *peripheral access crate* (PAC) generated using [`svd2rust`] **v0.14.x** or newer.
+All RTIC applications use the [`app`] attribute (`#[app(..)]`). This attribute only applies to a `mod`-item containing the RTIC application.
+
+The `app` attribute has a mandatory `device` argument that takes a *path* as a value. This must be a full path pointing to a *peripheral access crate* (PAC) generated using [`svd2rust`] **v0.14.x** or newer.
 
 The `app` attribute will expand into a suitable entry point and thus replaces the use of the [`cortex_m_rt::entry`] attribute.
 
@@ -12,13 +14,19 @@ The `app` attribute will expand into a suitable entry point and thus replaces th
 
 ## Structure and zero-cost concurrency
 
-An RTIC `app` is an executable system model for single-core applications, declaring a set of `local` and `shared` resources operated on by a set of `init`, `idle`, *hardware* and *software* tasks. In short the `init` task runs before any other task returning the set of `local` and `shared` resources. Tasks run preemptively based on their associated static priority, `idle` has the lowest priority (and can be used for background work, and/or to put the system to sleep until woken by some event). Hardware tasks are bound to underlying hardware interrupts, while software tasks are scheduled by asynchronous executors (one for each software task priority). 
+An RTIC `app` is an executable system model for single-core applications, declaring a set of `local` and `shared` resources operated on by a set of `init`, `idle`, *hardware* and *software* tasks. 
+
+* `init`  runs before any other task, and returns the `local` and `shared` resources.
+* Tasks (both hardware and software) run preemptively based on their associated static priority.
+* Hardware tasks are bound to underlying hardware interrupts.
+* Software tasks are schedulied by an set of asynchronous executors, one for each software task priority.
+* `idle` has the lowest priority, and can be used for background work, and/or to put the system to sleep until it is woken by some event.
 
 At compile time the task/resource model is analyzed under the Stack Resource Policy (SRP) and executable code generated with the following outstanding properties:
 
-- guaranteed race-free resource access and deadlock-free execution on a single-shared stack
-  - hardware task scheduling is performed directly by the hardware, and
-  - software task scheduling is performed by auto generated async executors tailored to the application.
+- Guaranteed race-free resource access and deadlock-free execution on a single-shared stack.
+- Hardware task scheduling is performed directly by the hardware.
+- Software task scheduling is performed by auto generated async executors tailored to the application.
 
 Overall, the generated code infers no additional overhead in comparison to a hand-written implementation, thus in Rust terms RTIC offers a zero-cost abstraction to concurrency.
 

book/en/src/by-example/hardware_tasks.md

@@ -1,8 +1,6 @@
 # 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.
-
-Hardware tasks are explicitly bound to interrupt handlers.
+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` (a hidden "task"), `#[init]` and `#[idle]` run as interrupt handlers.
 
 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.
 
@@ -17,6 +15,8 @@ Beware of using interrupt vectors that are used internally by hardware features;
 [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
 
+## Example
+
 The example below demonstrates the use of the `#[task(binds = InterruptName)]` attribute to declare a hardware task bound to an interrupt handler.
 
 ``` rust,noplayground

rtic/examples/hardware.rs

@@ -36,6 +36,8 @@ mod app {
 
         hprintln!("idle");
 
+        // Some backends provide a manual way of pending an
+        // interrupt.
         rtic::pend(Interrupt::UART0);
 
         loop {