1069: GPIOTE InputChannel with mutable reference. r=Dirbaio a=Ardelean-Calin
Adding these changes enables us to define a channel using a mutable reference to `GPIOTE_CH(n)`, similar to how we can do with other drivers. So instead of using:
```rust
let p = embassy_nrf::init(config);
let freq_in = InputChannel::new(
p.GPIOTE_CH0,
Input::new(&mut p.P0_19, embassy_nrf::gpio::Pull::Up),
embassy_nrf::gpiote::InputChannelPolarity::HiToLo,
);
```
we can use:
```rust
let p = embassy_nrf::init(config);
let freq_in = InputChannel::new(
&mut p.GPIOTE_CH0,
Input::new(&mut p.P0_19, embassy_nrf::gpio::Pull::Up),
embassy_nrf::gpiote::InputChannelPolarity::HiToLo,
);
```
therefore not giving ownership to GPIOTE_CH0.
Co-authored-by: Ardelean Călin Petru <ardelean.calin@outlook.com>
Co-authored-by: Ardelean Calin <ardelean.calin@proton.me>
1056: embassy-nrf: Add TWIS module r=Dirbaio a=kalkyl
Verified to be working on nrf9160
Co-authored-by: kalkyl <henrik.alser@me.com>
Co-authored-by: Henrik Alsér <henrik.alser@me.com>
Adding these changes enables us to define a channel using a mutable reference to `GPIOTE_CH(n)`, similar to how we can do with other drivers.
So instead of using:
```rust
let freq_in = InputChannel::new(
p.GPIOTE_CH0,
Input::new(&mut p.P0_19, embassy_nrf::gpio::Pull::Up),
embassy_nrf::gpiote::InputChannelPolarity::HiToLo,
);
```
we can use:
```rust
let freq_in = InputChannel::new(
&mut p.GPIOTE_CH0,
Input::new(&mut p.P0_19, embassy_nrf::gpio::Pull::Up),
embassy_nrf::gpiote::InputChannelPolarity::HiToLo,
);
```
1042: embassy-nrf: Add SPIS module r=Dirbaio a=kalkyl
Verified to be working on nrf9160
Co-authored-by: Henrik Alsér <henrik.alser@me.com>
Co-authored-by: Henrik Alsér <henrik.alser@ucsmindbite.se>
Co-authored-by: kalkyl <henrik.alser@me.com>
959: Generic, executor-agnostic queue implementation r=ivmarkov a=ivmarkov
Hopefully relatively well documented.
Implementation relies on a fixed-size `SortedLinkedList` from `heapless`. (By default, for up to 128 timer schedules, but we can lower this number to - say - 64.)
As discussed earlier, on queue overflow, the `WakerRegistration` approach is utilized, whereas the waker that is ordered first in the queue is awoken to make room for the incoming one (which might be the waker that would be awoken after all!). Wakers are compared with `Waker::will_wake`, so the queue should actually not fill up that easily, if at all.
I've left provisions for the user to manually instantiate the queue using a dedicated macro - `generic_queue!` so that users willing to adjust the queue size, or users (like me) who have to use the queue in a complex "on-top-of-RTOS-but-the-timer-driver-calling-back-from-ISR" scenario can customize the mutex that protects the queue.
The one thing I'm not completely happy with is the need to call `{ embassy_time::queue::initialize() }` early on before any futures using embassy-time are polled, which is currently on the shoulders of the user. I'm open to any ideas where we can get rid of this and do it on the first call to `_embassy_time_schedule_wake`, without introducing very complex combinations of critical sections, atomics and whatnot.
Co-authored-by: ivmarkov <ivan.markov@gmail.com>
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
855: PDM microphone support for nrf r=Dirbaio a=pbert519
PDM microphones have a long startup phase, therefore the driver samples continuously and only switches the target buffer if the user requests sampling.
Co-authored-by: pbert <pbert@posteo.net>
This commit removes some of the code duplication for UarteWithIdle at the expense of requiring a split. As the example illustrates though, this expense seems worth the benefit in terms of maintenance, and the avoidance of copying over methods. My main motivation for this commit was actually due to the `event_endtx` method not having been copied across.
958: Implement proper `Drop` for `BufferedUarte` r=lulf a=ZoeyR
The drop method in `BufferedUarte` was prone to hanging indefinitely and also didn't actually disable the peripheral. I mostly copied over the drop method from `Uarte` with some modifications since `BufferedUarte` could have a transmit lasting indefinitely.
Co-authored-by: Zoey Riordan <zoey@dos.cafe>
936: Add split() method to BufferedUarte in embassy-nrf r=ZoeyR a=ZoeyR
I haven't completed testing this yet. I'm creating this PR early so that I can get corrected if I went way off course.
This PR adds a `split()` method to `BufferedUarte` as discussed on matrix.
Co-authored-by: Zoey Riordan <zoey@dos.cafe>
938: Do not use cfg_if for embedded-hal-async feature gates. r=Dirbaio a=Dirbaio
Old code used `cfg_if!` because rustc still parses code inside disabled cfg's, and Rust stable at that time couldn't parse the new GAT where-clause location. This is not the case anymore.
bors r+
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
Old code used `cfg_if!` because rustc still parses code inside disabled cfg's, and Rust stable at that time couldn't parse the new GAT where-clause location. This is not the case anymore.
Ensures that nRF saadc sampling is stopped and is awaited prior to exiting the two sampling methods. Not doing so causes a potential power drain and the potential for dropped buffer writes when having finished continuous sampling.
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.
- 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
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).
