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.
