Merge pull request #22 from ferrous-systems/fixes

Minor readme fixes
This commit is contained in:
Jorge Aparicio 2020-07-10 16:07:37 +00:00 committed by GitHub
commit 67f9fb1611
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
2 changed files with 3 additions and 14 deletions

View file

@ -161,7 +161,7 @@ Open the `src/bin/resource.rs` file. The starter code shows the syntax to declar
In the starter code a resource is used to *move* (by value) the POWER peripheral from `init` to the `on_power_event` task. The POWER peripheral then becomes part of the state of the `on_power_event` task and can be persistently accessed throughout calls to `on_power_event()` through a *reference*. The resources of a task are available via the `Context` argument of the task.
To elaborate more on this *move* action: in the `svd2rust` API, peripheral types like `POWER` are *singletons* (only a single instance of the type can ever exist). The consequence of this design is that holding a peripheral instance, like `POWER`, *by value* means that the function (or task) has exclusive access, or ownership, over the peripheral. This is the case of the `init` function: it owns the `POWER` peripheral but then transfer ownership over it to a task using the resource initialization mechanism.
To elaborate more on this *move* action: in the `svd2rust` API, peripheral types like `POWER` are *singletons* (only a single instance of the type can ever exist). The consequence of this design is that holding a peripheral instance, like `POWER`, *by value* means that the function (or task) has exclusive access, or ownership, over the peripheral. This is the case of the `init` function: it owns the `POWER` peripheral but then transfers ownership over it to a task using the resource initialization mechanism.
We have moved the POWER peripheral into the task because we want to clear the USBDETECTED interrupt flag after it has been set by the hardware. If we miss this step the `on_power_event` task (function) will be called again once it returns and then again and again and again (ad infinitum).
@ -265,18 +265,7 @@ When you need to write some `no_std` code that does not involve device-specific
So that's what we'll do here. In `advanced/common/usb/lib.rs` you'll find starter code for writing a `no_std` SETUP data parser. The starter code contains some unit tests; you can run them with `cargo test` (from within the `usb` folder) or you can use Rust Analyzer's "Test" button in VS code.
If you run these tests, you'll notice this error:
```rust
error[E0599]: no variant named `Configuration` found for enum `Descriptor`
--> src/lib.rs:73:45
|
73 | descriptor: Descriptor::Configuration {index: desc_index },
| ^^^^^^^^^^^^^ variant not found in `Descriptor`
...
100 | pub enum Descriptor {
| ------------------- variant `Configuration` not found here
```
That's because the definition of `Descriptor::Configuration` has been "commented out" using an `#[cfg(TODO)]` attribute because it is not handled by the firmware yet. Delete the `#[cfg(TODO)]` so that the unit tests can access it. This pattern is used for enum members and test functions throughout this workshop, so keep it in mind should you see the error message again.
The definition of `Descriptor::Configuration` as well as the associated test has been "commented out" using an `#[cfg(TODO)]` attribute because it is not handled by the firmware yet. Delete the `#[cfg(TODO)]` so that the unit tests can access it. This pattern is used for enum members and test functions throughout this workshop, so keep it in mind should you see it again.
Now, proceed as follows:

View file

@ -36,7 +36,7 @@ const APP: () = {
// to show that its contents reflect our usb connection status
// (the USBDETECTED event that will trigger `on_power_event()` is derived from this information)
let vbusdetect: bool = power.usbregstatus.read().vbusdetect().bits();
// ^^^^^^^^^ bitfield name
// ^^^^^^^^^^ bitfield name
log::info!("USBREGSTATUS.VBUSDETECT: {}", vbusdetect);
}