mirror of
https://github.com/ferrous-systems/embedded-trainings-2020.git
synced 2025-01-24 14:58:09 +00:00
advanced/README.md: 9.4.7 usb -> prose
This commit is contained in:
parent
e1a71c93e6
commit
efc0a17237
2 changed files with 8 additions and 6 deletions
|
@ -16,7 +16,7 @@ Now modify the `print-descs` program to "open" the device -- this operation is c
|
||||||
|
|
||||||
## SET_CONFIGURATION
|
## SET_CONFIGURATION
|
||||||
|
|
||||||
Section 9.4.7, Set Configuration, of the USB spec describes how to handle this request but below you can find a summary:
|
The SET_CONFIGURATION request is sent by the host to configure the device.
|
||||||
|
|
||||||
- If the device is in the `Default` state, you should stall the endpoint because the operation is not permitted in that state.
|
- If the device is in the `Default` state, you should stall the endpoint because the operation is not permitted in that state.
|
||||||
|
|
||||||
|
@ -25,16 +25,18 @@ Section 9.4.7, Set Configuration, of the USB spec describes how to handle this r
|
||||||
- if the requested configuration value is non-zero and valid (was previously reported in a configuration descriptor) then move to the `Configured` state
|
- if the requested configuration value is non-zero and valid (was previously reported in a configuration descriptor) then move to the `Configured` state
|
||||||
- if the requested configuration value is not valid then stall the endpoint
|
- if the requested configuration value is not valid then stall the endpoint
|
||||||
|
|
||||||
- If the device is in the `Configured` state, then
|
- If the device is in the `Configured` state, then read the requested configuration value from `wValue`
|
||||||
- if the requested configuration value is 0 (`None` in the `usb` API) then return to the `Address` state
|
- if `wValue` is 0 (`None` in the `usb` API) then return to the `Address` state
|
||||||
- if the requested configuration value is non-zero and valid (was previously reported in a configuration descriptor) then move to the `Configured` state with the new configuration value
|
- if `wValue` is non-zero and valid (was previously reported in a configuration descriptor) then move to the `Configured` state with the new configuration value
|
||||||
- if the requested configuration value is not valid then stall the endpoint
|
- if `wValue` is not valid then stall the endpoint
|
||||||
|
|
||||||
In all the cases where you did not stall the endpoint (by returning `Err`) you'll need to acknowledge the request by starting a STATUS stage.
|
In all the cases where you did not stall the endpoint (by returning `Err`) you'll need to acknowledge the request by starting a STATUS stage.
|
||||||
This is done by writing 1 to the TASKS_EP0STATUS register.
|
This is done by writing 1 to the TASKS_EP0STATUS register.
|
||||||
|
|
||||||
NOTE: On Windows, you may get a `GET_STATUS` request *before* the `SET_CONFIGURATION` request and although you *should* respond to it, stalling the `GET_STATUS` request seems sufficient to get the device to the `Configured` state.
|
NOTE: On Windows, you may get a `GET_STATUS` request *before* the `SET_CONFIGURATION` request and although you *should* respond to it, stalling the `GET_STATUS` request seems sufficient to get the device to the `Configured` state.
|
||||||
|
|
||||||
|
> Section 9.4.7 Set Configuration, of the USB spec contains the full description of how to handle this request.
|
||||||
|
|
||||||
## Expected output
|
## Expected output
|
||||||
|
|
||||||
Once you are correctly handling the `SET_CONFIGURATION` request you should get logs like these:
|
Once you are correctly handling the `SET_CONFIGURATION` request you should get logs like these:
|
||||||
|
|
|
@ -3,7 +3,7 @@
|
||||||
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. The parser in `common/usb` will need to be updated to handle these requests:
|
||||||
|
|
||||||
1. `GET_DESCRIPTOR Configuration`, see section 9.4.3 of the USB spec
|
1. `GET_DESCRIPTOR Configuration`, see section 9.4.3 of the USB spec
|
||||||
2. `SET_CONFIGURATION`, see section 9.4.7 of the USB spec -- this request is likely to only be observed on Linux during enumeration
|
2. `SET_CONFIGURATION`, see section [SET_CONFIGURATION](#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.
|
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.
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue