Fix the watchdog load to reflect the 1us tick rate. This was changed
in #361, which presumably used the field name (delay_ms) and assumed
it was in milliseconds. So this also fixes the name to reflect that
it's microseconds.
* Add rtic-monotonic support for timer & alarms
* Force Alarm interrupt if timer is set too soon
* timer: Remove non_exhaustive attribute from ScheduleAlarmError
* timer: TooSoon is no longer emitted so it can be removed
* pio: Move interrupt related (en|dis)abling/forcing methods to the statemachine
The SM knows its id using the type system so there's no need for checking it.
This commit also adds a `PioIRQ` enum to select the output IRQ.
* Move the interrupt control to Rx & Tx and make all accesses to inte atomic
* Adjust the ergonomics of IRQ handling.
* Elide lifetimes where they can be (clippy's advice)
* Prep for HAL 0.6.0 release
* Update changelog, readme and version number for HAL 0.5.0 release
* Bump HAL version in BSP deps
* Add the missing boards to the main README.md
* Implementation of the interpolator.
* corrected formatting
* fixed documentation code
* add clamp flag to LaneCtrl
* addition of an example for the interpolator
* put documentation behind ///
* rewording comment for clarity
* using more idiomatic fn new
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.
* 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
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()
