* 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
The servo example included phase correction, which does not work with the
provided divider. Updated comments to explain numbers and also explain
alternate calculation with phase correction enabled.
Remove unusable aliases from all servo pins. The board includes a 180 Ohm
resistor on all servo data pins, which makes the lines not very usable for
Spi, Uart or I2C. The aliases were removed given they will rarely, if ever,
be used with this board.
* Add the Pimoroni Servo 2040 board
This PR adds the board support package and two simple examples.
* Animates a rainbow wheel across the RGB LEDs on the board.
* Moves a servo that's connected to GPIO0 back and forth.
* Format pimoroni-servo2040 board files
* Use us_to_duty function in servo example, clean up comments.
* Fix bad types
* Add Servo2040 description to top-level readme
* 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.
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
- 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.
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.
Implementing `impl From<SystemClock> for Hertz` is a footgun, as
SystemClock is not Copy, so the automatic conversion consumes the
owned clock.
This is visible in the example i2c.rs:
```
let mut i2c = hal::I2C::i2c1(
pac.I2C1,
sda_pin,
scl_pin, // Try `not_an_scl_pin` here
400.kHz(),
&mut pac.RESETS,
clocks.peripheral_clock,
);
```
If the user wants to use both `i2c0` and `i2c1` at the same time,
copying from this example won't work:
```
error[E0382]: use of moved value: `clocks.peripheral_clock`
--> rp2040-hal/examples/i2c.rs:106:9
|
97 | clocks.peripheral_clock,
| ----------------------- value moved here
...
106 | clocks.peripheral_clock,
| ^^^^^^^^^^^^^^^^^^^^^^^ value used here after move
|
= note: move occurs because `clocks.peripheral_clock` has type
`PeripheralClock`, which does not implement the `Copy` trait
```
As getting the frequency from a clock doesn't really need ownership,
changing it to `impl From<&SystemClock> for Hertz` is both more
logical and provides better usability.
This is, however, a breaking change: Code relying on this trait
implementation needs to be changed by adding a `&`.
