documentation fix; image from miro board

This commit is contained in:
Amanjeev Sethi 2023-06-22 14:51:16 -04:00
parent 209dfbf6ee
commit 2c3ee9e01a
3 changed files with 21 additions and 6 deletions

View file

@ -6,4 +6,11 @@ Below the `idle` function you'll see a `#[task]` handler, a function. This *task
Note that all tasks will be prioritized over the `idle` function so the execution of `idle` will be interrupted (paused) by the `on_power_event` task. When the `on_power_event` task finishes (returns) the execution of the `idle` will be resumed. This will become more obvious in the next section.
Try this: add an infinite loop to the end of `init` so that it never returns. Now run the program and connect the USB cable. What behavior do you observe? How would you explain this behavior? (hint: look at the `rtic-expansion.rs` file: under what conditions is the `init` function executed?)
Try this: add an infinite loop to the end of `init` so that it never returns. Now run the program and connect the USB cable. What behavior do you observe? How would you explain this behavior? (hint: look at the `rtic-expansion.rs` file: under what conditions is the `init` function executed?)
<details>
<summary>Click me to see hint</summary>
You may observe that nothing happens when you plug in the USB cable to J3. The `init` function is called once inside the `main` but `init` in this case has an infinite loop.
</details>

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.3 MiB

View file

@ -1,16 +1,24 @@
# USB Enumeration
Check this miro board for an [overview](https://miro.com/app/board/uXjVObcQhcc=/?invite_link_id=467100096053).
![Labeled Diagram of the nRF52840 and Host interaction](img/host-and-device.jpg)
A USB device, like the nRF52840, can be one of these three states: the Default state, the Address state or the Configured state. After being powered the device will start in the Default state. The enumeration process will take the device from the Default state to the Address state. As a result of the enumeration process the device will be assigned an address, in the range `1..=127`, by the host.
[Screenshot taken from miro board](https://miro.com/app/board/uXjVObcQhcc=/?invite_link_id=467100096053)
A USB device, like the nRF52840, can be one of these three states:
- the Default state,
- the Address state, or
- the Configured state
After being powered the device will start in the Default state. The enumeration process will take the device from the Default state to the Address state. As a result of the enumeration process the device will be assigned an address, in the range `1..=127`, by the host.
The USB protocol is complex so we'll leave out many details and focus only on the concepts required to get enumeration and configuration working. There are also several USB specific terms so we recommend checking chapter 2, "Terms and Abbreviations", of the USB specification (linked at the bottom of this document) every now and then.
Each OS may perform the enumeration process slightly differently but the process will always involve these host actions:
- USB reset. This will put the device in the Default state, regardless of what state it was in.
- GET_DESCRIPTOR request to get the device descriptor.
- SET_ADDRESS request to assign an address to the device.
- USB reset: put the device in the Default state, regardless of what state it was in.
- GET_DESCRIPTOR: request to get the device descriptor.
- SET_ADDRESS: request to assign an address to the device.
These host actions will be perceived as *events* by the nRF52840. During this workshop, we will gradually parse and handle these events and learn more about Embedded Rust along the way.