Copy edit USB.md

Change passive to active voice with engineering help.

Author: Amanda Butler

docs/reference/technology/USB.md

@@ -16,9 +16,9 @@ You can see the interaction of these three components in this diagram:
 
 #### Synchronization
 
-The class USBDevice is an interrupt-safe class. It uses a critical section to provide thread and interrupt-safe locking. This lock can be used from USB components inheriting from USBDevice but is not required.
+The class USBDevice is an interrupt-safe class. It uses a critical section to provide thread- and interrupt-safe locking. USB components inheriting from USBDevice can use this lock, but it is not required.
 
-The recommended model for synchronizing a USB component is to wrap code requiring synchronization in a call to `USBDevice::lock` and `USBDevice::unlock`. Functions or callbacks that are synchronized by a caller at a higher level should document this by locking requirement by calling `USBDevice::assert_locked` in the first line of the function or callback.
+The recommended model for synchronizing a USB component is to wrap code requiring synchronization in a call to `USBDevice::lock` and `USBDevice::unlock`. Functions or callbacks that a caller at a higher level has already synchronized should document this locking requirement by calling `USBDevice::assert_locked` in the first line of the function or callback.
 
 Code requiring locking:
 
@@ -33,7 +33,7 @@ void USBComponent::do_something()
 }
 ```
 
-Code where the lock is held externally:
+Code that expects a caller at a higher level to hold the lock:
 
 ```c
 void USBComponent::do_something_internal()
@@ -46,25 +46,25 @@ void USBComponent::do_something_internal()
 
 #### USB device state
 
-USB defines 5 separate states a device can be in - Attached, Powered, Default, Address and Configured. Each state adds functionality, with the Attached state having the least functionality and the Configured state having the most functionality.
+USB defines 5 separate states a device can be in - Attached, Powered, Default, Address and Configured. Each state adds functionality. The Attached state has the least functionality, and the Configured state has the most functionality.
 
 | State      | Functionality                            |
 |:----------:|:----------------------------------------:|
 | Attached   |    Power events                          |
 | Powered    |    Reset events                          |
 | Default    |    Control endpoint 0 active             |
-| Address    |                                          |
+| Address    |    No new functionality                  |
 | Configured |    All enabled endpoints are functional  |
 
-At any time the USB device can enter a state with less functionality. This could be due to a loss of power event or a surprise USB disconnect. When leaving or outside of the Configured state writes to and reads from all endpoints other than endpoint 0 are ignored.
+At any time, the USB device can enter a state with less functionality. This could be due to a loss of power event or a surprise USB disconnect. When leaving or outside of the Configured state, USBDevice ignores writes to and reads from all endpoints other than endpoint 0.
 
 #### USB component callbacks
 
-All callbacks sent by USBDevice to its children are prefixed with callback_*. These callbacks are called with the USB lock is held. One notable callback is `callback_state_change` which can be used generically handle leaving the Configured state. The Configured state is automatically exited by the USB stack on disconnect, power loss or USB reset.
+All callbacks USBDevice sends to its children are prefixed with callback_*. USBDevice calls these callbacks with the USB lock held. One notable callback is `callback_state_change`, which USB components can use generically to handle leaving the Configured state. The USB stack automatically exits the Configured state on disconnect, power loss or USB reset.
 
 ##### Control request state machine
 
-There are four callbacks that the USB control state machine sends. When these callbacks are called, they must return a result to continue the control state machine. The result does not need to be returned immediately, giving the USB component time to process the request. **Note that the response must always be sent regardless of any USB device state changes.**
+There are four callbacks that the USB control state machine sends. When USBDevice calls these callbacks, the USB component must return a result to continue the control state machine. The USB component does not need to return the result immediately, which gives it time to process the request. **Note that the USB component must always send the response, regardless of any USB device state changes.**
 
 Table of control callbacks and the required response:
 
@@ -77,23 +77,23 @@ Table of control callbacks and the required response:
 
 ![USB control state diagram](usb/usb_control_state_diagram_user.png)
 
-The USB stack guarantees the setup packet passed to `callback_request` and `callback_request_xfer_done` remains valid and unchanged up to the point the request is completed with `complete_request` and `complete_request_xfer_done`. Additionally, when `complete_request` is called with the value `Receive` or `Send`, the USB stack guarantees that `callback_request_xfer_done` will be called. If `complete_request` is called with a buffer and size, that buffer must remain valid and unchanged until USBDevice calls the function `callback_request_xfer_done`.
+The USB stack guarantees the setup packet passed to `callback_request` and `callback_request_xfer_done` remains valid and unchanged up to the point the USB component completes the request with `complete_request` and `complete_request_xfer_done`. Additionally, when the USB component calls `complete_request` with the value `Receive` or `Send`, the USB stack guarantees that `callback_request_xfer_done` is called. If the USB component calls `complete_request` with a buffer and size, that buffer must remain valid and unchanged until USBDevice calls the function `callback_request_xfer_done`.
 
 #### IN and OUT state machine for endpoints
 
-A USB component adds and removes endpoints as part of `callback_set_configuration` and `callback_set_interface` to set up the corresponding interface or configuration. Additionally, all added endpoints are automatically removed if the device leaves the Configured state.
+A USB component adds and removes endpoints as part of `callback_set_configuration` and `callback_set_interface` to set up the corresponding interface or configuration. Additionally, USBDevice automatically removes all added endpoints if the device leaves the Configured state.
 
-When an endpoint has been added, you can either write to it with `write` or read from it by calling `read_start` and `read_finish`. These functions copy data passed to them, so buffers can be freed or used for other purposes as soon as the call completes. Note that the buffer size must not exceed the maximum packet size for the given endpoint.
+When a USB component adds an endpoint, you can either write to it with `write` or read from it by calling `read_start` and `read_finish`. These functions copy data passed to them, so a USB component can free the buffers or use them for other purposes as soon as the call completes. Note that the buffer size must not exceed the maximum packet size for the given endpoint.
 
 Below is a diagram showing the typical state machine for read (OUT) and write (IN) transfers.
 
 ![USB endpoint state diagram](usb/usb_endpoint_state_diagram_user.png)
 
 #### Endpoint configuration
 
-To ensure a USB component runs on all supported devices, the endpoints that the configuration descriptor uses must be selected based on the current device. This is because endpoint number and endpoint functionality can differ by device. The features of a device can be determined by examining its endpoint table.
+To ensure a USB component runs on all supported devices, the USB component must select the configuration descriptor's endpoints based on the current device. This is because endpoint number and endpoint functionality can differ by device. A USB component can determine the features of USBPhy by examining its endpoint table.
 
-To simplify the process of selecting endpoints, we recommend you use the EndpointResolver class. It is constructed with an endpoint table and can be called to find an endpoint of the given type and size. After all required endpoints have been found, the function `EndpointResolver::valid()` can be called to check if this device supports this configuration. Below is an example of this:
+To simplify the process of selecting endpoints, we recommend you use the EndpointResolver class. A USB component constructs the class with an endpoint table. The USB component can then call the class to find an endpoint of the given type and size. After the component finds all required endpoints, it can call the function `EndpointResolver::valid()` to determine whether this device supports this configuration. Below is an example of this:
 
 ```c++
 EndpointResolver resolver(endpoint_table());