Rename Workbook/workshop

We run trainings, which have a mixture of slides and exercises

Author: jonathanpallant

exercise-book/src/SUMMARY.md

@@ -27,7 +27,7 @@
 
 - [Self-check project](./self-check.md)
 
-# Bare-Metal Firmware on the nRF52
+# Working with the nRF52
 
 - [Preparation](./nrf52-preparation.md)
   - [Code Organization](./nrf52-code-organisation.md)
@@ -44,9 +44,9 @@
   - [`no probe was found` error](./nrf52-troubleshoot-probe-not-found.md)
   - [`location info is incomplete` error](./nrf52-troubleshoot-location-info.md)
 
-## nRF52 Radio Workbook
+# Bare-Metal Rust: Getting Started
 
-- [nRF52 Radio Workbook](./nrf52-radio-workbook.md)
+- [nRF52 Radio Exercise](./nrf52-radio-exercise.md)
   - [Parts of an Embedded Program](./nrf52-radio-parts-embedded-program.md)
   - [Building an Embedded Program](./nrf52-radio-building-program.md)
   - [Binary Size](./nrf52-radio-binary-size.md)
@@ -68,14 +68,14 @@
     - [Interrupt handling](./nrf52-radio-interrupt-handling.md)
     - [Starting a Project from Scratch](./nrf52-radio-from-scratch.md)
 
-## nRF52 HAL Workbook
+# Bare-Metal Rust: Using a HAL
 
-- [nRF52 HAL Workbook](./nrf52-hal-workbook.md)
+- [nRF52 HAL Exercise](./nrf52-hal-exercise.md)
   - [Adding Buttons](./nrf52-hal-buttons.md)
 
-## nRF52 USB Workbook
+# Bare-Metal Rust: Interrupts
 
-- [nRF52 USB Workbook](./nrf52-usb-workbook.md)
+- [nRF52 USB Exercise](./nrf52-usb-exercise.md)
   - [Listing USB Devices](./nrf52-usb-listing-usb-devices.md)
   - [Hello, world!](./nrf52-usb-hello-world.md)
   - [Checking the API documentation](./nrf52-usb-api-documentation.md)

exercise-book/src/nrf52-code-organisation.md

@@ -1,8 +1,8 @@
 # nRF52 Code Organization
 
-## Workshop Materials
+## Training Materials
 
-You will need a local copy of the workshop materials. We recommend the Github release as it contains pre-compiled HTML docs and pre-compiled dongle firmware, but you can clone the repo with `git` and check out the appropriate tag as well if you prefer.
+You will need a local copy of the training materials. We recommend the Github release as it contains pre-compiled HTML docs and pre-compiled dongle firmware, but you can clone the repo with `git` and check out the appropriate tag as well if you prefer.
 
 Ask your trainer which release/tag you should be using.
 
@@ -19,7 +19,7 @@ git clone https://github.com/ferrous-systems/rust-exercises.git
 cd rust-exercises
 ```
 
-The git repository contains all workshop materials, i.e. code snippets, custom tools and the source for this handbook, but not the pre-compiled dongle firmware.
+The git repository contains all training materials, i.e. code snippets, custom tools and the source for this handbook, but not the pre-compiled dongle firmware.
 
 ## Firmware
 

exercise-book/src/nrf52-hal-workbook.md exercise-book/src/nrf52-hal-exercise.mdexercise-book/src/nrf52-hal-workbook.md renamed to exercise-book/src/nrf52-hal-exercise.md

@@ -1,6 +1,6 @@
-# nRF52 HAL Workbook
+# nRF52 HAL Exercise
 
-In this workshop you'll learn to:
+In this exercise you'll learn to:
 
 - use a HAL to provide features in a BSP
 - configure GPIO pins using the nRF52 HAL
@@ -9,7 +9,7 @@ To test your BSP changes, you will modify a small example: `hal-app/src/bin/blin
 
 You will need an nRF52840 Development Kit for this exercise, but not the nRF USB dongle.
 
-If you haven't completed the Radio Workbook, you should start there, and go at least as far as completing the "Timers and Time" section.
+If you haven't completed the Radio Exercise, you should start there, and go at least as far as completing the "Timers and Time" section.
 
 ## The nRF52840 Development Kit
 

exercise-book/src/nrf52-preparation.md

@@ -18,7 +18,7 @@ For the span of these exercises keep the nRF52840 DK connected to your PC using
 
 ## Starter code
 
