mirror of
https://github.com/ferrous-systems/embedded-trainings-2020.git
synced 2024-10-31 22:28:49 +00:00
Merge pull request #156 from ferrous-systems/improve-material
revisions
This commit is contained in:
commit
c8b1e73d4f
4 changed files with 17 additions and 9 deletions
|
@ -50,6 +50,7 @@ impl Request {
|
||||||
windex: u16,
|
windex: u16,
|
||||||
wlength: u16,
|
wlength: u16,
|
||||||
) -> Result<Self, ()> {
|
) -> Result<Self, ()> {
|
||||||
|
// Request Codes
|
||||||
// see table 9-4 (USB specification)
|
// see table 9-4 (USB specification)
|
||||||
const SET_ADDRESS: u8 = 5;
|
const SET_ADDRESS: u8 = 5;
|
||||||
|
|
||||||
|
|
|
@ -45,6 +45,9 @@ fn on_event(_usbd: &USBD, event: Event) {
|
||||||
Event::UsbEp0DataDone => todo!(),
|
Event::UsbEp0DataDone => todo!(),
|
||||||
// leave this at it is for now.
|
// leave this at it is for now.
|
||||||
|
|
||||||
Event::UsbEp0Setup => todo!(),
|
Event::UsbEp0Setup => {
|
||||||
|
log::info!("goal reached; move to the next section");
|
||||||
|
|
||||||
|
}
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
|
@ -13,7 +13,7 @@ We'll use the `dk::usb::Ep0In` abstraction. An instance of it is available in th
|
||||||
|
|
||||||
The `Ep0In` API has two methods: `start` and `end`. `start` is used to start a DATA stage; this method takes a *slice of bytes* (`[u8]`) as argument; this argument is the response data. The `end` method needs to be called after `start`, when the EP0DATADONE event is raised, to complete the control transfer. `Ep0In` will automatically issue the STATUS stage that must follow the DATA stage.
|
The `Ep0In` API has two methods: `start` and `end`. `start` is used to start a DATA stage; this method takes a *slice of bytes* (`[u8]`) as argument; this argument is the response data. The `end` method needs to be called after `start`, when the EP0DATADONE event is raised, to complete the control transfer. `Ep0In` will automatically issue the STATUS stage that must follow the DATA stage.
|
||||||
|
|
||||||
✅ Implement the EP0DATADONE event by calling the `end` method of the `EP0In` API.
|
✅ Handle the EP0DATADONE event by calling the `end` method of the `EP0In` API.
|
||||||
|
|
||||||
✅ Implement the response to the GET_DESCRIPTOR request. Extend `usb-3.rs` so that it uses `Ep0In` to respond to the `GET_DESCRIPTOR Device` request (and only to that request).
|
✅ Implement the response to the GET_DESCRIPTOR request. Extend `usb-3.rs` so that it uses `Ep0In` to respond to the `GET_DESCRIPTOR Device` request (and only to that request).
|
||||||
|
|
||||||
|
@ -30,6 +30,7 @@ The `Ep0In` API has two methods: `start` and `end`. `start` is used to start a D
|
||||||
- `bNumConfigurations = 1`, must be at least `1` so this is the minimum value
|
- `bNumConfigurations = 1`, must be at least `1` so this is the minimum value
|
||||||
|
|
||||||
>(\*) the `common` crate refers to the crate in the `advanced/common` folder. It is already part of the `firmware` crate dependencies.
|
>(\*) the `common` crate refers to the crate in the `advanced/common` folder. It is already part of the `firmware` crate dependencies.
|
||||||
|
|
||||||
**Use the `usb2::device::Descriptor` abstraction**
|
**Use the `usb2::device::Descriptor` abstraction**
|
||||||
|
|
||||||
Although you can create the device descriptor by hand as an array filled with magic values we *strongly* recommend you use the `usb2::device::Descriptor` abstraction. The crate is already in the dependency list of the project; you can open its API documentation with the following command: `cargo doc -p usb2 --open`.
|
Although you can create the device descriptor by hand as an array filled with magic values we *strongly* recommend you use the `usb2::device::Descriptor` abstraction. The crate is already in the dependency list of the project; you can open its API documentation with the following command: `cargo doc -p usb2 --open`.
|
||||||
|
|
|
@ -60,13 +60,16 @@ modify `usb-2.rs` to read `USBD` registers and parse the SETUP data when an EP0S
|
||||||
|
|
||||||
**Getting Started:**
|
**Getting Started:**
|
||||||
|
|
||||||
- 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`
|
- 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`
|
||||||
- let bmrequesttype = usbd.bmrequesttype.read().bits() as u8;
|
- let bmrequesttype = usbd.bmrequesttype.read().bits() as u8;
|
||||||
- remember that we've learned how to read registers in `events.rs`.
|
- remember that we've learned how to read registers in `events.rs`.
|
||||||
- you will need to put together the higher and lower bits of `wlength`, `windex` and `wvalue` to get the whole field
|
- you will need to put together the higher and lower bits of `wlength`, `windex` and `wvalue` to get the whole field
|
||||||
- > Note: If you're using a Mac, you need to catch `SetAddress` requests returned by the parser as these are sent before the first GetDescriptor request. You can handle them by doing nothing.
|
|
||||||
|
|
||||||
1. when you have successfully received a GET_DESCRIPTOR request for a Device descriptor you are done. You should see an output like this:
|
- > Note: If you're using a Mac, you need to catch `SetAddress` requests returned by the parser as these are sent before the first GetDescriptor request. You can handle them by doing nothing.
|
||||||
|
|
||||||
|
**Expected Result:**
|
||||||
|
|
||||||
|
When you have successfully received a GET_DESCRIPTOR request for a Device descriptor you are done. You should see an output like this:
|
||||||
|
|
||||||
``` console
|
``` console
|
||||||
INFO:usb_2 -- USB: UsbReset @ 438.842772ms
|
INFO:usb_2 -- USB: UsbReset @ 438.842772ms
|
||||||
|
@ -77,7 +80,7 @@ INFO:usb_2 -- GET_DESCRIPTOR Device [length=64]
|
||||||
INFO:usb_2 -- Goal reached; move to the next section
|
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.
|
> Note: `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 this step in `advanced/firmware/src/bin/usb-2-solution.rs`.
|
You can find a solution to this step in `advanced/firmware/src/bin/usb-2-solution.rs`.
|
||||||
|
|
Loading…
Reference in a new issue