more didactic changes

embedded-workshop-book/src/data-stage.md

@@ -1,6 +1,10 @@
 # USB-3: DATA Stage
 
-The next step is to respond to the GET_DESCRIPTOR request with a device descriptor. To do this we'll use the `dk::usb::Ep0In` abstraction -- we'll look into what the abstraction does in a future section; for now we'll just use it.
+The next step is to respond to the GET_DESCRIPTOR request with a device descriptor.
+
+✅ Open the file `src/bin/usb-3.rs`. Implement the response to the GET_DESCRIPTOR request. Use the following guide for assistance. 
+
+ To do this we'll use the `dk::usb::Ep0In` abstraction -- we'll look into what the abstraction does in a future section; for now we'll just use it.
 
 An instance of this abstraction is available in the `board` value (`#[init]` function). The first step is to make this `Ep0In` instance available to the `on_event` function.
 

embedded-workshop-book/src/dma.md

@@ -1,6 +1,14 @@
 # DMA
 
-Let's zoom into the `Ep0In` abstraction used in `usb4.rs` next. You can use VSCode's "Go to Definition" to see the implementation of the `Ep0In.start()` method. What this method does is start a DMA transfer to send `bytes` to the host. The data (`bytes`) is first copied into an internal buffer and then the DMA is configured to move the data from that internal buffer to the USBD peripheral.
+[What do endpoints have to do with dma]
+
+[What is the task in this section?]
+
+Let's zoom into the `Ep0In` abstraction used in `usb-4.rs` next. 
+
+✅ Open the file. Use VSCode's "Go to Definition" to see the implementation of the `Ep0In.start()` method. 
+
+What this method does is start a DMA transfer to send `bytes` to the host. The data (`bytes`) is first copied into an internal buffer and then the DMA is configured to move the data from that internal buffer to the USBD peripheral.
 
 The signature of the `start()` method does *not* ensure that:
 

embedded-workshop-book/src/idle-state.md

@@ -55,7 +55,7 @@ You can find traces for other OSes in these files (they are in the `advanced` fo
 - `macos-enumeration.txt`
 - `win-enumeration.txt`
 
-At this point you can double check that the enumeration works by running the [`usb-list` tool](./listing-usb-devices.md) while `usb-4.rs` is running.
+✅ Double check that the enumeration works by running the [`usb-list` tool](./listing-usb-devices.md) while `usb-4.rs` is running.
 
 ``` console
 Bus 001 Device 013: ID 1366:1015 <- J-Link on the nRF52840 Development Kit

embedded-workshop-book/src/supporting-standard-requests.md

@@ -1,13 +1,15 @@
 # USB-4: Supporting more Standard Requests
 
-After responding to the `GET_DESCRIPTOR Device` request the host will start sending different requests. The parser in `common/usb` will need to be updated to handle these requests:
+After responding to the `GET_DESCRIPTOR Device` request the host will start sending different requests. 
+
+✅ Update the parser in `common/usb` so that it can handle the following requests:
 
 1. `GET_DESCRIPTOR Configuration`, see the section on [Handling GET_DESCRIPTOR Configuration Requests](./get-descriptor-config.md#handling-get_descriptor-configuration-requests)
 2. `SET_CONFIGURATION`, see the section on [SET_CONFIGURATION](./getting-device-configured.md#set_configuration) of this course material
 
 The starter `common/usb` code contains unit tests for these other requests as well as extra `Request` variants for these requests. All of them have been commented out using a `#[cfg(TODO)]` attribute which you can remove once you need any new variant or new unit test.
 
-For each green test, you can extend `usb-4.rs` to handle the new requests your parser is now able to recognize. **Make sure to read the next sections as you're working**, since they contain explanations about the concepts used and needed to complete this task.
+✅ For each green test, extend `usb-4.rs` to handle the new requests your parser is now able to recognize. **Make sure to read the next sections as you're working**, since they contain explanations about the concepts used and needed to complete this task.
 
 If you need a reference, you can find solutions to parsing `GET_DESCRIPTOR Configuration` and `SET_CONFIGURATION` requests in the following files:
 

embedded-workshop-book/src/unknown-requests.md

@@ -5,5 +5,4 @@ You may come across host requests other than the ones listed in previous section
 For this situation, the USB specification defines a device-side procedure for "stalling an endpoint", which amounts to the device telling the host that it doesn't support some request.
 > This procedure should be used to deal with invalid requests, requests whose SETUP stage doesn't match any USB 2.0 standard request, and requests not supported by the device– for instance the SET_DESCRIPTOR request is not mandatory.
 
-You can use the `dk::usbd::ep0stall()` helper function to stall endpoint 0.
-Your task is to do this in the right place in `usb-4.rs`.
+✅ Use the `dk::usbd::ep0stall()` helper function to stall endpoint 0 in `usb-4.rs`.

embedded-workshop-book/src/updating-device-state.md

@@ -4,7 +4,7 @@ At some point during the initialization you'll receive a `SET_ADDRESS` request t
 
 The device state should be tracked using a resource so that it's preserved across multiple executions of the `USBD` event handler. The `usb2` crate has a `State` enum with the 3 possible USB states: `Default`, `Address` and `Configured`. You can use that enum or roll your own.
 
-Start tracking and updating the device state to move your request handling forward:
+✅ Start tracking and updating the device state to move your request handling forward:
 
 1. **Update the handling of the `USBRESET` event:** Instead of ignoring it, we now want it to change the state of the USB device. See section 9.1 USB Device States of the USB specification for details on what to do.