This was likely forgotten as part of c46418f12. Without this, when
creating a uarte instance, dropping it and then creating another
instance, this instance would never receive any bytes.
This implements SPIM TX workaround suggested from section 3.8.1
from Anomaly 109 addendum.
In workaround case we first keep track of original maxcnt values,
then initiate "fake" transfer with zero-length maxcnt values.
Once the "fake" transfer is triggered, we handle it, fill in the
original maxcnt values and restart the transmission.
- Move typelevel interrupts to a special-purpose mod: `embassy_xx::interrupt::typelevel`.
- Reexport the PAC interrupt enum in `embassy_xx::interrupt`.
This has a few advantages:
- The `embassy_xx::interrupt` module is now more "standard".
- It works with `cortex-m` functions for manipulating interrupts, for example.
- It works with RTIC.
- the interrupt enum allows holding value that can be "any interrupt at runtime", this can't be done with typelevel irqs.
- When "const-generics on enums" is stable, we can remove the typelevel interrupts without disruptive changes to `embassy_xx::interrupt`.
The regular one permanently requests HFCLK, while the low power one only does
so while counting, for 1 clock cycle. The regular mode is "deprecated" too.
1262: bump embedded-storage-async to 0.4 r=Dirbaio a=mehmetalianil
I just haven't found a way to revert the altered stm-metapac contents due to building.
Co-authored-by: Mehmet Ali Anil <mehmet@grusbv.com>
> dirbaio: so I was checking how zephyr does UARTE RX on nRF
> dirbaio: because currently we have the ugly "restart DMA on line idle to flush it" hack
> dirbaio: because according to the docs "For each byte received over the RXD line, an RXDRDY event will be generated. This event is likely to occur before the corresponding data has been transferred to Data RAM."
> dirbaio: so as I understood it, the only way to guarantee the data is actually transferred to RAM is to stop+restart DMA
> dirbaio: well, guess what?
> dirbaio: they just count RXDRDY's, and process that amount of data without restarting DMA
> dirbaio: with a timer configured as counter https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/serial/uart_nrfx_uarte.c#L650-L692
> dirbaio: 🤔🤷⁉️
> dirbaio: someone saying you can do the "hook up rxdrdy to a counter" trick, someone else saying it's wrong 🤪https://devzone.nordicsemi.com/f/nordic-q-a/28420/uarte-in-circular-mode
So we're going to do just that!
- BufferedUarte is lock-free now. No PeripheralMutex.
- The "restart DMA on line idle to flush it" hack is GONE. This means
- It'll work correctly without RTS/CTS now.
- It'll have better throughput when using RTS/CTS.
The UARTETWISPIn naming is quite horrible. With the nRF53, Nordic realized this
and renamed the interrupts to SERIALn. Let's copy that for our peripheral names, in nrf53 and nrf91.
If the user requests some configuration, but UICR is already programmed
to something else, detect this and warn the user.
We don't do it for the debug port settings, because if they are wrong
then the user will simply not be able to read debug logs.
- APPROTECT enable/disable. Notably this fixes issues with nrf52-rev3 and nrf53 from locking itself at reset.
- Use NFC pins as GPIO.
- Use RESET pin as GPIO.
NFC and RESET pins singletons are made available only when usable as GPIO,
for compile-time checking.
Obtaining the current WDT config is important so that we do not have to duplication configuration around the place. A constructor method has been introduced that returns WDT config in accordance with how the register is presently configured. The bootloader example has also been updated to show the watchdog can be obtained and used.
It's a perfectly fine thing to do, should be just a noop. Erroring is
really annoying when you're writing a payload to uart that might
be zero-length or not.
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>
