Skip to content

Commit 0518589

Browse files
author
Amanda Butler
authored
Merge pull request #438 from c1728p9/usb_spec
Initial draft of the HAL USBPhy API
2 parents c2ea16c + f42e654 commit 0518589

File tree

1 file changed

+34
-7
lines changed
  • docs/reference/contributing/target

1 file changed

+34
-7
lines changed
Lines changed: 34 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -1,25 +1,52 @@
1-
### USB
1+
### USB device
22

3-
[Include a brief description here.]
3+
The HAL USBPhy API provides physical access to the USB bus in the role of a USB device. Implementing this API enables the use of any supported class driver, such as CDC, HID and MSD.
4+
5+
<span class="warnings">**Warning:** We are changing the USB API in an upcoming release of Mbed OS. You can find details on how it may affect you in the [Implementing the USB](#implementing-usb) section.
46

57
#### Assumptions
68

79
##### Defined behavior
810

9-
[Include any defined behavior in bullet format here.]
11+
- You can use any endpoint configurations that fits in the parameters of the table returned by `USBPhy::endpoint_table`.
12+
- You can use all endpoints in any valid endpoint configuration concurrently.
13+
- The device supports use of at least one control, bulk, interrupt and isochronous in each direction at the same time - at least 8 endpoints.
14+
- USBPhy supports all standard endpoint sizes (wMaxPacketSize).
15+
- USBPhy can handle an interrupt latency of at least 100ms if the host PC is not performing a reset or setting the device's address.
16+
- USBPhy only sends USBPhyEvents when it is in the initialized state.
17+
- When unpowered, USBPhy only sends the `USBPhyEvents::power` event.
18+
- On USB reset, all endpoints are removed except for endpoint 0.
19+
- `USBPhyEvents::out` and `USBPhyEvents::in` events only occur for endpoints that you have added.
20+
- A call to `USBPhy::ep0_write` results in the call of `USBPhyEvents::in` when the PC reads the data unless a power loss or reset occurs first.
21+
- A call to `endpoint_read` followed by `endpoint_read_result` results in the call of `USBPhyEvents::out` when the PC sends data unless a power loss or reset occurs first.
22+
- Endpoint 0 naks all transactions aside from setup packets until higher-level code calls one of `USBPhy::ep0_read`, `USBPhy::ep0_write` or `USBPhy::ep0_stall`.
23+
- Endpoint 0 stall automatically clears on reception of a setup packet.
1024

1125
##### Undefined behavior
1226

13-
[Include any undefined behavior in bullet format here.]
27+
- Calling `USBPhy::endpoint_add` or `USBPhy::endpoint_remove` outside of the control requests SetInterface or SetConfiguration.
28+
- Devices behavior is undefined if latency is greater than 2ms when address is being set - see USB spec 9.2.6.3.
29+
- Devices behavior is undefined if latency is greater than 10ms when a reset occurs - see USB spec 7.1.7.5.
30+
- Calling any of the USBPhy::endpoint_* functions on endpoint 0.
1431

1532
##### Notes
1633

17-
[Include any potential trouble areas in bullet format here.]
34+
- Make sure USBPhy sends USBPhyEvents in the correct order when multiple packets are present. USBPhy must send IN endpoint events before OUT endpoint events if both are pending.
35+
- A host PC may resend setup packets to a USB device if there is noise on the USB line. The USBPhy should be able to handle this scenario and respond to the setup packet with an ACK.
36+
- Bidirectional protocols making use of alternating IN and OUT phases should not rely on the last ACK an IN transfer to indicate that the OUT phase should start. Instead, the OUT phase should be started at the same time the last IN transfer is started. This is because the ACK to the last in transfer may be dropped if there is noise on the USB line. If dropped, it will only be resent on the next IN phase. You can find more information on this in section 8.5.3.3 of the USB specification.
1837

1938
#### Implementing USB
2039

21-
[Include implementation information here.]
40+
To add support for the HAL USBPhy API, you need to implement this API and submit pull requests against the `feature-hal-spec-usb-device` branch. Please see the API and specification for the HAL USBPhy API for more information:
41+
42+
[![View code](https://www.mbed.com/embed/?type=library)](http://os-doc-builder.test.mbed.com/docs/development/feature-hal-spec-usb-device-doxy/class_u_s_b_phy.html)
43+
44+
To enable the HAL USBPhy API in Mbed OS, add the `USBDEVICE` label in the `device_has` option of the target's section in the `targets.json` file.
2245

2346
#### Testing
2447

25-
[Include testing information here.]
48+
The Mbed OS HAL provides a set of conformance tests for the HAL USBPhy API. You can use these tests to validate the correctness of your implementation. To run the HAL USBPhy API tests, use the following command:
49+
50+
```
51+
mbed test -t <toolchain> -m <target> -n mbed-os-tests-usb_device-*
52+
```

0 commit comments

Comments
 (0)