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

getting-device-configured.md: SET_CONFIGURATION fields -> prose; fix typo

Browse source
This commit is contained in:
Lotte Steenbrink 2020-07-13 17:08:07 +02:00
parent 38d6500879
commit 811402a423
2 changed files with 12 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -16,14 +16,21 @@ Now modify the `print-descs` program to "open" the device -- this operation is c
## SET_CONFIGURATION ## SET_CONFIGURATION
The SET_CONFIGURATION request is sent by the host to configure the device. The SET_CONFIGURATION request is sent by the host to configure the device. Its configuration according to section 9.4.7. of the USB spec is:
- `bmrequesttype` is 0b00000000
- `brequest` is SET_CONFIGURATION
- `wValue` contains the requested configuration value
- `wIndex` and `wLength` are 0, there is no `wData`
To handle a SET_CONFIGURATION, do the following:
- 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.
- If the device is in the `Address` state, then - If the device is in the `Address` state, then
- if the requested configuration value is 0 (`None` in the `usb` API) then stay in the `Address` state - if `wValue` is 0 (`None` in the `usb` API) then stay in 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 - if `wValue` 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 `wValue` is not valid then stall the endpoint
- If the device is in the `Configured` state, then read the requested configuration value from `wValue` - 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 0 (`None` in the `usb` API) then return to the `Address` state
@ -35,8 +42,6 @@ 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:

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

@ -15,7 +15,7 @@ The definition of `Descriptor::Configuration` as well as the associated test has
Your task now is to parse the data of this SETUP stage. We will 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. Your task now is to parse the data of this SETUP stage. We will 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.
The fields of a GET_DESCRIPTOR request are as follows: The fields of a GET_DESCRIPTOR request are as follows:
- `bmrequesttype` is 0b00000000 - `bmrequesttype` is 0b10000000
- `bRequest` is GET_DESCRIPTOR - `bRequest` is GET_DESCRIPTOR
- the high byte of `wValue` contains the descriptor type, whereas the low byte contains the descriptor index - the high byte of `wValue` contains the descriptor type, whereas the low byte contains the descriptor index
- `wIndex` is set to 0 for our purposes - `wIndex` is set to 0 for our purposes