fixed a few more reported mistakes in interrupts chapter

Author: BartMassey

mdbook/src/15-interrupts/README.md

@@ -54,7 +54,15 @@ generate an interrupt before you are ready to handle it.
 
 **Note** As with most microcontrollers, there is a lot of flexibility in when the GPIOTE can generate an interrupt. Interrupts can be generated on low-to-high pin transition, high-to-low (as here), any change ("edge"), when low, or when high. On the nRF52833, interrupts generate an event that must be manually cleared in the ISR to ensure that the ISR is not called a second time for the same interrupt. Other microcontrollers may work a little differently — you should read Rust crate and microcontroller documentation to understand the details on a different board.
 
-When you push the A Button, you will see an "ouch" message and then a panic. Why does the interrupt handler call `panic!()`? Try commenting the `panic!()` call out and see what happens when you push the button. You will see "ouch" messages scroll off the screen. The NVIC records when an interrupt has been issued: that "event" is kept until it is explicitly cleared by the running program. Without the `panic!()`, when the interrupt handler returns the NVIC will (in this case) re-enable the interrupt, notice that there is still an interrupt event pending, and run the handler again. This will continue forever: each time the interrupt handler returns it will be called again. In the next section we will see how to clear the interrupt indication from within the interrupt handler.
+When you push the A Button, you will see an "ouch" message and then a panic. Why does the interrupt
+handler call `panic!()`? Try commenting the `panic!()` call out and see what happens when you push
+the button. You will see "ouch" messages scroll off the screen. The NVIC records when an interrupt
+has been issued: that "event" is kept until it is explicitly cleared by the running program. Without
+the `panic!()`, when the interrupt handler returns the NVIC will (in this case) re-enable the
+interrupt, notice that there is still an interrupt event pending, and run the handler again. This
+will continue forever: each time the interrupt handler returns it will be called again. As we will
+see in a bit, the interrupt indication can be cleared from within the interrupt handler using the
+`reset_event()` peripheral method.
 
 You may define ISRs for many different interrupt sources: when I2C is ready, when a timer expires,
 and on and on. Inside an ISR you can do pretty much anything you want, but it's good practice to

mdbook/src/15-interrupts/sharing-data-with-globals.md

@@ -266,17 +266,25 @@ and the rest of the program.
 Give this example (`examples/count.rs`) a run and note that the count is bumped up 1 on every push
 of the MB2 A button.
 
+```rust
+{{#include examples/count.rs}}
+```
+
 > **NOTE** It is always a good idea to compile examples involving interrupt handling with
 > `--release`. Long interrupt handlers can lead to a lot of confusion.
 
 Really, though, that `rprintln!()` in the interrupt handler is bad practice: while the interrupt
 handler is running the printing code, nothing else can move forward. Let's move the reporting to the
 main loop, just after the `wfi()` "wait for interrupt". The count will then be reported every time
-an interrupt handler finishes (`examples/count-bounce.rs`). Again, the count is bumped up 1 on every
-push of the MB2 A button.
+an interrupt handler finishes (`examples/count-bounce.rs`). 
+
+```rust
+{{#include examples/count-bounce.rs}}
+```
 
-Maybe. Especially if your MB2 is old (!), you may see a single press bump the counter by
-several. *This is not a software bug.* Mostly. In the next section, I'll talk about what might be
-going on and how we should deal with it.
+In this example the count is bumped up 1 on every push of the MB2 A button. Maybe. Especially if
+your MB2 is old (!), you may see a single press bump the counter by several. *This is not a software
+bug.* Mostly. In the next section, I'll talk about what might be going on and how we should deal
+with it.
 
 [Interrupts Is Threads]: https://onevariable.com/blog/interrupts-is-threads