> 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.
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>
- 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
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.
- 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
