There are a lot of non-binary crates depending on rp2040-hal. That way,
the default-features of rp2040-hal may be activated unintentionally
through an indirect dependency. Therefore, a binary crate which wants
to disable the `critical-section-impl` feature to provide its own one
could have a hard time to do so.
In contrast, the board support crates are usually only used by top-level
binary crates. So disabling the default features on those should usually
just work.
Binary crates depending on rp2040-hal directly, which don't use any
board support crate, might need to activate the feature manually. This
is reasonable because those binary crates need to replicate some
boilerplate from the board crates anyhow.
* Use rp2040-hal in all example (possibly through their bsp)
Some of the examples were using the cortex_m_rt::entry method which
misses the device specific spinlock re-initialisation.
This commits makes the usage more consistent by using rp2040_hal exported
macro as the only `entry` method used across examples.
Current version of probe-run is 0.3.3, which uses defmt 0.3.2.
With a firmware using defmt 0.2, this causes the following error
message:
```
Error: defmt wire format version mismatch: firmware is using 0.2, `probe-run` supports 3
suggestion: `cargo install` a different version of `probe-run` that supports defmt 0.2
```
Therefore, upgrade defmt dependency, and also fix the linker script
in .cargo/config.
