mirror of
https://github.com/ferrous-systems/embedded-trainings-2020.git
synced 2025-01-24 06:48:11 +00:00
rename USB parser solutions
also put them outside the `src` directory so people don't think they are modules
This commit is contained in:
parent
9cab8bb24e
commit
48e2ef512f
5 changed files with 11 additions and 11 deletions
|
@ -1,5 +1,5 @@
|
|||
//! Some USB 2.0 data types
|
||||
// NOTE this is a solution to exercise `usb-3`
|
||||
// NOTE this is a partial solution to exercise `usb-3`
|
||||
|
||||
#![deny(missing_docs)]
|
||||
#![deny(warnings)]
|
|
@ -1,5 +1,5 @@
|
|||
//! Some USB 2.0 data types
|
||||
// NOTE this is a solution to exercise `usb-2`
|
||||
// NOTE this is a partial solution to exercise `usb-2`
|
||||
|
||||
#![deny(missing_docs)]
|
||||
#![deny(warnings)]
|
|
@ -1,5 +1,5 @@
|
|||
//! Some USB 2.0 data types
|
||||
// NOTE this is a solution to exercise `usb-2`
|
||||
// NOTE this is a partial solution to exercise `usb-4`
|
||||
|
||||
#![deny(missing_docs)]
|
||||
#![deny(warnings)]
|
|
@ -1,6 +1,6 @@
|
|||
# USB-2: SETUP Stage
|
||||
|
||||
At the end of program `usb-1` we received a EP0SETUP event. This event signals the *end* of the SETUP stage of a control transfer. The nRF52840 USBD peripheral will automatically receive the SETUP data and store it in the registers BMREQUESTTYPE, BREQUEST, WVALUE{L,H}, WINDEX{L,H} and WLENGTH{L,H}.
|
||||
At the end of program `usb-1` we received a EP0SETUP event. This event signals the *end* of the SETUP stage of a control transfer. The nRF52840 USBD peripheral will automatically receive the SETUP data and store it in the registers BMREQUESTTYPE, BREQUEST, WVALUE{L,H}, WINDEX{L,H} and WLENGTH{L,H}.
|
||||
In `usb-2.rs`, you will find a short description of each register above the variable into which it should be read.
|
||||
|
||||
> For in-depth register documentation, refer to sections 6.35.13.31 to 6.35.13.38 of the [nRF52840 Product Specification][nrf product spec].
|
||||
|
@ -25,16 +25,16 @@ You will also find this information in the `// TODO implement ...` comment in th
|
|||
|
||||
To complete the task, proceed like this:
|
||||
|
||||
1. **Parse GET_DESCRIPTOR requests:**
|
||||
1. **Parse GET_DESCRIPTOR requests:**
|
||||
Modify `Request::parse()` in `advanced/common/usb/src/lib.rs` to recognize a GET_DESCRIPTOR request so that the `get_descriptor_device` test passes. Note that the parser already handles SET_ADDRESS requests.
|
||||
|
||||
- check table 9-4 in the USB specification for Request Codes
|
||||
- remember that you can define binary literals by prefixing them with `0b`
|
||||
- you can use bit shifts (`>>`) and casts (`as u8`) to get the high/low bytes of a `u16`
|
||||
|
||||
See `advanced/common/usb/src/get-descriptor-device.rs` for a solution.
|
||||
See `advanced/common/usb/solution-get-descriptor-device.rs` for a solution.
|
||||
|
||||
2. **Read incoming request information and pass it to the parser:**
|
||||
2. **Read incoming request information and pass it to the parser:**
|
||||
modify `usb-2.rs` to read `USBD` registers and parse the SETUP data when an EPSETUP event is received.
|
||||
- for a mapping of register names to the `USBD` API, check the entry for `nrf52840_hal::target::usbd` in the documentation you've created using `cargo doc`
|
||||
- remember that we've learned how to read registers in `events.rs`
|
||||
|
@ -54,5 +54,5 @@ INFO:usb_2 -- Goal reached; move to the next section
|
|||
|
||||
`wlength` / `length` can vary depending on the OS, USB port (USB 2.0 vs USB 3.0) or the presence of a USB hub so you may see a different value.
|
||||
|
||||
You can find a solution to step 1. in `advanced/common/usb/get-descriptor-device.rs`.
|
||||
You can find a solution to step 1. in `advanced/common/usb/solution-get-descriptor-device.rs`.
|
||||
You can find a solution to step 2. in `advanced/firmware/src/bin/usb-2-solution.rs`.
|
||||
|
|
|
@ -11,7 +11,7 @@ For each green test, you can extend `usb-4.rs` to handle the new requests your p
|
|||
|
||||
If you need a reference, you can find solutions to parsing `GET_DESCRIPTOR Configuration` and `SET_CONFIGURATION` requests in the following files:
|
||||
|
||||
- `advanced/common/src/get-descriptor-configuration.rs`
|
||||
- `advanced/common/src/set-configuration.rs`
|
||||
- `advanced/common/usb/solution-get-descriptor-configuration.rs`
|
||||
- `advanced/common/usb/solution-set-configuration.rs`
|
||||
|
||||
Each file contains just enough code to parse the request in its name and the `GET_DESCRIPTOR Device` request. So you can refer to `set-configuration.rs` without getting "spoiled" about how to parse the `SET_CONFIGURATION` request.
|
||||
Each file contains just enough code to parse the request in its name and the `GET_DESCRIPTOR Device` and `SET_ADDRESS` requests. So you can refer to `solution-get-descriptor-configuration.rs` without getting "spoiled" about how to parse the `SET_CONFIGURATION` request.
|
||||
|
|
Loading…
Reference in a new issue