mirrors/embedded-trainings-2020
1
0
Fork 0
mirror of https://github.com/ferrous-systems/embedded-trainings-2020.git synced 2024-05-14 22:43:05 +00:00
Code Issues Projects Releases Wiki Activity

tell folks to keep the USB cable connected

Browse source
This commit is contained in:
Jorge Aparicio 2020-07-16 14:07:17 +02:00
parent 5fe1cd7a0e
commit 1310e1aa6d
4 changed files with 12 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
embedded-workshop-book/src/data-stage.md
View file

@ -2,7 +2,9 @@
The next step is to respond to the GET_DESCRIPTOR request with a device descriptor. 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. ✅ Open the file `src/bin/usb-3.rs`. Implement the response to the GET_DESCRIPTOR request. Use the following guide for assistance.
❗️ Keep the cable connected to the J3 port for the rest of the workshop
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. 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.

4
embedded-workshop-book/src/setup-stage.md
View file

@ -12,7 +12,9 @@ So that's what we'll do here. In `advanced/common/usb/lib.rs` you'll find starte
The definition of `Descriptor::Configuration` as well as the associated test has been "commented out" using an `#[cfg(TODO)]` attribute because it is not handled by the firmware yet. Delete the `#[cfg(TODO)]` so that the unit tests can access it. This pattern is used for enum members and test functions throughout this workshop, so keep it in mind should you see it again. The definition of `Descriptor::Configuration` as well as the associated test has been "commented out" using an `#[cfg(TODO)]` attribute because it is not handled by the firmware yet. Delete the `#[cfg(TODO)]` so that the unit tests can access it. This pattern is used for enum members and test functions throughout this workshop, so keep it in mind should you see it again.
✅ Parse the data of this SETUP stage. ✅ Parse the data of this SETUP stage.
❗️ Keep the cable connected to the J3 port for the rest of the workshop
Start with the GET_DESCRIPTOR request, which is described in detail in section 9.4.3 of the USB specification. All the constants you will need are described in Tables 9-3, 9-4 and 9-5. Start with the GET_DESCRIPTOR request, which is described in detail in section 9.4.3 of the USB specification. All the constants you will need are described in Tables 9-3, 9-4 and 9-5.

4
embedded-workshop-book/src/supporting-standard-requests.md
View file

@ -1,6 +1,6 @@
# USB-4: Supporting more Standard Requests # USB-4: Supporting more Standard Requests
After responding to the `GET_DESCRIPTOR Device` request the host will start sending different 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: ✅ Update the parser in `common/usb` so that it can handle the following requests:
@ -11,6 +11,8 @@ The starter `common/usb` code contains unit tests for these other requests as we
✅ 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. ✅ 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.
❗️ Keep the cable connected to the J3 port for the rest of the workshop
If you need a reference, you can find solutions to parsing `GET_DESCRIPTOR Configuration` and `SET_CONFIGURATION` requests in the following files: If you need a reference, you can find solutions to parsing `GET_DESCRIPTOR Configuration` and `SET_CONFIGURATION` requests in the following files:
- `advanced/common/usb/solution-get-descriptor-configuration.rs` - `advanced/common/usb/solution-get-descriptor-configuration.rs`

5
embedded-workshop-book/src/usb-events.md
View file

@ -2,12 +2,14 @@
The USBD peripheral on the nRF52840 contains a series of registers, called EVENTS registers, that indicate the reason for entering the USBD event handler. These events must be handled by the application to complete the enumeration process. The USBD peripheral on the nRF52840 contains a series of registers, called EVENTS registers, that indicate the reason for entering the USBD event handler. These events must be handled by the application to complete the enumeration process.
✅ Open the `firmware/src/bin/usb-1.rs` file. ✅ Open the `firmware/src/bin/usb-1.rs` file.
In this starter code the USBD peripheral is initialized in `init` and a task, named `main`, is bound to the interrupt signal USBD. This task will be called every time a new USBD event needs to be handled. The `main` task uses `usbd::next_event()` to check all the event registers; if any event is set (occurred) then the function returns the event, represented by the `Event` enum, wrapped in the `Some` variant. This `Event` is then passed to the `on_event` function for further processing. In this starter code the USBD peripheral is initialized in `init` and a task, named `main`, is bound to the interrupt signal USBD. This task will be called every time a new USBD event needs to be handled. The `main` task uses `usbd::next_event()` to check all the event registers; if any event is set (occurred) then the function returns the event, represented by the `Event` enum, wrapped in the `Some` variant. This `Event` is then passed to the `on_event` function for further processing.
✅ Connect the USB cable to the port J3 then run the starter code. ✅ Connect the USB cable to the port J3 then run the starter code.
❗️ Keep the cable connected to the J3 port for the rest of the workshop
Go to `fn on_event`, line 39. In this section you'll need to implement the following USB events until you reach the EP0SETUP event: Go to `fn on_event`, line 39. In this section you'll need to implement the following USB events until you reach the EP0SETUP event:
- `USBRESET`. This event indicates that the host issued a USB reset signal. According to the USB specification this will move the device from any state to the `Default` state. Since we are currently not dealing with any other state, you can handle this state by doing nothing. - `USBRESET`. This event indicates that the host issued a USB reset signal. According to the USB specification this will move the device from any state to the `Default` state. Since we are currently not dealing with any other state, you can handle this state by doing nothing.
@ -27,4 +29,3 @@ INFO:usb_1 -- goal reached; move to the next section
Do not overthink this exercise; it is not a trick question. There is very little to do and no new functionality to add. Do not overthink this exercise; it is not a trick question. There is very little to do and no new functionality to add.
You can find the solution in the `usb-1-solution.rs` file. You can find the solution in the `usb-1-solution.rs` file.