From efc0a172378f5e722464353272c9a644152ed454 Mon Sep 17 00:00:00 2001 From: Lotte Steenbrink Date: Mon, 13 Jul 2020 15:04:22 +0200 Subject: [PATCH] advanced/README.md: 9.4.7 usb -> prose --- .../src/getting-device-configured.md | 12 +++++++----- .../src/supporting-standard-requests.md | 2 +- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/embedded-workshop-book/src/getting-device-configured.md b/embedded-workshop-book/src/getting-device-configured.md index fe166ba..bf94815 100644 --- a/embedded-workshop-book/src/getting-device-configured.md +++ b/embedded-workshop-book/src/getting-device-configured.md @@ -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: diff --git a/embedded-workshop-book/src/supporting-standard-requests.md b/embedded-workshop-book/src/supporting-standard-requests.md index 59f5026..f6ab571 100644 --- a/embedded-workshop-book/src/supporting-standard-requests.md +++ b/embedded-workshop-book/src/supporting-standard-requests.md @@ -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.