mirrors/embedded-trainings-2020
1
0
Fork 0
mirror of https://github.com/ferrous-systems/embedded-trainings-2020.git synced 2025-01-09 07:45:34 +00:00
Code Issues Projects Releases Wiki Activity

advanced/README.md: 9.4.7 usb -> prose

Browse source
This commit is contained in:
Lotte Steenbrink 2020-07-13 15:04:22 +02:00
parent e1a71c93e6
commit efc0a17237
2 changed files with 8 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
embedded-workshop-book/src/getting-device-configured.md
View file

@ -16,7 +16,7 @@ Now modify the `print-descs` program to "open" the device -- this operation is c
## 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.
@ -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 not valid then stall the endpoint
- If the device is in the `Configured` state, then
- if the requested configuration value 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 the requested configuration value is not valid then stall the endpoint
- If the device is in the `Configured` state, then read the requested configuration value from `wValue`
- if `wValue` is 0 (`None` in the `usb` API) then return to the `Address` state
- 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 `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.
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.
> Section 9.4.7 Set Configuration, of the USB spec contains the full description of how to handle this request.
## Expected output
Once you are correctly handling the `SET_CONFIGURATION` request you should get logs like these:

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

@ -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:
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.