- 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
- It disturbs other stuff that uses WFE/SEV in the system. I ran into
issues with this.
- It needs the irq handler to check for RXTO/TXSTOPPED errors, which makes
it slower.
Add type UarteWithIdle that implements Read, Write and ReadUntilIdle
traits. The type uses a timer + 2 PPI channels internally, triggered on
RTXSTARTED event.
Since introducing the ctx pointer, the handler is now two words, so setting it can
race with the interrupt firing. On race it's possible for the new handler to be
alled with the old ctx pointer or viceversa.
Rather than documenting this, it's better to split the function in two to make it
obvious to the user that it's not atomic. The user can use a critical section, or
disable/enable the interrupt to avoid races if this is a concern.
The `interrupt` package previously tried to be drop-in compatible with the
`interrupt` package from PACs. THis meant that there was both a PAC-style enum
value `UARTE0` and an embassy-style owned `UARTE0Interrupt` type. This made
things VERY confusing.
This drops compatibility with the PAC, improving the names for embassy interrupts.
Prevents a panic in the case of:
1. Abort a receive future
2. Free Uarte::free()
3. Uarte::new()
-> panicked at 'assertion failed: uarte.enable.read().enable().is_disabled()'
The PS does not specify how many cycles it takes for a STARTXX task to
generate a XXSTARTED event. I think it is instantaneous but let’s be on
the safe side for the following sequence:
1. poll() starttx
2. drop() txstarted not yet set, but future gets dropped
3. txstarted set by hardware, peripheral enabled after it was dropped
The STOPRX task always triggers a timeout of ~55bit times until the
RXTO event is generated. Before we disabled the receiver only after
the timeout.
With this change the receiver is stopped right after reception has ended
because the DMA buffer is full.
For forced RX aborts like `stop()` or on drop still need to wait for the
RXTO event before disabling the receiver.
