diff --git a/embedded-workshop-book/src/data-stage.md b/embedded-workshop-book/src/data-stage.md index 322ee24..38b67db 100644 --- a/embedded-workshop-book/src/data-stage.md +++ b/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. diff --git a/embedded-workshop-book/src/dma.md b/embedded-workshop-book/src/dma.md index 2efe4cf..fdeca13 100644 --- a/embedded-workshop-book/src/dma.md +++ b/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: diff --git a/embedded-workshop-book/src/idle-state.md b/embedded-workshop-book/src/idle-state.md index b4ba40c..963b9fe 100644 --- a/embedded-workshop-book/src/idle-state.md +++ b/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 diff --git a/embedded-workshop-book/src/supporting-standard-requests.md b/embedded-workshop-book/src/supporting-standard-requests.md index f3cc5bb..86380d8 100644 --- a/embedded-workshop-book/src/supporting-standard-requests.md +++ b/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: diff --git a/embedded-workshop-book/src/unknown-requests.md b/embedded-workshop-book/src/unknown-requests.md index fbdecb8..a6d48d3 100644 --- a/embedded-workshop-book/src/unknown-requests.md +++ b/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`. \ No newline at end of file +✅ Use the `dk::usbd::ep0stall()` helper function to stall endpoint 0 in `usb-4.rs`. \ No newline at end of file diff --git a/embedded-workshop-book/src/updating-device-state.md b/embedded-workshop-book/src/updating-device-state.md index 29b69cb..a221bcc 100644 --- a/embedded-workshop-book/src/updating-device-state.md +++ b/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.