at some point cortex-m-rtic fixed a memory safety bug: RTIC was not marking the
cortex_m::Peripherals singleton as "taken" in its pre-init code. This made it possible to create two
instances of the singleton, e.g. by calling `cortex_m::Peripherals::take` in an RTIC app.
the fix included a breaking change: it makes `Peripherals::take` return `None` from within an RTIC
app. This breaks the use of `dk::init`, which `take`s those `Peripherals`, within an RTIC app and
thus breaks most of the exercises / examples in the advanced workshop
this PR fixes the issue by making `dk::init` not `take` the `Peripherals`. For more details read
in-line comments in the diff
Use the target actually mentioned in the .cargo/config file.
Updated the output in the troubleshooting page and
also updated the target for the board/dongle.
- add intermediate-step solutions
- add more hints
- refactor exercise & text to have the same amount of work on all OSes
- add `usb` parser solutions
- make `dk-run` less silent
- rename rtic binaries (shorter names)
- link to the main svd2rust API docs
the rtt-target implementation is light on compiler fences so the compiler could
be doing unwanted reordering of memory operations. At least patch up a place
where these orderings may result in an observable change of behavior
and adjust puzzle-radio starter code accordingly
this reduces the chance of people using puzzle-radio with the wrong dongle
app (i.e. loopback); that would lead to them getting response different than
what's indicated in the text
I have also added the app name to the dongle / serial-term output:
``` text
deviceid=75fa82ad7588b3c7 channel=20 TxPower=+8dBm app=loopback.hex
```
