640: Skip EasyDMA slice location check for empty slices and copy data if necessary r=Dirbaio a=TilBlechschmidt
As discussed, this PR makes the following changes:
- Ignore pointer location of zero-length slices (fixes#631)
- Change default functions so they copy the tx buffer if it does not reside in RAM
- Introduce new variants for `write`, `transfer`, and their blocking versions which fails instead of copying
- Add documentation about the motivation behind all these variants
<img width="984" alt="image" src="https://user-images.githubusercontent.com/5037967/155415788-c2cd1055-9289-4004-959d-be3b1934a439.png">
Remaining TODOs:
- [x] Change copying behaviour for other peripherals
- [x] TWI
- [x] UART
- [x] Add module-level documentation regarding EasyDMA and `_from_ram` method variants
`@Dirbaio` it probably makes sense for you to review it now before I "copy" over the changes to the other two peripherals.
Co-authored-by: Til Blechschmidt <til@blechschmidt.de>
Starting the sampling task prior to starting the SAADC peripheral can lead to unexpected buffer behaviour with multiple channels. We now provide an init callback at the point where the SAADC has started for the first time. This callback can be used to kick off sampling via PPI.
We also need to trigger the SAADC to start sampling the next buffer when the previous one is ended so that we do not drop samples - the major benefit of double buffering.
As a bonus we provide a calibrate method as it is recommended to use before starting up the sampling.
The example has been updated to illustrate these new features.
613: Rust stable support r=Dirbaio a=Dirbaio
This PR adds (limited) stable Rust support!
The drawbacks are:
- No `#[embassy::task]`, `#[embassy::main]`. (requires `type_alias_impl_trait`). You have to manually allocate the tasks somewhere they'll live forever. See [example](https://github.com/embassy-rs/embassy/blob/master/examples/nrf/src/bin/raw_spawn.rs)
- No async trait impls (requires GATs). Note that the full API surface of HALs is still available through inherent methods: #552#581
- Some stuff is not constructible in const (requires `const_fn_trait_bound`), although there's an (ugly) workaround for the generic `Mutex`.
So it's not that bad in the end, it's fully usable for shipping production-ready firmwares. We'll still recommend nightly as the default, until GATs and `type_alias_impl_trait` are stable.
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
591: PWM WS2812B example and flexible sequence config r=Dirbaio a=huntc
I've permitted the PWM sequences to be mutated on stopping the PWM by associating them with a new `SingleSequencer` structure. This is so that we can perform effects on the LEDs (and other use-cases, I'm sure!). The example has been updated to illustrate the use of this by flashing a WS2812B LED.
There's also a `Sequencer` structure for more sophisticated PWM interactions, along with a `pwm_double_sequence` example to illustrate.
These changes should make it possible to attain all of the nRF PWM functionality available.
Co-authored-by: huntc <huntchr@gmail.com>
This approach owns the sequence buffers which, while introducing an extra move, it eliminates the need to guard the lifetime of the sequence buffer. Given ownership, the buffer will be retained until the PWM sequence task is stopped.
Demonstrates how to set the colour of a WS2812B to blue using PWM, and the use of multiple sequences along with their own config. This required an API change.
I had introduced a small bug in my last PR where I assigned the sequence before stopping the PWM. I now stop the PWM before doing that now.
Also, corrected a math comment.
Sequences are now passed in via the start method to avoid having to stop the PWM and restart it. Sequences continue to be constrained with the same lifetime of the Pwm object itself. The pwm_sequence example has been extended to illustrate multiple sequences being passed around.
This commit allows event_endtx to be used outside of the Uarte itself. As a consequence, PPI can be used to drive tasks given the end of transmission on the Uarte. This is particularly useful for situations like RS485 where a GPIO must be set to high when transmitting then cleared when done. A non-ppi approach can cause a delay in the clearing of this GPIO as other Embassy tasks might become scheduled.
Unsafe is not required here given that all futures are required to live longer than their global peripheral instances. There are other occurrences of unsafe being used on new that should be removed. I started to do that but then went down a bit of a rabbit hole.
539: nrf: async usb r=Dirbaio a=jacobrosenthal
Frankensteined together from this old pr https://github.com/embassy-rs/embassy/pull/115 and nrf-usdb
~Doesnt currently work..~
Co-authored-by: Jacob Rosenthal <jacobrosenthal@gmail.com>
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>
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>
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.
The constructors themselves are not strictly unsafe. Interactions with DMA can be generally unsafe if a future is dropped, but that's a separate issue. It is important that we use the `unsafe` keyword diligently as it can lead to confusion otherwise.
486: Pwm ppi events r=Dirbaio a=jacobrosenthal
More PWM yak shaving. I was going to do some safe pwm ppi events stuff but I just dont think it fits this api design.. ppi is just very low level, im not sure how safe it will be in general
* first we should probably have borrows of handlers for ppi with lifetime of the peripheral? hal does eb4ba6ae42/nrf-hal-common/src/pwm.rs (L714-L716)
* in general having access to tasks can put the state in some configuration the api doesnt understand anymore. for `SequencePwm` ideally id hand you back either only seq_start0 or seq_start1 because youd only use one based on if your `Times` is even or odd.. but again we only know that with this api AFTER start has been called. I dont think were ready for typestates
SO I figured why not add the pwm ppi events but make them unsafe and commit this example since I started it.
Somewhat related drop IS removing the last duty cycle from the pin correctly, but stop DOES NOT..the only thing that sets the pin back is pin.conf() as far as I can tell, so I tried to document that better and got rid of stop for the `SimplePwm` again since that doesnt need it then. However its ackward we dont have a way to unset the pwm without setting a new sequence of 0s, or dropping the peripheral
Co-authored-by: Jacob Rosenthal <jacobrosenthal@gmail.com>
455: simple_playback api from nrf sdk r=Dirbaio a=jacobrosenthal
Port of the nrf_drv_pwm_simple_playback call from the nordic sdk that allows you to set up a sequence to play across leds with no interaction necessary using the 'shorts' registers to trigger looping sequences
Co-authored-by: Jacob Rosenthal <jacobrosenthal@gmail.com>
461: nrf: add initial nrf5340 support r=Dirbaio a=Dirbaio
Thanks to `@diondokter's` work on DPPI this was quite easy! :)
TODO:
- [ ] Add config option to enable 128mhz
- [ ] Add config option to unlock APPROTECT automatically.
- [ ] Add a way to boot net (config option or API?)
- [ ] Support WDT (there's WDT0, WDT1. Needs some refactor)
- [ ] Support NVMC
- [ ] Support TEMP
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
Moving `new_*` to the version-specific mod allows doing the correct
register writes right there in `new`, without needing abstractions
like `enable_all`/`disable_all`.
- Scary pointer math is now contained in the tasks and events
- ppi now sets the tasks and events immediately and the struct is now zero-sized
- StaticToOne is renamed to ZeroToOne
- Used DPPI tasks and events now panic when enabled twice
- Removed ConfigurableChannel and added capacity numbers to the channels
- Replaced the PPI api with a new one using the DPPI terminology (publish & subscribe)
- Updated all tasks and event registers for DPPI
The buffer will always have been filled and we never explicitly stop the task outside of this code. Thus, we can assume the number of bytes in the slice.
Implements continuous sampling for the nRF SAADC and also renames `OneShot` to `Saadc`. The one-shot behaviour is retained with the `sample` method and a new `run_sampler` method is provided for efficiently (i.e. zero copying) sampler processing. A double buffer is used for continuously sampling, which wlll be swapped once sampling has taken place.
A sample frequency is provided and will set the internal timer of the SAADC when there is just the one channel being sampled. Otherwise, PPI will be used to hook up the TIMER peripheral to drive the sampling task.
- It disturbs other stuff that uses WFE/SEV in the system. I ran into
issues with this.
- It needs the irq handler to check for RXTO/TXSTOPPED errors, which makes
it slower.
423: nRF9160 support r=Dirbaio a=diondokter
- Created a chip file with all the peripherals, interrupts and peripheral implementations.
- All peripherals now use an alias for the NS (non-secure) version of the nRF9160 version.
- Implementations of peripherals that don't exist are ignored.
- Most PPI functionality has been stubbed out because the nRF91 has the newer DPPI which is not compatible with the current API. (The channels are also set to not configurable, so they are kinda useless now, but in principle the stubs should never be called)
Co-authored-by: Dion Dokter <dion@tweedegolf.com>
One-shot mode now permits the sampling of differential pins, and the sampling of multiple pins simultaneously.
A new ChannelConfig structure has been introduced so that multiple channels can be configured individually. Further, the `sample` method now accepts a buffer into which samples are written.
Along the way, I've reset some default configuration to align with Nordic's settings in their nrfx saadc driver. Specifically, the channel gain defaults to 6 (from 4) and the time defaults to 10us (from 20us).
* Adds an executor for WASM runtimes based on wasm_bindgen.
* Add time driver based on JS time handling.
* Add example that can run in browser locally.
* Update to critical-section version that supports 'std' flag
Since `PeripheralMutex` is the only way to safely maintain state across interrupts, and it no longer allows setting the interrupt's priority, the priority changing isn't a concern.
This also prevents other causes of UB due to the interrupt being exposed during `with`, and allowing enabling the interrupt and setting its context to a bogus pointer.
`Peripheral` assumed that interrupts can't be preempted,
when they can be preempted by higher priority interrupts.
So I put the interrupt handler inside a critical section,
and also added checks for whether the state had been dropped
before the critical section was entered.
I also added a `'static` bound to `PeripheralState`,
since `Pin` only guarantees that the memory it directly references
will not be invalidated.
It doesn't guarantee that memory its pointee references also won't be invalidated.
There were already some implementations of `PeripheralState`
that weren't `'static`, though,
so I added an unsafe `PeripheralStateUnchecked` trait
and forwarded the `unsafe` to the constructors of the implementors.
Add type UarteWithIdle that implements Read, Write and ReadUntilIdle
traits. The type uses a timer + 2 PPI channels internally, triggered on
RTXSTARTED event.
Since introducing the ctx pointer, the handler is now two words, so setting it can
race with the interrupt firing. On race it's possible for the new handler to be
alled with the old ctx pointer or viceversa.
Rather than documenting this, it's better to split the function in two to make it
obvious to the user that it's not atomic. The user can use a critical section, or
disable/enable the interrupt to avoid races if this is a concern.
The `interrupt` package previously tried to be drop-in compatible with the
`interrupt` package from PACs. THis meant that there was both a PAC-style enum
value `UARTE0` and an embassy-style owned `UARTE0Interrupt` type. This made
things VERY confusing.
This drops compatibility with the PAC, improving the names for embassy interrupts.
- It's no longer possible to call run() reentrantly from within a task (soundness issue)
- it's now possible to spawn Send tasks across threads (SendSpawner, #37)
Prevents a panic in the case of:
1. Abort a receive future
2. Free Uarte::free()
3. Uarte::new()
-> panicked at 'assertion failed: uarte.enable.read().enable().is_disabled()'
The PS does not specify how many cycles it takes for a STARTXX task to
generate a XXSTARTED event. I think it is instantaneous but let’s be on
the safe side for the following sequence:
1. poll() starttx
2. drop() txstarted not yet set, but future gets dropped
3. txstarted set by hardware, peripheral enabled after it was dropped
The STOPRX task always triggers a timeout of ~55bit times until the
RXTO event is generated. Before we disabled the receiver only after
the timeout.
With this change the receiver is stopped right after reception has ended
because the DMA buffer is full.
For forced RX aborts like `stop()` or on drop still need to wait for the
RXTO event before disabling the receiver.
