544: Introduces split on the nRF Uarte r=Dirbaio a=huntc
A new `split` method is introduced such that the Uarte tx and rx can be used from separate tasks. An MPSC is used in an example to illustrate how data may be passed between these tasks.
The approach taken within the `Uarte` struct is to split into tx and rx fields on calling `Uarte::new`. These fields are returned given a call to `Uarte::split`, but otherwise, if that call isn't made, then the API remains as it was before.
Here's a snippet from a new example introduced:
```rust
#[embassy::main]
async fn main(spawner: Spawner, p: Peripherals) {
// ...
let uart = uarte::Uarte::new(p.UARTE0, irq, p.P0_08, p.P0_06, NoPin, NoPin, config);
let (mut tx, rx) = uart.split();
// ...
// Spawn a task responsible purely for reading
unwrap!(spawner.spawn(reader(rx, s)));
// ...
// Continue reading in this main task and write
// back out the buffer we receive from the read
// task.
loop {
if let Some(buf) = r.recv().await {
info!("writing...");
unwrap!(tx.write(&buf).await);
}
}
}
#[embassy::task]
async fn reader(mut rx: UarteRx<'static, UARTE0>, s: Sender<'static, Noop, [u8; 8], 1>) {
let mut buf = [0; 8];
loop {
info!("reading...");
unwrap!(rx.read(&mut buf).await);
unwrap!(s.send(buf).await);
}
}
```
Co-authored-by: huntc <huntchr@gmail.com>
543: Incrementally merge STM32 SPI versions, Part 3 r=Dirbaio a=GrantM11235
Notable changes:
- `SPE` is now disabled before `TXDMAEN` and `RXDMAEN` are disabled. This is the "mandatory" sequence for v2 and v3 (and maybe v1 as well, but I can't find it in the reference manual).
- v1's `write_dma_u8` now waits for idle and disables `TXDMAEN` after the transfer is complete, just like everything else.
Co-authored-by: Grant Miller <GrantM11235@gmail.com>
A new `split` method is introduced such that the Uarte tx and rx can be used from separate tasks. An MPSC is used to illustrate how data may be passed between these tasks.
542: nrf/gpiote: remove PortInput, move impls to Input/FlexPin. r=Dirbaio a=Dirbaio
`PortInput` is just a dumb wrapper around `Input`, it has no reason whatsoever to exist. This PR moves the `wait_for_x` functionality to `Input` directly.
It also adds it to `FlexPin` for completeness and consistency with `Input`.
(The reason `PortInput` exists is a while ago `GPIOTE` was an owned singleton that you had to initialize, so `PortInput::new()` would require it to enforce it's been initialized. This doesn't apply anymore now that GPIOTE is "global")
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
533: Book poc r=Dirbaio a=lulf
This is a Proof of Concept for an embassy book. It's using Antora/Asciidoc.
* Asciidoc because it's a single specification with a slightly richer feature set than markdown.
* Antora because it allows keeping content in the embassy repo, while book definition in another repo (embassy-book).
Using antora also allows for easy embedding of embassy doc in other projects, which I think in turn increases probability of upstream contributions.
The sources of content are located in docs/ but could also be in a separate repo. However, keeping it in the embassy repo makes it easier to support one version of the book per embassy version in the future.
At present, the book is automatically built every hour from this branch and published at: https://embassy-rs.github.io/embassy-book/embassy/dev/index.html
Co-authored-by: Ulf Lilleengen <lulf@redhat.com>
Co-authored-by: Ulf Lilleengen <ulf.lilleengen@gmail.com>
534: Provides AsyncWrite with flush r=huntc a=huntc
As per Tokio and others, this commit provides a `poll_flush` method on `AsyncWrite` so that a best-effort attempt at wakening once all bytes are flushed can be made.
Co-authored-by: huntc <huntchr@gmail.com>
As per Tokio and others, this commit provides a `poll_flush` method on `AsyncWrite` so that a best-effort attempt at wakening once all bytes are flushed can be made.
531: Rust Analyzer documentation r=Dirbaio a=huntc
Intends to clarify how to make Embassy usable from within Visual Studio Code by assuming the presence of the Rust Analyzer.
Note that IntelliJ does not support the Rust Analyzer, so an open question remains as to the whether this is a good move. If it turns out not to be a good move then we should still look at clarifying the use of a workspace file.
Co-authored-by: huntc <huntchr@gmail.com>
