Apply suggestions from code review

Co-authored-by: Lotte Steenbrink <lotte@zombietetris.de>
This commit is contained in:
Jorge Aparicio 2020-07-14 09:59:32 +00:00 committed by GitHub
parent a61f676b9d
commit a7051bd4e3
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
2 changed files with 4 additions and 4 deletions

View file

@ -2,7 +2,7 @@
## String descriptors
Here's one more USB exercise for you: add string descriptors support to the USB firmware.
If you'd like to continue working on your workshop project, we recommend adding String Descriptors support to the USB firmware.
- First, you'll want to read through section 9.6.7 of the USB spec, which covers string descriptors.
- Next, we suggest you change your *configuration* descriptor to use string descriptors. You'll want to change the `iConfiguration` field to a non-zero value.

View file

@ -2,9 +2,9 @@
## Collision avoidance
Here's one more RADIO exercise for you: test out collision avoidance.
If you've already completed the main workshop tasks or would like to explore more on your own, we suggest you test the collision avoidance of the IEEE 802.15.4 radio used by the Dongle and DK.
If you check the API documentation of the `Radio` abstraction we have been using you'll notice that we haven't used these methods: `energy_detection_scan`, `set_cca` and `try_send`.
If you check the API documentation of the `Radio` abstraction we have been using you'll notice that we haven't used these methods: `energy_detection_scan()`, `set_cca()` and `try_send()`.
The first method scans the currently selected channel (see `set_channel`), measures the energy level of ongoing radio communication in this channel and returns the maximum energy observed over a span of time. This method can be used to determine what the *idle* energy level of a channel is. If there's non-802.15.4 traffic ongoing on this channel the method will return a high value.
@ -27,7 +27,7 @@ Here are some things for you to try out:
## Interrupt handling
We haven't covered interrupt handling in the workshop but the `cortex-m-rt` crate provides attributes to declare exception and interrupt handlers: `#[exception]` and `#[interrupt]`. You can find documentation about these attributes in the ["Concurrency" chapter][concurrency] of the Embedded Rust book.
We haven't covered interrupt handling in the workshop but the `cortex-m-rt` crate provides attributes to declare exception and interrupt handlers: `#[exception]` and `#[interrupt]`. You can find documentation about these attributes and how to safely share data with interrupt handlers using Mutexes in the ["Concurrency" chapter][concurrency] of the Embedded Rust book.
Another way to deal with interrupts is to use a framework like Real-Time Interrupt-driven Concurrency ([RTIC]); this framework has a [book] that explains how you can build reactive applications using interrupts. We use this framework in the advanced level workshop.