-Project templates and starter code for this workshop can be found at [in this repo](https://github.com/ferrous-systems/rust-exercises).
+Project templates and starter code for our trainings can be found at [in this repo](https://github.com/ferrous-systems/rust-exercises).
 
 ## Required tools
 

exercise-book/src/nrf52-radio-collision-avoidance.md

@@ -8,7 +8,7 @@ The first method scans the currently selected channel (see `set_channel()`), mea
 
 Under the 802.15.4 specification, before sending a data packet devices must first check if there's communication going on in the channel. This process is known as Clear Channel Assessment (CCA). The `send` method we have been used performs CCA in a loop and sends the packet only when the channel appears to be idle. The `try_send` method performs CCA *once* and returns the `Err` variant if the channel appears to be busy. In this failure scenario the device does not send any packet.
 
-The `Radio` abstraction supports 2 CCA modes: `CarrierSense` and `EnergyDetection`. `CarrierSense` is the default CCA mode and what we have been using in this workshop. `CarrierSense` will only look for ongoing 802.15.4 traffic in the channel but ignore other traffic like 2.4 GHz WiFi and Bluetooth. The `EnergyDetection` method is able to detect ongoing non-802.15.4 traffic.
+The `Radio` abstraction supports 2 CCA modes: `CarrierSense` and `EnergyDetection`. `CarrierSense` is the default CCA mode and what we have been using in this exercise. `CarrierSense` will only look for ongoing 802.15.4 traffic in the channel but ignore other traffic like 2.4 GHz WiFi and Bluetooth. The `EnergyDetection` method is able to detect ongoing non-802.15.4 traffic.
 
 Here are some things for you to try out:
 

exercise-book/src/nrf52-radio-workbook.md exercise-book/src/nrf52-radio-exercise.mdexercise-book/src/nrf52-radio-workbook.md renamed to exercise-book/src/nrf52-radio-exercise.md

@@ -1,14 +1,14 @@
-# nRF52 Radio Workbook
+# nRF52 Radio Exercise
 
-In this workshop you'll get familiar with:
+In this exercise you'll get familiar with:
 
 - the structure of embedded Rust programs,
 - the existing embedded Rust tooling, and
 - embedded application development using a Board Support Package (BSP).
 
 To put these concepts in practice you'll write applications that use the radio functionality of the nRF52840 microcontroller.
 
-You have received two development boards for this workshop. We'll use both in the this radio workshop.
+You should have acquired two development boards for your training. We'll use both in the this radio exercise.
 
 ## The nRF52840 Development Kit
 
@@ -26,7 +26,7 @@ The board has the form factor of a USB stick and can be directly connected to on
 
 ## The nRF52840
 
-Both development boards have an nRF52840 microcontroller. Here are some details about it that are relevant to this workshop.
+Both development boards have an nRF52840 microcontroller. Here are some details that are relevant to these exercises:
 
 - single core ARM Cortex-M4 processor clocked at 64 MHz
 - 1 MB of Flash (at address `0x0000_0000`)

exercise-book/src/nrf52-radio-in.md

@@ -16,4 +16,4 @@ The Dongle will respond as soon as it receives a packet. If you insert a delay b
 
 Having log statements between `send` and `recv_timeout` can also cause packets to be missed so try to keep those two calls as close to each other as possible and with as little code in between as possible.
 
-> NOTE Packet loss can always occur in wireless networks, even if the radios are close to each other. The `Radio` API we are using will not detect lost packets because it does not implement IEEE 802.15.4 Acknowledgement Requests. For the next step in the workshop, we will use a new function to handle this for us. For the sake of other radio users, please do ensure you never call `send()` in a tight loop!
+> NOTE Packet loss can always occur in wireless networks, even if the radios are close to each other. The `Radio` API we are using will not detect lost packets because it does not implement IEEE 802.15.4 Acknowledgement Requests. For the next step in the exercise, we will use a new function to handle this for us. For the sake of other radio users, please do ensure you never call `send()` in a tight loop!

exercise-book/src/nrf52-radio-interrupt-handling.md

@@ -1,8 +1,8 @@
 # Interrupt handling
 
-We haven't covered interrupt handling in the workshop but the `cortex-m-rt` crate provides attributes to declare exception and interrupt handlers: `#[exception]` and `#[interrupt]`. You can find documentation about these attributes and how to safely share data with interrupt handlers using Mutexes in the ["Concurrency" chapter][concurrency] of the Embedded Rust book.
+If we haven't covered interrupt handling in your training, the `cortex-m-rt` crate provides attributes to declare exception and interrupt handlers: `#[exception]` and `#[interrupt]`. You can find documentation about these attributes and how to safely share data with interrupt handlers using Mutexes in the ["Concurrency" chapter][concurrency] of the Embedded Rust book.
 
-Another way to deal with interrupts is to use a framework like Real-Time Interrupt-driven Concurrency ([RTIC]); this framework has a [book] that explains how you can build reactive applications using interrupts. We use this framework in the "USB" workshop.
+Another way to deal with interrupts is to use a framework like Real-Time Interrupt-driven Concurrency ([RTIC]); this framework has a [book] that explains how you can build reactive applications using interrupts. We use this framework in the "USB" exercise.
 
 [concurrency]: https://rust-embedded.github.io/book/concurrency/index.html
 [RTIC]: https://crates.io/crates/cortex-m-rtic

exercise-book/src/nrf52-radio-link-quality.md

@@ -22,4 +22,4 @@ Take note of how LQI changes with these changes. Does packet loss occur in any o
 
 The radio API we are using follows the PHY layer of the IEEE 802.15.4 specification, but it's missing MAC level features like addressing (each device gets its own address), opt-in acknowledgment (a transmitted packet must be acknowledged with a response acknowledgment packet; the packet is re-transmitted if the packet is not acknowledged in time). These MAC level features are not implemented *in hardware* (in the nRF52840 Radio peripheral) so they would need to be implemented in software to be fully IEEE 802.15.4 compliant.
 
-This is not an issue for the workshop exercises but it's something to consider if you would like to continue from here and build a 802.15.4 compliant network API.
+This is not an issue for these exercises but it's something to consider if you would like to continue from here and build a 802.15.4 compliant network API.

exercise-book/src/nrf52-radio-messages.md

@@ -82,7 +82,7 @@ On the other hand, `"Hello"` is a string literal with type `&str`. `str` strings
 
 ## Printing strings and characters
 
-In this workshop we'll work with ASCII strings so byte string literals that contain no escaped characters are OK to use as packet payloads.
+In this exercise we'll work with ASCII strings so byte string literals that contain no escaped characters are OK to use as packet payloads.
 
 You'll note that `defmt::println!("{:?}", b"Hello")` will print `[72, 101, 108, 108, 111]` rather than `"Hello"` and that the `{}` format specifier (`Display`) does not work. This is because the type of the literal is `&[u8; N]` and in Rust this type means "bytes"; those bytes could be ASCII data, UTF-8 data or something else.