* 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.
This is a little bit hacky, as it relies on rp2040-hal actually
using (and therefore linking) some defmt code when the defmt feature is
enabled.
However this solution has the advantage that it only affects
dev-dependencies and therefore has no impact on the board crates
themselves.
Closes#420
* Implement rp2040-E5 workaround for usb enumeration.
* Expand documentation and add to pico_usb_serial & pico_usb_twitchy_mouse
* Fix errata-5 documentation around the bus-keep state.
* Update CHANGELOG.md
The workflow only shows "Runs action-rs/cargo@v1" which does not tell us
much about what's actually being done.
The list and clean up done after each build varies by only the debug/release
part of the path that is repeated several times (2).
This commit gives each step a more meaningful name and simplify the list &
cleanup step with a generic one liner that can be copy/pasted without
modification.
Without this change, building the vector_table example fails when
building from the rp2040-hal directory:
```
rp2040-hal$ cargo build --release --example vector_table
Compiling rp2040-hal v0.5.0 (rp2040-hal)
error[E0432]: unresolved import `pac::interrupt`
--> rp2040-hal/examples/vector_table.rs:30:5
|
30 | use pac::interrupt;
| ^^^^^---------
| | |
| | help: a similar name exists in the module (notice the capitalization): `Interrupt`
| no `interrupt` in the root
error: cannot determine resolution for the attribute macro `interrupt`
--> rp2040-hal/examples/vector_table.rs:148:3
|
148 | #[interrupt]
| ^^^^^^^^^
|
= note: import resolution is stuck, try simplifying macro imports
```
* Add struct VectorTable to represent an interrupt vector table
* Add member function to VectorTable to initialise based on the current Interrupt Vector Table from VTOR
* Add member function to VectorTable to register an extern "C" function to call on interrupt
* Add example using VectorTable to demonstrate initialisation and interrupt function registration
usb_device ignores PollResult::Suspend when already suspended,
and PollResult::Resume when not suspended.
This may lead to repeatedly triggered interrupts if for some reason
the Suspend flag gets set while the device is already suspended.
I observed such a situation when a reset was triggered while the device
was suspended.
To make sure that this can't cause interrupt storms, clear the flags
before returning from poll()
- Clippy warns about empty loops, https://github.com/rust-lang/rust-clippy/issues/6161
- wfi allows to CPU to save some power
WFI was avoided in examples for fear of ill interactions with debuggers.
However the rp2040 debug port does continue to work, as long as the
relevant clocks are not disabled in SLEEP_EN0/SLEEP_EN1. (By default,
all clocks stay enabled in sleep mode.)
This patch replaces several different workarounds with just calling wfi.
Uses build.rs in board directories to set the linker options locally.
The file .cargo/config can't be used for that, as in a workspace the
local .cargo/config is ignored if the build is triggered from the
workspace root.
The ep0-out buffer must not be marked as available unless required.
Otherwise, the controller will acknowledge the data-out packet but
won't reflect that in its status registers.
This patch forces the controller to nack the data-out phase until we have
processed the setup packet.
As per 4.1.2.5.1, the access to the DPSRAM should "be considered asynchronous
and not atomic".
It is recommended to write to buffer control register in two steps.
A first one to configure all bits but Available.
Wait clk_sys/clk_usb (typically 125MHz/48MHz).
Then set the available bit (if required).
The only thing accessed by those methods is `&mut self`, which is
guaranteed to be a unique reference. So an interrupt can not
interfere with the correctness of the operation.
