this reports errors at the same location the blocking uart would, which
works out to being mostly exact (except in the case of overruns, where
one extra character is dropped). this is actually easier than going
nuclear in the case of errors and nuking both the buffer contents and
the rx fifo, both of which are things we'd have to do in addition to
what's added here, and neither are needed for correctness.
sending break conditions is necessary to implement some protocols, and
the hardware supports this natively. we do have to make sure that we
don't assert a break condition while the uart is busy though, otherwise
the break may be inserted before the last character in the tx fifo.
the rp uart receive fifo is 32 entries deep, so the 31 byte test data
fits into it without needing any buffering. extend to 48 bytes to fill
the entire fifo and the 16 byte test buffer.
1405: add IPCC peripheral for stm32wb r=xoviat a=OueslatiGhaith
Hello again,
This pull request is related to #1397 and #1401, inspired by #24, and was tested on an stm32wb55rg.
This pull request aims to add the IPCC peripheral for stm32wb microcontrollers.
I am debating whether this should be included in the public API, since the IPCC peripheral would be typically managed by the TL Mailbox, not by the app directly.
Co-authored-by: OueslatiGhaith <ghaith.oueslati@enis.tn>
1412: stm32/uart: abort on error r=Dirbaio a=xoviat
This PR aborts the DMA transfer in the event of a UART error. Otherwise, the transfer will never complete, and an error will not be returned.
Co-authored-by: xoviat <xoviat@users.noreply.github.com>
1403: Bump versions preparing for -macros and -executor release r=lulf a=lulf
I'd like to propose a new release of embassy-macros and embassy-executor, as there is a challenge with some of the features changing since 0.1.1 when using libraries that depend on 0.1.1 with applications that patch to use git versions.
Co-authored-by: Ulf Lilleengen <lulf@redhat.com>
1406: rp: DMA behaviour during flash operations r=Dirbaio a=kalkyl
This PR changes the old behaviour during flash operations where all DMA transfers were paused during the flash operation.
The new approach is to wait for any DMA operating in flash region to finish and let RAM transfers continue.
Co-authored-by: kalkyl <henrik.alser@me.com>
1402: rp: remove pio Cargo feature. r=Dirbaio a=Dirbaio
We shouldn't have Cargo features if their only purpose is reduce cold build time a bit.
bors r+
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
1396: Add an external LoRa physical layer feature r=Dirbaio a=ceekdee
The original LoRa drivers have been deprecated and examples associated with them deleted; however, the original LoRa drivers are still available to allow a gentle transition to the external lora-phy crate.
Co-authored-by: ceekdee <taigatensor@gmail.com>
Co-authored-by: Chuck Davis <taigatensor@gmail.com>
Co-authored-by: Ulf Lilleengen <lulf@redhat.com>
- probe-run screwed up the last release 2 weeks ago and it's still not fixed (issue 391). Doesn't look well maintained.
- Even when it's not broken, it lags behind probe-rs-cli in new chips support because it's slow in updating probe-rs.
1392: embassy-rp : Fix for division intrinsics clashing with rp2040-hal r=Dirbaio a=peterkrull
Commit [7a682ec](7a682ec02a (diff-f121955242a67342004444b26214e5d1d591c3182dcd0fedf4329ad472cd1200)) may break compilation if also using `rp2040-hal`. It seems that the rp2040-hal does have a feature flag for [disabling intrinsics](2c9921cdc5/rp2040-hal/src/sio.rs (L323)), but I still cannot seem to compile with that enabled. Adding these flags fixes it for me.
Co-authored-by: Peter Krull <peterkrullpeter@gmail.com>
