871: nrf/saadc: add type-erased AnyInput. r=Dirbaio a=Dirbaio
872: nrf/usb: prevent user code from constructing a PowerUsb directly. r=Dirbaio a=Dirbaio
PowerUsb must be constructed through `new()` so that it sets up the IRQ.
It must have at least one private field, otherwise user code can construct
it directly with `PowerUsb{}`.
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
PowerUsb must be constructed through `new()` so that it sets up the IRQ.
It must have at least one private field, otherwise user code can construct
it directly with `PowerUsb{}`.
810: Takes care of power for nRF USB devices r=Dirbaio a=huntc
Modifies the usb-serial example to illustrate how to setup USB for situations where the USB power can be detected and removed.
Gaps:
~~* No support for the nrf-softdevices as yet, although this should be possible via another constructor.~~
* No support for the nrf5340, although this should be possible via USBREG.
The change is tested and appears to work. Some notes:
* There's an existing field named self_powered as a UsbDevice field. It doesn't ever appear to get set. I'm wondering if this field is intended to signal that a device has the nRF VBUS power situation or not. I'm not presently using it.
* The new PowerDetected event is generated on the bus initially in situations where just new is used i.e. without power management, including on STM. We can therefore rely on this event always being generated.
Old description:
~~EnabledUsbDevice is a wrapper around the `UsbDevice` where its enablement is also subject to external events, such as `POWER` events for nRF. It is introduced generically to support other platforms should they also require external signaling for enablement.~~
Co-authored-by: huntc <huntchr@gmail.com>
Eliminated a signal by using a simpler trait method that returns whether VBus power is available. Also includes a UsbSupply that can be signalled for use with the nRF softdevice. Includes the requirement for waiting for power to become available.
Allow creating UarteRx/UarteTx directly. This allows using uart unidirectionally
(rx-only or tx-only), without having to 'waste' a pin for the unused direction.
It currently contains whoever was first to write some code for the crate,
even if many more people have contributed to it later.
The field is "sort of" deprecated, it was made optional recently:
https://rust-lang.github.io/rfcs/3052-optional-authors-field.html
Due the the reasons listed there I believe removing it is better than
setting it to generic fluff like "The Embassy contributors".
- Move Interrupt and InterruptExecutor from `embassy` to `embassy-cortex-m`.
- Move Unborrow from `embassy` to `embassy-hal-common` (nothing in `embassy` requires it anymore)
- Move PeripheralMutex from `embassy-hal-common` to `embassy-cortex-m`.
Following the project's decision that "leak unsafe" APIs are not marked as "unsafe",
update PeripheralMutex to accept non-'static state without unsafe.
Fixes#801
788: Misc USB improvements, for stm32 r=Dirbaio a=Dirbaio
See individual commit messages.
These changes help implementing the driver for STM32 USBD (#709)
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
768: nrf/usb: fix control out transfers getting corrupted due to ep0rcvout sticking from earlier. r=Dirbaio a=Dirbaio
bors r+
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
The stack reads its own descriptors to figure out which endpoints
are used in which alt settings, and enables/disables them as needed.
The ControlHandler has a callback so it can get notified of alternate
setting changes, which is purely informative (it doesn't have to do anything).
* Adds implementations of embedded-storage and embedded-storage-async
for QSPI
* Add blocking implementations of QSPI
* Use blocking implementation in new() and embedded-storage impls
* Use async implementation in embedded-storage-async impls
* Add FLASH_SIZE const generic parameter
* Own IRQ in Qspi to disable it on drop
657: Async usb stack r=Dirbaio a=Dirbaio
TODO
- [x] Make it work on nRF
- [x] Add a way for classes to handle their own EP0 control requests - thanks `@alexmoon!`
- [x] Handle CONTROL OUT requests with data.
- [ ] Impl AsyncRead/AsyncWrite for CDC ACM -- will do later, it's not trivial
- [x] Cleanup unwraps/asserts/panics
- [x] Cleanup logs (make everything trace/debug, not info)
- [ ] Port synopsys-usb-otg
- [ ] Port stm32-usbd
- [ ] Add more classes? HID, MSD?
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
Co-authored-by: alexmoon <alex.r.moon@gmail.com>
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>
